Agents Have Wallets Now. Who Checks the Other Side?

Agents have wallets now. They pay for data, inference, and tools over x402 by the million, and they show up at gates asking to be let in. In both directions the same thing is missing: a verifiable answer about who is on the other side. This post is about what goes wrong without one, what we sell in its place, what it costs, where the money can come from, and why the answer stays checkable long after the payment clears.

The rails are real. The traffic is thinner than the counts.

The numbers first, because they are more honest than the narrative. Chainalysis counted well over 100 million cumulative x402 transactions on Base through the first quarter of 2026, and noted that much of the early surge came from a pay-to-mint memecoin experiment, with growth moderating once the speculation cooled. An industry tracker put the whole protocol at 120 million transactions and $41 million settled by mid-April, with an average payment of five cents. CoinDesk's March analysis, as relayed by one adoption tracker, estimated real commercial volume at roughly $28,000 a day, with about half of all activity classed as gamified.

The chain mix has moved. Solana passed Base on weekly transaction count in the second week of December 2025. By late August, Token Terminal data showed 3.3 million USDC transfers over x402 on Solana in a single week and put Solana at roughly 70 percent of monthly x402 volume. Base still leads cumulative dollars. Polygon and Arbitrum are live on the same facilitator. The x402 Foundation now counts around 40 members, and Cloudflare announced agent wallets with allowance limits, merchant allow-lists, and per-transaction caps during its August Agents Week.

So: a working standard, a lot of settlement infrastructure, fragmented across chains, carrying mostly tiny payments, and looking for things worth paying for. That is the market. It is a fine one to build in, as long as you are clear about what the rails do and do not do.

What goes wrong without a check

Every control announced this year sits on the payer's side of the wire. Allowance limits, allow-lists, and transaction caps bound how much an agent can lose. As InfoQ's headline on the Cloudflare launch put it, the spending controls stop at the payment. None of them asks anything about the party on the other side, and none of them helps the party on the other side ask anything about the agent.

That gap is where the stories come from. In March, Fortune collected three in as many weeks: an agent that published an attack piece on an engineer who rejected its code, a Meta AI safety director whose agent bulk-deleted her email while ignoring her instructions to stop, and a research agent that quietly diverted its compute to mine cryptocurrency. None of those involved a wallet. Give the same class of agent a funded one and the failure has a price tag.

In August, an AI professor writing in The Conversation walked through the dispute that follows. You tell an agent to find a shirt under $30 but not buy it. It buys it. The retailer's record is accurate, the payment processor's record is accurate, the agent provider's log is accurate, and "nothing in those records links the charge to the task you gave the agent." Senator Warner's AI AGENT Act, introduced July 21, would require agents to act in a "transparent, documented, limited and revocable" way. The author's point is that even that bill does not require a verifiable evidence chain across the systems involved. Records are not evidence. Evidence is something a third party can check.

The protocol's own tracker says the same thing in engineering terms. The most-discussed open proposal on the x402 repository this year asks for fiscal-authority metadata and agent spend limits. August brought a proposed delegated-authorization hook, an authorization-evidence profile, and an authorization-provenance extension. Different authors, one need: before money moves, somebody wants a checkable statement about standing.

And it is not only money. The same agent that pays for an API also asks to be let into things: a data feed reserved for holders, a discount reserved for members, a tool reserved for registered agents, an action reserved for a delegate. Access has the same hole as payment. Whoever runs the gate either lets in anyone who can pay, or blocks everyone, because there is no cheap, verifiable way to ask a question about the wallet at the door.

Why an agent needs a check it cannot be talked out of

Here is the reasoning, stripped down. An agent's decisions come from a model, and a model can be persuaded. In every incident below, text arrived, the model acted on it, and funds moved. Prompt manipulation can change what a model does. It cannot, by itself, change independently observed chain state. Spend caps limit the damage per incident. Allow-lists work until the attacker is on one or impersonates one. What none of those controls do is ask a question whose answer the attacker cannot supply.

A condition over chain state is that question. "Does the wallet I am about to pay hold at least this much of this asset?" "Is it a registered agent?" "Does it hold the attestation my policy requires?" "Is the delegation I am acting under still valid?" The attacker can write anything into the prompt. Persuasion writes nothing into the chain; qualifying state has to be put there in public, at a cost, before the trick can work. And when the answer comes back signed by a third party that read the chain, the agent's policy can be a single line: no signed yes, no payment. That is what /v1/attest is for. /v1/trust is the same idea for a counterparty you know nothing about: instead of conditions you define, a fact profile of what the wallet has actually done.

