How Pocket works

What is Pocket

Pocket is a trading layer for AI agents on BNB Chain. Connect your agent, set its conditions and stay private.

The pool contract holds custody and checks Groth16 proofs of valid note transitions. Spending proofs hide which notes are consumed. Direct transaction senders, deposits, trading amounts and withdrawals remain visible on-chain.

Quickstart

Everything below happens in the web app. There's nothing to install.

1. 1
   Sign in
   Open the app and sign in with your wallet. Signing a message proves it's you; it sends no transaction.
2. 2
   Create an allocation
   Set a budget, the tokens your agent may trade, its percentage choices and whether you approve each trade. Each allocation gets its own wallet.
3. 3
   Fund and shield
   Send BNB or USDT to the allocation's wallet address on BNB Smart Chain, then shield it. The protocol fee is 0.5%; keep a little public BNB for gas.
4. 4
   Connect your agent
   In Connections, pick the app your agent lives in: ChatGPT, Claude Code, Grok, Cursor, Muse, WeChat, any MCP app or your own code.
5. 5
   Trade or pay
   Review a PancakeSwap quote and confirm the trade, or paste a Pocket receiving address to send a shielded payment. The recipient can recover and spend its note.
6. 6
   Withdraw and review
   Withdraw to the wallet’s public address, inspect Activity, edit permissions or revoke the agent’s access.

What is private

Notes keep their contents encrypted. The current agent service submits transactions directly from each wallet, so its public sender and transaction timing remain visible. The owner service holds the keys and can read its managed wallets.

On a swap, the sender, pair, amounts, executor, nullifiers and timing are public. Pocket Pay publishes commitments, nullifiers and encrypted receipts without a public token payout. It does not hide the transaction sender.

Pocket for agents

Give an agent a wallet with encrypted notes and a scoped access key. The owner service checks its token budgets, allowed actions, slippage, expiry and revocation before authorizing an operation.

Connecting an agent

Pocket doesn't build or host agents. You connect the one you already run: give it a label in the app, choose its rules, and get an access key shown once. The key identifies that agent. It is not your spending key and can't move anything outside the rules.

Connect over MCP

In Blind mode your agent reaches Pocket through a remote MCP server. There is nothing to install on your side, and the agent never sees balances or amounts.

1. 1
   Create an access key
   Open an active allocation, go to Connections, name your agent and create its external access key. The key is shown once.
2. 2
   Add Pocket to your agent
   In Claude Code, copy the one-line setup command. In Cursor, download the settings file. In any other MCP app, choose Streamable HTTP, paste the MCP server URL and put the key in its bearer token field.
3. 3
   Give it the skill
   Optional. Download the Blind agent skill and drop it into your agent's skills folder. It explains percentages, approvals and safe retries, and holds no keys.
4. 4
   Ask for a trade
   Your agent reads its choices, asks for something like "buy BNB with 5%", and the exact trade waits in Approvals for you.

Full access tools

The JavaScript SDK exposes the same operations. Persist a unique request ID before each money operation and reuse it for retries.

Permissions

The owner service enforces these rules. Limits apply per credential, including reserved amounts for pending operations.

1. 1
   Active and unexpired
   A revoked or expired credential cannot authorize operations. Revocation is permanent.
2. 2
   Allowed action and tokens
   Shielding, quoting, trading, payments and withdrawals are enabled separately. Both trade assets must be allowed.
3. 3
   Allowed recipient
   An optional Pocket Pay allowlist restricts payments to exact receiving addresses.
4. 4
   Slippage within cap
   The requested trade slippage must fit the configured basis-point limit.
5. 5
   Within token budgets
   Each asset has a per-action cap and a day, week or lifetime budget, measured in exact token amounts.
6. 6
   Within gas budget
   A separate BNB allowance limits total gas and the maximum cost of one transaction.

Where rules are enforced

Pocket keeps wallet keys in the owner service’s encrypted vault and gives agents scoped credentials. These are service-enforced permissions; the operator and host remain trusted. An owner can create separate wallets or assign credentials to an existing wallet.

Pocket Pay

Pocket Pay sends a recipient-owned note within the pool. Share the receiving address from the app, paste it into Pocket Pay, choose a token and amount, and submit. The recipient recovers the note from encrypted events and can pay onward, trade or withdraw.

A separate transfer circuit checks ownership, membership and conservation. A payment consumes up to two notes and produces a recipient note plus optional sender change. It moves no public assets and charges no additional protocol fee. Amount, asset and recipient remain private inputs; the transaction sender and timing remain public. Receiving addresses belong to one chain and pool.

Notes

A note is a private record that says "this owner has this much of this asset in this pool". Your balance is the sum of your unspent notes. Notes are never edited: spending one burns it and creates new ones.

The pool stores only a commitment, a Poseidon hash of all the note's fields. Two random values, rho and blinding, make every commitment unique and unguessable even for identical amounts.

Alongside the commitment, the pool emits the note encrypted to your viewing key: a 401-byte ciphertext sealed with HPKE (X25519, HKDF-SHA256, ChaCha20-Poly1305). Anyone can see it. Only you can open it.

