SKIP TO CONTENT
AI AGENTS6 minStandards That Ship / Ep. 3 · Stage 3-2

Agent Payment Standards: Who the Agent Is, What It May Spend

You can already check who an agent is and what it may spend. What’s still missing is a rule to pay only if a condition is proven.

XIN
Pixel-art illustration of a robot at a payment terminal tethered by a glowing cord back to a distant human silhouette.

IN 30 SECONDS

An agent payment stack is the set of layers a payment can pass through, here: an on-chain identity naming the agent’s principal, transfer rules and a smart account that can cap spending. ERC-8203, a Draft in open PR #1614, not merged, aims to add settle-only-if-proven.

KEY TAKEAWAYS · 3

  • The pieces exist: OnchainID (ERC-734/735), ERC-3643 and ERC-4337/7579. Combining them for agents still needs to be built and tested.
  • I shipped them at Tokeny and Biconomy, where the rails moved $441M across 38M+ transactions: totals for that broader work, not a benchmark for this design or proof it is production-ready.
  • ERC-8203, a Draft in open PR #1614, not merged, aims to settle a payment only if a condition is proven. I’m second of three named authors; Xianrui Qin is the primary author.
On this page

The three pieces I already shipped

IN SHORT Identity, transfer rules and account permissions already exist as standards, and I’ve shipped each one. That alone doesn’t make their combination safe for agents.

WORDS TO KNOW

On-chain identity
An identity contract on a blockchain that holds signed statements about its owner, which other contracts and services can read.
Smart account
A wallet controlled by code on the blockchain. It can enforce rules, such as a spending limit, if the modules it runs include them.
PR (pull request)
A proposed change to a code repository, here the ERCs one. “Open, not merged”: not yet part of it.

I helped put KYC, the identity checks banks run on customers, on a blockchain. This post argues for doing the same with agents.

STEP BY STEP

Layered stack diagram: 3 layers, top to bottomLayered stack diagram: 3 layers, top to bottom. Layer 1, Identity: OnchainID (ERC-734/735), Who is this agent? Who vouches for it?. Layer 2, Transfer rules: ERC-3643, May this holder receive the token?. Layer 3, Account permissions: ERC-4337 / ERC-7579, What may it spend, and when?.IDENTITYOnchainID (ERC-734/735)Who is this agent? Whovouches for it?TRANSFER RULESERC-3643May this holder receive thetoken?ACCOUNT PERMISSIONSERC-4337 / ERC-7579What may it spend, and when?

Step 1. Identity. OnchainID answers: who is this agent, and who vouches for it?

Pick a step to see it move
  1. Identity OnchainID answers: who is this agent, and who vouches for it?
  2. Transfer rules ERC-3643 asks: may this holder receive the token?
  3. Spending rule The smart account checks what the agent may spend, through its code or modules.
  4. Over the cap A payment above the cap is refused, but only if the account’s code or an installed module enforces that cap.
Three possible layers for one agent payment. The integration and its trust assumptions still need to be built and tested.

Identity first. OnchainID is an On-chain identity An identity contract on a blockchain that holds signed statements about its owner, which other contracts and services can read. See the glossary contract holding signed claims from trusted issuers, a layer I built at Tokeny. For an agent, the claim names its principal, still to be checked for validity and tied to the action: one possible design, not the only one.

Then transfer rules. On an ordinary transfer, ERC-3643 checks the identity and compliance rules the issuer set; privileged actions, like an issuer’s forced transfer, follow other rules. I’m one of its five named authors.

WATCH OUT

ERC-3643 doesn’t define agent mandates: that would be a separate design job. And a Smart account A wallet controlled by code on the blockchain. It can enforce rules, such as a spending limit, if the modules it runs include them. See the glossary can enforce spending rules through its own code or installed modules. ERC-4337 and ERC-7579 alone don’t guarantee limits per session.

$441M
MOVED ON THE RAILS
Biconomy, across 38M+ transactions

Reported totals for my Biconomy work (ERC-4337/7579): that broader work, not this proposed design, and no proof it is production-ready.

$32B+

tokenized on ERC-3643, identity-gated

Headline figure published on erc3643.org.

ITEM GET

Three layers, three questions

Stack the three: the payment comes from a scoped account, by an agent with a named principal, checked against an identity rule.

Coming up next: So what does none of the three layers say?

ERC-8203 (Draft, open PR #1614, not merged): pay if proven

IN SHORT ERC-8203, still a Draft in open PR #1614, not merged, aims to standardize one missing step: paying only if a condition is proven.

Neither identity nor a scoped account says: pay only if this off-chain condition is later proven true. In my view, a lot of real agent commerce needs that step.

ERC-8203 (AGENT OFFCHAIN CONDITIONAL SETTLEMENT): DRAFT, OPEN PR #1614, NOT MERGED
Flow diagram: 3 stepsFlow diagram: 3 steps. Lock the payment with a condition, then Wait for the proof. Wait for the proof, then Settle or refund. Settle or refund branches into 2: If Settled with valid proof before expiry, then Settle. If Expiry passes, not settled, then Refund can be claimed.SETTLED WITH VALID PROOFBEFORE EXPIRYEXPIRY PASSES, NOT SETTLED1Lock the payment with aconditionAmount, expiry, what must beproven2Wait for the proofA proof or an attestation3Settle or refundSettleRefund can be claimed
Simplified from the draft’s lock fields (amount, expiry, condition). Settlement also needs a valid current state, and a refund must be claimed. Draft in open PR #1614, not merged: names and rules can still change.

ERC-8203 is an early Draft, still in PR (pull request) A proposed change to a code repository, here the ERCs one. “Open, not merged”: not yet part of it. See the glossary and not merged. Xianrui Qin is the primary author. I’m the second of three named authors, and I wrote the reference implementation.

IN PLAIN WORDS

The draft doesn’t care what kind of signer uses it: people and other automated systems can too. It leaves identity to other standards and says nothing about x402. Linking the two is my proposal, not part of the draft.

My three other standards, ERC-3643, ERC-6960 and ERC-7410, are merged into the ERCs repository. ERC-8203, my fourth named authorship, is still a Draft in open PR #1614, not finished or merged: don’t build against it today.

Sources: ERC-8203 draft, open PR #1614, not merged.

FAQ

It can put a signed claim about the agent’s principal where other services can check it, if they trust its issuer, the claim is still valid and a rule links identity to permissions. ERC-3643 doesn’t define agent mandates or decide liability. Signed off-chain credentials are another option.

Not as a set. The identity and account parts already run in deployed systems, but this combination still needs to be built, reviewed and tested, and ERC-8203 is still a Draft in open PR #1614, not merged. Parts that work elsewhere don’t make a system built from them ready for production.

STAGE CLEAR

What you now know

  • ERC-4337 and ERC-7579 cap nothing by themselves: the account’s code or an installed module has to enforce the limit.
  • ERC-8203, a Draft in open PR #1614, not merged, aims to let a payment settle only once a condition is proven.

Check yourself

Tap or click a question to see the answer.

An agent pays from an ERC-4337 smart account with no spending module installed. Can you assume it is capped?

No. A cap exists only if the account’s own code or an installed module enforces one, so check the implementation.

Next stage:Which records should you keep so a disputed agent payment can be reviewed?6 min
Adam Boudjemaa
Adam Boudjemaa

Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.

Have a project to ship or a role to fill?

Discuss your project or role
LinkedInTwitterGitHub
Follow the engineering notes

Get new articles on production AI and smart contracts by email.