The Trust Stack
How Four ERC Standards Give
Anonymous AI Agents On-Chain Credibility

Pseudonymous humans and autonomous software agents look similar on a block explorer — both are just addresses — but they fail differently, and the standards stack in this article exists because of that difference. A human operating a pseudonymous wallet still faces a cost to spin up a new identity: time, reputation-building, and in the worst case a legal backstop that can eventually attach a real name to a persistent pattern of harmful behavior. An autonomous agent has none of that friction. Forking a new wallet and redeploying a model endpoint costs almost nothing, there is no natural rate limit on how many "identities" a single operator can spin up, and in most jurisdictions there is no legal person sitting behind the curtain to eventually hold accountable.

There is a second, subtler difference. A human's intentions are relatively stable from one transaction to the next. An agent's behavior is probabilistic — the same system prompt, run twice, can produce two different actions, and under adversarial conditions a jailbreak or a prompt-injection attack can push a well-intentioned agent into a transaction its owner never authorized. Trusting an agent the way you'd trust a known counterparty doesn't transfer cleanly, because there often isn't a stable "who" to trust in the first place — only a policy, a model, and a host that may or may not be faithfully relaying what the model actually decided.

Most agent frameworks in production today handle this badly in one of two ways. Some hand the agent process a raw private key directly: fast to build, and catastrophic the moment a prompt-injection payload embedded in a webpage or a tool response convinces the model to emit a transfer instruction. Others route execution through a hosting platform that holds the key on the user's behalf: this removes the key from the agent's immediate reach, but replaces it with a new single point of failure — the host can now suppress outputs, delay requests, or simply misrepresent what the agent decided, and the user has no cryptographic way to prove what actually happened. ERC-8196 has a precise name for this second failure mode: the hosting trust trap.

No single EIP solves the anonymity-credibility problem. Five standards — four requested here plus the identity registry underneath them — stack cleanly into four functional layers, though none of the authors coordinated them into one master proposal. They converge because the problem decomposes the same way every time an engineer sits down to solve it: an agent needs to be discoverable and addressable, it needs to own the intellectual property that constitutes it, it needs to be independently checkable for risk, and it needs to be constrained in what it can actually do with capital.

ERC-8004, "Trustless Agents," is the connective tissue underneath everything that follows, so it is worth a paragraph even though it is not one of the four standards this article centers on. It defines three registries on top of ERC-721: an Identity Registry that assigns each agent a globally unique agentId combining namespace, chain ID, and contract address, whose tokenURI (called the agentURI) resolves to a JSON registration file with endpoints and supported trust models; a Reputation Registry where any client can submit numerical feedback signals; and a Validation Registry where independent validators — including ERC-8126 verification providers — can record auditable verification results. Every function name referenced in the sections below that takes an agentId parameter is, ultimately, resolving against this registry.

ERC-7662 starts from a simple observation: for a large class of agents, the product is the prompt. A well-engineered system prompt, tool configuration, and model pairing represents real intellectual effort and is directly commercializable — but a vanilla ERC-721 with the prompt sitting in public token metadata defeats the entire business model the moment the token is listed, because anyone can read and clone it for free without buying anything.

interface IERC7662 is IERC721 {
    function getAgentData(uint256 tokenId) external view returns (
        string memory name,
        string memory description,
        string memory model,
        string memory userPromptURI,
        string memory systemPromptURI,
        bool promptsEncrypted
    );

    event AgentUpdated(uint256 indexed tokenId);
}

Each token carries a model identifier (for example gpt-4-0125-preview or claude-3-opus-20240229), and two URIs — userPromptURI and systemPromptURI — pointing at decentralized storage. The recommended architecture encrypts both before upload and ties decryption capability to ownerOf(tokenId), so that transferring the NFT transfers decryption rights atomically with ownership — the same trick NFT-gated content platforms use, applied to a prompt instead of a media file. The standard also mandates a ${variableName} syntax for injectable runtime parameters, so downstream tooling — a web form, an agent runtime, an MCP server — can recognize and substitute dynamic values without parsing free text.

The limitation is structural, not incidental: mapping-tied encryption is a convention, not a proof. Nothing in ERC-7662 requires a seller to have actually re-encrypted the underlying data for the buyer's key at the moment of transfer — transferFrom()only moves a token ID, and says nothing about the payload it is supposed to represent. A buyer has no cryptographic way to confirm the encrypted content they now "own" is current, correctly re-keyed, or not simply corrupted. That gap is exactly what the next standard closes.

ERC-7857, "AI Agents NFT with Private Metadata," formalizes exactly the gap ERC-7662 leaves open. It treats an agent's memory, model weights, and character definition as IntelligentData that must be provably re-encrypted and handed over on every transfer — not implied by a naming convention, but demonstrated through an off-chain prover and on-chain verifier pattern supporting two oracle types: Trusted Execution Environments (TEE) and zero-knowledge proofs (ZKP).

