Role

Goals

  • Discover a service, read its price and payment requirements, and pay within one request cycle.
  • Hold a stable identity (an agentId, a signing key, a registration) that counterparties can look up before accepting a request.
  • Stay inside the budget, payee list and expiry of the mandate it was given, and halt when a constraint fails.
  • Produce receipts and proofs (transaction hashes, a Payment-Receipt, signed mandates) for every payment so its principal and auditors can verify them.
  • Accumulate feedback that raises its probability of being selected for the next task.
  • Pay other agents for subtasks using the same protocols it accepts payments through.

Pains

  • Services speak x402 V1, x402 V2 or MPP, and a wrong guess costs a round trip or a failed payment.
  • A payment can settle and the service can still fail or return unusable output. The exact scheme has no refund path, and most flows have no evaluator.
  • Edge verification requires a key in a vendor directory the agent may not be listed in, so verified-only merchants return 403 or a block page.
  • Feedback is written by counterparties and cannot be contested beyond appendResponse, while Sybil reviewers dilute honest scores.
  • Mandates from different providers (AP2, Verifiable Intent, an SPT allowance) carry the same constraints in different shapes, and an unrecognized constraint must cause a hard failure.
  • Prompt injection in a merchant page or a tool result can redirect the agent's payment, and the agent has no independent check on its own instructions.

Decisions they own

  • Which service to buy from when several quote a price, given cost, reputation and proof of past payment.
  • Whether to pay upfront, by authorization, or by opening a session, based on the expected task length.
  • When to stop and request a new mandate instead of continuing within an expiring or exhausted one.
  • Which identity to present (agentId, Web Bot Auth key, registered agent credential) for a given counterparty.

Vocabulary

  • agentId
  • agentWallet
  • 402
  • PaymentPayload
  • mandate
  • constraint
  • cnf
  • receipt
  • txHash
  • feedback
  • services
  • A2A
  • MCP
  • session voucher

Each protocol from this seat

Relevance levels: High, a main persona on the protocol page; Medium, owns, implements or verifies a step; Low, relies on or observes a step; None, no role found in the protocol page.

ERC-8004: Trustless Agents

Relevance: High

Finds other agents in the registry, pays them through another protocol and writes feedback afterward. Source [1, 2, 3, 4]

Goals

  • Pick a counterparty it has never met
  • Pay the right address
  • Leave feedback that others can verify

Pains

  • Most registered agents have no live endpoint
  • Raw summaries are polluted by Sybil reviewers
  • Feedback costs gas

Implements

  • Lookups of agentURI and getAgentWallet
  • A trusted reviewer list for getSummary
  • Feedback files with proofOfPayment, then giveFeedback

Must trust

  • Its own reviewer list
  • The registration file as served at lookup time
  • The payment rail it uses, such as x402

Questions they ask

  • Which reviewers should count?
  • Is the advertised endpoint the one I am talking to?
  • Is this agentWallet still current?

First three steps

  1. Resolve the agent file and check its registrations entry
  2. Call getSummary with reviewers it trusts
  3. Probe the endpoint before paying

Metrics they care about

  • Share of hires that delivered
  • Feedback written per paid task
  • Spend on agents without trusted feedback

A day in the life. A research agent needs a translation service. It queries an indexer for agents tagged with translation skills, reads each registration file and drops those whose MCP endpoint does not answer. For the rest it calls getSummary with the twenty client addresses its operator trusts. It pays the best one through x402 at the address returned by getAgentWallet, keeps the transaction hash, uploads a feedback file with proofOfPayment and then calls giveFeedback with the file URI. The gas comes from a sponsor, as the text allows for clients that need not be registered.

Steps in the responsibility table

  • Relies onWrite and host the registration file
  • Relies onBind the payment wallet (setAgentWallet)
  • VerifiesProve domain control (/.well-known)
  • OwnsPay the agent (outside ERC-8004)
  • OwnsWrite feedback with proofOfPayment
  • ImplementsChoose trusted reviewers for getSummary
  • Relies onWatch transfers, URI changes and upgrades

x402

Relevance: High

Pays on its own within limits a human set, choosing among accepts entries per request. Source [5, 6, 7, 8]

Goals

  • Finish the task within budget
  • Pay only for what the task needs
  • Leave a verifiable trail

Pains

  • Prices that change between calls
  • Servers that take payment and return nothing useful
  • Altered 402 responses that name another payTo

Implements

  • Selection logic over accepts entries
  • Per-payment and per-task caps
  • Receipt keeping and stop rules

Must trust

  • Its wallet and key isolation
  • The policy its operator configured
  • The facilitator not to stall payments

Questions they ask

  • Is this payTo the seller I meant to pay?
  • Is the price within my cap?
  • Do I have a way back if the result is wrong?

First three steps

  1. Check payTo against the expected seller before every signature
  2. Refuse amounts above the configured cap
  3. Record each transaction hash with the task step

Metrics they care about

  • Spend per completed task
  • Refusals by policy
  • Payments without useful delivery

