ERC-8274: AI Inference Proof Verification

ERCs
, ,
21

Done. Both L3 and L4 are live.

Live attestation:

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



{
  "input_hash":   "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824",
  "l4_signature": "0xd3eb65203317d3775ef25dc22328ea4bd82624b8836d590706f4ad578efb43006ba4cdc4df3686ca9f0960b033306696ae0adcc85f7034dec9781e4e227d45681b",
  "l3_tx":        "0xc3aeb16d0aef167e2ebc6d4afc9333fcd13a71b8c02e5485bc6be7491e393319"
}

L3 tx on Base Sepolia, block 41731493: https://sepolia.basescan.org/tx/0xc3aeb16d0aef167e2ebc6d4afc9333fcd13a71b8c02e5485bc6be7491e393319

record(input_hash) on OCP contract 0x0963Fd33DF80c94360F2DC22e5c09517AeE7ED5c. L3 fires async after L4 — response path unaffected. If the signer wallet is unfunded, l3_tx stays null, nothing blocks.

Formal PR against the KYA repo: https://github.com/damonzwicker/observation-commitment-protocol/pull/1

Adds docs/spec/appendix-ai-inference-attestation.md — L3 commitment, L4 EIP-712 struct, field semantics, identity sentinel, and the decoupling contract between layers. Happy to adjust to match wherever you’re taking the spec.

1 Like
22

Merged. PR #1 is in main.

docs/spec/appendix-ai-inference-attestation.md is now part of the OCP spec — the first external contribution to the repository.

L3 transaction independently verified before merge: input_hash 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824 confirmed in Recorded event log on contract 0x0963Fd33DF80c94360F2DC22e5c09517AeE7ED5c at block 41731493. The full stack is live.

Damon / OCP

1 Like
23

we just opened ERC-8263 (Onchain Proof Layer for AI Agents)

which tackles the proof-anchoring side rather than the verification

registry side. PR: Add ERC: Onchain Proof Layer for AI Agents by TruthAnchor-AI · Pull Request #1748 · ethereum/ERCs · GitHub — would

welcome thoughts on whether these should reference each other.

1 Like
24

Vincent —

Read ERC-8263 carefully. These aren’t competing — they’re two halves of the same problem.

ERC-8263 defines the write side: how an agent anchors a proof hash on-chain via anchorProof(agentId, proofHash). Clean interface, the batch variant is a practical addition, and tying it to ERC-8004 agent identity is the right architectural instinct.

What it doesn’t define is the read side: how a third party independently verifies that a specific byte sequence produced the anchored hash — without trusting the system that produced it. That’s the gap OCP fills.

OCP’s verification invariant:

recompute → compare → confirm inclusion

A portable proof envelope that carries the chain ID, block hash, transaction reference, extraction rule, and hash function — everything a verifier needs to reproduce the check from raw ledger data. No SDK, no provider, no indexer. The math is the proof.

OCP has been live since April 2026 with a working commit-and-verify implementation. The write side — digest computation, serialization, record(bytes32) on-chain — has been part of the protocol from day one. This isn’t a reaction to ERC-8263; it predates it by six weeks.

The natural composition:

  • ERC-8263 defines how the commitment gets on-chain
  • OCP defines how it gets verified off-chain, independently
  • ERC-8004 resolves agent identity

All three compose cleanly. None absorbs the semantics of the others.

One open question worth resolving in ERC-8263: the agentId field is a bytes32 — how does a verifier resolve that to an ERC-8004 identity without trusting the anchoring system? If the answer is the ERC-8004 registry, making that explicit in the spec closes a real gap.

Happy to reference ERC-8263 in the OCP appendix. If you’re open to referencing OCP’s verification procedure in ERC-8263, these two specs become more useful together than either is alone.

Damon / OCP

25

Gate 3 complete.

The same observation is now committed on two fundamentally different ledger architectures:

EVM (Base Sepolia) — via event log

tx: 0xf2e1f6c085768b4e3d60463717d52bb2a338803a74a4cfd48aea5738d2595ddd
digest: 14cca453684a18c1ef3e1c0b9a7744cfa06942660719bba373ef5fc36208bf73

Solana (devnet) — via instruction data

