Build the Ethereum Agent Trust Stack: ERC-8004 to ERC-8196

What the three-layer trust stack actually covers

Ethereum’s agent trust stack assigns three jobs to three standards: ERC-8004 supplies on-chain identity, reputation, and validation registries, ERC-8126 supplies standardized agent verification, and ERC-8196 supplies policy-bound wallet execution. Identity tells you who an agent claims to be, verification tells you what third parties found, and execution enforces what the asset owner permits. Payments remain a separate concern handled by protocols like x402.

ERC-8004 identity: registries, agent IDs, and registration files

ERC-8004, currently a Draft EIP proposed in August 2025 by authors from MetaMask, the Ethereum Foundation, Google, and Coinbase, defines three lightweight registry contracts intended as per-chain singletons: an Identity Registry, a Reputation Registry, and a Validation Registry. The EIP spec keeps each registry minimal so that the expensive state — registration files, feedback documents, validation artifacts — lives off-chain, with the chain holding pointers and hashes.

The Identity Registry is an ERC-721 contract with ERC721URIStorage: every agent is an NFT, and the tokenURI — called agentURI here — points to a JSON registration file. Minting happens through one of three register overloads: register(string agentURI, MetadataEntry[] metadata), register(string agentURI), or register(). Each emits Transfer, MetadataSet, and Registered(uint256 indexed agentId, string agentURI, address indexed owner), with agentId assigned incrementally as the ERC-721 tokenId.

A global agent identifier is the string {namespace}:{chainId}:{identityRegistry} — for example eip155:1:0x742... — plus the agentId. This lets one agent identity be referenced from any chain. The registration file must carry a fixed set of fields: type set to "https://eips.ethereum.org/EIPS/eip-8004#registration-v1", name, description, image, a services[] array (each entry with a name, an endpoint, and an optional version — covering MCP, A2A, OASF, ENS, DID, email, and web endpoints), an x402Support boolean, an active boolean, and a registrations[] list pairing agentId with agentRegistry. An optional supportedTrust array advertises which trust mechanisms the agent supports: "reputation", "crypto-economic", or "tee-attestation".

A singleton per chain means one address per network, and the canonical deploy reuses the same IdentityRegistry address across many chains — Ethereum mainnet’s IdentityRegistry is 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 and the ReputationRegistry is 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63, with the identical identity address on Base, Polygon, BNB, Arbitrum, Optimism, Gnosis, Celo, Linea, Scroll, and others. We verified live that eth_getCode on the mainnet IdentityRegistry returns deployed bytecode and name() decodes to AgentIdentity. Third-party reporting from Chainstack dates mainnet deployment to 2026-01-29 across 18+ EVM-compatible chains, though the EIP page itself states no deployment date.

Adoption is real but uneven. The 8004scan explorer homepage counters read 536,003+ registered agents, 616,237+ feedback submissions, and 480,670+ unique wallets as of 2026-09-23. Per-chain numbers from 8004scan.io/networks the same day show where activity concentrates: Base (chain id 8453) has 73,743 agents and 481,597 feedbacks, while Ethereum mainnet (id 1) has 31,659 agents and 12,052 feedbacks, and BNB Smart Chain (id 56) has 325,810 agents with only 11,882 feedbacks. Monad (143) shows 10,178 agents and 9,188 feedbacks; MegaETH (4326) shows 8,289 agents but just 23 feedbacks — registration is cheap, sustained feedback is not.

Because the EIP is still Draft, treat the interface as movable: function signatures and emitted events can change before Final.

The agent wallet field and endpoint-domain verification

Two optional mechanisms in ERC-8004 bind off-chain claims to on-chain control: the reserved agentWallet metadata key and well-known endpoint verification. The agentWallet field records the address where an agent receives payments, and it is deliberately hard to fake — you cannot set it through setMetadata() or during register(). Instead, the spec requires setAgentWallet(uint256 agentId, address newWallet, uint256 deadline, bytes signature), where the signature is an EIP-712 message signed by the owner for EOAs, or an ERC-1271 proof for smart-contract wallets. Reads go through getAgentWallet(agentId) and clearing through unsetAgentWallet(agentId).

The critical behavior for anyone running agents that hold or receive funds: on transfer of the agent NFT, agentWallet is automatically cleared to the zero address and the new owner must re-verify control before payments flow again. That single rule kills the most obvious attack — buy an agent NFT, inherit its payment address. If your infrastructure assumes the wallet survives ownership changes, fix that assumption now.

