poro

x402 made it possible for an agent to buy an API call with no account, no key, and no subscription. What it did not bring is any way to govern that spending. An agent with a funded wallet calls a priced endpoint as many times as its loop tells it to, and the operator finds out afterwards by reading the wallet.

Three things are missing at once. There is no budget, so nothing stops the tenth call after the ninth was already wasteful. There is no record — a wallet shows transfers, not what was bought or why. And there is no brake: when spending goes wrong, the only remedy is to kill the process and drain the key.

The gap is not hypothetical. This hackathon alone produced roughly ten priced World Cup endpoints and nothing on the buying side. Every one of them assumes an agent holding a wallet and exercising unlimited discretion, which is exactly the assumption that stops being safe the moment the amounts matter. Poro is the buying side.

How a purchase works. The agent asks Poro to buy. Poro guards the destination before a byte leaves the process — https only, no private or loopback addresses, no cross-host redirects, so a prompt-injected agent cannot make it pay a cloud metadata endpoint. It then probes the endpoint unpaid and reads the price out of the HTTP 402. That gap between quote and payment is the whole product: it is where a budget can be enforced. Below the threshold and inside the budget, Poro pays and the agent never notices there was a decision. At or above the threshold, it returns the quote and waits for a human. Over budget, it refuses and names the shortfall, so the agent can ask for the right amount instead of guessing or retrying.

Payment is an EIP-3009 USDC authorization, with the request replayed byte-identically under a PAYMENT-SIGNATURE header, so a body-priced endpoint quotes against the request it settles. The agent never holds a key, never sees the authorization, and cannot approve its own spending.

Approval is what makes it an allowance rather than a cap. A spending cap can only ever say no. Poro asks. And on approval it re-quotes before paying — the 402's validity window is measured in seconds while human approval takes minutes, so paying against the original quote would let a seller quote low, wait for the approval-shaped retry, and re-quote high. Poro pays only at or below what the operator approved.

Settlement is judged against the chain, never the seller's word. A purchase counts as settled only when the endpoint reports success and names a transaction. Anything less — a missing header, a malformed one, no response at all — parks the purchase and holds the funds, because once the payment header went out the seller holds a submittable authorization. A bounded scan for the AuthorizationUsed log then decides against the chain. This is not theoretical caution: during testing a third-party seller reported failure twice on purchases that had both already settled on chain, and only that reconciler kept the ledger correct.

Every completed purchase writes a receipt naming the endpoint, what was requested, the price, the time, and the Injective transaction that settled it. A judge can take any line to a public explorer and confirm it without access to Poro at all.

The four technologies, each load-bearing. x402 supplies the price before payment — remove it and there is nothing to enforce a budget against. CCTP refills an exhausted allowance from Base Sepolia, gated so the agent must ask and only an operator can approve; without it a refused agent stays refused. An MCP server is the agent's only interface: five tools, and none of them can approve spending — the literal reading of "expose approval as a tool" would let an agent approve its own purchases and empty the whole design of meaning. A bundled Agent Skill teaches the working loop and, more importantly, the refusal behaviour: ask for a top-up or stop, never retry, which is the difference between a graceful stop and a crash loop.

World Cup 2026 data. A bundled kiosk serves the tournament record — 104 matches, 48 teams — behind x402, in four priced claim types deliberately straddling the approval threshold: match result (0.01 USDC), head-to-head (0.02), a team's full tournament path (0.05, exactly at the threshold), and top scorers (0.12). That ladder is what lets a single run show an uninterrupted purchase, an approval, and a refusal.

Proof. Seven transactions on Injective testnet back the README, all independently verified: an uninterrupted purchase, an approved purchase that re-quoted first, a purchase recovered by the reconciler after the seller lost the response, a complete CCTP transfer from Base Sepolia burn through Injective mint, and two settlements against another team's x402 seller — a different codebase using the official Express middleware, paid to their address, with nothing in Poro's executor changed to make it work.

Building it against real funded wallets also surfaced a defect worth reporting: the Injective testnet RPC shipped in the x402 network registry answers eth_call and eth_blockNumber but returns null for eth_getTransactionReceipt on transactions that demonstrably exist. A facilitator waiting on that receipt reports settlement failure for payments that already succeeded — the buyer is charged and gets no data. It is documented in the README, and it was independently reproduced in another hackathon project using the same endpoint.

What Poro deliberately is not. No smart contract: the allowance is enforced in custody, because a contract would be a second place for the budget to live and a second thing to keep in sync. Not a seller — the bundled kiosk exists only so the demo has something real to buy. Not a wallet interface, and not a marketplace.

Built entirely during the hackathon, from an empty repository on 23 July to a working system on 26 July.

Day one: workspace, three funded wallets, and the World Cup kiosk behind x402. Day two: the SQLite ledger with cross-process reservations, the purchase executor, the settling reconciler, and the approval queue. Day three: CCTP top-up, the MCP server, the Agent Skill, the demo, the landing page and the demo video.

The last day was spent proving it against funded wallets rather than fixtures, which is where the real defects surfaced. Three were found and fixed: the Injective RPC named in the x402 registry never returns transaction receipts, so a facilitator reports settlement failure for payments that already settled; the paid retry timed out before a seller could answer; and the test runner silently skipped every live gate. Two requirements the plan allowed to ship unmet were then closed with evidence — a full CCTP transfer, and two settlements against another team's x402 seller.

Seven transactions on Injective testnet back the claims in the README, each verifiable on a public explorer.

no fundraising