tx: 43B5qatkYp5VZpaxrSCSe4jEHG2NgFpPGi6RdGABD9v3YbBcoCt5faKbrAgxFt4N4QzT69Z5vcnL81jaasRaUcfq
digest: 14cca453684a18c1ef3e1c0b9a7744cfa06942660719bba373ef5fc36208bf73
program: GCXRKzreL2fdYBpnfmKzFqTxE46eGmwQuErMw4uZ1DUL
discriminator: 49f0c95bf2609126

Same digest. Same proof envelope format. Different chains. The abstraction held without structural modification.

The proof envelope schema required no changes for Solana. All existing fields accommodate the Solana values. One additive extension field (commitment) was added to ledger_ref.finality to carry the Solana-native commitment level — this does not break EVM envelope compatibility.

OCP’s cross-chain claim is now proven in practice, not just in spec.

26

Damon — appreciate the careful read.

You’re right, and the framing is correct: ERC-8263 specifies the on-chain commitment surface; it deliberately does not constrain the off-chain verification procedure. A portable, system-independent envelope like OCP’s is exactly the missing half. The three-layer composition — ERC-8004 (identity) / ERC-8263 (commitment) / OCP (verification) — is cleaner than anything I’d get by trying to absorb verification semantics into the spec.

On the agentId: bytes32 resolution question — this is a real gap and worth closing in the spec. My intent has been:

  • When the agent is ERC-8004-registered: agentId == bytes32(uint256(erc8004AgentId)), resolvable against a canonical IdentityRegistryaddress (chain-scoped).

  • When the agent is not registry-bound: agentId == keccak256(canonical_agent_uri)where canonical_agent_uri follows a DID-style scheme committed at registration time.

A verifier should be able to disambiguate these without trusting the anchoring system. I’ll add an agentIdSchemediscriminator (1 byte, packed) plus a normative section “Resolving agentId” in the next revision, and explicitly reference ERC-8004’s registry interface. If you want to comment on the draft text before it goes up, I’ll share it as a gist first.

Re mutual referencing — yes, happy to. Concrete proposal:

  1. ERC-8263 adds a non-normative “Verification” section pointing to OCP as a reference verification procedure, with the envelope schema link.

  2. OCP appendix references ERC-8263 as the commitment-side standard, with the anchorProof ABI excerpt.

  3. We co-sign a one-page “Composition Note” (8004 + 8263 + OCP) — keeps each spec scoped while making the stack legible to implementers.

Will open a PR to your repo this week with (2). Send me a draft of (1) at your pace.

— Vincent

1 Like
27

Vincent —

The three-layer composition is the right frame and I’m glad it landed that way. ERC-8004 / ERC-8263 / OCP is cleaner than any of the three specs trying to absorb the others.

On agentId resolution — the discriminator byte approach is exactly right. The two-path scheme (ERC-8004 registry vs. keccak256(canonical_agent_uri)) covers the real deployment surface and the normative “Resolving agentId” section will close the gap cleanly. Happy to review the gist before it goes up — send it when ready.

On mutual referencing — agreed on all three:

  1. ERC-8263 non-normative verification section pointing to OCP — I’ll draft this and send it to you directly. Give me a day.

  2. OCP appendix referencing ERC-8263 as the commitment-side standard with the anchorProof ABI — I’ll have this done before your PR lands so the cross-references are in place on both sides simultaneously.

  3. Composition Note (8004 + 8263 + OCP) — this is the most valuable artifact for implementers. One page, scoped tightly, co-signed. I’ll draft a skeleton and share it as a gist for your input.

Looking forward to the PR.

Damon / OCP

28

Vincent — sent you a DM with the draft verification section and Composition Note skeleton.

29

Damon —

Thanks for landing on the composition cleanly. Three quick confirmations:

1) AgentId resolution gist — I’ll have it ready within 24h. The two-path
scheme will look roughly like:

  • Path A (on-chain registry): discriminator=0x01 | registryChainId(2B) |
    registryAddress(20B) | tokenId(uint256)
  • Path B (canonical URI hash): discriminator=0x02 | keccak256(canonical_agent_uri)

The “Resolving agentId” section will cover both directions: agentId → resolution
target, and registered identity → canonical agentId. Will send the gist link
directly once it’s up — would genuinely value structural feedback before I PR
it into the ERC.

2) OCP appendix / ERC-8263 verification section — agreed on the
simultaneous landing. I’ll hold my ERC PR in draft state until your OCP
appendix is in flight, so cross-references resolve in the same week rather
than ships-in-the-night. My non-normative section will reference OCP’s
commitment ABI and link directly to your appendix once it’s published.