Where a check would have changed the outcome

We went looking for real losses, not hypotheticals, and asked of each one honestly: would a signed condition over chain state, enforced before the transfer, have stopped it?

• Freysa, November 2024. An agent guarding a prize pool was told never to approve a transfer. After 482 attempts by 195 people, one message redefined its approveTransfer function as something that fires on incoming funds, and the agent sent the whole pool, about $47,000 in ETH, to the person who wrote it. The recipient was whoever asked. A payee condition the agent could not reinterpret, such as "the recipient must hold the treasury's own pass" or "must be a registered agent," is evaluated from chain state, not from the conversation. The message that rewrote the model's understanding of a function could not have rewritten a wallet's holdings.
• Grok and Bankrbot, May 4, 2026. A Morse-code prompt posted on X walked past the safety filters and had an AI-linked wallet on Base transfer roughly 3 billion DRB tokens, worth between $150,000 and $200,000, to the attacker. The OECD logged it as an AI incident because the failure was in how the model read its input, not in any contract. The agent had the keys and the authority. The injection only supplied a destination. A destination that has to satisfy a signed condition first is a destination the attacker has to fund, register, or qualify in public, on-chain, before the trick works.
• Two live campaigns, reported July 2026. Zscaler documented websites built to be read by agents, with instructions hidden in schema markup and metadata telling the agent to complete a cryptocurrency payment to a hardcoded wallet as a routine step. This is the industrialized version of the two incidents above, and the same gate applies: a hardcoded attacker wallet does not meet conditions it was never set up to meet.
• Agents buying tokens that were built to fail. Chainalysis's 2026 crime report, as reported by CoinDesk, put 2025 losses to scams and fraud at $17 billion, with impersonation up 1,400 percent and AI-enabled scams 4.5 times more profitable than the old kind. Trading agents buy into these faster than people do. Two of our condition types speak directly to that: ratio_to_supply asks what share of a token's supply the deployer or top wallet holds, and a trust profile of the deployer shows whether that wallet has any history at all across stablecoins, governance, NFTs, or staking. A fresh wallet holding most of the supply is a fact, and it is checkable before the buy.

Two honest limits. First, the check only helps if the agent's spend path is actually gated on it; an attestation nobody waits for stops nothing. Second, a determined attacker can qualify a wallet in advance, so the conditions have to cost more to satisfy than the attack pays. Holdings, registrations, and delegations from a specific principal are the kind of thing that does. A short chat message is not.

And on the protocol's own weaknesses: a May 2026 paper describes five practical attacks on x402 that produce "unpaid service or paid-but-denied outcomes." Our rail is built against exactly those two failure modes, which we come back to below.

What we sell: a signed answer about the other side

InsumerAPI does one thing. You state conditions about a wallet. We read the chain, evaluate the conditions, and return a signed boolean. Conditions in, signed attestations out. No balance leaves the building; the answer is yes or no, with the block it was true at and a signature anyone can check against our published keys.

For an agent about to pay, that turns "who am I paying?" into a question with an answer. POST /v1/trust returns a fact profile of the counterparty wallet: 44 checks across 25 chains in five dimensions by default, up to 49 across 27 chains in nine when you supply Solana, XRPL, Bitcoin, or Tron addresses. No score and no opinion, just evidence organized by dimension, each check signed. Batch it for up to ten wallets in one call.

For a gate about to let an agent in, POST /v1/attest answers up to ten conditions at once, across 38 chains, in one signed verdict. Nine condition types: token balances, NFT ownership, EAS attestations, Farcaster identity, any boolean view function on any contract, two ratio rules that never need re-tuning, and two built for agents. erc8004_agent asks whether the wallet is a registered agent. erc7710_delegation asks whether a principal's delegation to this agent is valid right now, and can carry a storage proof that it has not been revoked. "Registered agent, holding ten times the transaction amount, under an unrevoked delegation" is one request, one signature, one answer.

That is the missing piece in both directions. The payer's spend cap says how much can go out. Our attestation says whether the wallet on the other side meets the conditions you set. The merchant's allow-list says who may call. Our attestation says whether the caller has standing right now. We do not make the decision. We make the fact checkable.

How an agent pays us: any of four networks, no account

The service is itself an x402 endpoint, because the agents that need it do not have accounts. Send POST /v1/attest, /v1/trust, or /v1/trust/batch with no credential headers and the answer is a 402 quote. As of this week the quote carries one entry per settlement network, all at the same price:

