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

AI Agent Payments: What Evidence Would Show Who Decided?

If your agent pays for data, could you show later that it, not a script, made that choice?

XIN
Pixel-art night scene of a glowing pipe carrying identical data packets. A magnifying glass over the pipe shows mostly clock icons and only two magenta robot heads.

IN 30 SECONDS

Decision provenance is the record of which process decided a payment, and a settlement record doesn’t carry it. My proposal: answer three questions, and log the decision before the agent signs.

KEY TAKEAWAYS · 3

  • My proposal, not a standard: ask who decided, what was authorized, and what condition settled the payment.
  • ERC-8203, a Draft in open PR #1614 (not merged) that I co-author, can address the third question only.
  • Operator records written at decision time, protected and corroborated, can support attribution under a stated method, not prove it alone.
On this page

Three questions I’d want a payment record to answer

IN SHORT My proposal, not a standard: three questions to answer before you credit a payment to an AI agent.

WORDS TO KNOW

Provenance
Which process actually made a decision, not which entity an address is declared to belong to.
Mandate
The spending power a person or team hands to an agent: for what, up to what cap, until when.
Append-only log
A record where lines are added but never edited or deleted.

I report public specs and measurements, not my own payment volumes. Not legal or investment advice.

  • Who decided? Identity: who an address is declared to belong to. Provenance Which process actually made a decision, not which entity an address is declared to belong to. See the glossary: which process actually made this payment decision.
  • What was authorized? The Mandate The spending power a person or team hands to an agent: for what, up to what cap, until when. See the glossary: who delegated the spending power, for what, up to what cap, until when.
  • What condition settled it: delivery, a proof, a timeout? The narrowest question, the one a settlement standard can address.

A basic x402 settlement record answers none of the three.

Agent registries help with identity, not provenance. ERC-8004, “Trustless Agents”, is one, still a Draft, and TRM notes such declarations are “voluntary and currently not utilized by the majority of participants.”

IN PLAIN WORDS

A registry is a name tag on an address: who claims it, not which program paid this time.

For the mandate, TRM describes Google’s AP2 as “a framework for verifying that an agent’s purchases are authorized by a user.”

In September, Ant International, Mastercard and Visa said they had begun work on a shared Know-Your-Agent framework. The announcement has no spec. ERC-3643, where I’m a named author, ties token holders’ claims to an ONCHAINID identity (see the Know Your Agent episode).

Coming up next: So could a settlement standard answer the first question too?

Where conditional settlement fits, and where it stops

IN SHORT ERC-8203, a Draft (open PR #1614, not merged), ties a payment to its release condition, not to who decided.

WHAT HAPPENS, IN PLAIN WORDS
Flow diagram: 2 stepsFlow diagram: 2 steps. A payment is locked with a condition, then Then one of two outcomes. Then one of two outcomes branches into 2: If valid proof of the condition arrives, then The payment can settle. If expiry passes before settlement completes, then A refund becomes valid.VALID PROOF OF THE CONDITIONARRIVESEXPIRY PASSES BEFORESETTLEMENT COMPLETES1A payment is locked witha conditionAn amount, the condition itwaits for, and an expiry2Then one of two outcomesThe payment can settleA refund becomes valid
Simplified from ERC-8203, Agent Offchain Conditional Settlement, the Draft I co-author. Names and rules can still change.

It doesn’t say whether the payer is an AI agent. Its abstract calls it “actor-agnostic”: agents motivated it, but people and other automated systems can use it too.

ADAM says: If someone tells you a settlement standard proves an agent paid, they’re overselling. That would include me.

It calls identity and reputation standards “Orthogonal”: a separate job. It was written for off-chain channel frameworks and doesn’t mention x402. So it can address the third question, never the first.

Under the draft, a payment can point to the condition it was locked to and to a reference for its proof. The draft “does not standardize the contents of the proof itself”: its worth depends on the program that checks the proof, and on who you trust.

What I’d log on the operator side

IN SHORT My proposal for anyone running agents that pay: write down who decided before you sign, then link it to the payment.

PROPOSED OPERATOR RECORD

Flow diagram: 6 stepsFlow diagram: 6 steps. Run starts, then Mandate check. Mandate check, then Price asked. Price asked, then Decision. Decision, then Sign and send. Sign and send, then Payment confirmed.1Run starts2Mandate check3Price asked4Decision5Sign and send6Payment confirmed

Step 1. Trigger. What started the run: a schedule, an agent’s plan or a person.

Pick a step to see it move
  1. Trigger What started the run: a schedule, an agent’s plan or a person.
  2. Mandate check The mandate, its cap and the budget left.
  3. Price asked The resource and the price the server asked.
  4. Decision Which process decided: its run, agent, version and reason.
  5. Sign The fingerprint (hash) of the signed authorization.
  6. Settlement The transaction’s fingerprint, joined to the record so log and chain line up.
What I’d write at each step of one paid call. The decision step, not the trigger, is what classifies the payment.

I’d write the record when the decision is made, then join it to the settlement transaction. You also need to state what you consider agentic, and keep an Append-only log A record where lines are added but never edited or deleted. See the glossary.

A trigger label alone isn’t enough: a timer may start the run, then an agent decides to pay. I laid out that record design in proving an agent’s work to an auditor.

ITEM GET

Support, not proof

Then you can report a share classified under a stated method, and an auditor can check the records. Protected and corroborated, they can support the attribution, not prove agency on their own.

FAQ

Not from the payment record alone: TRM says “a scheduled script and an agent produce the same record”. Operator records written when the decision is made, protected and corroborated, can support attribution under a stated method, but don’t prove it alone.

It can tie a payment to the condition that released it, under the draft’s rules. It’s actor-agnostic, so it doesn’t show whether an agent or a script paid.

Sources: TRM Labs, KYA announcement, ERC-8004 (Draft), ERC-8203 (Draft, open PR #1614, not merged).

STAGE CLEAR

What you now know

  • Why “who decided” is two questions: identity and provenance.
  • What ERC-8203, a Draft in open PR #1614, not merged, can and can’t show about a payment.

Check yourself

Tap or click a question to see the answer.

A person starts a research job. The agent then picks which paid report to buy and accepts the price. Whose decision was the payment?

The agent run’s. A person triggered it, but the decision step classifies the payment, so the record should name that run, its version and its reason.

You finished every stage published so far in this series. Back to the series map

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.