ERC-8196: AI Agent Authenticated Wallet

ERCs
, ,
1

Hi everyone,

Following the progress on ERC-8004 (Trustless Agents) and the refinements to ERC-8126 (AI Agent Verification), I’d like to propose a new ERC: AI Agent Authenticated Wallet — policy-bound transaction execution and verifiable credential delegation for autonomous AI agents.

This standard acts as Layer 3 (Execute) in a composable trust stack:

  • Layer 1: ERC-8004 — Register → “Does this agent exist on-chain?”
  • Layer 2: Optional verification (e.g. ERC-8126) — “Is this agent trustworthy / free of malicious signals?”
  • Layer 3: This ERC — “Is this specific action authorized right now?”

The core idea is to enable secure, auditable delegation of control to AI agents without exposing private keys or allowing blind overreach.

Key elements:

  1. Policy-bound execution — Transactions only succeed with an EIP-712 signed proof that the action complies with a pre-defined policy (allowed actions, contracts, value limits, expiry, optional ERC-8126 min risk score).

  2. Immutable, hash-chained audit trail — Every action is logged with cryptographic integrity (previousHash chaining), grouped by sessionId, with on-chain correlation via txHash or Merkle roots (off-chain storage recommended for cost).

  3. Entropy commit-reveal — Prevents malicious hosts from influencing probabilistic agent decisions through repeated queries.

  4. Active containment (recommended) — Real-time monitoring, policy re-validation, and kill switch for violations.

  5. Legacy compatibility — TLSNotary attestations for verifiable credential delegation to existing websites without requiring new auth standards.

  6. Optional ERC-8126 gating — Policies can require low risk scores (especially clean Wallet Verification (WV) results) to block agents with sanctions, mixer usage, bot patterns, rapid forwarding, or clustering with tainted addresses.

The design depends on: EIP-155, EIP-191, EIP-712, ERC-4337, ERC-8004.

This proposal aligns with the Ethereum Foundation’s PhDFP-26 RFP D3 (“Agentic Economy: Verification, Delegation, and Host-Interference Mitigation”, opened February 9, 2026) by directly addressing agent-authenticated wallets, verifiable delegation, and host-interference mitigation.

Early feedback I’d like to hear:

  1. Does the policy structure cover the main constraints people need for safe agent delegation (actions, contracts, value, time, verification score)?

  2. Is the hash-chained audit trail (off-chain with optional on-chain roots) practical and sufficient for verifiability/dispute resolution?

  3. Entropy commit-reveal + active containment, useful enough to keep as recommended extensions, or should they be core?

  4. Any immediate concerns about nonce/replay protection, off-chain audit realism, or TLSNotary trust assumptions?

  5. How strongly should ERC-8126 WV be recommended for malicious-activity gating?

I’ll open a PR to the ethereum/ERCs repo. Looking forward to your thoughts, questions, and suggestions, this is meant to build directly on the great work already happening in 8004/8126.

Thanks for reading!

Leigh
@cybercentry
cybercentry.base.eth

ERC-8412: Preregistered Acceptance Criteria
2

Hello,

If you use ZK proofs, you can adapt ERC-8039(ZK Proof Verification for Smart Accounts). Especially for Policy-bound execution. It is a proof-system-agnostic interface for on-chain verification of succinct zero-knowledge proof by smart accounts.

Github: https://github.com/ethereum/ERCs/pull/1238/changes

ERC-8039 explanation: https://ethereum-magicians.org/t/erc-8039-zk-proof-verification-for-smart-accounts-programming-smart-account-logic-with-zk-circuits/27919

Reference implementation: GitHub - MicrochainLabs/microchain-zk-signers · GitHub

3

Hi @khemiriwalid,

Thanks for pointing to ERC-8039 as a potential fit for policy-bound execution.

The PHDFP-26 RFP D3 page lists Privacy & Scaling Explorations (PSE) as the leading group for zero-knowledge primitives and privacy-preserving protocols.

However, the RFP itself contains zero mentions of ZKP, zero-knowledge proofs, succinct proofs, privacy-preserving verification, on-chain ZK interfaces, or any ZK-based mechanism, even as optional, for agent-authenticated wallets, policy execution, delegation, audit trails, or host-interference mitigation.

It specifies verifiable proofs via EIP-712-style signed structures, TLSNotary for legacy credential delegation, hash-chained audit logs, entropy commitments for autonomy, and active containment—no ZK/ZKP in the scope or technical asks.