3) Composition Note — this is the highest-leverage artifact of the three.
Two questions on scope before you sketch the skeleton:

  • Format: gist-first as a community artifact, with the option to
    promote to an Informational ERC later if implementers pick it up? Or
    do you want to go straight to Informational? I lean gist-first to keep
    iteration cycles tight, but no strong preference.
  • Worked example: should the Note include one end-to-end walkthrough
    (single agent: registered via 8004 → emitting OCP commitments →
    anchored via 8263 with on-chain TX hashes)? My read is that
    implementers will absorb a concrete walkthrough an order of magnitude
    faster than abstract composition rules, but it does add ~1 page.

Happy to co-sign whatever shape you draft, and to host the worked example
if we go that route (I can produce live on-chain TX hashes from TruthAnchor’s
infra for the 8263 leg).

Looking forward to it.

— Vincent

2 Likes
30

Got it — reviewing both now. Will reply in DM with line edits, and post
back here once the three artifacts (verification section, OCP appendix,
agentId gist) are ready for public review together.:heart:

1 Like
31

Thanks to Vincent for the cross-link to the ERC-8257 thread.

For anyone arriving from that discussion — OCP sits below the registry layer. Whatever tool or skill registry emerges from ERC-8257 and ERC-8239, the verification question is the same: once a tool executes, how does anyone independently confirm what it received, what it produced, and that nothing was altered?

That’s the layer OCP addresses. The invariant is minimal:

recompute → compare → confirm inclusion

A portable proof envelope. Raw ledger verification. No SDK, no provider, no trust in the originating system.

The full stack as it’s converging:

ERC-8004  →  agent identity
ERC-8257/8239  →  tool/skill registry and discovery
ERC-8263  →  on-chain commitment
OCP  →  independent verification

Each layer independently optional. None absorbs the semantics of the others.

Happy to answer questions or talk through how OCP composes with whatever the tool registry discussion lands on.

Damon / OCP

1 Like
32

@TMerlini @VincentWu —

Tiago —

Damon and Vincent here, writing jointly.

Over the past week we have been specifying how three pieces of the
agent verification stack compose:

  • ERC-8004 — agent identity

  • ERC-8263 — on-chain proof commitment

  • OCP — independent verification of committed digests

ERC-8263 includes an agentIdScheme discriminator. Scheme 0x01 is the registry-based path intended to compose with ERC-8004. OCP independently verifies the committed digest through the evm/erc-8263 extraction rule; identity attribution remains in the ERC-8004 / ERC-8263 layer.

The ERC-8263 V1 reference contract is now deployed and source-verified
on Ethereum mainnet, and OCP now includes an evm/erc-8263 extraction
rule for verifying ERC-8263 commitments. We also drafted a short
Composition Note explaining how the three layers fit together without
any one spec absorbing the semantics of the others.

We’d like your review on the ERC-8004 side:

  1. Does the identity-layer description accurately reflect ERC-8004?

  2. Does the agentIdScheme / REGISTRY path in ERC-8263 compose cleanly
    with ERC-8004 from your perspective?

  3. Is there anything in the Composition Note that would make ERC-8004
    implementers uncomfortable or ambiguous?

Composition Note:

If the framing looks right to you, we’d be happy to add you as the
ERC-8004 co-author / co-signer on the note before sharing it more
broadly — making this the natural reference point for anyone building
on agent identity, commitment, or verification primitives going forward.

Damon / OCP
Vincent / ERC-8263

2 Likes
33

Confirming co-authorship from the ERC-8263 side.

The agentIdScheme discriminator in ERC-8263 V1 was specifically
designed with this composition in mind — scheme 0x01 (REGISTRY)
accepts 32-byte ERC-8004 record ids natively. The Composition Note
reflects how Damon and I have been thinking about the stack, and
we’re hoping Tiago’s read on the identity layer will tighten it
further.

Vincent Wu / ERC-8263
truthanchor.biz

2 Likes
34

Hi Vincent and Damon , will be happy to do so , I’m out of the country and will be back Monday , happy to send the report has soon has I’m back!

2 Likes
35

Thanks Tiago — appreciated.

No rush. Damon and I will hold the Composition Note in draft until you’re back and have had time to review the ERC-8004 section and the agentIdScheme = 0x01 / REGISTRY mapping.

