How Pakana works

Pakana is a split-architecture private payments infrastructure on Stellar. Verification happens on one side. Public access happens on the other. They do not share a surface.

The split: Primary and Satellite

One-way replication (read-only)

Stellar Ledger

On-chain BN254/Poseidon proof verification. Protocol 25 primitives. Permanently auditable without Pakana cooperation.

A private payment, step by step

  1. A client or agent prepares a private-payment action. Stealth address derivation happens client-side.
  2. Proof generation runs off-chain — including browser-prover paths. No payment detail touches a Pakana server before verification.
  3. The Primary verifier receives and verifies the proof. Authoritative state is updated. No public API is exposed at this layer.
  4. Replicated state is available through the Satellite for dashboards, app integrations, and agent runtimes.

Protocol 25 verification primitives

BN254 elliptic curve
The curve used for Groth16 proof generation and verification. Supported natively in Stellar Protocol 25 host functions.
Poseidon hash function
ZK-friendly hash used in the payment circuit. Runs efficiently inside the BN254 constraint system.
Groth16 proof system
The proving system used for private-payment verification. Proofs are compact and fast to verify on-chain.

No custody. No pooled funds.

Pakana does not hold, pool, or have discretionary access to user funds at any layer. The verification workflow is designed so that proof, state, and payment settlement flow through protocol-layer mechanisms, not through a centralized operator account.

On-chain evidence

Satellite ledger, Stellar ledger, replication lag, and contracts deployed.

Read the integration path

If you are building on Pakana, the developer page covers the Satellite API surface, endpoint structure, and how to integrate without touching the Primary.