Autonomous agents pay for APIs, compute, and data feeds across sessions. Every on-chain payment leaks: amount, address, timing, frequency. An observer can reconstruct your agent's entire activity graph from public ledger data. Pakana's rails eliminate that exposure — ZK-shielded amounts, stealth addresses, no cross-session linkability.
A human reviewing a wallet can tolerate some payment history visibility. An autonomous agent running across hundreds of sessions cannot. Every payment from a known agent address is a data point: which APIs it calls, how often, at what cost, in what sequence. Payment history is a behavioral fingerprint.
Standard Stellar payments leave full amount and address visibility on the public ledger. Wrapping payments in an agent loop doesn't help — the ledger sees every XLM or token transfer regardless of what called it. The problem is at the protocol layer, not the application layer.
An agent making 200 micropayments per session across 50 sessions has made 10,000 on-chain attributable actions. Without shielding, those actions can be correlated, clustered, and sold. Pakana shields each payment at the proof layer before it touches the ledger.
Non-custodial, ZK private, and Soroban-native — each one load-bearing for agent deployments.
Pakana never pools agent funds. The agent generates its own spending keypair, holds its own balance, and signs its own transactions. There is no custodial intermediary that can freeze, censor, or misappropriate agent funds. The protocol routes and shields; it never holds.
Every payment generates a Groth16 ZK proof. The proof attests to the validity of the transfer — correct balance, authorized sender — without revealing the payment amount or the recipient's canonical address. What hits the Stellar ledger is a verified proof and a stealth address, not a traceable transfer.
Payment verification runs inside the PakanaTracker Soroban contract. Any other Soroban contract can call into PakanaTracker to gate behavior on verified payment proofs — no off-chain oracle needed. Agents can trigger contract logic that requires confirmed private payment as a precondition.
Each payment uses a fresh stealth address derived from the recipient's view key. An observer watching the ledger sees independent transactions with no shared address, no shared amount pattern, and no linkable metadata. Cross-session correlation is broken at the cryptographic level.
Pakana separates the public-facing API from the verification layer. Agents interact exclusively with Satellite Nodes over HTTPS. The Primary Node, which verifies ZK proofs and maintains canonical protocol state, is intentionally not reachable from the public internet — and therefore not reachable from the agent runtime.
| Component | Agent's view | What it does |
|---|---|---|
| Satellite Node | HTTPS API endpoint | Accepts payment requests, generates ZK proofs, submits to Soroban, returns receipt |
| Primary Node | Not directly reachable | Verifies proofs, maintains canonical state, replicates to Satellites via mTLS |
| PakanaTracker | Soroban contract address | On-chain proof verification using Stellar Protocol 25 BN254 host functions |
Keeping the Primary Node off the public internet means there is no API endpoint an agent (or attacker) can probe, enumerate, or exhaust. The Satellite handles all agent-facing traffic. The Primary's only job is verification — and it receives proof bundles from Satellites over authenticated mTLS, not from untrusted agent runtimes.
One POST to the Satellite API. The proof generation, submission, and receipt are handled server-side.
The agent_session_id field is never written to the ledger. It is used only for local receipt
matching on the agent side. The on-chain footprint is a verified proof and a one-time stealth address — no
session identifier, no canonical agent address, no payment amount in the clear.
The Satellite API, SDK reference, and Soroban contract addresses are in the developer docs. API access is invite-gated during the current alpha.