Pakana is payment infrastructure, not a custodian. No layer of the protocol holds, pools, or transmits user funds on a discretionary basis. Zero-knowledge proofs are posted on-chain and independently verifiable by any compliance team — without accessing underlying payment details.
Pakana does not custody user funds at any layer of the protocol stack. Payments move directly between counterparties as native Stellar ClaimableBalances sent to stealth addresses. Neither the Pakana Node, the PakanaTracker Soroban contract, nor any Satellite endpoint ever holds an asset on behalf of a user.
The protocol's only function at settlement is mathematical verification: confirming that a submitted zero-knowledge proof is valid before downstream state is updated. Asset movement is entirely controlled by Stellar's native consensus — the protocol never intermediates it.
No component in the Pakana stack has discretionary control over user funds at any point. There is no omnibus account, no pooled float, no exchange function, and no mechanism by which the protocol could direct or restrict a user's assets. This is a structural property of the architecture, not a policy election.
Every verified transaction leaves a cryptographic record on the Stellar ledger that compliance teams can inspect without accessing payment details.
When a sender submits a Groth16/BN254 zero-knowledge proof to the PakanaTracker contract, the verification result is recorded as an on-chain Soroban event. The proof demonstrates — without revealing — that the underlying payment was correctly constructed: the correct amount, to the correct stealth address, by an authorized sender.
Compliance teams and auditors can independently verify any proof on the Stellar ledger using the contract's public verification key. Verification requires no privileged access to Pakana infrastructure and no cooperation from any counterparty. The chain is the audit log.
Each submitted proof and its verification result are permanently recorded as Soroban contract events on the Stellar ledger. The ledger is immutable and publicly accessible via Stellar Horizon.
ZK proofs confirm transaction validity — amount, sender authorization, recipient stealth address — without revealing the underlying values to any party inspecting the ledger.
Any party with access to Stellar Horizon can verify a proof against the PakanaTracker contract's public verification key. No cooperation from Pakana is required to confirm a transaction occurred.
The Pakana Node runs as a Primary–Satellite system. The Primary Node has no inbound public HTTP and performs all ZK proof ingestion and verification. Satellite Nodes are read-only replicas that expose the developer API and dashboard. Neither node controls funds in any form.
| Component | Role | Custody or fund control |
|---|---|---|
| Primary Node | Ingests Stellar events, submits ZK proofs to PakanaTracker, replicates verified state to Satellites | None — no asset access at any point |
| PakanaTracker (Soroban) | On-chain ZK verifier; records proof validity as contract events | None — verifies math only, cannot move assets |
| Satellite Node | Read-only replica; exposes public API and verification dashboard | None — read-only access to verified state |
| Fee-bumping relayer | Submits user proofs to Stellar without requiring user to hold XLM | None — relays transactions, cannot access payment assets |
| Stellar Network | Settlement and finality of ClaimableBalances between counterparties | Governed by Stellar validators; Pakana is not a validator |
The split-brain design means that the verification pathway (Primary → PakanaTracker) is isolated from public API access. There is no path by which an API consumer can influence the authoritative verification state or introduce custody at the protocol level.
Pakana's compliance properties are enforced at the cryptographic and consensus layer, not by policy or contractual commitment alone. The following properties hold by construction of the protocol:
On-chain ZK verification uses Stellar Protocol 25's native BN254 elliptic curve host functions. Proof verification is performed by Stellar validators as part of consensus — it is not delegated to any Pakana server and cannot be bypassed by any party.
Groth16 proofs are constant-size and verifiable by any party holding the circuit's verifying key. A proof that verifies on-chain cannot be forged. A transaction that does not have a valid proof cannot be accepted by the PakanaTracker contract.
Recipients are identified by stealth addresses derived client-side from a shared secret. No mapping between a stealth address and a real-world identity is recorded on-chain or stored by the protocol. Compliance teams access this mapping only via the recipient's own viewing key.
This page describes Pakana's architectural and protocol design as it relates to custody and auditability. It does not constitute legal advice, regulatory guidance, or an opinion on how applicable law classifies Pakana's activities in any jurisdiction. Organizations subject to specific regulatory obligations should seek independent counsel.
These properties hold by construction of the protocol stack, not by policy election.
Compliance and risk teams can request a detailed technical overview of Pakana's architecture, on-chain proof structure, and custody separation. No commitment required.