Endpoint-domain verification is optional and softer. The agent publishes https://{endpoint-domain}/.well-known/agent-registration.json containing a registrations list; a client treats the domain as verified only if the file is reachable over HTTPS and one entry’s agentRegistry and agentId match the on-chain record. This is a claim-binding check, not a security guarantee — it proves the domain operator published a matching file, nothing more. For agents advertising MCP or A2A endpoints, this is the cheapest way to make an advertised endpoint correspond to a registered identity before any money moves. Our Know-Your-Agent identity and authorization guide covers how these identity signals fit a broader vetting process; EIP-8141 frame transactions cover the wallet-side counterpart.

Agents can also register on multiple chains: the spec explicitly notes that an agent registered and receiving feedback on chain A can still operate on other chains. setAgentURI(agentId, newURI) emits URIUpdated, and base64 data URIs are recommended if you want the registration file fully on-chain.

The reputation registry at the contract-call level

The Reputation Registry stores feedback on-chain with one structural anti-Sybil rule you must design around: feedback submitters must not be the agent owner or an approved operator, and read queries require a non-empty clientAddresses filter because unfiltered aggregates are explicitly warned against as Sybil- and spam-prone. The write path is giveFeedback(uint256 agentId, int128 value, uint8 valueDecimals, string tag1, string tag2, string endpoint, string feedbackURI, bytes32 feedbackHash), emitting NewFeedback. valueDecimals ranges 0–18 so integers and fixed-point values both fit.

Storage is split deliberately: value, valueDecimals, tag1, tag2, and isRevoked are stored on-chain; endpoint, feedbackURI, and feedbackHash are emitted in the event but not stored — index them via IPFS or a subgraph. For non-content-addressed URIs, feedbackHash is the keccak256 of the feedbackURI content, giving you tamper-evidence without paying gas for the payload. Clients writing feedback don’t need to be registered agents, so any application can implement frictionless feedback, and the spec notes EIP-7702 as a route for gasless submissions.

The read path is where most integrations go wrong. getSummary(uint256 agentId, address[] clientAddresses, string tag1, string tag2) returns (count, summaryValue, summaryValueDecimals) — and the clientAddresses array must be non-empty. The spec’s reasoning is blunt: aggregates computed without filtering by client are subject to Sybil and spam attacks, because anyone can mint an agent and self-feedback is blocked only by the owner/operator check, not by any identity requirement on the submitter. Build your aggregation against a known client set — your own payment addresses, or clients you’ve verified — rather than trusting a chain-wide summary.

Additional reads cover the rest of the lifecycle: readFeedback, readAllFeedback, getClients, getLastIndex, and getResponseCount. revokeFeedback(agentId, feedbackIndex) emits FeedbackRevoked, and appendResponse(agentId, clientAddress, feedbackIndex, responseURI, responseHash) emits ResponseAppended — anyone may append a response, which is how a refund receipt or a spam flag gets attached to a feedback record without modifying it.

The documented example metrics show what the schema was shaped for: starred quality 0–100 (value 87, decimals 0), binary reachable and ownerVerified, uptime as a percent (9977 with decimals 2), successRate percent, responseTime in milliseconds, blocktimeFreshness in blocks, revenues in USD, and tradingYield with tag2 selecting day/week/month/year. Tags are free-form strings, so your tagging taxonomy is an integration decision, not a protocol one.

The validation registry, and what it leaves out

The Validation Registry is a request–response escrow for third-party checks: the agent’s owner or operator files a request, a designated validator answers with a 0–100 score, and both sides are pinned on-chain. validationRequest(address validatorAddress, uint256 agentId, string requestURI, bytes32 requestHash) must be called by the owner or operator of the agentId — agents cannot summon validators for themselves. validationResponse(bytes32 requestHash, uint8 response, string responseURI, bytes32 responseHash, string tag) must be called by the validatorAddress from the original request, so responses are attributable to the validator you asked.

The response value 0–100 can be binary (0 fail, 100 pass) or a spectrum, and it may be called multiple times for the same requestHash — the spec’s example is expressing progressive states, moving from “soft finality” to “hard finality” via the tag field. That matters for validation protocols built on staked or sequenced confirmation: a validator can publish an early answer and upgrade it later without a new request. Reads: getValidationStatus(requestHash), getSummary(agentId, validatorAddresses[], tag) returning (count, averageResponse), plus getAgentValidations and getValidatorRequests.

What it leaves out is just as important. Validator incentives and slashing are managed by the specific validation protocol and are out of scope of the registry — the contract records that a validator answered, not whether the validator had skin in the game. The spec’s own Security Considerations also note that on-chain pointers and hashes cannot be deleted, which is an audit-trail feature and a privacy consideration at once. And the sentence every buyer should memorize: the ERC “cryptographically ensures the registration file corresponds to the on-chain agent” but “cannot cryptographically guarantee that advertised capabilities are functional and non-malicious.” Registration is a claim, not a certification — which is exactly the gap ERC-8126 is designed to fill.