• Base (eip155:8453), listed first, as it always was
• Polygon (eip155:137)
• Arbitrum One (eip155:42161)
• Solana (solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp)

Pick one. On the EVM networks the agent signs an EIP-3009 USDC authorization under that chain's USDC domain; on Solana it signs a USDC transfer with the quoted fee payer. Retry with the PAYMENT-SIGNATURE header, the facilitator settles gasless, and the signed answer comes back in the same round trip with the settlement transaction in PAYMENT-RESPONSE. The wallet needs USDC and nothing else. No gas token on any of the four.

One discipline holds throughout, and it is the answer to the two failure modes that paper names: no service without money, no money without service. The payment is verified before any chain work starts, the answer is computed but withheld, and settlement gates the response. If the evaluation refuses to sign, nothing is charged. If settlement fails, the answer is never released. Each payment is single-use; a replay is refused before it reaches the chain.

If you would rather hold credits, an agent can buy a key with USDC or USDT on eight chains or with BTC, or take a free key with an email. A wallet that has spent a dollar over x402 can also claim a soulbound pass and switch to wallet-signed requests with no key at all. Every path lands on the same endpoints and the same signatures.

Receipts

We do not ask you to take the four-network claim on faith. On September 3 we paid ourselves once on each network with the reference x402 client, five cents per attestation, and verified every response with the open-source insumer-verify library:

• Base: 0xea91b0e9…4115777
• Polygon: 0x8082ab84…708f09c2
• Arbitrum: 0x23f0644a…8757ce81
• Solana: uZcxbnC6…8bpwT4fj

Trust profiles and batches settled the same day on Solana, Polygon, and Arbitrum. The rail has been live since July 27, when the first five-cent delegation check settled on Base, and it appears as a live payable rail in Shoal Research's August census of x402 endpoints. Third parties already build on the same signatures: a counterparty-risk API surfaces our trust profile inside its scores, and an agent-payments provider names our attestations in its own catalog entry.

What it costs

Pay-per-call is priced as a small premium over prepaid credits, derived by rule so it can never undercut them:

• Attestation: $0.05, or $0.10 with a Merkle storage proof
• Trust profile: $0.15, or $0.30 with proofs
• Batch: the same per wallet, up to ten wallets
• Prepaid: from $0.04 a call at the entry tier down to $0.02 at volume, via credits

Same price on every network. The quote is priced for the exact body you send, so the amount you see is the amount you pay; overpayment is rejected, not kept.

Why the answer outlives the payment

A payment is settled once. An attestation is evidence, and evidence gets read later: in a dispute, an audit, a regulator's question about what an agent knew when it acted. So the answer has to stay checkable for as long as anyone might ask.

Every attestation and every trust profile is signed twice. The ECDSA signature is the one every verifier already checks. Since September 1, a second signature rides beside it: an ML-DSA-65 companion under FIPS 204, the post-quantum standard, over the same bytes. Both public keys are in the JWKS, and the binding between the two keys is itself signed by both and anchored on Base, so the date the companion came into existence is public record. The spec treats the companion as an independent verdict, and insumer-verify reports it as one. Nothing about the classical signature changed; a verifier that never heard of the companion works exactly as before.

The practical meaning is simple. The signed answer an agent buys today for five cents is designed to remain independently checkable years later, by anyone, against public keys and public chain state, without depending on the payment rail, the facilitator, or any single signature algorithm of 2026. Boolean, not balance. Provable and private. Built to be read later.

For agents: where to find us

If you are an agent, or you are writing one, everything below is machine-readable and needs no account:

• Start here: insumermodel.com/llms.txt (short) and llms-full.txt (complete)
• x402 discovery: /.well-known/x402 and /.well-known/agents.json
• OpenAPI: insumermodel.com/openapi.yaml, also served at api.insumermodel.com/openapi.json
• Pay-per-call endpoints: POST https://api.insumermodel.com/v1/attest, /v1/trust, /v1/trust/batch. Send no credentials, read the 402, pay on any listed network, retry.
• Catalogs: listed on x402scan and indexed in the facilitator's Bazaar
• Verify anything we sign: npm install insumer-verify, keys at /.well-known/jwks.json, published test vectors

The next time an agent is about to pay someone, or let someone in, the question "does the wallet on the other side meet my conditions right now?" has a signed answer. On four networks, for five cents, with receipts that keep.