{"slug": "composition-note-8004-8263-ocp-md", "title": "composition-note-8004-8263-ocp.md", "summary": "Three complementary Ethereum standards — ERC-8004, ERC-8263, and the Observation Commitment Protocol (OCP) — compose into a complete proof stack for AI agent actions, providing on-chain identity, commitment, and verification without relying on the system that produced the record. ERC-8004 establishes on-chain identity for AI agents as registered tokens with canonical wallets and resolvable manifests, while ERC-8263 provides a minimal interface for committing action digests linked to that identity. OCP enables independent verification of the commitment digest from chain state alone, with HBS image provenance extending the stack to make committed payloads portable across distribution channels.", "body_md": "*A reference guide for implementers building on the AI agent verification stack*\n\nCo-authored by:\n\n- Vincent Wu — ERC-8263 (Onchain Proof Layer for AI Agents)\n- Damon Zwicker — Observation Commitment Protocol (OCP)\n- Tiago Merlini — ERC-8004 / WYRIWE / execution-attestation profile\n\nThis note describes how five lanes compose into a complete proof stack for AI agent actions:\n\n| Lane | Specification / Implementation | Role |\n|---|---|---|\n| Identity | ERC-8004 — Tiago Merlini et al. | who is the agent |\n| Commitment | ERC-8263 — Vincent Wu / TruthAnchor | what the agent committed |\n| Verification | Observation Commitment Protocol — Damon Zwicker | how anyone verifies the digest independently from chain state alone |\n| Persistence | HBS image provenance — Tiago Merlini and @wgw_eth | how the proof travels with the artifact |\n| Reference workflow | TruthAnchor | implementation surface composing the four above; not a normative requirement of any of them |\n\nThe 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.\n\nThis 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.\n\nAI 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.\n\nThree complementary standards address this together.\n\nEstablishes on-chain identity for AI agents. An agent is a registered token with a canonical wallet, a bound collection, and a resolvable manifest.\n\n**What it answers:** Who is this agent?\n\nReference: [ERC-8004](https://ethereum-magicians.org/t/erc-8004-trustless-agents/25098)\n\nProvides a minimal interface for committing action digests on-chain, linked to agent\nidentity. The `agentIdScheme`\n\ndiscriminator provides a first-class on-chain bridge\nto ERC-8004.\n\n```\nfunction anchor(\n    uint8 agentIdScheme,\n    bytes32 agentId,\n    bytes32 proofHash\n) external;\n\nfunction anchorWithAux(\n    uint8 agentIdScheme,\n    bytes32 agentId,\n    bytes32 proofHash,\n    bytes calldata aux\n) external;\n\nevent AnchorProof(\n    uint8           agentIdScheme,\n    bytes32 indexed agentId,\n    bytes32 indexed proofHash,\n    address indexed operator,\n    bytes           aux\n);\n```\n\n**agentIdScheme registry:**\n\n| Scheme | Name | agentId derivation |\n|---|---|---|\n| 0x00 | ANONYMOUS | agentId MUST be bytes32(0) |\n| 0x01 | REGISTRY | `bytes32(uint256(erc8004AgentId))` — 32-byte zero-padded ERC-8004 (or compatible) record id |\n| 0x02 | URI_HASH | keccak256(canonical agent URI) |\n| 0x03+ | reserved | rejected at contract level |\n\n**aux:** aux is profile-defined opaque bytes. ERC-8263 does not assign canonical\nsemantics to it, and commitment semantics MUST NOT depend on it. Profiles may use\naux for session IDs, parent-proof references, OCP envelope pointers, Merkle proofs,\nor other contextual metadata. The contract does not impose an on-chain size cap,\nbut clients and indexers MAY enforce profile-specific size limits or refuse oversized\naux.\n\n**What it answers:** What did this agent commit, and when?\n\nReference: [ERC-8263](https://github.com/ethereum/ERCs/pull/1748)\n\nDefines 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.\n\n```\nrecompute → compare → confirm inclusion\n```\n\n**What it answers:** Can I verify this independently, without trusting anyone?\n\nReference: [OCP](https://github.com/damonzwicker/observation-commitment-protocol)\n\n```\n┌─────────────────────────────────────────────────────┐\n│                   Application Layer                  │\n└──────────────────────┬──────────────────────────────┘\n                       │\n┌──────────────────────▼──────────────────────────────┐\n│  ERC-8004 — Identity                                 │\n│  Who is the agent? Registry lookup, wallet, manifest │\n└──────────────────────┬──────────────────────────────┘\n                       │\n┌──────────────────────▼──────────────────────────────┐\n│  ERC-8263 — Commitment                               │\n│  anchor(agentIdScheme, agentId, proofHash)           │\n└──────────────────────┬──────────────────────────────┘\n                       │\n┌──────────────────────▼──────────────────────────────┐\n│  OCP — Verification                                  │\n│  recompute → compare → confirm inclusion in tx       │\n└─────────────────────────────────────────────────────┘\n```\n\nproofHash = H(canonical observation bytes), where H is defined by the proof profile. For the TruthAnchor / OCP path, H = SHA-256.\n\nEach layer is independently verifiable. None absorbs the semantics of the others.\n\n**Commitment (write side):**\n\n- Agent executes an action against an observation\n`proofHash = H(observation)`\n\n— raw bytes, algorithm defined by proof profile`anchor(agentIdScheme, agentId, proofHash)`\n\ncalled on-chain (ERC-8263)- OCP proof envelope constructed from the transaction receipt\n\n**Verification (read side):**\n\n- Verifier receives: observation + OCP proof envelope\n`H′ = H(observation)`\n\n— recomputed independently using declared hash function`H′ == proofHash`\n\n— compared against envelope value`proofHash ∈ R(tx)`\n\n— confirmed in raw transaction receipt`agentId`\n\nresolved according to`agentIdScheme`\n\n: for`0x01`\n\n, resolution goes through ERC-8004; for`0x02`\n\n, agentId is`keccak256(canonical agent URI)`\n\n; for`0x00`\n\n, no identity resolution applies\n\n**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.\n\n| Standard | Out of scope |\n|---|---|\n| ERC-8004 | Does not define commitment or verification |\n| ERC-8263 | Does not define verification procedure or proof format |\n| OCP | Does not define identity, authorship, sanitization, or data availability |\n| HBS | Does not define identity, commitment, or verification — carries the proof only |\n\nThe 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.\n\nReference: [hbs-attestation-poc](https://github.com/Echo-Merlini/hbs-attestation-poc)\n\nWhen no sanitization pipeline is applied, `sanitization_pipeline_hash`\n\nMUST be the IDENTITY_SENTINEL:\n\n```\n8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea\n```\n\nSHA-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.\n\nThe value `8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea`\n\nis the OCP-profile-specific SENTINEL. Each profile SHOULD declare its SENTINEL value explicitly so verifiers can branch correctly.\n\nVerifier branching invariant:\n\n`sanitization_pipeline_hash == IDENTITY_SENTINEL`\n\n→`raw_input_hash`\n\n==`input_hash`\n\n, skip sanitization transformation verification`sanitization_pipeline_hash != IDENTITY_SENTINEL`\n\n→ verify the transformation defined by the sanitization pipeline and require the transformed input to hash to`input_hash`\n\nVerifiers that do not implement this branch will incorrectly reject pass-through executions.\n\nOCP's proof envelope is chain-agnostic. The same format works across EVM chains\nand Solana (devnet verified May 2026). ERC-8263 product anchoring deployments:\nPolygon, Base, and BNB Smart Chain mainnets plus Sepolia testnet. Polygon, Base,\nand BNB Smart Chain deployments are verified on their respective chain explorers.\nThe Ethereum Mainnet V1 reference contract\n(`0xe95d6a15...`\n\n) is Etherscan-verified and serves as the canonical reference\ndeployment; it is not the default user anchor path. ERC-8004 is EVM-native.\nCross-chain deployments of ERC-8263 and ERC-8004 are outside the scope of\nthis note.\n\n| Standard | Reference |\n|---|---|\n| ERC-8004 | gateway.ensub.org · attestation: `GET /agent/{registry}/{agentId}/attestations` · sentinel-aware verifier: `GET /agent/verify/:inputHash` · live example:\n|\n| ERC-8263 | truthanchor.biz · ETH Mainnet V1:\n|\n\nOCP verifier: `npm install -g ocp-verify`\n\n*Co-authored with Tiago Merlini.*\n\nThis 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.\n\n| Layer | Specification | Role | Trust model |\n|---|---|---|---|\n| L1 — Identity | ERC-8004 | Who is the agent — registered token, canonical wallet, resolvable manifest | on-chain, trustless |\n| L2 — Input Trust | ERC-8263 with the WYRIWE input-provenance profile (\n|\n\nL3 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.\n\nSurfacing L4 explicitly does two things:\n\n**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.\n\n**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.\n\nNot a normative addition to ERC-8263, ERC-8004, or OCP. The three core standards remain unchanged; this profile composes them.\n\nNot 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.\n\nNot 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.\n\nL1 + L4 binding: `GET gateway.ensub.org/agent/{registry}/{agentId}/attestations`\n\nreturns EIP-712 InferenceAttestation payloads signed under the gateway key resolved through ERC-8004 getAgentWallet.\n\nL2 + L3 verification: `GET gateway.ensub.org/agent/verify/:inputHash`\n\n([live example](https://gateway.ensub.org/agent/verify/758d61f26a44448384e5c4468a0dcb7a2abe456067b0f7b505bc28b9411fe931)) performs the recompute → compare → confirm path against the on-chain ERC-8263 anchor.\n\nThe following are under active development and will be referenced in future revisions of this note once stable:\n\n**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](https://gist.github.com/TMerlini/bf3abd30c332cccb257d0e5bdff1ff95)\n\n- @wgw_eth — HBS / persistence alignment\n\nPublication-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.com/TMerlini/wyriwe). 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.\n\n*github.com/damonzwicker/observation-commitment-protocol*", "url": "https://wpnews.pro/news/composition-note-8004-8263-ocp-md", "canonical_source": "https://gist.github.com/damonzwicker/8742e742bdc627b8e2179c00b81289dc", "published_at": "2026-05-23 05:04:16+00:00", "updated_at": "2026-05-28 22:27:15.507122+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "ai-ethics", "ai-research"], "entities": ["Vincent Wu", "Damon Zwicker", "Tiago Merlini", "ERC-8263", "ERC-8004", "Observation Commitment Protocol", "TruthAnchor", "HBS"], "alternates": {"html": "https://wpnews.pro/news/composition-note-8004-8263-ocp-md", "markdown": "https://wpnews.pro/news/composition-note-8004-8263-ocp-md.md", "text": "https://wpnews.pro/news/composition-note-8004-8263-ocp-md.txt", "jsonld": "https://wpnews.pro/news/composition-note-8004-8263-ocp-md.jsonld"}}