struct IntelligentData {
    string dataDescription;
    bytes32 dataHash;
}

struct AccessProof {
    bytes32 oldDataHash;
    bytes32 newDataHash;
    bytes nonce;
    bytes encryptedPubKey;
    bytes proof;
}

struct OwnershipProof {
    OracleType oracleType;      // TEE or ZKP
    bytes32 oldDataHash;
    bytes32 newDataHash;
    bytes sealedKey;
    bytes encryptedPubKey;
    bytes nonce;
    bytes proof;
}

struct TransferValidityProof {
    AccessProof accessProof;
    OwnershipProof ownershipProof;
}

The main IERC7857 interface exposes four distinct operations, each answering a different question about who can do what with an agent's data: iTransfer() moves ownership and re-encrypts the underlying data for the recipient, verified through a TransferValidityProof[]; iClone() duplicates the data to a new token while the original owner retains theirs — useful for licensing a fine-tuned copy of an agent without losing the master; authorizeUsage() grants usage rights without transferring ownership at all, the equivalent of renting an agent rather than buying it; and delegateAccess() assigns an assistant for access verification, foreshadowing the execution-delegation problem ERC-8196 solves in full.

Replay protection relies on nonce tracking with a time-bounded expiration window, cleared via cleanExpiredProofs(); sealed-key changes and ownership changes are required to be atomic and independently verifiable, so a proof cannot be partially applied.

Owning a well-encrypted, provably-transferable agent NFT says nothing about whether that specific agent is safe to interact with today. ERC-8126, "AI Agent Verification," is the layer that answers exactly that — deliberately specified as an off-chain verification standardwith an optional on-chain attestation hook, so routine checks don't need to be gas-metered to be standardized.

The flow is mandatory and deliberately closes a spoofing hole: a verification provider must call tokenURI(agentId) on the ERC-8004 Identity Registry and resolve the returned metadata — direct parameter submission without an agentId is explicitly prohibited. This means a verifier can never be tricked into scoring metadata that was never actually bound to the agent on-chain.

The overall risk score is the arithmetic mean of the five sub-scores on a 0–100 scale, bucketed for straightforward interpretation: 0–20 low risk, 21–40 moderate, 41–60 elevated, 61–80 high, 81–100 critical. Two optional layers extend this: Private Data Verification (PDV) generates zero-knowledge proofs of the verification results without exposing the underlying sensitive data, which matters for GDPR-adjacent compliance and eliminates a whole category of breach risk; and Quantum Cryptography Verification (QCV), an optional quantum-resistant layer using AES-256-GCM that returns an encrypted record_id and decryption_urlfor long-horizon security against Shor's-algorithm-class threats to current elliptic curve cryptography.

interface IERC8126 {
    event AgentVerified(
        uint256 indexed agentId,
        uint8 overallRiskScore,
        bytes32 etvProofId,
        bytes32 mcvProofId,
        bytes32 scvProofId,
        bytes32 wavProofId,
        bytes32 wvProofId,
        bytes32 summaryProofId
    );

    event AttestationPosted(
        uint256 indexed agentId,
        uint8 riskScore,
        bytes32 proofId
    );

    function getLatestRiskScore(uint256 agentId) external view returns (uint8);
}

Verification results may optionally post as attestations to ERC-8004's Validation Registry, making a risk score portable and discoverable across any application that reads the same registry rather than trapped inside one provider's dashboard. Providers may charge gasless fees using EIP-3009's TransferWithAuthorization for USDC settlement, and the standard is explicitly provider-agnostic — any entity can implement a compliant verification service, which is meant to produce competition and specialization rather than a single gatekeeper.

That single line does more work than most of the standard's prose. A wallet can be compromised the day after a clean WV check; an endpoint can be hijacked the week after a passing WAV result. The standard's own security section treats re-verification as a first-class operational requirement, not an edge case — which is precisely the hook ERC-8196 uses to make a risk score actionable in real time rather than a one-time gate.

A perfectly verified agent — an ERC-8126 score of 5, comfortably "low risk" — is still just a number you have to trust was computed and interpreted correctly. It says nothing about what the agent will actually be permitted to do with your funds tomorrow. ERC-8196, "AI Agent Authenticated Wallet,"is the layer that turns a risk score into an enforceable, revocable, funds-bounded contract. The standard explicitly frames itself as Layer 2 (Execute) of a two-layer trust stack, sitting directly on top of ERC-8126 as Layer 1 (Identify & Verify) — the difference between a background check and an employment contract with a termination clause.