The note tree

Every new commitment becomes a leaf in a Poseidon Merkle tree with 32 levels, room for about 4.3 billion notes. Each insert produces a new root.

To spend, you prove your note is a leaf under some root the pool has recorded, without saying which leaf. Pocket keeps every root for the life of the pool, so notes created at different times can be spent together, each with its own membership path.

Nullifiers

When you spend a note you reveal its nullifier, a Poseidon hash of the chain, pool, the note's rho and your spend secret. The pool marks it as burned. Trying to spend the same note again reveals the same nullifier and is rejected with InvalidSpend.

Without your spend secret, nobody can link a nullifier back to the commitment it came from, so the chain sees that some note was spent but not which one.

Keys

Pocket gives you two independent keys, generated in your browser.

The two are generated separately on purpose, and backups refuse to export them if they are identical. Your connected wallet is still the note owner: deposits bind it, and withdrawals pay it.

Proofs

Each action has its own Groth16 circuit on the BN254 curve, written as readable Circom sources in Pocket v2. Your wallet software, the browser or the owner service, generates the proof, and a verifier contract checks it on-chain. What a proof binds is listed below. Change any of it after proving, and verification fails.

Binding the chain and pool means a proof can't be replayed anywhere else. Binding the ciphertext hash means nobody can swap your encrypted output for one sealed to them.

Shield

Shielding moves tokens from your wallet into the pool and gives you a private note.

1. 1
   Create and seal the note
   Your browser picks fresh randomness, derives a spend secret and encrypts the note to your viewing key.
2. 2
   Prove the deposit
   The proof binds the chain, pool, your address, the asset, the net amount and the commitment.
3. 3
   Get an admission
   You sign the deposit request. The pool owner's admission service checks it against its policy and returns an approval valid for at most 5 minutes, tied to this exact commitment and ciphertext.
4. 4
   Submit
   The pool checks the proof, consumes the approval, and for tokens confirms that exactly the stated amount arrived. Then the note is inserted.

Swap

Swaps happen inside the pool. You spend notes in one asset and receive a note in another, without revealing which notes were spent. The pair, the amounts and the sending wallet are public.

1. 1
   Get a quote
   Pocket reads PancakeSwap V2 reserves and returns an exact-input quote within your slippage tolerance, through BNB directly or one hop via WBNB. Agent quotes expire within 60 seconds.
2. 2
   Prove the trade
   Your browser proves you own one or two notes covering the sell amount and describes up to two outputs: the bought asset and your change.
3. 3
   Settle atomically
   The pool sends the sell amount to Pocket's PancakeSwap executor, which must return exactly the quoted buy amount. If reserves moved or anything else is off, the whole trade reverts, nullifiers included.

Withdraw

Withdrawing spends one or two of your notes and sends tokens to the note owner, the wallet you deposited from. If the notes are worth more than you take out, the rest comes back as one change note.

• No fee on withdrawals.
• Works while the pool is paused and after an asset is disabled. Exits never check the pause flag.
• The proof reveals the owner, asset and amount, but not which notes were spent.

Fees

One flat protocol fee of 50 basis points, rounded down: the fee on an amount is that amount divided by 200, ignoring the remainder.

Fees sit in a separate reserve per asset. The treasury can claim that reserve and nothing else. After every action the pool holds exactly what it owes notes plus the fees it earned.

Deposit admission

Deposits need an admission: a signature from the pool owner's admission signer saying this wallet may make this exact deposit. Admission only ever applies to deposits. Trades, withdrawals and Pocket Pay on existing notes don't need it.

• You sign the request with the depositing wallet, so nobody can request admission on your behalf.
• Approvals last at most 5 minutes and are tied to the pool, your address, the asset, the amounts, the commitment and the ciphertext hash.
• Each approval works once. Replays revert with InvalidAdmission.
• A denial or review only blocks that deposit. It never touches existing notes or withdrawals.

Changing the signer or policy is one configuration call on the admission contract, with no redeploy.

Backup and recovery

You can get your notes back two ways.

Encrypted backup file

The Keys card exports your viewing and spending keys sealed with a passphrase of at least 12 characters, using AES-256-GCM and a key derived with PBKDF2-SHA256 over at least 600,000 iterations. Without the passphrase the file is useless.

Rescanning the chain

With your viewing key, Pocket reads every NoteCreated event, tries to decrypt each one, and rebuilds your notes and their Merkle paths. Your spending key then re-derives each note's spend secret and checks it against the commitment.

Guarantees

The pool rejects forged proofs, double spends, replays across chains or pools, altered ciphertexts, stale quotes, expired or reused admissions, lying tokens and underpaying solvers. Each one is a specific check in the contract.

Watch them fail live in the attack console, along with the transactions from the latest end-to-end run that actually mined and reverted them.

Governance powers

Governance is deliberately narrow.

It can

• Enable or disable assets for deposits and trading.
• Pause deposits and trading.
• Change the deposit admission signer and policy.

It cannot

• Move or freeze anyone's notes.
• Stop withdrawals, even while paused.
• Take anything beyond the fee reserve.

Limits

FAQ

Glossary