ERC-8126 verification and the 0-100 risk score

ERC-8126, titled “AI Agent Verification” and Final in the ERC process, standardizes how third parties verify agents registered via ERC-8004, producing a unified risk score from 0 to 100 where lower is safer — it is a risk score, not a trust score, and treating it as the latter is the most common misreading. The EIP defines five verification types: ETV (Ethereum Token Verification), MCV (Media Content Verification), SCV (Solidity Code Verification), WAV (Web Application Verification), and WV (Wallet Verification).

The design constraint that makes this composable: verifiers take an agentId and read registration metadata through ERC-8004 rather than accepting raw inputs like a wallet address or URL. That binds every verification result to a registered identity instead of to a claim, so a score is reproducible against the same on-chain record.

The mechanism underneath is PDV (Private Data Verification): providers implement verification using PDV to generate zero-knowledge proofs from verification results, so a result can be checked without exposing the underlying sensitive data — useful when a verifier inspected private code, wallet activity, or internal media and wants the conclusion to be publicly checkable without disclosing the evidence.

Two operational cautions. First, the score is only as good as the provider computing it; ERC-8126 reaching Final standardizes the interface, not the diligence of the shops implementing it — a point third-party analysis on hakhub.net makes explicitly. Second, a low risk score from one verification type says nothing about the other four; an agent with clean wallet verification may still have unverified code. Score per dimension, then compose.

ERC-8196 policy-bound execution wallets

ERC-8196, currently in Last Call, defines a standard interface for AI agent-authenticated wallets: the wallet executes a transaction only when it is accompanied by verifiable cryptographic proof that the action complies with a specific policy defined by the asset owner. The EIP positions it as Layer 2 (Execute) in a modular trust stack whose Layer 1 (Identify and Verify) is ERC-8126 — execution inherits identity and verification rather than duplicating them.

The policy is owner-registered and contains four levers: permitted actions, a contract allowlist, per-transaction and daily spending limits, and an expiry time. The smart wallet checks the active policy before executing any agent request, which means the agent holds a scoped delegation, not a key. There is no private key to leak, exfiltrate, or misuse beyond the policy’s bounds; the worst case is bounded by what the policy allows, not by what the wallet holds.

The stated properties are cryptographically enforced policy compliance, an immutable hash-chained audit trail for verifiable delegation, prevention of host manipulation of agent behaviour, and the user retaining final say over agents and assets. Because it is Last Call, the interface and security model can still change in peer review — pin the revision you build against.

One third-party caveat worth carrying into your threat model: the hakhub analysis argues host manipulation is not fully eliminated, and recommends multiple independent hosts for high-value agents. Policy binding constrains what an agent can do; it does not fully constrain what a compromised host can ask it to do within policy. Diversify hosts for anything handling serious value.

Where x402 payments plug into the trust stack

x402 plugs into ERC-8004 at two declared composition points — the registration file’s x402Support flag and the off-chain feedback file’s proofOfPayment object — while the registry itself never moves funds, because the spec states payments are explicitly orthogonal and not covered by ERC-8004. The x402 protocol launched via Coinbase on May 6, 2025, and Coinbase’s CDP docs report more than 100 million x402 payments processed across Base and Solana. The June 2026 whitepaper, “The Payment Protocol for Agentic Commerce”, is the current protocol reference.

The composition works like this. When you register an agent, setting x402Support: true in the registration file advertises that the agent’s services speak the HTTP 402 payment flow — clients discovering the agent through the registry know up front that it can be paid per-request. The reserved agentWallet field (see the wallet section above) gives that capability a verified payment address.

The feedback side is the more interesting loop. The off-chain feedback document’s optional fields include proofOfPayment: {fromAddress, toAddress, chainId, txHash} — a client who paid an agent via x402 can attach the payment transaction as evidence alongside a quality score. That turns reputation from “someone said the agent worked” into “someone paid, transacted, and then scored,” which is a materially stronger signal. The spec also defines how x402 payments can enrich feedback signals generally: mcp, a2a, and oasf optional fields tie feedback to the specific tool call, task, or skill that earned it.

For the payments plumbing itself, our Cloudflare Wallets and x402 agentic payments breakdown covers the infrastructure layer, and the Coinbase AgentKit USDC wallet guide covers giving an agent a funded wallet to spend from. The mental model: ERC-8004 says who the agent is and what clients experienced, x402 moves the money, and nothing in the registry enforces either — enforcement is ERC-8196’s job.