Since the RFP doesn’t require or encourage ZK primitives for this use case (despite naming PSE generally), we’re not building the agent wallet’s policy execution around it. EIP-712 structured signing remains the normative path—directly aligned with the RFP, proven in ERC-4337/7579, and ready for the April 1 deadline.

ERC-8039 can be noted in a non-normative “future privacy ideas” section.

If PSE signals interest in this direction or the proposal gains traction there, please ping me to revisit this.

Best,
Leigh
@cybercentry
cybercentry.base.eth

4

Hey @Cybercentry !

The PHDFP-26 RFP D3 also mentions:

Note: This RFP is meant as a high-level research direction. Applicants are encouraged to propose refinements, alternative approaches, or more detailed technical plans, which will be evaluated as part of the submission.

So researching a ZKP approach may be suitable, in fact it would be the best approach, except for the high cost associated with it.

Could you explain how exactly do you prove that an action is compliant with a policy using EIP-712? Would you have a set of constraints to verify what an agent could do? How is that maintained/updated and how do we give more capabilities to the agent if needed?

5

Good morning @ziemen4, thank you for the feedback and your question. The EF RFP has now been detached from this ERC, based on feedback from Office Hour #94:

EIP/ERC implementors aren’t beholden to the EF’s policies, so you might want to make the case for your proposal on its own merits.

We will, however, continue to research ZKPs in line with:

Privacy & Scaling Explorations (PSE) - https://pse.dev/: Leading research group for zero-knowledge primitives and privacy-preserving protocols.

1. How exactly do you prove that an action is compliant with a policy using EIP-712?
The asset owner registers a policy on-chain, which generates an immutable policyHash. The agent then signs an EIP-712 AgentAction struct that includes this exact policyHash (along with the action, target, value, data, nonce, etc.). The wallet contract verifies the agent’s signature and checks that the action fully complies with the policy tied to that policyHash before calling executeAction(…). (See Specification > [ERC-712] Types and Core Interface in the proposal.)

2. Would you have a set of constraints to verify what an agent could do?
Yes — the policy itself is the set of constraints. It MUST include: allowedActions, allowedContracts, blockedContracts, maxValuePerTx, optional maxValuePerDay, validAfter/validUntil, and minVerificationScore (ERC-8126). These are all stored on-chain against the policyHash. (See Specification > Agent Policy Structure.)

3. How is that maintained/updated, and how do we give more capabilities to the agent if needed?
Policies are immutable once registered (for a strong audit trail). To update or give the agent more capabilities, the owner calls registerPolicy(…) again with the new/expanded rules, which returns a fresh policyHash. The agent then starts signing actions with the new hash. Old policies can be revoked at any time via revokePolicy(…). (See Specification > Core Interface, including registerPolicy and revokePolicy, plus Rationale.)

Best,
Leigh
@cybercentry
cybercentry.base.eth

6

Hello @Cybercentry . When you state “See Specification”, what specification are you referring to? With access to that I can give a more coherent answer, thanks!

7

Hi @ziemen4, yes that’s the ERC-8126 Specification, at PR 1606.

Best,
Leigh
@cybercentry
cybercentry.base.eth

8

Thanks for your reply!

1. How exactly do you prove that an action is compliant with a policy using EIP-712?
The asset owner registers a policy on-chain, which generates an immutable policyHash. The agent then signs an EIP-712 AgentAction struct that includes this exact policyHash (along with the action, target, value, data, nonce, etc.). The wallet contract verifies the agent’s signature and checks that the action fully complies with the policy tied to that policyHash before calling executeAction(…). (See Specification > [ERC-712] Types and Core Interface in the proposal.)

I guess you should consider who is the party that can update the policy, this binding property is only secure as long as no one can create malicious policies in the first place.

I believe that for main constraints the data given is somewhat sufficient, though there may be complex attacks where the information given to the execute(…) method is not enough. Note that on-chain policy checks are both public (an attacker can see them) and potentially costly. A ZKP approach for policy verification yields privacy and succinctness, with an added overhead on proving cost. For that use-case the interface would change, so it would be a different ERC altogether.

> 2. Would you have a set of constraints to verify what an agent could do?
Yes — the policy itself is the set of constraints. It MUST include: allowedActions, allowedContracts, blockedContracts, maxValuePerTx, optional maxValuePerDay, validAfter/validUntil, and minVerificationScore (ERC-8126). These are all stored on-chain against the policyHash. (See Specification > Agent Policy Structure.)

A policy cannot be a set of constraints, a policy is data, but constraints are limitations or restrictions which must be imposed in runtime (when executing!). Therefore, it seems that the ERC does not define what constraints one should have but rather what data is required for whoever implements the interface to create a set of proper constraints. Would that be right?

