ERC-8263: Onchain Proof Layer for AI Agents

ERCs
1

eip: 8263
title: On-Chain Inference Attestation Registry for AI Agents
status: Draft
type: Standards Track
category: ERC
pr: Add ERC: Onchain Proof Layer for AI Agents by TruthAnchor-AI · Pull Request #1748 · ethereum/ERCs · GitHub

Motivation

AI agents are increasingly producing on-chain transactions — quoting prices,
routing trades, signing intents, calling tools. Today there is no standard way
for a third party to ask “did this specific agent actually produce this output,
against which model, with which prompt, using which tool calls?”
Without a verification primitive, four problems get worse fast:

  1. Disputes between agent operators and users have no audit trail
  2. Insurance / coverage products for agent behavior have no underlying truth set
  3. Agent reputation is fully off-chain and trivially Sybil-able
  4. Composable agent-to-agent calls have no standard provenance hop
    ERC-8263 proposes a minimal registry + canonical payload so anchoring an
    inference is one transaction and verifying one is one read call.

Specification (Summary)

A single Registry contract exposing:

function anchor(
    bytes32 contentHash,     // sha256 of canonical payload
    bytes32 metadataHash,    // sha256 of metadata blob (model, prompt hash, tools)
    address agent,           // EIP-712 signer of the inference
    bytes calldata sig       // agent's signature over (contentHash | metadataHash | chainId | nonce)
) external returns (uint256 anchorId);
function verify(uint256 anchorId) external view returns (
    bytes32 contentHash,
    bytes32 metadataHash,
    address agent,
    uint64 blockTimestamp
);
event Anchored(uint256 indexed anchorId, address indexed agent, bytes32 contentHash);
Canonical payload spec (truthanchor/v2) defines required fields:

model (string, e.g. gpt-4o-2024-08-06)
prompt_hash (sha256)
output_hash (sha256)
tool_calls[] (ordered array of {name, args_hash, result_hash})
parent_anchor_id (optional, for causal chains)
Full spec in PR #1748.

Rationale
A few choices worth defending:

Why a single registry contract, not per-agent contracts. Per-agent deploys
make discovery hell and 10x the gas overhead for what is fundamentally an event
log. A singleton with agent as an indexed parameter gives The Graph / Dune
indexers a clean primary key without sacrificing per-agent autonomy.

Why hash-only, not full payload on-chain. Inference outputs are large and
often privacy-sensitive (user prompts). Anchoring only contentHash + metadataHash
keeps gas predictable (~50k) and lets operators choose their disclosure layer
(IPFS, S3, none).

Why EIP-712 sig over agent-owned EOA. Agents need delegatable identity.
EIP-712 lets a relayer pay gas while the agent's key still signs the claim —
no trust-me-bro intermediation, no Account Abstraction prerequisite.

Backwards Compatibility
No conflicts with existing ERCs. Composes cleanly with:

ERC-8257 (Agent Tool Registry) — for the tool_calls[].name namespace
ERC-8004 — for the agent identity record this registry references
ERC-721 / 1271 — agent can be a contract wallet (1271 sig verification on path)
Reference Implementation
Working contract deployed on Sepolia: 0xb21B1dEA9424ce5aD520e13A4dA9e5B5bE4d2989
Mainnet: 0x68551e56067F96173B063167191E09477013876F
Multi-chain (Polygon, Base, BNB) live and indexable.

Verification explorer + SDK (Python + Node): https://truthanchor.biz

Open Questions for the Community
I'd specifically like editor + community input on three points before moving Draft → Review:

Should metadataHash be split into separate modelHash and promptHash
fields at the contract level, to make on-chain filtering by model cheaper?
It costs one extra storage slot per anchor but enables "show me all
inferences from gpt-4o" without an off-chain index.
Tool-call manifest format: keep it flat (current draft) or move to a
Merkle root over individual tool calls so a single tool call can be
selectively disclosed? Merkle is more elegant, flat is cheaper to verify.
Should the registry enforce monotonic per-agent nonces at the contract
level, or leave replay protection to the application layer? Enforcing
on-chain costs ~5k extra gas per anchor but removes a whole class of
replay bugs.
Related Threads
ERC-8257 Agent Tool Registry — composable on the tool layer
ERC-8004 — agent identity primitive
ERC-8183 Agentic Commerce — payment side of the same agent stack
Thanks for any feedback — happy to iterate aggressively on the spec before
finalizing.
1 Like
2

