The Five-Cent Standing Check

On July 27, an AI agent with no account, no API key, and no human watching paid five cents in USDC and got back a cryptographically signed answer to the question agent commerce keeps skipping: did this principal actually delegate authority to this agent? The payment settled on Base, where anyone can verify it. The verdict came back signed, so anyone can verify it left our keys unaltered. And the one fact that can change at a later block, revocation, can arrive with its own chain proof.

Here is the settlement, on-chain, if you would like to check before reading further: block 49204694 on Base.

The question everyone was skipping

Agent payments got rails before agent authority got checks. We wrote about this twice while it was still a gap. In June: an agent that claims to act for someone should be able to prove it, and almost nothing in the stack asks. In July: the x402 protocol lets an agent pay for anything in one request, which makes the missing question sharper, because now the agent can spend.

At settlement time there are really three questions. Can this wallet pay? Payment rails answer that one well. Is the decision sound? Reasoning verifiers are working on it. Does this party have standing to act, for this principal, right now? That third question was going unanswered, and it is the one that decides whether the other two matter.

What is now possible

Two new condition types on POST /v1/attest answer the standing question directly, from chain state:

• erc8004_agent asks: is this wallet a registered ERC-8004 agent? The verdict is true when the wallet owns the agent NFT or is the registry's signature-verified agent wallet binding. We are precise about what that means: ERC-8004 registration is permissionless minting, so the signed statement is registration and ownership, nothing more. No vetting, no reputation, no endorsement. An attestation that overclaims is worse than none.
• erc7710_delegation asks the bigger one: under the MetaMask Delegation Framework on Base, is this signed delegation from principal to agent valid right now? The verdict is true only when the whole chain of facts holds: the attested wallet is the delegate, the declared principal matches, the EIP-712 signature verifies (a plain wallet signature or a smart-contract wallet's ERC-1271 check, and the signed result names which), the delegation is unrevoked as of the anchored block, every caveat uses a recognized enforcer, and any time window is currently open. Spending caps and target restrictions the principal signed come back decoded as declared limits, clearly labeled as what the principal authorized rather than something we simulated.

And here is the part that makes it usable by the machines it was built for: neither requires an account. Send the request with no credentials and the API answers with an x402 quote. Sign a USDC authorization on Base, retry, done. Five cents per attestation, settled on-chain, gasless for the payer. An agent can go from never having heard of us to holding a signed delegation verdict in two HTTP requests.

Money on-chain, answer off-chain

It is worth being precise about what lives where, because the split is the design.

The payment is on-chain. The five-cent settlements are ordinary Base transactions; the first one is public and anyone can inspect it.

The attestation is off-chain, on purpose. The verdict is ECDSA-signed bytes in the API response. It touches no chain, costs no gas, and verifies against our published key with any standard library. That is the product in one line: off-chain attestation of on-chain state. The chain is what we read. The signature is what you check.

And if "unrevoked as of block N" is a clause you would rather prove than trust, ask for it with proof: "merkle" and the response carries an EIP-1186 storage proof of the revocation slot itself, verifiable against the block header from any source you like. The state attestation spec walks through the whole procedure. You do not have to take our word for the one part of the verdict that could change a block later.

One row on a much bigger menu

Agent standing is the newest thing attest can do. It is nowhere near the only thing. The same endpoint, the same signed-boolean shape, the same one call, currently answers nine condition types across 38 chains:

• Token balances, from "holds 100 USDC on Base" to native BTC, TRX, XLM, and SUI
• NFT ownership, EVM collections, Solana, and XRPL issuers
• EAS attestations, including Coinbase Verifications and Gitcoin Passport templates
• Farcaster identity
• Arbitrary contract predicates: any view function that answers yes or no about an address, like hasAccess(address), becomes attestable with evm_view_call
• Ratio rules that never need re-tuning: hold at least ten times the spend amount, or hold at least half a percent of supply
• Agent standing: the two types above

Up to ten conditions stack in a single request, across any mix of chains, into one signed verdict. So "registered agent AND holds 10x the transaction amount AND principal's delegation is unrevoked" is not three integrations. It is one call, one signature, one answer.

That is the actual thesis. Communities keep putting new kinds of proof on-chain: registrations, delegations, attestations, memberships. Each one becomes a row on this menu, answered in the same shape as every other row. The agent types took the menu from seven rows to nine. They will not be the last.

Start with one request

If you are building an agent, you do not need to sign up to try this. Send a request with no credentials, read the 402 quote, pay it. If you would rather have a key, the free tier takes an email and gives you 100 reads a day. Every SDK speaks the new types: the MCP server for Claude and friends, LangChain, LlamaIndex, and the ElizaOS plugin.

The next time an agent shows up claiming to act for someone, the question is answerable. For five cents, in two requests, with receipts.