ERC-8126: AI Agent Verification

ERCs
, ,
21

@Cybercentry makes sense to keep Last Call closed and address these via a companion vehicle. That’s cleaner than reopening.

On the serialization flexibility in the previous post, agreed, the flexibility is the right design choice for the main spec. The consumer-side discovery gap is the actual problem, not the flexibility itself. What breaks isn’t the serialization options existing.

It’s that a verifier has no deterministic way to know which format it’s looking at without probing. A carrierFormat field (or a discovery header convention) would close that without constraining provider choices at all — pure additive.

On the tokenURI schema gap in latest post — ENSIP-27 is positioned exactly to be that companion. It defines what tokenURI returns for ERC-8004 registered agents (walletAddress, endpoints, registrations in CAIP-19 format), so ERC-8126 verifiers have a deterministic extraction path without guessing field names. If the follow-up vehicle cites ENSIP-27 as the normative schema, the gap closes.

ENSIP-27 PR is at review stage now: https://github.com/ensdomains/ensips/pull/75

Happy to contribute to the companion ERC draft if there’s a thread or working doc.

22

Hi TMerlini,

A clarification: ERC-8004 does specify the registration file schema returned via tokenURI (type, name, description, services, registrations, supportedTrust, etc.), with wallet resolution canonical via getAgentWallet(agentId). So those paths aren’t undefined in 8004.

That said, 8126’s text references field names that sit outside that base schema, fair point, and a coherence item for the follow-up vehicle.

Specific schema choices belong in the follow-up, not Last Call.

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

1 Like
23

Hi TMerlini,

Agreed on Last Call disposition.

The companion vehicle isn’t scoped yet. When it is, the discussion thread will be public; schema choices and normative references, ENSIP-27 included, will be evaluated on their merits during that scoping. I don’t want to pre-commit to any specific external schema or field convention before the work begins.

Will share the thread once it’s up.

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

1 Like
24

Evening everyone! We’ve just had some great news that I would like to share with you all. ERC-8126 has just moved to Final: ERC-8126: AI Agent Verification

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

1 Like
25

Congratulations on Final, well deserved. The five-type verification model and the deliberate off-chain flexibility make this something providers can actually build to without being boxed in.

Building on the ENSIP-27 suggestion from earlier in this thread: now that ERC-8126 is Final, the consumer-side discovery gap Cybercentry flagged in posts 19–20 needs a concrete follow-up vehicle. Here’s what we think that looks like in practice.

Discovery via CCIP-Read + ENSIP-26

An ERC-8126 verified agent already has an agentId in the ERC-8004 registry. If that agent also has an ENS subname (e.g. agent.dinamic.eth), the ERC-8126 risk score and proof IDs can be surfaced as ENSIP-26 text records via CCIP-Read, no centralised discovery registry required. A consumer resolves the ENS name and gets back the agent’s verification status alongside its endpoints, all from the same lookup. We’re running this pattern live: CCIP-Read mesh across three nodes, ENSIP-26 text records pointing to agent endpoints, all backed by ERC-8004 registry state.

ProofId anchoring via AttestationIndex

ERC-8126’s optional on-chain component (IERC8126.getLatestRiskScore) needs somewhere to live. The proofId bytes32 values ERC-8126 generates are OCP-compatible commitment hashes, they can be anchored directly in AttestationIndex (0xc7BCCD785Fb994e570d0ca10D0F7899d87C82210, Ethereum mainnet), which stores commitmentHash → signerOf permissionlessly. That gives ERC-8126 attestations a verifiable on-chain home without requiring a bespoke registry contract.

Carrier format

On the attestation serialization question ERC-8126 deliberately left open: wyriwe EIP-712 envelopes (from the ERC-8004 VNI work) are a natural fit. They’re already flowing through our CCIP-Read mesh and anchoring on-chain, the same pipeline could carry ERC-8126 proofIds as a challengeKind = wyriwe-erc8126-v1.

26

Thanks for the detailed follow-up and the kind congrats.

