Cordon
Cordon helps AI teams balance performance and cost within a shared budget
About
1. The problem AI agents can decide which tools to call, repeat failed requests, and delegate work to other agents. That flexibility makes their costs difficult to predict. A user may approve a task expecting a useful result, only to discover that the agents have spent the budget collecting information without completing the final output. There is evidence that unexpected agent costs are a real engineering problem. A June 2026 research preprint catalogues 63 reported production budget-overrun incidents across 21 orchestration frameworks, including failures involving delegated work. This evidence concerns broader agent computation and orchestration costs rather than specifically Circle marketplace payments, but it illustrates the financial consequences of poorly coordinated autonomous activity. Source: https://arxiv.org/abs/2606.04056 Delegation adds a coordination problem. If workers receive independent allowances without a shared total check, their combined purchases can exceed the owner’s intended task budget. And a limit written per wallet cannot express the rule that matters once work is delegated: a purchase made a few delegations down still counts against what the person at the top signed. A worker that spawns a helper expands the number of keys, and every new key is a new allowance the owner never sized. Existing spending controls provide an essential foundation. Circle Agent Wallets, for example, document per-transaction, daily, weekly, and monthly limits, along with recipient restrictions. Cordon builds on that foundation: it adds a shared tree on top of per-wallet controls, so delegation narrows the owner’s budget instead of bypassing it. Source: https://developers.circle.com/agent-stack/agent-wallets/wallet-operations/custom-policies A second, less visible problem sits on the seller side. To a paid service, a buyer is an address, and an address is free — so a seller cannot tell a bounded agent from a script. Independent reputation data shows how poor the signal is: on Base, 90.6% of reviewers in the shared agent-reputation registry are Sybil-flagged, and 98.7–100% of feedback carries no payment or task behind it. A seller has no way to ask, before serving, whether the buyer in front of it is bounded and accountable. Source: https://arxiv.org/abs/2606.26028 2. What Cordon is and how it helps Cordon is an on-chain budget tree for AI agents, used through a Model Context Protocol (MCP) server and an SDK. One owner signs one mandate and funds one vault; every agent under it draws from that vault inside the bounds the owner set. A tree that only narrows. Agents are spawned beneath the mandate, each strictly narrower than its parent on every axis. The registry refuses a wider child whoever asks, including the owner, so no per-spawn approval is needed. Ancestor debit. Every purchase is charged to the agent that asked and to every ancestor up to the owner. This is the bound no per-wallet limit carries: a purchase made three delegations down still counts against the root. The agent holds no key. Its only tool takes a URL; there is no tool that names a recipient or an amount, and there never will be. A daemon holds the operator key and asks the contract before any money exists. A refusal is a transaction, not an error. The contract returns rather than reverts, so the refusal stays on chain and is published to the ERC-8004 Reputation Registry, naming the draw that produced it. It also consumes no budget. Readable by anyone. Every agent has an ENSv2 name whose records — cordon.live, cordon.headroom, cordon.boundBy — are computed from the contracts at resolve time, not stored. A seller can check a buyer with any ENS library, no account and no permission from us. The owner can also release one refusal (a signed exception) or cut a branch. What is live today (testnet — Ethereum Sepolia and Arc): three contracts and a settlement rail on each chain, an MCP server on npm (cordon-mcp), a seller SDK (@cordon/verify), a console for the owner’s actions, a public name-resolve page, a real settled purchase read back from chain, and a hostile drill whose result is published whichever way it came out. What is next. Today a refusal tells an agent no with a reason. Our next step is to help agents use that feedback: choose a cheaper service, reuse information they already have, avoid retries that will be refused anyway, and reserve enough budget for the remaining work — or ask the owner for a specific exception. Cost-aware planning and alternative-service selection are the capabilities we aim to build on this foundation. 3. How we will evaluate Cordon We will compare three approaches: direct purchasing without Cordon, a conventional shared budget with a hard stop, and Cordon. Each receives the same task, starting information, service options, and output requirements. Our main question is whether Cordon can reduce the total cost of completing a task while delivering an equally useful result. We will measure task completion, total spending, repeated or unnecessary purchases, completion time, and the number of times the owner needs to intervene. Total cost will include payment fees, gas, and any Cordon service fee. For deterministic tasks, such as retrieving a fixed dataset or performing a calculation, we will check whether the final outputs match exactly. For research and synthesis tasks, we will evaluate accuracy, completeness, source quality, and freshness against the same checklist. We will use fixed data or aligned timestamps where needed to make comparisons fair. We will also test difficult situations: repeated failures, expensive services, and several agents drawing from one budget — and an agent that is prompt-injected or left running, since that is where the owner is the victim and the bound is what stops it. A run that spends less because it stops early will count as incomplete, not as an efficiency improvement. An earlier version of this test already exists as a gate: one task, split across a root and its workers, run under Cordon and under a plain shared cap, three runs each. With a worker stuck in a loop, the shared cap spent the total it was given and the other worker’s work never happened; under Cordon the loop was refused and the brief still completed. We will extend this into the full three-way evaluation above and publish the result — towards our end goal: helping AI teams balance performance and cost within a shared budget.
How it's made
Cordon is four layers, and authority only flows downward: from the owner to the contract, never up from the agent. Five Solidity contracts across two testnets. MandateRegistry manages the agent tree and enforces narrowing. TreeVault holds the funds and performs the ancestor debit, so every draw charges every node up to the root. ConductRecord publishes a refusal to ERC-8004's reputation registry. CordonResolver answers ENS lookups from those contracts. LocalGateway is the settlement rail on a chain without Circle's Gateway. No proxy, no admin key, no upgrade path. It runs on Arc testnet (chain 5042002) and Ethereum Sepolia (11155111), for opposite reasons. Arc has USDC as both gas and the payment token, so an operator holds one asset, and sub-second finality makes per-purchase on-chain enforcement affordable. Sepolia is where ENSv2 lives, so it is where the agent names are. The chain decides the rail: Arc settles through Circle Gateway with x402 and EIP-3009, and Sepolia settles directly, with LocalGateway depositing the tranche into the operator's own wallet at the draw and nothing charged on top of the price. The daemon (Node 23.6+, TypeScript, viem 2) is the only component that holds a private key. Agents call cordon_fetch(url). The daemon reads the seller's x402 challenge, takes the price and the payee from it (never from the agent), and asks the vault. There is no cordon_transfer or cordon_pay tool, and a test asserts each stays unregistered. An agent that cannot express "send money to X" cannot be talked into it. Every agent also has an ENSv2 name, and the records are computed, not stored. CordonResolver reads the registry and the vault while it answers, so cordon.live, cordon.headroom and cordon.boundBy are live as of the block. The permission model lives in that namespace and mirrors the mandate: an operator that may spawn holds ROLE_REGISTRAR in its own subregistry, it holds no ROLE_UNREGISTER, and it cannot write its own records. ENSIP-25 links the name to the agent's ERC-8004 identity, and ENSIP-26 carries its endpoint and context. The surfaces: an MCP server on npm (cordon-mcp) with three tools, a seller SDK (@cordon/verify) that turns a name or the payer address into a serve-or-refuse answer, and a console where the owner signs. Privy powers the console's wallet gate with embedded wallets via createOnLogin, so an owner without a browser wallet can still sign a mandate. The hacky bit is the ancestor debit. A grandchild's $1 purchase debits $1 at every node up to the root, so headroom is always the tightest bottleneck across the whole path, and the node it names is often an ancestor rather than the agent that asked. We validated it with 1,200 adversarial strategies across 45,360 draws: zero got past a bound. A hostile drill gave an LLM agent the daemon and told it to spend freely against a $0.02 mandate; it reached $0.007 before concentration stopped it. And a separate gate measures whether the fence lets real work through: one task, two conditions, three runs each, where a worker stuck in a loop stayed refused under Cordon and the brief still completed.