Looking forward to your report when convenient.

— Vincent

2 Likes
36

Implementation Report — ERC-8004 + ERC-8263 + OCP Stack

dinamic.eth / TMerlini — May 25, 2026

Live Endpoints

All endpoints below are live, public, and require no authentication for read operations.

Resource URL
Attestation log GET https://gateway.ensub.org/agent/0xe61f5a6783ae09949b9a1b6821b68f89c0d7bb2d/5/attestations?limit=1
Agent card (ENSIP-27) GET https://gateway.ensub.org/agent/0xe61f5a6783ae09949b9a1b6821b68f89c0d7bb2d/5/.well-known/agent.json
ERC-8004 tokenURI GET https://gateway.ensub.org/agent/0xe61f5a6783ae09949b9a1b6821b68f89c0d7bb2d/5
Provenance verifier GET https://gateway.ensub.org/verify/input-provenance?rawInputHash=...&sanitizationPipelineHash=...&inputHash=...

Live Attestation

{
  "registry":                   "0xe61f5a6783ae09949b9a1b6821b68f89c0d7bb2d",
  "agent_id":                   "5",
  "action_type":                "chat",
  "raw_input_hash":             "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824",
  "sanitization_pipeline_hash": "8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea",
  "input_hash":                 "2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824",
  "output_hash":                "74b4d50e1b13e3a8ef9492c34f5c0af2d3a46dda11bb59378026207eea9b434b",
  "manifest_hash":              "0a56e06bbff01de7c1955dc902fadcd4f7b893bc6fc260f9253d779c220a569e",
  "l4_signature":               "0xd3eb65203317d3775ef25dc22328ea4bd82624b8836d590706f4ad578efb43006ba4cdc4df3686ca9f0960b033306696ae0adcc85f7034dec9781e4e227d45681b",
  "l3_tx":                      "0xc3aeb16d0aef167e2ebc6d4afc9333fcd13a71b8c02e5485bc6be7491e393319",
  "l3_chain":                   "84532",
  "created_at":                 "1779231272"
}

L3 commitment: Base Sepolia (chain 84532), block 41731493
L4 signer: resolved via registry.getAgentWallet(5) on Ethereum mainnet

Identity Sentinel Verification

sanitization_pipeline_hash is the IDENTITY_SENTINEL — no sanitization transformation was applied on this execution. Verified via the provenance endpoint:

GET /verify/input-provenance
  ?rawInputHash=2cf24dba...
  &sanitizationPipelineHash=8116eec2...
  &inputHash=2cf24dba...

Response:

{
  "valid": true,
  "transformation": "identity",
  "sentinelSpec": "ipfs://QmTst97dG8i9tFrutdetqMbVhSHqJGJaxMmPzWCcVVTWDU",
  "reason": "Identity pipeline: raw === input, no transformation applied"
}

When sanitization_pipeline_hash equals the IDENTITY_SENTINEL, raw_input_hash === input_hash and verifiers skip sanitization verification. This is a hard invariant — any mismatch between the sentinel and equal hashes is a protocol violation.

CAIP-19 Identity Reference (Agent Card)

The /.well-known/agent.json response now includes a registrations field aligned with ERC-8263 and ENSIP-64:

"registrations": [
  {
    "agentId":       "5",
    "agentRegistry": "eip155:1/erc8004:0xe61f5a6783ae09949b9a1b6821b68f89c0d7bb2d/5",
    "agentURI":      "https://gateway.ensub.org/agent/0xe61f5a6783ae09949b9a1b6821b68f89c0d7bb2d/5"
  }
]

Feedback on Post #32 (Damon + Vincent)

1. Accuracy of identity layer description :white_check_mark:

registry.getAgentWallet(agentId) is the correct and complete resolution path. No additional steps required. The returned address is the EIP-712 signing key for that agent — resolve it, recover the signer from l4_signature, assert equality.

2. Compatibility of agentIdScheme 0x01 / REGISTRY with ERC-8004 :white_check_mark:

Confirmed compatible. One encoding note for implementers: ERC-8263 uses bytes32 agentId, ERC-8004 uses uint256. The bridge is bytes32(uint256(agentId)). This is trivial but should be one explicit line in the composition guide — it will otherwise cause silent mismatches in at least a few implementations.