A day in the life. The agent is asked to compile a report from paid sources overnight. Each fetch that returns 402 goes through the same checks: the network and asset are on its list, the amount is under five cents, and the payTo matches the address its operator pinned for that domain. One source suddenly asks for twenty cents; the agent refuses and notes it. Another returns a 402 whose payTo differs from the pinned one, so it stops and flags the domain. By morning it has spent a little over a dollar across ninety calls, and every payment in its log has a transaction hash a human can check.

Steps in the responsibility table

  • Relies onPublish payment requirements (402 with PAYMENT-REQUIRED)
  • OwnsChoose an accepts entry
  • Relies onEnforce spend caps and payTo allowlists
  • OwnsSign the authorization (EIP-712)
  • Relies onRun the handler
  • OwnsReturn and store the PAYMENT-RESPONSE receipt

Visa Trusted Agent Protocol

Relevance: None

Not one of the main personas on the Visa Trusted Agent Protocol page. The responsibility table gives this persona no step.

Agentic Commerce Protocol (ACP)

Relevance: None

Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.

UCP

Relevance: None

Not one of the main personas on the UCP page. The responsibility table gives this persona no step.

Stripe MPP (Machine Payments Protocol)

Relevance: High

The software that pays: reads challenges, chooses a method within its limits, signs, retries and keeps receipts. Source [9, 10]

Goals

  • Finish the task within budget
  • Prefer the cheapest acceptable method
  • Keep proof of every payment

Pains

  • Challenges that look valid but name the wrong recipient
  • Descriptions that can say anything
  • Streams that cut off mid-session

Implements

  • Accept-Payment preference ordering
  • Pre-payment checks on amount, currency, recipient and expires
  • Receipt storage with reference and timestamp

Must trust

  • Its operator's policy and key custody
  • The server's challenge binding
  • The rail's finality

Questions they ask

  • Is this price within my budget for this task?
  • Is the challenge still valid?
  • Did I get a receipt for every paid response?

First three steps

  1. Read the challenge and decode request
  2. Check amount, recipient, currency and expires against policy
  3. Pay through the preferred method and store the receipt

Metrics they care about

  • Cost per completed task
  • Receipts per paid response
  • Rejected challenges

A day in the life. An overnight procurement agent needs ten datasets. For each it requests the file, receives a 402 with two challenges and decodes both. One is a Tempo charge for 0.40 USD to an address its operator approved; the other is a Stripe charge it is not configured to use, so it ignores it. It checks that the challenge expires in four minutes, signs and retries, and stores the receipt hash in its task log. One server asks for 40 USD with a reassuring description. The agent ignores the description, compares the amount with its budget, refuses, and flags the server for its operator.

Steps in the responsibility table

  • Relies onIssue the bound challenge (402 with WWW-Authenticate: Payment)
  • OwnsState preferences with Accept-Payment
  • OwnsCheck amount, recipient, currency and expires
  • Relies onEnforce budgets and allowlists
  • OwnsPay through the method (sign, mint SPT, get card token)
  • Relies onReturn and store the Payment-Receipt
  • OwnsClose or force-close session channels

AP2

Relevance: None

Not one of the main personas on the AP2 page. The responsibility table gives this persona no step.

Mastercard Agent Pay

Relevance: None

Not one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.

Sources

  1. ERC-8004: Trustless Agents (specification source, ERCS/erc-8004.md) (external link)Ethereum ERCs repository. Specification, primary source. Published . Accessed .
  2. ReputationRegistryUpgradeable.sol (external link)erc-8004 (GitHub organization). Repository, primary source. Accessed .
  3. ERC-8004 agent census (measured read, 2026-09-26) (external link)CSOAI Ltd (Council of AI) on Hugging Face. Dataset, primary source. Published . Accessed .
  4. Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem (external link)arXiv (Xiong, Li, Wei, Wang et al.). Paper, primary source. Published . Accessed .
  5. x402Client.ts (SpendControls, DEFAULT_MAX_AMOUNT_PER_PAYMENT) (external link)x402 Foundation. Repository, primary source. Accessed .
  6. x402 Protocol Specification v2 (external link)x402 Foundation. Specification, primary source. Published . Accessed .
  7. Scheme: exact on EVM (external link)x402 Foundation. Specification, primary source. Published . Accessed .
  8. Five Attacks on x402 Agentic Payment Protocol (external link)arXiv. Paper, primary source. Published . Accessed .
  9. The "Payment" HTTP Authentication Scheme (draft-httpauth-payment-01, repository source) (external link)Tempo Labs and Stripe (B. Ryan, J. Moxey, T. Meagher, J. Weinstein, S. Kaliski). Specification, primary source. Published . Accessed .
  10. Charge Intent for HTTP Payment Authentication (draft-payment-intent-charge-00) (external link)Tempo Labs. Specification, primary source. Accessed .

Source details

    Loading the index.

    Enter open Esc close ? shortcuts