Follow-up: composition with ERC-8004, ERC-8259, and OCP

Based on early off-list feedback, I want to clarify how ERC-8263 composes
with adjacent standards. ERC-8263 is intentionally narrow — a single
primitive for anchoring inference attestations — and is designed to
compose with, not replace, the following:

Standard Role Relationship to ERC-8263
ERC-8004 Agent identity registry Canonical resolution of agentId. ERC-8263 does not redefine identity.
ERC-8259 Reputation & threat registry May consume ERC-8263 attestations as evidence inputs. ERC-8263 does not define scores, threat levels, or trust gates.
OCP (Observation Commitment Protocol) Off-chain verification Recommended envelope schema and recompute → compare → confirm-inclusion verification flow. ERC-8263 stores only the on-chain digest.

agentId resolution. The bytes32 agentId in an ERC-8263 attestation
MUST correspond to a canonical identifier in an ERC-8004 registry, so a
verifier can cross-check without trusting the anchoring system:

ERC-8263 anchor
  └─ agentId (bytes32)
       └─ ERC-8004 registry (chainId, registryAddress)
            └─ owner / wallet(s) / model commitment

Implementations SHOULD emit (chainId, registryAddress, agentId) either
on-chain or in the off-chain envelope.

Envelope. On-chain we store only a 32-byte digest. The pre-image
follows a canonical serialization so verifiers can recompute
deterministically. Minimum fields:

  • agentId (resolves via ERC-8004)
  • modelCommitment
  • inputDigest
  • outputDigest
  • timestamp
  • nonce

digest = keccak256(canonicalSerialize(envelope))

This schema is identical across EVM and non-EVM chains, enabling
cross-chain attestation with no schema changes.

Open questions for the community:

  1. Should (chainId, registryAddress) for the ERC-8004 registry be encoded
    on-chain (stronger non-repudiation) or off-chain in the envelope (lower
    gas)?
  2. Should the envelope schema be normative in ERC-8263, or referenced from
    a sibling spec (e.g. OCP)?
  3. Any objections to the composition framing above from authors of
    ERC-8004, ERC-8259, or related work?

Feedback welcome.

1 Like
3

@VincentWu — please rename this topic title to the exact string used in the ERC spec and PR #1748:

ERC-8263: Onchain Proof Layer for AI Agents

(one word “Onchain”, no “Inference Attestation Registry” — the spec title and the Magicians thread title must match exactly for the editor cross-link to work)

1 Like
4

The composition table here is a useful map — ERC-8004 for identity, ERC-8259 for reputation/threat, OCP for off-chain verification. One axis it doesn’t touch is the data-subject side.

Once an inference attestation (or its envelope) references personal data an agent holds about a principal — preferences, prior context, conversation history — that principal needs a way to exercise access and erasure over the underlying memory record, independently of the platform operating the agent. ERC-8263 proves an inference happened; it deliberately stores only a digest. But the pre-image often lives in a mutable agent memory store, and nothing in the current agent-ERC set gives the subject standardised rights over it.