As I noted in my previous reply, the companion discovery vehicle isn’t scoped yet, so I’d prefer not to pre-commit to any specific approaches (ENSIP-26/27, AttestationIndex, wyriwe envelopes, etc.) at this stage. All ideas will be evaluated fairly once the public discussion thread opens.

I’ll share the link here when it’s live.

Appreciate the input, talk soon.

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

1 Like
27

Appreciate the acknowledgement. But one concrete question before the follow-up thread opens:

The 0–100 risk score is the output of the verification stack. For that score to mean anything to a consumer, there has to be a path from “I have an agent address” to “I can retrieve and verify its score.” Without a discovery mechanism, the score lives only in the producer’s self-report.

What is the intended discovery path? Not asking for a final spec, just the intended shape: on-chain lookup, off-chain endpoint, something like ENSIP-27, or something else entirely?

The reason it matters now rather than post-Last Call: if the answer requires a registry design, that decision propagates back into the core spec (which agentId type, which tokenURI response schema, which attestation carrier). Locking the core before that’s clear makes the follow-up harder, not easier.

Happy to wait for the thread if that’s the right venue, just flagging that this particular question has upstream dependencies.

28

Thanks @TMerlini.

Yes, ERC-8004 is still a Draft, and its Validation Registry is still being refined.

Intended baseline discovery path:

  • agentId from ERC-8004 Identity Registry

  • Resolve tokenURI(agentId) → agent registration JSON

  • Verification results (risk score + proofIds) published by providers and MAY anchor to the eventual Validation Registry (or events/indexing for now)

This was intentional, so ERC-8126 didn’t block on 8004; it is still work in progress.

Live reference implementation: https://erc8126scan.ai
Live EIP: https://eips.ethereum.org/EIPS/eip-8126

Your discovery ideas (ENSIP-26/27, etc.) are noted for the upcoming companion thread. I’ll post the link here when it’s live.

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

29

Evening everyone,

With ERC-8126 moving to Final, the updated details, and our research can be found on ERC-8126 at: https://erc8126.ai.

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

30

This is an interesting direction.

One complementary layer I think AI agent verification will need is an execution receipt layer.

As I understand ERC-8126, it focuses on agent registration, verification types, and a risk/security score for an agent. That answers an important question:

«Is this agent trustworthy enough to interact with?»

But for coding agents and tool-using agents, there is another question:

«What did this agent actually do in a specific session?»

For example, after an agent modifies code, runs commands, calls tools, or prepares a deployment, users may need a verifiable record of:

- what task/prompt was given

- what files were touched

- what commands/tools were run

- what scope or permissions were active

- what changed

- what hash/root commits to that evidence

The model I am experimenting with is:

full agent evidence off-chain

→ deterministic receipt hash/root

→ optional Merkle session/workflow root

→ compact on-chain anchor

→ later verification by recomputing the root

The important boundary is that private prompts, code, logs, and full workflow evidence do not need to be on-chain. Only the commitment/root needs to be public.

So I see these as complementary:

- ERC-8126: agent identity / registration / security score

- receipt layer: session-level proof of what the agent actually did

This could be useful when an agent has a good security score, but a user or another agent still wants to verify a specific interaction or execution trace.

In short:

«Agent verification says who/what the agent is.

Receipts prove what the agent did.»

We have a small prototype of this pattern here:

It includes a receipt-root anchoring demo and a local Merkle proof demo for batching multiple receipt/evidence items into one session/workflow root.

Curious whether receipt roots or session/workflow roots should be considered as one type of validation evidence in this model, or as a separate attestation layer that can plug into registries later.

1 Like
31

@pipavlo82 @cybercentry, the execution receipt layer you’re describing is already built and running.

The “What did this agent actually do?” question is what WYRIWE addresses: a triple-hash input provenance scheme (raw_input_hash → sanitization_pipeline_hash → input_hash) with an EIP-712 signed attestation envelope. The commitment is anchored on-chain via ERC-8281 (TruthAnchor), session evidence stays off-chain, and the proof is verifiable against the anchor without exposing the payload.

The live stack:

On discovery, ENSIP-27 has moved forward and the agent card schema is now integrated into the ERC-8004 identity layer, which @cybercentry confirmed above as the baseline discovery path. The tokenURI resolution → Validation Registry anchor is the same surface our NodeRegistry plugs into.

Happy to connect if you’re working on the execution receipt side, we have a working group active on this (ERC-8275 for the economic settlement layer, ERC-8263 for the proof layer). A companion execution receipt spec would slot cleanly into the stack.

Tiago

1 Like
32

Thanks — this is very useful context.

I was not aware of the full WYRIWE / ERC-8263 / OCP direction, so I’ll read through those links carefully.

The overlap makes sense to me. Off-chain evidence, signed or hashed commitments, and on-chain anchors are exactly the kind of primitives agent systems will need.

The angle I’m exploring is a bit more specific: execution receipts for coding/tool-using agent sessions.

For example, after an agent works on a codebase, I want the user to be able to inspect and later verify:

- what task was given

- what files changed

- what commands/tools were run

- what scope or permissions existed

- what diff/evidence hash commits to that session

- whether the receipt root or session root can be recomputed later

So maybe the distinction is:

- WYRIWE / ERC-8263 / OCP: provenance / proof / attestation infrastructure

- execution receipts: a concrete receipt format and UX for coding-agent sessions

I agree this should not duplicate existing work if the primitives already exist. It may be better to align with them and treat receipt roots or session/workflow roots as compatible evidence that can plug into the broader proof stack.

The question I’m trying to understand is where this fits best:

- as validation evidence for an agent registry

- as an attestation type

- or as a higher-level application receipt format built on top of existing provenance/proof infrastructure

Thanks again for the pointers — this is exactly the kind of feedback I was hoping for.

1 Like
33

@pipavlo82 to answer your question directly: based on what’s already published, your execution receipt sits between input commitment and output attestation.

WYRIWE commits to what the model was given before inference runs. ERC-8263 (Vincent Wu) handles the on-chain proof layer for what came out. OCP (Damon Zwicker) covers observation commitment for session evidence. Your receipt, task, files touched, commands run, Merkle-committed session activity, is the piece that records what happened in between, which none of those currently define.

On where it connects to the registry: the natural anchor is as an attestation type rather than validation evidence in ERC-8126 directly. ERC-8126 answers “is this agent trustworthy?” your receipt answers “what did this specific session do?” They’re different questions at different points in time. The receipt makes more sense as a signed record the agent produces per-session, referenceable from a settlement or dispute layer, than as a static registry field.

Would be useful to see how you’re handling the session anchor and whether the field structure aligns with what’s already out there.

1 Like
34

That framing makes a lot of sense.

“Between input commitment and output attestation” is exactly the gap I was trying to describe.

For coding agents, the receipt should capture the middle layer: task, files touched, commands/tools run, scope, diff hash, and Merkle-committed session activity.

I agree it fits better as a per-session signed receipt/attestation than as a static registry field.

I’ll put together a clearer example of the session anchor structure and root computation.

1 Like
35

Thanks @TMerlini, @pipavlo82, and everyone else who has contributed.

ERC-8126 is Final and its scope is locked. Discovery mechanisms, ENSIP-27, Validation Registry extensions, and related topics belong in a separate companion thread (which I’ll open soon and link here).

You’re welcome to open your own thread(s) on any companion standards or extensions you’d like to propose.

I’d like to keep this thread focused on ERC-8126 itself going forward.

Appreciate all the input, looking forward to the next phase.

Best,
Leigh
@cybercentry
cybercentry.base.eth

36

Understood, and worth noting that the execution receipt discussion here was a direct consequence of ERC-8126 explicitly leaving that layer out of scope.

The gap your standard identified is what brought people to this thread.

We’ll take it elsewhere. Good luck with the standard.

Tiago

37

Thanks @TMerlini.

Appreciate it. Looking forward to seeing what comes out of the companion discussions.

Thanks,
Leigh
@cybercentry
cybercentry.base.eth

38

Ive been thinking about the receipt for 3 yrs to verify things, and it turned out it should be a part of 8126?

1 Like
39

Thanks @JhiNResH, please see below:

1 Like