3. Implementer ambiguities

The proofHash field in ERC-8263’s anchorProof(agentId, proofHash) should be clearly specified as input_hash — SHA-256 of the sanitized input (post-pipeline), not raw_input_hash. If an implementer hashes the raw input instead, OCP verification will fail without an obvious error. Recommend adding one sentence to the spec: “proofHash MUST be the SHA-256 digest of the input after any declared sanitization pipeline has been applied.”

Independent Verification Steps (No Gateway Trust Required)

1. GET /attestations → retrieve input_hash, l4_signature, l3_tx
2. Call registry.getAgentWallet(5) on mainnet → signerAddress
3. Recover EIP-712 signer from l4_signature → recoveredAddress
4. Assert recoveredAddress == signerAddress
5. Query Base Sepolia (chain 84532) tx 0xc3aeb16d... → confirm Recorded(input_hash) event at block 41731493

Steps 2–5 require only a public RPC endpoint. No API key, no gateway, no trust assumption beyond the registry contract.

ERC-8004 Factory — Reference Registries (Ethereum Mainnet)

Registry Collection
0xe61f5a6783ae09949b9a1b6821b68f89c0d7bb2d Goblinarinos
0xe0454dfa17a57a84c3e0e2dbfda5318cbbe91e2c Pixel Goblins
Factory: 0xc2bb6502a7d8ee3cdb2f96508d6cdf426aa2858f AgentIdentityRegistryFactory
FactoryFacade: 0xC939b58F3B36293D3D55993ADD6EE0C79e7AAD2f Public deploy interface

All verified on Etherscan. Factory deploys per-collection registries, each collection owns its own registry, agents are uint256 token IDs within that registry.

Reference implementation: https://github.com/Echo-Merlini/hbs-attestation-poc
Agent card spec (ENSIP-27): https://github.com/ensdomains/ensips/pull/75
HBS image provenance: https://gist.github.com/TMerlini/ffd44a7f2e2f730cf2be51993bbfcd3e

2 Likes
37

Hey @VincentWu yes, cross-referencing makes a lot of sense here, the overlap is direct.

ERC-8263’s anchorProof(agentId, proofHash) maps almost exactly to what our reference implementation already does: the proofHash corresponds to input_hash (SHA-256 of the sanitized input), and agentId resolves via ERC-8004’s registry.getAgentWallet(agentId). We’ve been running this on Base Sepolia — L3 tx at block 41731493 is the live example, record(input_hash) via OCP contract, agentId anchored to an ERC-8004 registry.

The way the three standards layer together in practice:

ERC-8004  — who is the agent? (identity, signing key via getAgentWallet)
ERC-8263  — what did the agent commit? (anchorProof → proofHash on-chain)
OCP       — can anyone verify it independently? (read side, no trust required)

Each handles one job cleanly. ERC-8263 being the formal write-side primitive is exactly what’s been missing as a standalone spec — right now implementations like ours are doing it informally through OCP’s record().

A few things worth aligning on between ERC-8263 and ERC-8004 specifically:

  • bytes32 agentId in ERC-8263 vs uint256 agentId in ERC-8004 — worth confirming the encoding convention so resolvers don’t need to guess

  • Whether ERC-8263 should specify that registry.getAgentWallet(agentId) is the canonical resolution path, or leave identity resolution to the caller

  • The proofHash field — should the spec recommend a specific hash construction (SHA-256 of sanitized input, as in our implementation) or remain content-agnostic?

Happy to share the reference implementation in more detail if useful — live endpoint at gateway.ensub.org, full attestation schema with l3_tx + l4_signature + input_hash all wired up.

2 Likes
38

Hey @Damonzwicker , the agentId resolution question has a clean answer in ERC-8004, and it’s exactly how our L4 verification is wired.

registry.getAgentWallet(agentId) returns the signing key for that agent — a pure on-chain lookup, no trust in the anchoring system required. The full verification path without any off-chain dependency:

1. Read anchorProof(agentId, proofHash) from ERC-8263 contract
2. Call registry.getAgentWallet(agentId) on the ERC-8004 registry → signerAddress
3. Recover EIP-712 signer from l4_signature over InferenceAttestation struct
4. Assert recovered == signerAddress
5. Assert proofHash == input_hash in the attestation