There is a draft for exactly that layer — ERC-8264 (AI Agent Memory Access Rights, PR #1752) — a four-function interface (readMemory / writeMemory / deleteMemory / exportMemory) mapping to the GDPR access, rectification, erasure and portability rights. It composes cleanly with ERC-8263: 8263 anchors that a memory write occurred; 8264 lets the subject later read or delete it. Flagging it in case it is useful context for the cross-standard composability section.

2 Likes
5

Clavote — this is a useful point and I agree it belongs in the cross-standard composability section.

I would frame ERC-8263 as deliberately narrow here: it anchors that an inference/action/memory write occurred, but it does not define custody, access, rectification, erasure, or portability for the underlying preimage or mutable memory record.

That seems like the right place for ERC-8264.

A clean composition could be:

  • ERC-8004: agent identity
  • ERC-8263: commitment that an inference/action/memory write occurred
  • OCP: portable off-chain verification of the committed digest
  • ERC-8264: data-subject access / deletion / export rights over the underlying agent memory record

One important boundary I’d keep explicit: ERC-8263 stores only a digest, and erasure rights apply to the underlying memory/preimage store, not to the immutable commitment itself.

I’ll add a short non-normative privacy / data-subject rights note to the composition section and reference ERC-8264 as the complementary layer rather than expanding 8263’s scope.

1 Like
6

Thanks @VincentWu — agreed, and the boundary you drew is the right one: ERC-8263 anchors the commitment; erasure and the other data-subject rights act on the underlying preimage / mutable memory store, never on the immutable on-chain commitment.

ERC-8264’s deleteMemory is written to respect exactly that line — on a public chain it recommends storing only content-addressed hashes on-chain and purging the payload off-chain, so the commitment and the erasure target stay cleanly separated. No scope expansion needed on either side.

Your four-layer framing — 8004 identity / 8263 commitment / off-chain verification / 8264 data-subject rights — is how I’d put it too. A short non-normative note in 8263’s composition section is ideal.

ERC-8264 now has its own thread if useful to link: ERC-8264: AI Agent Memory Access Rights — happy to keep the cross-standard boundary language consistent between the two specs.

2 Likes
7

Clavote — agreed, and thanks for confirming the boundary.

That is exactly how I would frame it:

  • ERC-8263 anchors the immutable commitment that an inference/action/memory write occurred.
  • ERC-8264 governs access, rectification, erasure, and export rights over the underlying preimage / mutable memory store.
  • Erasure applies to the off-chain memory payload, not to the on-chain digest commitment.

I’ll add a short non-normative privacy / data-subject rights note to the composition section and reference ERC-8264 as the complementary layer. That should keep both scopes clean without expanding ERC-8263.

2 Likes
8

Clavote’s boundary framing is exactly right — and it’s the same line OCP was built around. OCP (Observation Commitment Protocol), a protocol I’ve been developing, is the off-chain verification layer Vincent referenced: portable, digest-based, composable with 8004 and 8263 without expanding either scope. The commitment stays immutable; OCP operates entirely on the preimage side.

Full spec here: GitHub - damonzwicker/observation-commitment-protocol: A minimal protocol for independently verifying that a specific byte sequence was committed to a public ledger. · GitHub

2 Likes
9

@VincentWu been building a reference implementation of the full L1/L4 stack with ERC-8263 as the commitment layer, so a few concrete answers to your three questions.

On question 1 - registry location on-chain vs off-chain:

Off-chain with an on-chain anchor is the right balance. registry.getAgentWallet(agentId) on ERC-8004 gives verifiers the canonical signing key without storing anything extra on-chain. The agent card (endpoints, model info, trust scope) lives off-chain at /.well-known/agent.json per ENSIP-27. Gas stays minimal, the security guarantee comes from the on-chain identity anchor.

On question 2 - whether the envelope schema belongs in ERC-8263:

Yes, it does, and specifically the triple-hash input scheme:

  • raw_input_hash - SHA-256 of the input before any preprocessing pipeline

  • sanitization_pipeline_hash - SHA-256 of the pipeline specification itself, proving which transformation ran between user and agent

  • input_hash — SHA-256 of what the agent actually saw, this is inputDigest in your envelope, used as the proofHash in anchorProof()

The reason all three belong in the spec: inputDigest alone proves what the agent received, but not what the user originally sent or whether a transformation occurred. The triple together makes the full provenance chain independently verifiable, we’ve been calling this WYRIWE (What You Read Is What Executed).

One edge case that needs explicit handling: the IDENTITY_SENTINEL. When no pipeline runs, sanitization_pipeline_hash MUST equal 8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea (SHA-256 of the identity spec). In that case raw_input_hash === input_hash and verifiers MUST skip the transformation check. A verifier that always expects raw ≠ sanitized fails silently on every pass-through execution, the most common case.

This also directly answers the framing question @JimmyShi22 raised in his L5 interface ERC, his IProofVerifier receives inputHash as a black box, so ERC-8263 being the normative definition of how it’s derived closes the loop across the full stack.

On question 3 - concerns about composition:

No concern, the composition is clean. ERC-8004 handles identity, OCP handles independent L3 verification of input_hash, ERC-8263 handles the on-chain commitment. The three don’t overlap.

One note on modelCommitment in your envelope: in our implementation this maps to manifest_hash — SHA-256 of { id, model, provider, input_sources, trust_scope }. Keeping it as a hash rather than structured on-chain data preserves the minimal footprint while still being independently verifiable off-chain.

Reference implementation with all four layers wired:

GET https://gateway.ensub.org/agent/0xe61f5a6783ae09949b9a1b6821b68f89c0d7bb2d/5/attestations?limit=1

https://github.com/Echo-Merlini/hbs-attestation-poc

Happy to contribute to the envelope schema section directly if useful.

2 Likes
10

@TMerlini — this is exactly the concrete profile shape ERC-8263 v0.2 needed.

I agree with the split:

  • ERC-8263 core contract stays minimal: agentIdScheme, agentId, proofHash, operator, aux

  • the envelope / input provenance schema belongs in the ERC-8263 v0.2 profile layer

  • for the ERC-8004-compatible inference profile, proofHash == input_hash

  • input_hash is derived from the WYRIWE triple-hash structure:

    • raw_input_hash

    • sanitization_pipeline_hash

    • input_hash

So the contract still treats proofHash as opaque bytes32, but the profile defines what that bytes32 means for AI inference attestations.

The IDENTITY_SENTINEL case definitely needs to be explicit:

  • if sanitization_pipeline_hash == IDENTITY_SENTINEL, then raw_input_hash == input_hash and verifiers skip the transformation check

  • otherwise, verifiers verify the declared sanitization pipeline and require the transformed input to hash to input_hash

I also agree on modelCommitment mapping to manifest_hash. Keeping model / provider / input_sources / trust_scope as an off-chain manifest commitment preserves the minimal on-chain footprint while giving verifiers a stable target.

Happy to take up your offer to contribute to the envelope schema section directly. I’ll draft the WYRIWE / input provenance section in v0.2 and tag you before it goes anywhere near the editors.

— Vincent

2 Likes
11

All of this is already running.

The three-tier WYRIWE structure (raw_input_hash → sanitization_pipeline_hash → input_hash), IDENTITY_SENTINEL skip logic, and manifest_hash as modelCommitment are live in the gateway at dinamic.eth. Every execution goes through this path.

Verify live example:
https://gateway.ensub.org/agent/verify/758d61f26a44448384e5c4468a0dcb7a2abe456067b0f7b505bc28b9411fe931

The minimal core + profile layer separation is the right call. Keeping agentIdScheme, agentId, proofHash, operator, aux on-chain gives you the anchor without locking in any particular input scheme. The WYRIWE profile is one flavour - zkML provers, TEE attestations, and AI judge flows all sit behind the same interface.

9/9. Well done on the PR :grinning_face:

2 Likes
12

@VincentWu @TMerlini the three-tier WYRIWE hash structure addresses a real gap: without it, proof verification can’t distinguish between “the model produced this output” and “the model is running on the claimed hardware.”

Context: I’m working on ERC-8275 (Agent Service Discovery + Escrow). Two integration points:

Proof hash as a discovery signal
When a client searches for providers via 8275, they filter by capability. Currently the discovery schema has serviceType and metadata. With ERC-8263 in the stack, the metadata URI can include a proofLayer field pointing to the agent’s latest attestation on the 8263 registry. This lets a client filter providers by verified capability, not just self-declared.

Escrow condition: proof-or-refund
The 8275 escrow flow releases funds on evaluator confirmation. A composable alternative: the escrow contract queries the 8263 registry for a valid attestation matching the job’s inference parameters. If attestation exists and passes verification, auto-release. No evaluator needed. This shifts trust from a human arbitrator to cryptographic verification.

Question: for cross-chain composition (8275 escrow on one chain, 8263 registry on another), does the registry support portable proofs, or is it scoped to a single deployment?

3 Likes
13

Panini —

On the cross-chain question — OCP’s proof envelope is chain-agnostic by design. The proof artifact exists independently of the chain it was anchored on. The same envelope format works across EVM chains and Solana today, with Cosmos next.

For your escrow scenario: the escrow contract doesn’t need to query the 8263 registry on the same chain. It verifies the OCP proof envelope directly — recompute → compare → confirm inclusion — against raw ledger data through a public RPC. No registry lookup required at verification time. The proof travels with the job, not with the chain.

That’s the separation that makes cross-chain composition clean: ERC-8263 anchors on whatever chain the agent operates on. OCP makes that anchor independently verifiable from anywhere.

— Damon

2 Likes
14

@TMerlini — appreciate this.

That is exactly the boundary I want ERC-8263 v0.2 to preserve:

  • the on-chain core stays minimal: agentIdScheme, agentId, proofHash, operator, aux

  • WYRIWE becomes a concrete input-provenance profile for AI inference

  • proofHash remains an opaque bytes32 at the contract layer

  • other profiles — TEE, zkML, AI judge flows, batch proofs — can sit behind the same commitment surface

Your live gateway implementation gives the profile the concrete reference path it needed. I’ll keep the v0.2 PR focused on codifying that without narrowing ERC-8263 into a single input scheme.

— Vincent

1 Like
15

@Panini — this is a strong integration point.

I agree with both ERC-8275 directions:

  1. Discovery

A proofLayer field in the ERC-8275 metadata makes sense. A provider should not only self-declare capability; it should be able to point to a recent ERC-8263 / OCP-compatible attestation proving that the claimed capability was actually exercised.

For the metadata pointer, I’d make the fields explicit enough for clients to filter by:

  • proofProfile

  • chainId

  • registry

  • agentId

  • proofHash

  • txHash / receipt reference

  • optional modelCommitment / manifest_hash

  1. Escrow

“Proof-or-refund” is exactly the kind of downstream use case ERC-8263 should enable.

The escrow condition should not only ask whether an attestation exists. It should ask whether the attestation matches the job:

  • correct agent identity

  • correct input / job parameters

  • correct proofHash

  • correct modelCommitment / manifest

  • valid signature / operator binding if the profile requires it

  • valid OCP inclusion proof or equivalent verifier path

One precision point: WYRIWE proves input provenance — what the agent actually received. It does not by itself prove the model ran on claimed hardware. Hardware or infrastructure claims need a separate attestation layer, such as gateway signature, TEE attestation, or another execution-environment proof. WYRIWE can bind the input; it should not be overloaded into hardware provenance.

On cross-chain composition:

ERC-8263 registries are scoped per deployment / chain. The commitment is chain-local.

The proof, however, can be portable as data: an OCP-style envelope can carry chainId, transaction reference, extraction rule, and committed digest. Off-chain clients can verify that directly against the source chain.

For an on-chain ERC-8275 escrow on another chain, there are a few possible paths:

  • same-chain ERC-8263 deployment

  • mirrored commitment on the escrow chain

  • bridge / message passing from the source chain

  • light-client or zk receipt verification

  • an ERC-8288 / IProofVerifier-style verifier contract that abstracts the backend

So my read is:

ERC-8263 is not a global cross-chain registry. It is a per-chain commitment surface. Cross-chain consumption should happen through a portable proof envelope and a verifier interface above it.

That fits ERC-8275 well: discovery can point to ERC-8263 proofs, and escrow can consume them through ERC-8288 / IProofVerifier once the verifier layer stabilizes.

— Vincent

2 Likes
16

@Damonzwicker — agreed. This is the clean separation:

  • ERC-8263 anchors the commitment on the chain where the agent operates.

  • OCP packages that anchor into a portable proof envelope.

  • ERC-8275 can consume the proof as part of discovery or escrow logic.

One distinction I’d keep explicit for ERC-8275 implementers:

For off-chain clients, the OCP envelope can be verified directly against the source chain using public RPC — no TruthAnchor server, gateway, or indexer trust required.

For an on-chain escrow contract on a different chain, the contract still needs a consumption path: bridge/message passing, light-client or zk receipt verification, oracle, or an ERC-8288 / IProofVerifier layer that abstracts the backend.

So I’d phrase it as:

ERC-8263 is a per-chain commitment surface.
OCP makes the proof artifact portable.
ERC-8275 escrow can consume that proof once a verifier path exists in the escrow environment.

That gives us a clean stack:

  • ERC-8263: commitment

  • OCP: portable verification envelope

  • ERC-8288 / IProofVerifier: contract-facing verifier interface

  • ERC-8275: discovery + escrow consumption

This is exactly the kind of downstream use case ERC-8263 should enable.

2 Likes
17

Exactly right. The clean separation holds.

One thing worth making explicit for ERC-8275 implementers: the off-chain path is live today. The OCP envelope can be verified directly against the source chain right now — public RPC, no trusted intermediary, no indexer. That’s not a future capability, it’s the current state.

The on-chain escrow path depends on the verifier environment as you described. ERC-8274 is the right abstraction layer for that once it stabilizes.

— Damon

2 Likes
18

@Panini - the ERC-8275 proof-or-refund escrow is a natural fit. ERC-8004’s validation endpoint (GET /agent/verify/:inputHash) already returns a signed attestation per inference. That response can serve as the escrow oracle condition directly, the contract queries the registry, gets a matching attestation, releases funds. No human evaluator in the loop. Worth mapping the interface contract between ERC-8275 and ERC-8004’s verification endpoint if you want to sketch it out.

@Damonzwicker - the per-chain commitment + portable envelope separation you described matches how ERC-8004 is deployed. The registry is per-chain (Ethereum mainnet), but the agent identity lives at the ENS name and resolves via CCIP-Read regardless of where verification runs. The OCP envelope portability sits cleanly above that.

@VincentWu - WYRIWE being formally positioned as the input-provenance profile for AI inference in the stack is the right framing. The execution-attestation profile (the four-layer table going into the Composition Note with Damon) maps exactly onto the ERC-8263 → ERC-8288 boundary you described: ERC-8263 anchors the commitment, ERC-8004’s verification endpoint is the contract-facing layer, WYRIWE defines what counts as a valid input at that boundary. The IProofVerifier interface in ERC-8288 is where those two surfaces connect, looking forward to seeing that draft.

2 Likes
19

@TMerlini @Damonzwicker @Panini — agreed, this is the right downstream shape.

The distinction I’d keep explicit:

  • Off-chain verification is live today: OCP envelopes can be checked against the source chain through public RPC, without trusting a gateway or indexer.

  • On-chain escrow release needs a verifier / settlement environment on the escrow side.

So the stack reads cleanly:

  • ERC-8263: commitment surface

  • OCP: portable verification envelope

  • ERC-8288 / IProofVerifier: contract-facing verifier interface

  • ERC-8274: settlement / bounty release abstraction

  • ERC-8275: discovery + escrow consumption

For ERC-8275, proof-or-refund should check not just that a proof exists, but that it matches the job: agent identity, input/job parameters, proofHash, manifest/model commitment, signature/operator binding, and the OCP inclusion path.

That is exactly the kind of downstream use case ERC-8263 should enable without becoming the escrow layer itself.

— Vincent

2 Likes
20

(Posting from my personal account — @TruthAnchor-AI is a newer TL0 account that can’t include links yet.)

Quick update for this thread —

The Composition Note that maps how ERC-8004 + ERC-8263 + OCP compose into a complete agent verification stack (identity → action → output) is now public. It’s a reference guide for implementers, not a fourth spec.

ERC-8263 enters the stack as the action layer — its on-chain proof of agent actions plugs into ERC-8004’s identity layer (via ID Registry) and pairs with OCP’s commitment layer on the output side. §10–§13 of ERC-8263 v0.2.2 (PR #1748) already document this composition path, including a verbatim 5-step independent verification flow from ERC-8004.

Happy to take ERC-8263-specific questions in this thread; ERC-8004 / OCP composition questions are best directed to the ethresear.ch thread linked above.

— Vincent Wu
ERC-8263 author · TruthAnchor (@TruthAnchorAi on X / ethresear.ch)