function registerPolicy(
    address agent, uint256 agentId,
    string[] calldata allowedActions,
    address[] calldata allowedContracts,
    address[] calldata blockedContracts,
    uint256 maxValuePerTx, uint256 maxValuePerDay,
    uint256 validAfter, uint256 validUntil,
    uint8 minVerificationScore
) external returns (bytes32 policyHash);

function executeAction(
    bytes32 policyHash, address target, uint256 value,
    bytes calldata data, uint256 nonce,
    bytes32 entropyCommitment, bytes calldata signature
) external returns (bool success, bytes32 auditEntryId);

function revokePolicy(bytes32 policyHash, string calldata reason) external;

event ActionExecuted(
    bytes32 indexed policyHash, address indexed agent,
    address target, uint256 value, bytes32 auditEntryId
);

error PolicyViolation(bytes32 policyHash, string reason);
error ValueExceedsLimit(uint256 value, uint256 maxValue);

Every call to executeAction() requires an EIP-712-signed action referencing policyHash, checked against expiration, value caps, and the contract allow/block lists — and critically, against a live call to getLatestRiskScore(agentId) on ERC-8126. If the agent's current score has degraded past minVerificationScoresince the policy was registered, execution is rejected automatically — a policy can suspend an agent's spending authority without any human noticing the degradation first.

The entropyCommitmentparameter is the standard's answer to probabilistic host manipulation: the agent (or its host) commits to a random seed before generating its proposed action, then reveals it at execution time, and the contract checks the reveal against the earlier commitment. A malicious host cannot generate several candidate outputs, see which one would be scored most favorably or execute most profitably for the host, and submit that one after the fact — the randomness is locked in before the model runs.

Every executed action is written to a hash-chained audit trail — each AuditEntryLogged event carries a previousHash, a sequence number, and a session ID. Implementations may store entries off-chain (IPFS is the natural choice) and anchor periodic Merkle roots on-chain to keep gas costs manageable, while any tampering with the off-chain log breaks the hash chain and is immediately detectable without needing to store every entry on Ethereum itself. revokePolicy() is callable by the owner at any time, and because every subsequent action requires a live policy check, revocation takes effect immediately — a real kill switch, not a request the agent has to agree to honor.

Consider a protocol treasury that wants to run an autonomous market-making agent against its stablecoin reserves. The five standards above compose into a single lifecycle, each one handing a verifiable artifact to the next.

// 1. ERC-8004 — mint identity
const agentId = await identityRegistry.register(agentURI);

// 2. ERC-7857 — commit encrypted IP, provable on future transfer
const dataHash = await agentNFT.iClone(agentId, {
  intelligentData: [{ dataDescription: "system-prompt", dataHash: hash(prompt) }],
});

// 3. ERC-8126 — independent risk score, resolved via agentId only
const { overallRiskScore } = await verifier.verify(agentId); // reads tokenURI(agentId)

// 4. ERC-8196 — treasury binds an enforceable envelope
const policyHash = await wallet.registerPolicy(
  agentAddress, agentId,
  ["swap", "rebalance"],
  [aaveRouter, curvePool], [],
  parseEther("50000"), parseEther("250000"),
  now, now + THIRTY_DAYS,
  20 // minVerificationScore — "low risk" bucket only
);

// 5. ERC-8196 — agent proposes, contract checks live score + policy at execution time
const { success, auditEntryId } = await wallet.executeAction(
  policyHash, curvePool, rebalanceValue, calldata,
  nonce, entropyCommitment, agentSignature
);

Notice what nobody in this flow ever needs to know: the treasury never learns the operator's legal identity. It only needs an agentId, a risk score computed against verifiable metadata, and a policy contract that refuses to execute anything outside its bounds regardless of what the agent — or a hostile host — tries to submit. That is what "credibility without identity" actually means in practice. The stack substitutes provenance-of-behavior, checkable in a single transaction, for provenance-of-person, which was never actually available for a pseudonymous counterparty anyway.

A stack that claims to make anonymous agents credible deserves the same scrutiny it applies to the agents themselves. Four gaps are worth building around rather than assuming away.

There is a fifth gap worth naming even though no panel above covers it cleanly: cross-chain fragmentation. An agentIdunder ERC-8004 is scoped to namespace, chain ID, and contract address — an agent operating identically across five chains today needs five separate identities, with no native standard for linking them into one reputation surface. Anyone building a multi-chain agent product should plan to solve that stitching problem themselves; it isn't covered by any of the four standards above.

For a team deciding whether to let an autonomous agent touch real capital, the sequencing below matters more than any individual integration detail.

Teams with an existing ERC-4337 smart account stack will move fastest, since ERC-8196 is written to compose directly with account abstraction rather than requiring a parallel wallet system. Teams starting from a raw EOA-per-agent model should expect the migration to policy-bound execution to be the largest single piece of work in this roadmap — and the piece with the highest payoff if the agent is ever compromised.