Composition Note: ERC-8004 + ERC-8263 + OCP — A reference guide for implementers building on the AI agent verification stack

Architecture
1

Co-authored with @TruthAnchorAi (Vincent Wu — ERC-8263) and @tmerlini (Tiago Merlini — ERC-8004 / WYRIWE). Full document also available at: composition-note-8004-8263-ocp.md · GitHub

Composition Note: ERC-8004 + ERC-8263 + OCP

A reference guide for implementers building on the AI agent verification stack

Co-authored by:

  • Vincent Wu — ERC-8263 (Onchain Proof Layer for AI Agents)

  • Damon Zwicker — Observation Commitment Protocol (OCP)

  • Tiago Merlini — ERC-8004 / WYRIWE / execution-attestation profile

The proof stack

This note describes how five lanes compose into a complete proof stack for AI agent actions:

Lane Specification / Implementation Role
Identity ERC-8004 — Tiago Merlini et al. who is the agent
Commitment ERC-8263 — Vincent Wu / TruthAnchor what the agent committed
Verification Observation Commitment Protocol — Damon Zwicker how anyone verifies the digest independently from chain state alone
Persistence HBS image provenance — Tiago Merlini and @wgw_eth how the proof travels with the artifact
Reference workflow TruthAnchor implementation surface composing the four above; not a normative requirement of any of them

The first three lanes form the core protocol stack. Each has a single, independent job, and the full attribution–commitment–verification chain requires them acting together; applications may adopt any subset of the stack but should not expect the chain to hold without the corresponding layer. HBS is a non-normative artifact-layer extension on top of that core, not a fourth normative protocol layer — it makes the committed payload portable across distribution channels, while identity resolution and on-chain inclusion still require the underlying public chain data. TruthAnchor is listed separately as a reference workflow to make the spec/implementation boundary explicit: ERC-8263 governs the contract semantics; TruthAnchor is one deployment of that semantics, not the spec itself.

This note is descriptive, not normative. Each underlying specification governs itself; the composition described here is a guide to clean co-deployment, not a meta-standard.

The problem

AI agents increasingly perform consequential actions — trading, governance, content generation, autonomous decisions. There is no standard way to bind an agent identity to an independently verifiable commitment about an action, input, output, or observation — without relying on the system that produced the record.

Three complementary standards address this together.

The three standards

ERC-8004 — Agent Identity Registry

Establishes on-chain identity for AI agents. An agent is a registered token with a canonical wallet, a bound collection, and a resolvable manifest.

What it answers: Who is this agent?

Reference: ERC-8004

ERC-8263 — Onchain Proof Layer

Provides a minimal interface for committing action digests on-chain, linked to agent identity. The agentIdScheme discriminator provides a first-class on-chain bridge to ERC-8004.

function anchor(
    uint8 agentIdScheme,
    bytes32 agentId,
    bytes32 proofHash
) external;

function anchorWithAux(
    uint8 agentIdScheme,
    bytes32 agentId,
    bytes32 proofHash,
    bytes calldata aux
) external;

event AnchorProof(
    uint8           agentIdScheme,
    bytes32 indexed agentId,
    bytes32 indexed proofHash,
    address indexed operator,
    bytes           aux
);

agentIdScheme registry:

Scheme Name agentId derivation
0x00 ANONYMOUS agentId MUST be bytes32(0)
0x01 REGISTRY bytes32(uint256(erc8004AgentId)) — 32-byte zero-padded ERC-8004 (or compatible) record id
0x02 URI_HASH keccak256(canonical agent URI)
0x03+ reserved rejected at contract level

aux: aux is profile-defined opaque bytes. ERC-8263 does not assign canonical semantics to it, and commitment semantics MUST NOT depend on it. Profiles may use aux for session IDs, parent-proof references, OCP envelope pointers, Merkle proofs, or other contextual metadata. The contract does not impose an on-chain size cap, but clients and indexers MAY enforce profile-specific size limits or refuse oversized aux.

What it answers: What did this agent commit, and when?

Reference: ERC-8263

OCP — Observation Commitment Protocol

Defines how a committed digest is independently verified against raw ledger data. No trusted SDK, gateway, or indexer required; verification can be performed from raw ledger data through a public RPC.

recompute → compare → confirm inclusion

What it answers: Can I verify this independently, without trusting anyone?

Reference: OCP

How they compose

┌─────────────────────────────────────────────────────┐
│                   Application Layer                  │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│  ERC-8004 — Identity                                 │
│  Who is the agent? Registry lookup, wallet, manifest │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│  ERC-8263 — Commitment                               │
│  anchor(agentIdScheme, agentId, proofHash)           │
└──────────────────────┬──────────────────────────────┘
                       │
┌──────────────────────▼──────────────────────────────┐
│  OCP — Verification                                  │
│  recompute → compare → confirm inclusion in tx       │
└─────────────────────────────────────────────────────┘

