x401 and x402: Who the Agent Acts For, How It Pays, and What Its Wallet Holds

At Money20/20 in Las Vegas this week, Proof and Circle are showing an AI agent complete a purchase with two answers in one exchange. The merchant asks who the agent acts for, and the agent presents a verified Proof credential over x401. The merchant asks to be paid, and the agent pays in USDC over x402 from a Circle Agent Wallet. Plenty of purchases turn on a third question that the demo leaves to the merchant: does the wallet that is paying qualify? Take a members' price. A store sells at one price to the public and a lower one to holders of its membership pass. Knowing who the agent acts for and that it can pay does not tell the store which price applies. That is a question about wallet state, and wallet auth answers it.

What Proof and Circle Are Showing

The joint announcement, published October 19, describes an identity-gated purchase. The merchant answers the agent with two requirements: an x401 request naming the fact it needs, the issuers it trusts and how strongly the identity must have been verified, and an x402 payment request in USDC. The agent's Proof wallet presents the verified credential with a signed approval for that purchase, disclosing only the facts asked for. The merchant checks the signature against Proof's published keys without calling Proof, receives no copy of the person's ID document, and keeps signed evidence of who approved the purchase. The agent then pays in USDC from its Circle Agent Wallet.

Circle's VP of Product, Gagan Mac, summed up the pairing: “Agents that can pay also need a way to show who they act for.”

Three Questions at the Checkout

x402 moves the money. InsumerAPI checks the conditions. x401 tells the merchant who stands behind the agent. The three answer different questions, so a merchant can ask for any of them alone or all three in one purchase.

Why the Wallet Question Is Its Own Layer

Some facts belong in a credential. Legal identity, age and the authority to sign for a company all need someone to vouch for them. x401 is built so a service can ask for exactly those facts and nothing more.

Other facts already sit on a chain: a membership pass, a position in a token, an attestation another issuer wrote, whether an account is a plain key, an EIP-7702 delegated account or a contract. Nobody has to issue a claim about those for each purchase. The merchant can read them.

That reading is what InsumerAPI does. It reads the wallet's state, evaluates the merchant's conditions and signs the answer. Read. Evaluate. Sign. Keep. By default no balance comes back, only whether each condition is met. The condition belongs to the merchant, the agent has nothing extra to carry, and the holder does not ask anyone to issue anything.

Each Layer Covers What the Others Cannot

A signed InsumerAPI result is explicit about its limits. It is InsumerAPI's statement that it read chain state and evaluated the stated conditions. It does not show who controls the wallet or who the person is.

In this checkout the other two layers close those gaps. The x402 payment is signed by the wallet that pays, so once the merchant has verified it, the merchant knows the agent controls that wallet. The x401 credential says who the agent acts for. Wallet auth adds what that wallet holds. No layer has to do another layer's job.

One rule follows for anyone building the merchant side: run the condition check on the wallet that signed the verified payment, never on an address the caller simply names. Wallet state is public, so a qualifying wallet is easy to find. Tying the check to the payer is what ties it to the agent in front of you.

How the Three Fit in One Purchase

The demo covers identity and payment. The sequence below is our proposal for adding the wallet check to it; Proof and Circle have not shown or built this combined flow.

1. The agent asks for the resource. The merchant answers with its x401 proof request and its x402 payment quote.
2. The agent presents the Proof credential and a signed x402 payment from its wallet.
3. The merchant verifies the payment against its quote first. x402 keeps verification and settlement as separate steps, so a payment can be confirmed valid without being settled. Only then does the merchant take the payer address from it.
4. Still before settling, the merchant asks InsumerAPI whether that payer wallet holds its membership pass, and checks the signed answer against InsumerAPI's published keys, offline.
5. A yes means the members' price stands and the merchant settles. A no means it quotes the public price, or declines, without submitting the buyer's payment for settlement.

Two things to keep straight. First, checking the payer establishes what the paying wallet holds. It does not establish that the person named by x401 owns that wallet. If that link matters, the checkout has to bind the approval, the payer and the order together. Second, there are two payments in this picture: the buyer's payment to the merchant, and the merchant's payment for the wallet check. A buyer who does not qualify is never charged, but the check itself is paid for either way, because a signed no is as much an answer as a signed yes.

Step 4 is one request. Here the merchant asks whether the paying wallet holds its membership pass on Base, and asks for the answer as a signed JWT:

curl -X POST https://api.insumermodel.com/v1/attest \
  -H "Content-Type: application/json" \
  -H "X-API-Key: YOUR_API_KEY" \
  -d '{
    "wallet": "0xPAYER_ADDRESS_FROM_THE_X402_PAYMENT",
    "format": "jwt",
    "conditions": [{
      "type": "nft_ownership",
      "contractAddress": "0xYOUR_MEMBERSHIP_PASS_CONTRACT",
      "chainId": 8453,
      "label": "Member pass on Base"
    }]
  }'

The response carries met: true or met: false for each condition, the block it was read at and an expiry, signed so that any standard JWT library can verify it against the published keys. One request can carry up to ten conditions, from a token threshold to an NFT to an EAS attestation, and the answer is true only when all of them hold.

The Same Verification Model on Both Sides

Proof's credential and InsumerAPI's answer are checked the same way: against the issuer's published keys, by the merchant, without a call back. Each asks for little. The x401 flow discloses only the identity facts the merchant requested. The wallet check needs only a wallet address and the merchant's conditions, and by default returns no balance. InsumerAPI keeps a record that a check took place, its result and when, but not the wallet or the conditions. Every InsumerAPI result is signed twice, ES256 and a post-quantum ML-DSA-65 signature, and both keys are in the same public key set.

The two companies also say they are exploring a model where businesses pay identity issuers for each verification in USDC over x402. A wallet check already works that way. POST /v1/attest accepts x402 with no account and no key, $0.05 per call in USDC on Base, Polygon, Arbitrum, Arc or Solana. Arc is Circle's own chain. The payer is charged only for a successful answer, and the payer sees the answer only after the payment settled. A signed no counts as an answer; a check that could not read the chain is refused, never signed, and never charged. More on that flow is in how the settlement state machine works.

What to Do Next

If you are building the merchant side of an agent checkout, add the wallet check after you verify the payment and before you settle. The quickstart gets a key in seconds with 10 free verifications plus 100 requests a day. Agents can skip the key entirely and pay per call over x402, or ask the hosted MCP server at https://api.insumermodel.com/mcp.

If you run a store, club or community and want the same check at a real counter, Skye Meta builds on InsumerAPI and runs the screens for it.