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.
Builds policy around agents: which agents a fleet may hire or pay, based on registry data plus its own checks. Source [1, 2, 3, 4]
Goals
- Turn public signals into an allowlist
- Block payments to stale wallets
- Explain decisions to auditors
Pains
- No native spending caps, consent or kill switch
- Values are not comparable across tags
- One upgrade key can change registry behavior
Implements
- Trusted reviewer lists and weighting by proofOfPayment
- Checks that agentWallet was set after the last transfer
- Monitoring of URIUpdated, MetadataSet and Transfer events
Must trust
- Its own indexer
- The off-chain files it caches
- The payment layer that enforces caps
Questions they ask
- Which signals are strong enough to allow a payment?
- How do I detect a sold agent?
- What if the registry is upgraded?
First three steps
- Index the identity and reputation events for the chains you use
- Define a trusted reviewer set
- Alert on transfers and wallet changes
Metrics they care about
- Payments blocked by policy
- Agents with stale wallets
- Time from upgrade to alert
A day in the life. Lena runs controls for a company whose agents buy data from other agents. She indexes Transfer, URIUpdated and MetadataSet events and refuses payment to any agent whose token moved since its wallet was last bound. She scores reputation only from reviewers that paid with a verifiable proofOfPayment. Spending caps live in her payment layer, because ERC-8004 has none. When she learns that one externally owned account can upgrade the registries, she adds an alert on the proxy implementation slot and writes the risk into her vendor review.
Steps in the responsibility table
- ObservesWrite and host the registration file
- VerifiesBind the payment wallet (setAgentWallet)
- VerifiesProve domain control (/.well-known)
- VerifiesPay the agent (outside ERC-8004)
- ObservesWrite feedback with proofOfPayment
- OwnsChoose trusted reviewers for getSummary
- ObservesAppend responses to feedback
- OwnsWatch transfers, URI changes and upgrades
Builds independent controls around x402: budgets, allowlists, approvals and monitoring at the client, edge or facilitator. Source [5, 6, 7, 8, 9]
Goals
- Enforce limits the protocol does not define
- Act before a signature exists
- Detect abuse from public data
Pains
- Budgets are out of scope in the spec
- On chain, x402 payments look like ordinary transfers
- Each SDK has different hooks
Implements
- Policies and hooks such as onBeforePaymentCreation and onBeforeSettle
- payTo allowlists and per-task budgets
- Monitoring on facilitator events and contract events
Must trust
- The SDK to call its hooks in order
- The facilitator to report outcomes accurately
- Indexers that label payments
Questions they ask
- Where can I stop a payment: before signing, at the edge, or at settle?
- How do I tell x402 payments from other transfers?
- Can I revoke a signed authorization before it settles?
First three steps
- Add a policy that enforces a payTo allowlist before signing
- Set validBefore windows as short as the use allows
- Subscribe to settle outcomes and alert on unusual spend
Metrics they care about
- Payments blocked before signing
- Time from anomaly to block
- Coverage of agents under a policy
A day in the life. Omar's team sells a spend-control layer to companies that run agents. For x402 his main lever is the client: a policy hook that runs before the payment is created, checks payTo against an allowlist, enforces a daily budget per agent, and refuses unknown assets. A second lever is short validity windows, because a signed authorization cannot be recalled once it leaves the agent. On the seller side he offers hooks before verify and settle. Monitoring is harder: on chain the payments look like ordinary token transfers, so he relies on the facilitator's records and builder codes where sellers use them.
Steps in the responsibility table
- ObservesPublish payment requirements (402 with PAYMENT-REQUIRED)
- VerifiesChoose an accepts entry
- OwnsEnforce spend caps and payTo allowlists
- VerifiesSign the authorization (EIP-712)
- ObservesVerify the payload (POST /verify)
- ObservesScreen for sanctions (KYT, OFAC)
- ObservesSettle on chain and pay gas (POST /settle)
- ObservesReturn and store the PAYMENT-RESPONSE receipt
- OwnsMonitor spend and anomalies
Not one of the main personas on the Visa Trusted Agent Protocol page. The responsibility table gives this persona no step.
Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.
Not one of the main personas on the UCP page. The responsibility table gives this persona no step.
Builds an independent controls layer (budgets, allowlists, monitoring, kill switches) around MPP clients and servers. Source [10, 11, 12]
Goals
- Enforce budgets the protocol does not have
- See every payment an agent makes
- Stop spending quickly when something goes wrong
Pains
- No protocol kill switch or revocation message
- Channels without expiry
- Identity only as an SDK add-on
Implements
- Policy extensions that run before mppx signs
- Channel inventory and forced-close automation
- Receipt and MPPscan monitoring
Must trust
- The SDK hook order
- Public chain data for reconciliation
- Rail-level limits such as SPT max_amount
Questions they ask
- Where can I intercept a payment before it is signed?
- How do I prove a payment to an auditor?
- How long can a channel stay open unseen?
First three steps
- Add an mppx extension that enforces a per-task budget
- Export receipts and channel states to a ledger
- Alert on open channels older than a set age
Metrics they care about
- Blocked versus allowed payments
- Open channel value at risk
- Time to stop an agent
A day in the life. Sam runs the controls team for a company with 300 agents. MPP gives him clean hooks: every payment starts with a decoded challenge, and mppx runs his extension before it signs. His extension checks a per-agent budget, a recipient allowlist and a maximum price per unit for sessions. A dashboard joins stored receipts with on-chain settlements. The gap he cannot close in policy is time: channels never expire, so his nightly job force-closes channels idle for a day. When an agent misbehaves, he revokes its key at the wallet, because the protocol has no stop button.
Steps in the responsibility table
- ObservesIssue the bound challenge (402 with WWW-Authenticate: Payment)
- VerifiesCheck amount, recipient, currency and expires
- OwnsEnforce budgets and allowlists
- ObservesSettle on the rail
- VerifiesReturn and store the Payment-Receipt
- VerifiesClose or force-close session channels
- ObservesHandle disputes and refunds
Not one of the main personas on the AP2 page. The responsibility table gives this persona no step.
Not one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.