proofHash = H(canonical observation bytes), where H is defined by the proof profile. For the TruthAnchor / OCP path, H = SHA-256.

Each layer is independently verifiable. None absorbs the semantics of the others.

End-to-end flow

Commitment (write side):

  1. Agent executes an action against an observation

  2. proofHash = H(observation) — raw bytes, algorithm defined by proof profile

  3. anchor(agentIdScheme, agentId, proofHash) called on-chain (ERC-8263)

  4. OCP proof envelope constructed from the transaction receipt

Verification (read side):

  1. Verifier receives: observation + OCP proof envelope

  2. H′ = H(observation) — recomputed independently using declared hash function

  3. H′ == proofHash — compared against envelope value

  4. proofHash ∈ R(tx) — confirmed in raw transaction receipt

  5. agentId resolved according to agentIdScheme: for 0x01, resolution goes through ERC-8004; for 0x02, agentId is keccak256(canonical agent URI); for 0x00, no identity resolution applies

Result: Independent, system-agnostic proof that a digest was committed on-chain under an agent identity reference. Attribution to a specific agent depends on the ERC-8004 / ERC-8263 identity and operator-binding rules used by the verifier.

What each standard does NOT do

Standard Out of scope
ERC-8004 Does not define commitment or verification
ERC-8263 Does not define verification procedure or proof format
OCP Does not define identity, authorship, sanitization, or data availability
HBS Does not define identity, commitment, or verification — carries the proof only

Note: Persistence Layer (non-normative)

The core stack described above — ERC-8004 for agent identity, ERC-8263 for on-chain commitment, and OCP for independent digest verification — operates at the protocol and ledger layer. A complementary persistence primitive has emerged from independent work by Tiago Merlini and @wgw_eth: HBS image provenance embedding. HBS operates at the artifact layer by encoding attestation or provenance data directly into image pixels or PNG metadata, allowing the proof payload to travel with the artifact after it leaves the contract, gateway, or application. HBS does not replace identity, commitment, or verification. It makes the embedded payload portable; full verification may still require public chain data such as registry resolution or transaction inclusion checks. This is a non-normative observation: HBS is not part of the core three-layer stack, but it demonstrates a natural extension path for implementations that need portable, self-describing artifacts such as badges, score cards, reports, or provenance images.

Reference: hbs-attestation-poc

Identity sentinel

When no sanitization pipeline is applied, sanitization_pipeline_hash MUST be the IDENTITY_SENTINEL:

8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea

SHA-256 of the identity spec. Surfaced by Tiago Merlini in the ERC-8263 ↔ ERC-8004 alignment thread; documented here so verifiers handle the pass-through case explicitly. The verifier-branching invariant is codified in ERC-8263 v0.2 Appendix A.2; specific SENTINEL values are profile-declared.

The value 8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea is the OCP-profile-specific SENTINEL. Each profile SHOULD declare its SENTINEL value explicitly so verifiers can branch correctly.

Verifier branching invariant:

  • sanitization_pipeline_hash == IDENTITY_SENTINEL → raw_input_hash == input_hash, skip sanitization transformation verification

  • sanitization_pipeline_hash != IDENTITY_SENTINEL → verify the transformation defined by the sanitization pipeline and require the transformed input to hash to input_hash

Verifiers that do not implement this branch will incorrectly reject pass-through executions.

Cross-chain compatibility

OCP’s proof envelope is chain-agnostic. The same format works across EVM chains and Solana (devnet verified May 2026). ERC-8263 product anchoring deployments: Polygon, Base, and BNB Smart Chain mainnets plus Sepolia testnet. Polygon, Base, and BNB Smart Chain deployments are verified on their respective chain explorers. The Ethereum Mainnet V1 reference contract (0xe95d6a15...) is Etherscan-verified and serves as the canonical reference deployment; it is not the default user anchor path. ERC-8004 is EVM-native. Cross-chain deployments of ERC-8263 and ERC-8004 are outside the scope of this note.

Reference implementations

Standard Reference
ERC-8004 gateway.ensub.org · attestation: GET /agent/{registry}/{agentId}/attestations · sentinel-aware verifier: GET /agent/verify/:inputHash · live example: https://gateway.ensub.org/agent/verify/758d61f26a44448384e5c4468a0dcb7a2abe456067b0f7b505bc28b9411fe931
ERC-8263 truthanchor.biz · ETH Mainnet V1: 0xe95d6a15…eb5ec3d (Etherscan Exact Match, v0.8.19, no optimizer, MIT) · L2 mainnets (Polygon/Base/BSC): 0x87dd3A56AFD0D2c488aD7E13fB036b59144b25dC (verified on respective chain explorers)
OCP GitHub - damonzwicker/observation-commitment-protocol: A minimal protocol for independently verifying that a specific byte sequence was committed to a public ledger. · GitHub
HBS GitHub - Echo-Merlini/hbs-attestation-poc · GitHub