Steps 2–5 are pure on-chain. No gateway, no API, no trust assumption beyond the registry contract itself, which is the same trust assumption you’d make for any ERC-721 ownerOf call.

The open question is just the agentId encoding — ERC-8263 uses bytes32, ERC-8004 uses uint256. Trivial to bridge (bytes32(uint256(agentId))), but worth making explicit in both specs so verifiers don’t have to guess.

Full reference implementation with schema, decode scripts, and independent verification steps:
https://github.com/Echo-Merlini/hbs-attestation-poc

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

Returns l4_signature, input_hash, l3_tx — all three independently verifiable from on-chain state alone.

Congrats on the merge, first external OCP contribution is a amazing milestone. :smile:

TMerlini

1 Like
39

Hey @TMerlini — this is the alignment I was looking for. The Base Sepolia L3 example at block 41731493 is exactly the kind of concrete reference path the spec needed, and the 5-step verification sequence you wrote out for @Damonzwicker is the right interop shape.

I’d like to adapt those five steps into ERC-8263 v0.2 as an ERC-8004-compatible “Independent Verification” profile, rather than make them the only normative path for all ERC-8263 use cases.

That gives us a clean structure:

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

  • ERC-8004 compatibility specifies how agentIdScheme = 0x01 resolves

  • OCP verifies digest inclusion

  • gateway.ensub.org can be cited as a live ERC-8004 / OCP interop reference implementation

On your three alignment questions:

  1. bytes32 vs uint256 agentId

I agree the bridge should be explicit:

bytes32 agentId8263 = bytes32(uint256(agentId8004))

ERC-8263 should keep bytes32 because it is the more general identity reference type. Locking ERC-8263 to uint256 would couple it too tightly to one registry shape and make cross-chain or non-NFT identity registries harder. For ERC-8004, we define the canonical encoding so verifiers do not guess.

  1. registry.getAgentWallet(agentId)

I’d make this a SHOULD for agentIdScheme = 0x01, not a MUST for all ERC-8263 anchors.

For ERC-8263 v0.2, scheme 0x01 should be defined as the ERC-8004 registry path. ERC-8004-compatible alternatives can either follow that interface exactly or use future schemes (0x03+). That keeps ERC-8263 composable without shrinking the base spec to a single identity system.

  1. proofHash construction

I’d keep ERC-8263 content-agnostic at the core level: bytes32 proofHash, no required hash algorithm.

Then add a non-normative “proofHash construction profiles” appendix:

  • SHA-256(canonical sanitized input) — recommended for OCP-compatible AI inference attestations, with your implementation as the live reference example

  • keccak256(payload) — EVM-native payload commitments

  • MerkleRoot(leaves) — batch anchoring

  • Poseidon(payload) — ZK-friendly applications

Mandating SHA-256 in the core would close off batch and ZK use cases. Recommending SHA-256 for the ERC-8004 / OCP inference-attestation profile gives implementers a clear default without narrowing the base spec.

I’ll open an ERC-8263 v0.2 draft PR within the next 7 days covering:

  • ERC-8004 compatibility bridge: bytes32(uint256(agentId8004))

  • ERC-8004-compatible Independent Verification profile

  • proofHash construction profiles appendix

  • gateway.ensub.org as live interop reference

  • OCP digest inclusion path

I’ll tag both you and @Damonzwicker before it goes anywhere near the ERC editors.

Separately, Damon and I have been drafting a Composition Note with a four-part framing: ERC-8004 identity / ERC-8263 commitment / OCP verification / HBS artifact carrier. Your comments above map directly to the identity and commitment boundary, so I’d like to loop you into that draft as well.

— Vincent

2 Likes
40

@VincentWu all three land.

The “Independent Verification” profile structure is the right call, keeps ERC-8263 minimal and lets the ERC-8004 composition be opt-in for implementations that need the full identity resolution path. The explicit bytes32(uint256(agentId)) bridge is exactly what’s needed; small thing, big footgun if left implicit.

Algorithm-agnostic core + SHA-256 profile also works for us, our proofHash is SHA-256 of sanitized input, so it maps cleanly to the profile without requiring it at the spec level.

Live reference for the v0.2 PR if useful:

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

Returns input_hash (SHA-256, post-sanitization), l4_signature, l3_tx, all three independently verifiable from on-chain state via registry.getAgentWallet(5) on mainnet.

Looking forward to the v0.2 PR.

TMerlini

2 Likes