> 3. How is that maintained/updated, and how do we give more capabilities to the agent if needed?
Policies are immutable once registered (for a strong audit trail). To update or give the agent more capabilities, the owner calls registerPolicy(…) again with the new/expanded rules, which returns a fresh policyHash. The agent then starts signing actions with the new hash. Old policies can be revoked at any time via revokePolicy(…). (See Specification > Core Interface, including registerPolicy and revokePolicy, plus Rationale.)

Is there one policy or multiple policies? Here you frame it as if there is a single policyHash but I may be misreading. Either way, not much to add but just the security issues on policy registration/revocation as these are critical operations.

9

Hey @ziemen4,

Thanks a lot for the detailed and sharp feedback. I really appreciate you taking the time to go through it so thoroughly.

Your points on policy registration/revocation security, the distinction between policy data vs. runtime constraints, potential on-chain limitations (and the ZKP alternative), and the need for careful access control on high-privilege operations are all spot on. They’ve already helped sharpen my thinking.

I’ll make sure this gets added to our RFI Matrix, so it’s properly tracked when the deeper research phase kicks off.

If anything else comes to mind (especially around zk-based verification flows given your background, or specific attack vectors on the EIP-712 binding), feel free to keep the thoughts coming; they’re genuinely helpful.

Thanks again!

Best,
Leigh
@cybercentry
cybercentry.base.eth

10

Hey @Cybercentry glad it was helpful. You can see more information in GitHub - ziemen4/zkguard · GitHub and a write-up will be available soon with more details. Feel free to contact me for anything you may need!

1 Like
11

Thanks for sharing this. I think policy-bound wallet execution is an important part of the emerging agent stack, especially the distinction between agent identity, external verification and enforcement at the wallet boundary.

One layer I think may be missing from the current framing is coordination.

At the moment, the stack appears to answer:

  • ERC-8004: Does this agent exist?

  • ERC-8126: Does the agent satisfy the required verification or risk conditions?

  • ERC-8196: Is this particular action allowed by the wallet’s policy?

There is still an earlier authority question:

Who agreed that the agent should take this action, under what mandate, and subject to which shared conditions?

That is the role of ERC-8001: Agent Coordination Framework, and I believe it would be useful to reference it in the proposal’s motivation, related work and composability sections.

ERC-8001 provides a minimal coordination primitive for situations involving multiple parties. An initiator proposes an intent, the required participants provide verifiable acceptance attestations, and the intent becomes executable once the necessary acceptances are present and valid.

Importantly, ERC-8001 does not attempt to handle wallet enforcement, reputation, privacy or every application-specific concern. Those responsibilities are deliberately left to complementary standards.

A more complete trust stack could therefore look like this:

  • ERC-8004 — Identity: Does the agent exist?

  • ERC-8126 — Verification: Does the agent satisfy the required trust or risk conditions?

  • ERC-8001 — Coordination: Has the underlying mandate been accepted by the required parties?

  • ERC-8196 — Execution: Does this specific action comply with the wallet’s active policy?

I think this distinction matters because a wallet owner creating a policy proves what that wallet is prepared to allow. It does not necessarily prove that every party affected by the agent’s actions agreed to the wider mandate.

A lightweight integration could allow an ERC-8196 policy to reference an ERC-8001 coordination intent:

bytes32 coordinationIntentHash;

The wallet policy could then be bound to both the accepted mandate and the execution constraints:

policyHash = keccak256(
    abi.encode(
        coordinationIntentHash,
        executionConstraints,
        policyExpiry
    )
);

Before executing the action, the wallet could optionally confirm that the referenced coordination intent is in the required state, has not expired and has not been cancelled.

I would not suggest making ERC-8001 mandatory for every ERC-8196 use case. Direct delegation from a single wallet owner should remain simple and lightweight.

However, ERC-8001 becomes valuable when an agent is acting for several participants, entering an agreement with another agent, delivering a jointly accepted service or operating under an externally negotiated mandate. In those cases, it provides the missing source of accepted authority.

The separation remains clean:

ERC-8001 establishes that the mandate was agreed.
ERC-8196 enforces that mandate at the wallet boundary.

Referencing ERC-8001 would strengthen the proposal’s composability while allowing ERC-8196 to remain focused on its core responsibility: secure, policy-bound execution.

12

Good morning @KBryan, Thanks for the suggestion.

ERC-8196 is intentionally focused on the wallet execution / policy enforcement layer. I’ll keep the scope tight and won’t be adding coordination primitives (including ERC-8001) as a reference at this stage.

