Pocket

Demo

About

Everyone who has handed a task to an AI agent has had the same small moment of hesitation. You are about to let it run on its own, and somewhere in the back of your mind is the question: what if it doesn't stop? We are comfortable letting agents write code, book things, and read half the internet. We are not comfortable handing one a credit card. And that is the thing standing between where agents are now and where they are obviously going, because almost everything useful an agent needs is sold per call. Search results, market data, compute, other agents' output. Someone has to pay for it, and right now the only options are to do it yourself in advance or to give the agent your card and hope. Pocket is the third option. Give the agent its own wallet and a limit it cannot raise. WHAT THAT LOOKS LIKE → You create an agent in a dashboard and you set the rules in plain terms. How much it can spend a day. How much on any one purchase. How much on a particular job. Who it is allowed to pay. And the amount above which you want to approve things yourself. → Then you let it go. Every time it tries to buy something, Pocket checks the purchase against those rules before any money moves. If it passes, the payment goes through in about a second and nobody is interrupted. If it fails, the purchase is refused and written down along with the exact rule that stopped it, so you are never left guessing why your agent did not do something. → The agent cannot change any of this. It does not hold the key to its own wallet, and it cannot raise its own limit. Those are set by you, and the agent only ever spends against them. The limit is not a suggestion it agrees to follow. It is a wall. And everything is written down. Every purchase, every refusal, every change you make, in a record that cannot be edited after the fact. If you want to know what your agents spent last week and why, the answer is one page. HOW IT IS PUT TOGETHER → Agents pay sellers using x402, an open payment standard that lets a website charge for a single request without the buyer ever opening an account or holding an API key. It is what makes an agent buying one search result for one cent actually practical. We built Pocket to sit inside that exchange: the seller names its price, Pocket decides whether that money may be spent, and only then is anything signed. → The wallets are held by Privy, so no private key ever touches our servers. We also set a second, independent limit inside Privy itself, which means even if Pocket were compromised, the wallet would still refuse to overspend. → Payments settle on Hedera, which is fast and cheap enough that buying something for one cent is not absurd, and every settled payment links out to a public block explorer so any number on the screen can be checked against the chain. → The Graph prices the limits you set in dollars. We deliberately ask two independent Graph sources for every price and require them to agree. If they disagree, Pocket refuses the purchase rather than guessing, because a limit enforced with a wrong price is not a limit. → Agents connect through MCP, the standard Claude and other assistants already use for tools. There are eight of them (tools), and only one can actually spend money. The other seven let an agent check what it is allowed to do before it tries, so it can ask "would this be approved?" without moving anything. TRY IT 1. Dashboard: https://www.pocket-app.xyz 2. Documentation: https://docs.pocket-app.xyz/docs 3. API: https://api.pocket-app.xyz 4. MCP server: https://mcp.pocket-app.xyz 5. An example seller, with six live data feeds priced from one cent to seventy-five: https://pay.pocket-app.xyz That last one is worth a click. It is a genuinely separate business that knows nothing about Pocket and has no account with the buyer. It states a price, gets paid, and serves the data. We built it so the demo is a real purchase from a real counterparty rather than Pocket paying itself. How the whole exchange works: https://docs.pocket-app.xyz/docs/how-it-works

How it's made

WHERE THIS STARTED Making an agent spend money took an afternoon. Making it refuse to took the rest of the build. That is the honest summary. The happy path here is genuinely easy: a seller asks for payment, a wallet signs, the data comes back. The hard part, and the only part that matters, is everything that has to be true before the wallet is ever asked. So we built the refusal first. The very first thing that worked was an engine that said no and explained itself, with nothing behind it that could actually pay. Spending came later. See: https://docs.pocket-app.xyz/docs/how-it-works THE SPINE Every purchase runs as a single call, in a fixed order that never varies. → Read the seller's 402 terms. Price it, if the limit is written in dollars. Check it against the daily budget, the task budget, the per-transaction cap, the recipient list and the category rules. Ask for a signature, but only if every check passed. Settle. Record the outcome either way. → The order is not an implementation detail, it is the product. Nothing is signed before the decision, so a refused payment leaves no signature lying around for a later request to replay. And the agent never holds a payload of its own, so there is no policy step for it to skip. WHAT THAT TURNED INTO 1. Dashboard (https://www.pocket-app.xyz), where a human sets the limits and reads the record. Signing in starts a setup guide that takes you from an empty organization to an agent that has bought its own data. 2. API (https://api.pocket-app.xyz), the decision, the ledger and the audit trail across 35 endpoints. Open the root and it describes itself: every endpoint, which vendor is answering for each slot, and which build is running. 3. MCP server (https://mcp.pocket-app.xyz), how an agent actually reaches Pocket. The root lists the transport, the credential it wants, and all eight tools with whether each one can spend. 4. Example seller (https://pay.pocket-app.xyz/catalog), an x402 business we built specifically so we would have someone real to pay. Its catalogue is public and quotes every price without charging. 5. Documentation (https://docs.pocket-app.xyz/docs), with screenshots of every screen and every state, refusals included. That fourth one deserves a sentence. We could have faked the seller. We built it as a genuinely independent service with six live data feeds instead, because a payments demo where both sides are yours proves nothing. 1) PRIVY (https://docs.pocket-app.xyz/docs/stack/privy) Privy custodies every agent wallet, so no private key ever touches our servers. The same application also signs operators into the dashboard, which saved us building a second identity system. The part we are proud of is that we did not trust our own engine alone. When a wallet is created, Pocket installs a Privy-side policy capping transfer value and denying key export. That is a second ceiling underneath the first: if Pocket itself were compromised, Privy would still refuse the transaction. One lock is a single point of failure, and this is money. 2) HEDERA (https://docs.pocket-app.xyz/docs/stack/hedera) Payments settle on Hedera through the x402 exact scheme and a facilitator. Hedera earned its place by being cheap and fast enough that buying something for one cent is not absurd, which is the entire premise of paying per call. Every settled payment carries a public explorer link, so any number on the dashboard can be checked against the chain. 3) THE GRAPH (https://docs.pocket-app.xyz/docs/stack/the-graph) Two jobs, and only one of them needed keys. (i) Pricing came from a problem we did not see at first. A limit written in tokens is not a limit on money: an agent allowed two HBAR is allowed unbounded value if HBAR moves. So dollar ceilings are priced by two Graph products that check each other, the hosted Token API and a subgraph on the decentralized gateway. If they disagree beyond a tolerance, or if fewer than two answer, Pocket returns no price and denies the purchase. It never guesses. A price feed that decides whether money moves should not be one thing that can be wrong. (ii) Reconciliation needed no keys at all, because The Graph does not support Hedera and there was no endpoint to paste. So we ship our own subgraph and Graph Node setup that indexes transfers, and Pocket checks its own ledger against what actually settled on chain. 4) MCP (https://mcp.pocket-app.xyz) Eight tools, and exactly one can spend. The other seven exist so an agent can find out what it is allowed to do before it tries, including a preview that returns the real decision without moving anything. The server holds no credential of its own: every caller brings its own key, which is what stops a hosted endpoint becoming an open door onto someone else's agents. THE HACKY BITS → x402 on Hedera addresses accounts by native ID, but wallets are provisioned by EVM address. Rather than have someone paste the ID into config and get it wrong, the seller looks up its own payee through the mirror node at startup. → The seller warms every feed before it opens its port. A feed whose upstream is unreachable is simply not offered, because nothing should quote a price for something it cannot deliver. Stale data is served and labelled stale rather than failing a request somebody already paid for. → 686 tests, including the policy engine against every refusal path and the API against a real database rather than a mock.