Split-brain architecture explainer

How Pakana verifies private payments without ever taking custody of funds.

Pakana separates private verification from public API access. The API-dark Primary Node performs verification work, while the read-only Satellite Node serves dashboard and API responses from replicated ledger state.

Primary/Satellite split

Primary Node: authoritative verifier, no public HTTP surface, and never directly exposed to internet traffic. It ingests payment-proof events and commits verified state.

Satellite Node: read-only replica that exposes API endpoints and dashboard views over live ledger-backed data. Satellites cannot mutate canonical verification state and cannot grant fund control.

This split-brain design keeps the trust-critical verifier API-dark while still giving integrators and users a fast public interface.

ZK proof flow (high-level)

  1. Payment intent: the sender prepares the payment intent and transaction details locally.
  2. Proof generation: the sender generates a zero-knowledge proof locally using BN254/Poseidon primitives.
  3. On-chain verification: the proof is submitted for verification on Soroban, where Stellar Protocol 25 ZK primitives act as the verification layer.
  4. Satellite confirmation: Satellite reads the resulting on-chain ledger state and confirms verified status through its read-only API and dashboard.

Architecture diagram

Primary Node verifies with Soroban and replicates state to read-only Satellite Node for confirmations.

Non-custodial invariant

No pooled custody

Pakana never pools, holds, or discretionary-controls user funds. Keys and proof artifacts stay with the sender, and fund movement remains a user-to-recipient ledger action. Pakana's role is verification and replication, not custody.

Continue exploring

For integration details, visit /developers. For agent-facing surfaces, visit /agents.