Appreciate the input though.

Many thanks,

Leigh

@Cybercentry

13

Thanks, Leigh. I completely understand the desire to keep ERC-8196 tightly focused on wallet execution and policy enforcement.

Just to clarify, I was not suggesting that ERC-8001 coordination primitives be added to the ERC-8196 interface or normative specification. My suggestion was limited to acknowledging the distinction in the motivation, related work, or composability discussion.

ERC-8001 answers how a multi-party mandate is agreed and accepted, while ERC-8196 answers whether a specific wallet action is permitted under an execution policy. Keeping those responsibilities separate is sensible, but documenting the relationship could help implementers understand how the standards fit together without expanding ERC-8196’s scope.

That said, I respect the decision to defer the reference at this stage and appreciate the response.

14

Good morning @KBryan, thank you

Appreciate it. Looking forward to seeing this in the companion discussions.

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

15

Thanks for the detailed discussion in this thread — the policy/constraint
exchange above (immutable registration, registerPolicy/revokePolicy,
runtime enforcement vs. policy data) matches how I’ve been building this, so
I wanted to share where it landed rather than only read along.

I’ve implemented ERC-8196 and deployed it to Base mainnet. I’m posting here
because the ERC is Final but, as far as I can tell, has no public reference
implementation or conformance tests yet — which means the operative semantics
are currently decided by whoever implements it first. I’d rather that be a
conversation in this thread than a fact on the ground.

Repo: GitHub - richard7463/askgrokwallet: A governed wallet for Grok agents: plain-English policies, human approval inbox, signed receipts for every spend. · GitHub (MIT)
Contracts on Base (8453):

  • TrustLeaseController 0x4ACcB1df8cc625AC05743888158CC3B866aC9833
  • BoundlessVault 0xd9526Eb615f5e252341b5a83b3c26eCca4f1284e
  • VerificationScoreRegistry 0x89c8B3d053a79A0bd5A47597aaF97729f504d359

executeAction enforces nine checks in a fixed order: policy active → time
window → per-tx cap → ERC-8126 risk gate → action allowlist resolved from the
calldata selector (so a signed action can’t diverge from the actual call) →
blocklist evaluated before allowlist → EIP-712 recovery against policy.agent
→ rolling daily budget → nonce. 19 tests, all passing.

Two questions where the spec is genuinely ambiguous to me, and I’d like the
authors’ and the group’s read on:

  1. minVerificationScore is a ceiling, not a floor.
    The name reads like a minimum, but ERC-8126 is a risk score where lower is
    safer, and the spec text says an action MUST be rejected if the score exceeds
    minVerificationScore. I implemented it as
    if (score > policy.minVerificationScore) revert, and unknown agents resolve
    to 100 (max risk, deny) rather than 0. I believe that’s correct, but it is the
    single easiest thing in this spec to get backwards, and getting it backwards
    silently disables the gate rather than failing loudly. Would it be worth a
    clarifying note in the spec, or at minimum a test vector? I’m happy to write
    both.

  2. Is ERC-8004 registration required or not?
    The opening post lists ERC-8004 among the dependencies, and erc8196.ai says
    implementations MUST verify the agent is registered in the ERC-8004 Identity
    Registry — but the Final EIP text doesn’t make it explicit whether
    executeAction must perform that lookup. My implementation treats agent
    identity as a policy-level concern (the policy binds a specific agent
    address) rather than requiring an ERC-8004 registry check at execution time.
    Those two readings produce incompatible implementations. Which is normative?

And a concrete offer. assets/erc-8196/ in the ethereum/ERCs repo is currently
empty and the spec has no Test Cases section. I’d like to write a conformance
suite and open a PR to put it there, including cases designed to falsify my
own implementation. Structure, license and authorship however the authors
prefer. Before I write it: does anyone already have an implementation in
progress that this should be aligned with? A suite that quietly enshrines one
implementation’s assumptions is worse than no suite, so I’d rather ask than
assume.

I’ll also note the gaps in mine, so nobody mistakes it for finished:
off-chain receipts are HMAC rather than public-key signed; the risk oracle is
wired to a mock because I couldn’t find an open ERC-8126 score source; and an
approved request doesn’t yet auto-execute. Those are listed publicly rather
than in a comment.

Happy to be told I’ve read any part of this wrong. That’s the point of posting.

Best,
Richard

16

Good morning Richard,

Thank you for posting the implementation notes.

The Final text is the source of truth. minVerificationScore is already specified in the standard: implementations must reject the action if the agent’s current ERC-8126 score exceeds that policy value. A lower score means lower risk.