OCP verifier: npm install -g ocp-verify

ERC-8004 reference execution-attestation profile

Co-authored with Tiago Merlini.

This section describes a reference execution-attestation profile built around ERC-8004, WYRIWE, OCP, and EIP-712 gateway attestations. It is not a replacement for the core ERC-8004 / ERC-8263 / OCP composition table above. The core table describes the minimal composition needed for “an agent committed something, and anyone can verify it independently.” For deployments built on the ERC-8004 identity registry with gateway-mediated execution (the reference deployment pattern at gateway.ensub.org), a fuller four-layer view surfaces an additional axis the core table abstracts away: whether the execution infrastructure itself attests to the action, separately from whether the digest is committed.

Layer Specification Role Trust model
L1 — Identity ERC-8004 Who is the agent — registered token, canonical wallet, resolvable manifest on-chain, trustless
L2 — Input Trust ERC-8263 with the WYRIWE input-provenance profile (github.com/TMerlini/wyriwe, Appendix A.2) What the agent actually received — raw_input_hash → sanitization pipeline → input_hash binding; IDENTITY_SENTINEL pass-through invariant when no sanitization is applied off-chain pipeline, on-chain committed hash
L3 — Commitment Verification OCP Trustless verification of input_hash from chain state alone — recompute → compare → confirm inclusion; no SDK or gateway required fully trustless, public RPC
L4 — Infrastructure Attestation EIP-712 InferenceAttestation over gateway key, with gateway key resolved via ERC-8004 getAgentWallet Which execution infrastructure processed and signed the action — gateway as attestor, not agent self-signing; the L3/L4 gap is visible by construction infrastructure trust, gateway as notary

Why a fourth layer

L3 answers “was this digest committed under this agent identity?” — a trustless question. L4 answers “did this specific execution infrastructure process the input that produced the digest?” — an infrastructure-trust question that L3 deliberately abstracts away.

Surfacing L4 explicitly does two things:

Makes the L3/L4 gap legible. Verifiers that need only “digest was committed” stop at L3. Verifiers that need “and the named gateway attested processing” continue to L4. The gap is not a flaw — it is the transparency signal: a deployment that ships L1–L3 without L4 has chosen not to commit to an infrastructure attestor, and that choice is now visible.

Separates self-signing from notary signing. When the gateway key binds via ERC-8004 getAgentWallet, the attestation is signed by the infrastructure, not by the agent itself. This matches the practical deployment shape: agents do not hold persistent keys; gateways do.

What this profile is not

Not a normative addition to ERC-8263, ERC-8004, or OCP. The three core standards remain unchanged; this profile composes them.

Not a mandate that every ERC-8263 deployment carry an L4 attestation. Anchors without L4 attestation are still valid ERC-8263 anchors with the standard L1–L3 trust model.

Not equivalent to ERC-8263’s full profile space. WYRIWE is one of three profiles documented in Appendix A.2 of ERC-8263 v0.2 (alongside the single observation digest profile and the Merkle batch root profile); the input-trust framing of L2 above applies specifically when the WYRIWE profile is in use.

Reference implementation

L1 + L4 binding: GET gateway.ensub.org/agent/{registry}/{agentId}/attestations returns EIP-712 InferenceAttestation payloads signed under the gateway key resolved through ERC-8004 getAgentWallet.

L2 + L3 verification: GET gateway.ensub.org/agent/verify/:inputHash (live example) performs the recompute → compare → confirm path against the on-chain ERC-8263 anchor.

Related future extensions

The following are under active development and will be referenced in future revisions of this note once stable:

  • ERC-8274 — AI Inference Proof Verification Interfaces (Jimmy Shi): contract-facing IProofVerifier interface layer above ERC-8263

  • ERC-8275 — Agent Service Discovery + Escrow (Panini): discovery and proof-or-refund escrow consuming the L3/L4 stack

  • BountySettlement — reference on-chain bounty settlement contract keyed on input_hash (Tiago Merlini + Jimmy Shi): gist.github.com/TMerlini/bf3abd30c332cccb257d0e5bdff1ff95

  • @wgw_eth — HBS / persistence alignment

Status

Publication-ready — all three co-authors confirmed. ERC-8004 reference execution-attestation profile section incorporated (Vincent Wu + Tiago Merlini). ERC-8263 v0.2 live (PR #1748, 9/9 CI green). WYRIWE ERC draft live ( GitHub - TMerlini/wyriwe: WYRIWE — What You Read Is What You Execute: input-provenance profile for verifiable AI inference · GitHub ). ERC-8274 v0.1 live (PR #1771). This note will be updated as the specs evolve. It is intended as a living reference for implementers, not a normative document.

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