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
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.
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.
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
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
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
┌─────────────────────────────────────────────────────┐
│ 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.
Commitment (write side):
- Agent executes an action against an observation
proofHash = H(observation)
— raw bytes, algorithm defined by proof profileanchor(agentIdScheme, agentId, proofHash)
called on-chain (ERC-8263)- OCP proof envelope constructed from the transaction receipt
Verification (read side):
- Verifier receives: observation + OCP proof envelope
H′ = H(observation)
— recomputed independently using declared hash functionH′ == proofHash
— compared against envelope valueproofHash ∈ R(tx)
— confirmed in raw transaction receiptagentId
resolved according toagentIdScheme
: for0x01
, resolution goes through ERC-8004; for0x02
, agentId iskeccak256(canonical agent URI)
; for0x00
, 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.
| 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 |
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
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 verificationsanitization_pipeline_hash != IDENTITY_SENTINEL
→ verify the transformation defined by the sanitization pipeline and require the transformed input to hash toinput_hash
Verifiers that do not implement this branch will incorrectly reject pass-through executions.
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.
| Standard | Reference |
|---|---|
| ERC-8004 | gateway.ensub.org · attestation: GET /agent/{registry}/{agentId}/attestations · sentinel-aware verifier: GET /agent/verify/:inputHash · live example: |
| ERC-8263 | truthanchor.biz · ETH Mainnet V1: |
OCP verifier: npm install -g ocp-verify
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 ( | ||
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.
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.
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.
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
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.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.
github.com/damonzwicker/observation-commitment-protocol