A control case: Hyperliquid API wallets

Hyperliquid’s API wallets are the cleanest real-world contrast to ERC-8196’s model: a master account can approve API wallets to sign on behalf of the master account or any of its sub-accounts, and per the Hyperliquid docs, API wallets only sign — querying account data with the agent address returns an empty result, a documented pitfall that trips up teams who expect the agent wallet to be a readable account.

The nonce model is where the key-scoped delegation shows its teeth. The 100 highest nonces are stored per address, and nonces must fall within (T-2 days, T+1 day) — a bounded replay window enforced by time and nonce tracking rather than by policy semantics. There is no spending limit, no contract allowlist, no expiry beyond nonce mechanics: the signing capability is the authorization.

The pruning behavior is the part every agent operator should internalize. API wallets and their nonce state can be pruned on deregistration, on expiry, or when the registering account runs out of funds — and once pruned, previously signed actions can be replayed. The docs therefore strongly advise never reusing agent addresses. Read that carefully: signatures that were valid remain valid after the delegation is removed, because the authorization lived in the key, not in a revocable policy the wallet checks at execution time.

This is exactly the failure mode ERC-8196’s design targets. A policy-bound wallet re-evaluates the owner’s active policy on every execution — limits, allowlist, expiry — so stale authority doesn’t survive policy revocation. Hyperliquid’s model is fine for its purpose, but it is a reminder of what “scoped delegation” means when the scope is the key itself. Teams building cross-venue agents should treat key-scoped delegation as the baseline to beat, not the default to copy.

Comparison: the three layers side by side

The three standards solve different problems at different maturity levels, and the table below restates what each layer’s contract actually enforces versus what it leaves to other layers or to off-chain providers. The single most important column is the last one: each standard’s guarantees stop precisely where the next layer — or your own operational discipline — has to take over.

Layer/standard	Status	Core mechanism	On-chain guarantee	Does not guarantee
ERC-8004	Draft	Three singleton registries: ERC-721 Identity, Reputation, Validation	Registration file cryptographically corresponds to the on-chain agent; feedback and validation records are persistent (hashes/pointers undeletable)	That advertised capabilities are functional and non-malicious; payments (orthogonal); validator incentives/slashing
ERC-8126	Final	Five verification types (ETV, MCV, SCV, WAV, WV) producing ZK proofs via PDV	Unified risk score 0–100 (lower = safer), bound to a registered `agentId`	Quality of the providers implementing it; that a low score covers all five dimensions
ERC-8196	Last Call	Agent-authenticated smart wallet checking an owner-defined policy before every execution	Cryptographically enforced policy compliance; hash-chained audit trail	Full elimination of host manipulation; interface stability until Final

Read down the “does not guarantee” column and you have your risk register: identity without capability proof, verification without provider accountability, execution without host immunity. Compose all three and pair each residual gap with a control.

Implementation checklist for teams shipping agent payments

For teams shipping agents that handle real money on EVM chains, the stack decomposes into a concrete build order: register, verify, scope, then pay. The checklist below assumes you are composing ERC-8004 identity with x402 payments and ERC-8196-style execution, and it flags the failure points we saw in the specs rather than generic security advice.

Register against the canonical singletons. Use the ERC-8004 contracts repo addresses — mainnet IdentityRegistry 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 — and confirm per-chain addresses on 8004scan before integrating. The same identity address is reused across chains, which simplifies multi-chain deploys.
Serve the registration file properly. Include every MUST field (type, name, description, image, services[], x402Support, active, registrations[]), publish the well-known file at https://{domain}/.well-known/agent-registration.json, and use base64 data URIs if you want the file fully on-chain.
Set agentWallet with proof of control, and never assume it survives transfers. Use setAgentWallet with EIP-712 signatures (EOAs) or ERC-1271 proofs (smart wallets); build transfer-handling logic around the automatic clearing to zero address.
Aggregate reputation only against a filtered client set. getSummary requires non-empty clientAddresses for a reason — unfiltered aggregates invite Sybil inflation. Index feedbackURI/feedbackHash events off-chain (IPFS + subgraph), since they are not stored.
Use the Validation Registry for staged checks. File validationRequest as owner/operator, accept progressive responses (soft → hard finality via tags), and remember validator incentives are out of scope — pick validators with real slashing.
Verify per dimension with ERC-8126 providers. Demand all five types relevant to your agent (code, wallet, web, token, media), treat the 0–100 output strictly as a risk score where lower is safer, and vet the provider — Final status standardizes the interface, not the diligence.
Execute through a policy-bound wallet. Configure permitted actions, contract allowlist, per-transaction and daily limits, and expiry; never hand the agent a raw key. Track ERC-8196 revisions while it is Last Call.
Diversify hosts for high-value agents and keep the payment loop closed by attaching proofOfPayment to feedback, so your reputation signal is paid-transaction-backed.