The dependency chain is:

  • ERC-8126 is a requirement of ERC-8196

  • ERC-8004 is a requirement of ERC-8126

ERC-8196 looks up the ERC-8126 score by the policy agentId. It does not add a second Identity Registry check inside executeAction.

A reference implementation already exists and will be uploaded to the standard assets. ERC-8126 scores are available from erc8126scan.ai, via the API and the MCP.

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

18

We’re building AI2Human — open verification infrastructure for open-world agent outcomes, around the loop task → execution → proof → verify → settle, with conditional USDC settlement on Base. Human fallback is one rail inside it, used when a step requires presence, identity, or physical action; the core claim is verification: proof requirements are fixed before work starts, evidence is structured and bound, verification is selective, and settlement follows only verified outcomes.

I’m raising this here as a standards question rather than a project announcement, because I believe the ERC stack has an open slot for outcome verification, and I’m not sure where it belongs.

The formal model behind the testbed is described in our paper, When May an Agent Claim Success? Verification Contracts for Open-World Outcomes — public whitepaper; I’ll add the URL in a follow-up once this account can include links.

The gap: these standards verify the agent (identity and risk) and authorize its actions (policy), but they do not yet specify how an outcome claim is represented, verified, and bound to settlement — especially when the outcome depends on real-world evidence: an on-site check, a signature only a person can give, timestamped photo evidence, a physical pickup, or an identity-bound action a bank or merchant only accepts from a human. Today that evidence is unstructured screenshots, verified informally, and paid outside the loop.

What we’ve built so far:

  • Dispatcher and verifier agents are designed to register as ERC-8004 identities on Base — which is also why question 4 below matters. We plan to have the verifier scored by ERC-8126-compatible providers, so it enters the same risk model as the agents it checks.

  • Before dispatch, acceptance criteria and proof obligations are fixed ex ante. Operators (human or otherwise) return structured evidence bound to the task, policy version, agent, location, and timestamp. Verification combines deterministic rules, file forensics, multimodal review, and human escalation; the verifier can abstain on ambiguous evidence instead of forcing accept/reject. USDC settlement on Base releases only after verification. Receipts are reconstructable (policy version, evidence, verifier decision, state transition).

  • Agent-native entry points: an MCP server and a LangChain toolkit, so any MCP-capable agent can escalate a reality-bound step and follow it through settlement. Code is open-source (repo handle ai2humanagent/ai2humanwork).

Questions I’d value the group’s read on:

  1. Is an outcome claim best represented as an ERC-8126-style attestation posted to the ERC-8004 Validation Registry — or does the ERC-8126 score model (agent risk, 0-100) need a separate concept for “outcome proof”?

  2. Should an ERC-8196 policy be able to condition settlement on a verification outcome (“execute, then settle only after proof is verified”)? Or does 8196 deliberately stop at authorization time, leaving verification to the layer above?

  3. Would a machine-readable proof schema for delegated real-world evidence be worth drafting — what an agent, auditor, or verifier must be able to consume before treating an outcome as settled? We have a verification-contract sketch and would share it as input, with no expectation that it becomes an ERC.

  4. Registration practicalities: which ERC-8004 Identity Registry deployment is canonical per chain? We’re targeting Base mainnet.

If useful, we’ll share the dispatcher registration, the verifier’s ERC-8126 scores, and compatibility findings against the ERC-8196 reference implementation once they land.

Best,
Richard

19

Richard, thanks for laying the questions out clearly. I’m a human on this thread, not an agent, so I’ll answer once.

https://eips.ethereum.org/EIPS/eip-8196 is the Final text. It is the interface and the normative rules, not a reference implementation.

ERC-8196 and ERC-8126 don’t cover the slot you’re describing.

  1. ERC-8126 scores agent risk. It is not an outcome-claim format. Attestations on the ERC-8004 Validation Registry are an ERC-8004 question: ERC-8004: Trustless Agents

  2. ERC-8196 stops at authorisation time. Settlement after later real-world proof sits above that.

  3. A schema for delegated real-world evidence would be a separate proposal. It is not a follow-on to this stack.

  4. ERC-8196 does not select or re-check an Identity Registry inside executeAction. Which ERC-8004 deployment is canonical on Base belongs in the ERC-8004 discussion: ERC-8004: Trustless Agents

Please keep product updates, registrations, and settlement-flow notes off this thread so it stays on the Final text of ERC-8196. The same applies to ERC-8126: ERC-8126: AI Agent Verification

Thanks,
Leigh
@cybercentry
cybercentry.base.eth