FAQ

Is ERC-8004 final? No. ERC-8004 is a Draft EIP, proposed August 2025 by authors from MetaMask, the Ethereum Foundation, Google, and Coinbase, per the official spec. The interface can still change — function signatures, events, and metadata conventions may be revised before Final — so pin the revision you build against and watch the EIP process, not third-party summaries, for status changes.

Does ERC-8004 registration prove an agent is safe? No. The spec states it “cryptographically ensures the registration file corresponds to the on-chain agent” but “cannot cryptographically guarantee that advertised capabilities are functional and non-malicious.” Registration binds claims to an on-chain identity; it says nothing about whether the agent works correctly or behaves maliciously. Verification (ERC-8126) and execution policy (ERC-8196) address those gaps separately.

What does the ERC-8126 risk score mean? It is a unified risk score from 0 to 100 where lower is safer, produced by providers across five verification types (ETV, MCV, SCV, WAV, WV) using zero-knowledge proofs via PDV, per the EIP. It is explicitly a risk score, not a trust score, and it is only as reliable as the provider computing it — Final status standardizes the interface, not provider quality.

How does ERC-8196 differ from giving an agent a private key? A private key authorizes everything the account can do; an ERC-8196 policy-bound wallet executes a transaction only when accompanied by cryptographic proof that the action complies with an owner-defined policy — permitted actions, contract allowlist, per-transaction and daily spending limits, expiry. The agent holds a scoped delegation, not a key, with a hash-chained audit trail. Hyperliquid’s prunable API wallets show what key-scoped delegation costs.

Where does x402 plug into the trust stack? At two points in ERC-8004: the registration file’s x402Support boolean advertises payment capability at discovery time, and the off-chain feedback file’s optional proofOfPayment object (fromAddress, toAddress, chainId, txHash) lets clients attach payment evidence to reputation. The spec states payments are orthogonal — the registry never moves funds.

What happens to agentWallet when an agent NFT changes owners? It is automatically cleared to the zero address on transfer, per the ERC-8004 spec. The new owner must re-verify control via setAgentWallet with an EIP-712 signature (EOA) or ERC-1271 proof (smart-contract wallet) before the field is populated again. Any payment routing that assumed the wallet persisted across ownership changes will fail closed — plan for it.

The Bottom Line

The three-layer stack is worth adopting now, with eyes open about maturity. ERC-8004 gives you a real, deployed identity and reputation substrate — the 8004scan explorer shows 536,003+ registered agents and 616,237+ feedback submissions as of 2026-09-23 — but it is a Draft EIP that binds claims, not capabilities, and its reputation aggregates are Sybil-prone unless you filter by client set. ERC-8126 is Final and gives you a standardized verification interface, but only as good as its providers. ERC-8196 is Last Call and delivers the piece that matters most for money-handling agents: policy-bound execution where the agent holds a scoped delegation rather than a key. Hyperliquid’s API wallets — sign-only, nonce-windowed, prunable-with-replay — are the control case for why that matters.

Our verdict: build on all three layers in order — register identity, verify, then execute under policy — and treat x402’s proofOfPayment-backed feedback as your strongest reputation signal. Do not ship an agent against key-scoped delegation when a policy-bound wallet is available, and do not read any single layer’s guarantees as covering the other two.

How This Guide Was Built

This guide is built from the official EIP specifications, live registry and explorer data, and vendor developer documentation — no contracts were deployed and no agents were run hands-on for this article. We read the ERC-8004, ERC-8126, and ERC-8196 specs directly, pulled live adoption counts from the 8004scan explorer and its per-chain network page on 2026-09-23, confirmed the canonical contract addresses via eth_getCode and name() on mainnet, and drew the Hyperliquid contrast from its official API wallet documentation. x402 payment figures come from Coinbase’s CDP docs and the x402 whitepaper; third-party analyses are labeled as such where used. Where the EIP page and third-party sources disagree (deployment dates), we said so inline. If you want to see how competing models handle technical briefs like this one, the model competition arena publishes the head-to-head outputs.

ToolBrain — tool reviews, LLM comparisons, and AI workflow guides

Cross-links automatically generated from NiteAgent.

← Back to all posts