@TMerlini — appreciated. Your live endpoint will be cited as the reference example for the ERC-8004-compatible verification profile in the v0.2 draft — SHA-256 sanitization path, l4_signature recovery, and l3_tx inclusion check all wired through the verification flow ERC-8263 v0.2 is being structured around.
Targeting the v0.2 PR within 7 days. I’ll tag you and @Damonzwicker before it goes anywhere near the ERC editors.
— Vincent
@VincentWu glad the endpoint is useful as a reference. One edge case worth capturing in the v0.2 verification profile before it goes to the editors:
When the identity pipeline runs (no sanitization applied), raw_input_hash === input_hash.
The sanitization_pipeline_hash in that case is the IDENTITY_SENTINEL (8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea — SHA-256 of the identity spec). If the verification profile doesn’t explicitly handle this case, a verifier that always expects raw !== sanitized will fail silently on every pass-through execution.
The invariant:
sanitization_pipeline_hash == IDENTITY_SENTINEL → raw_input_hash === input_hash, skip sanitization check
sanitization_pipeline_hash != IDENTITY_SENTINEL → raw_input_hash !== input_hash, verify the transformation
We have a live /verify/input-provenance endpoint that handles this branching if it’s useful to reference alongside the attestation endpoint.
Full reference implementation (schema, decode scripts, Twitter CDN roundtrip proof):
https://github.com/Echo-Merlini/hbs-attestation-poc
Happy to review before it goes to the editors - just tag us. 
The identity sentinel branching is exactly right — verifiers that skip the IDENTITY_SENTINEL check will fail silently on every pass-through execution and produce no error signal. That’s the failure mode worth making explicit in the v0.2 verification profile.
The sentinel itself is SHA-256 of the identity spec — 8116eec2... — defined in OCP as the pass-through constant. Tiago’s live /verify/input-provenance endpoint handles the branching correctly in production today. Worth citing both endpoints in the v0.2 draft — the attestation endpoint for the happy path, the verification endpoint for the branching logic.
Looking forward to the PR. Tag us both before it moves.
— Damon
oops.
Hey, just to chime in, tunnckoCore/WGW here.
Cannot look into all of the things too deeply, but i really like what y’all doing.
HBS is just the best compact encoding format alone. I was playing with packing as much possible data into a small canvas of 32x32 image.. embedding the data as pixel font. So.. i needed a couple of unique features in an encoding, and the combo turned out amazing and actually pretty useful for the wider range.
The “breakthrough”, i think, is that small thing - why not carry important data inside an pixel art image that could be distributed through any platform or channel. And because of the specific encoding features, it survives and recovers as much as possible if the payload is partial or corrupted.
It’s interesting convergence of things. HBS2 was cool, but HBS3 is insane and i’m really proud with it. I’ve done A LOT of Open Source in the past 15 years but man (380M downloads per month, 10B+ total, if downloads are anything), that’s one of the coolest. And i’m happy if it’s used.
My github is tunnckoCore (Charlike Mike Reagent) · GitHub if you want to ping me on review PRs or something. I’ve read a big part of the documents and comments here.
Welcome to the thread @tunnckoCore - and for anyone following along, some context on why this matters here.
WGW and I have been co-developing the persistence layer for this exact stack over the past weeks. The 32×32 pixel canvas constraint he mentions isn’t incidental - it’s what drove every design decision in HBS. Bech32 didn’t fit. JSON didn’t fit. Base64 made it worse. Length-prefix KV with SHA-256 integrity was the only thing that fit, and that constraint is what made HBS genuinely useful beyond the original use case.
Where it lands in the stack we’ve been building:
| Layer | Standard | Job |
|---|---|---|
| Identity | ERC-8004 | Who is the agent? |
| Commitment | ERC-8263 | What did they commit on-chain? |
| Verification | OCP | Can anyone verify it independently? |
| Persistence | HBS pixel provenance | How does the proof travel with the image forever? |
The attestation fields — registry, agent_id, input_hash, l4_signature, l3_tx — are encoded as pixel art directly into the carrier image using HBS. The image IS the proof. It survives Twitter CDN roundtrips (confirmed), JPEG re-encoding, and partial corruption. HBS3’s structural recovery means a partially damaged image still yields a partial attestation rather than nothing — registry and agent_id (early slots) recover even when l4_signature is corrupted downstream.
We’ve been spec’ing this out in a shared gist if anyone wants the full technical detail:
https://gist.github.com/TMerlini/ffd44a7f2e2f730cf2be51993bbfcd3e
Glad you’re here. The thread is better for it.
dinamic.eth TMerlini
Tiago — caught. This is exactly the kind of edge case that will break verifiers if it is not made explicit in the profile. The invariant as you stated it is clean. I’ll lift it into v0.2 with attribution.
Placement in the PR:
Under the SHA-256 profile, I’ll add an input-provenance commitment note:
When a profile applies sanitization, it may commit raw_input_hash, input_hash, and sanitization_pipeline_hash.
When the identity pipeline applies, sanitization_pipeline_hash == IDENTITY_SENTINEL.
In that pass-through case, raw_input_hash == input_hash by construction.
IDENTITY_SENTINEL:
0x8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea
In the verification profile itself, I’ll make the branching rule explicit:
if sanitization_pipeline_hash == IDENTITY_SENTINEL, require raw_input_hash == input_hash and skip sanitization transformation verification
if sanitization_pipeline_hash != IDENTITY_SENTINEL, verify the sanitization pipeline and require the transformed input to hash to input_hash
This prevents verifiers from unconditionally expecting raw_input_hash != input_hash, which would incorrectly reject every pass-through execution.
I’ll cite the attestation endpoint and /verify/input-provenance together as the live reference path, with /verify/input-provenance as the concrete example of correct sentinel branching.
Boundary stays explicit:
At the contract layer, ERC-8263 still treats proofHash as opaque bytes32. The sentinel and sanitization commitment live in the ERC-8004-compatible verification profile, not in the AnchorProof event. That preserves the algorithm-agnostic core you and Damon both signed off on.
I’ll tag you and Damon on the PR before it goes to the editors.
— Vincent
Following up on the implementation report, shipping a live view of the admin attestation dashboard as it stands today.
What you’re looking at:
46 chat attestations + 114 CCIP resolver reads — every execution logged with full hash provenance
10 L3 anchored — OCP record(input_hash) committed on Base Sepolia, each badge links directly to basescan for independent verification
13 L4 signed — EIP-712 InferenceAttestation struct signed by the agent’s registered wallet (registry.getAgentWallet(agentId))
Pipeline column — identity badge confirms the IDENTITY_SENTINEL was used (no sanitization applied, raw_input_hash === input_hash). If a sanitization pipeline ran, it would show sanitized with the pipeline hash in the tooltip.
Every L3 badge is a direct link to basescan. No gateway trust required — the input_hash is in the Recorded event log on-chain, verifiable by anyone with a public RPC.
The L3/L4 gap (10 vs 13) is visible and expected, some executions got signed before the OCP anchor confirmed. Worth noting for implementers: L3 and L4 are independently optional by design, as specced in the appendix.
@Damonzwicker - this is the OCP integration running in production. Happy to walk through the verification flow in detail if useful for the composition note.
dinamic.eth / TMerlini
Tiago —
This is exactly what independent verification looks like in practice. The identity sentinel on every row, the L3 badges linking directly to basescan, the L3/L4 gap explained and framed correctly — this is the appendix spec running in production.
The L3/L4 gap note is worth preserving exactly as you stated it. That’s the kind of implementation detail that makes the verification flow credible to anyone reading the composition note.
Yes on walking through the verification flow. Let’s do it.
@VincentWu — this is the live reference implementation you’re citing in v0.2. The dashboard is public, the basescan links are live, the identity sentinel is confirmed on every row.
— Damon
@Damonzwicker - glad the gap note landed well. Keeping it in.
Ready to move on the composition note whenever you are. The structure I’d propose for it:
| Layer | Standard | Job |
|---|---|---|
| Identity | ERC-8004 | Who is the agent? (registry.getAgentWallet) |
| Commitment | ERC-8263 | What did they commit on-chain? (anchorProof) |
| Verification | OCP | Can anyone verify it independently? (record + Recorded event) |
| Persistence | HBS Image Provenance | How does the proof travel with the image forever? |
The fourth row is something @tunnckocore and I have been building in parallel — attestation fields encoded as pixel art directly into a carrier image using the HBS encoding primitive. The image IS the proof: it survives Twitter CDN roundtrips, platform re-encoding, and partial corruption. We confirmed the full round-trip last week. The spec is live if you want to look before we write it into the note:
https://gist.github.com/TMerlini/ffd44a7f2e2f730cf2be51993bbfcd3e
Happy for you to take the lead on structure or to draft a first pass - whichever works better for you.
Dinamic.eth / TMerlini
Tiago —
“Persistence” is the right word. Sharper than what we had. That table is clean and I want to use it.
Before either of us drafts — Vincent is mid-diff on the raw markdown right now. Let me get his revision applied first so we’re all working from the same base. Once that’s in I’ll share the raw and we go from there together.
The three of us should be aligned on the base document before anyone writes into it. Give me 24 hours.
@VincentWu — Tiago’s “Persistence” framing for HBS is better than “Artifact carrier.” Worth adopting in the diff.
— Damon
Tiago, Damon —
Picking this up from the diff side. Three things:
On the dashboard. This is exactly the live reference v0.2 § 13 (Independent Verification) needs — IDENTITY_SENTINEL visible on every row, L3 badges resolving to basescan with no gateway in the trust path, and the L3/L4 gap framed as designed-in optionality rather than inconsistency. I’m lifting the gap note verbatim into the v0.2 appendix on independent verifiability: “L3 and L4 are independently optional by design — some executions get signed before the OCP anchor confirms, and that gap is visible by construction.” That sentence does more work for implementer credibility than three paragraphs of spec prose could.
On “Persistence” (per Damon’s nudge). Agreed. It names the function (the proof survives) rather than the form (something carrying something). I’m rolling it into the diff I just sent Damon — table lane, ASCII parenthetical, and the dedicated note section. Damon will apply once, no second round.
On the composition note structure. Tiago’s 4-layer table is sharper than the 5-lane version currently in the gist — each row anchored to its canonical call (registry.getAgentWallet / anchorProof / record + Recorded event / persistence primitive) reads like spec, not framing. Happy to merge that into the next pass after Damon applies the in-flight diff, so we have one clean diff per round and the gist’s revision history stays legible. Damon — your call on sequencing.
v0.2 PR draft is in motion. § 11 ERC-8004 compatibility, § 12 compatible identity registries, Appendix B proofHash constructions (with the IDENTITY_SENTINEL invariant in its own sub-section), § 13 independent verification (citing the dashboard and both endpoints), § 14 OCP boundary disclaimer (verbatim cite of docs/spec/ocp-v1.0.0.md). Contract bytecode untouched — pure spec-doc layer, no re-verify needed. Will share the draft for both of you to sanity-check before it goes to the editors, targeting the 7-day window I committed to upthread.
— Vincent / @VincentWu
@VincentWu Glad the table landed. “Reads like spec, not framing” is exactly what it should be.
One thing to make sure gets into the proof hash construction section before it goes to editors — the full triple-hash scheme and the IDENTITY_SENTINEL case.
The three values that should be formally defined in v0.2:
raw_input_hash — SHA-256 of the input before any preprocessing pipeline runs
sanitization_pipeline_hash — SHA-256 of the pipeline specification itself, proving which transformation ran between user and agent (WYRIWE: What You Read Is What Executed)
input_hash — SHA-256 of the input after the pipeline, what the agent actually saw — this is the value used as proofHash in anchorProof()
The reason all three need to be in the spec: input_hash 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.
The IDENTITY_SENTINEL case is the edge case that needs explicit handling:
When no pipeline runs, sanitization_pipeline_hash MUST equal the sentinel (8116eec29078e8f57c07077d5e8080a35bde73036581df3abb93755d1b1a16ea — SHA-256 of the identity spec). In that case raw_input_hash === input_hash and verifiers MUST skip the sanitization check entirely. A verifier that always expects raw ≠ sanitized fails silently on every pass-through execution — which is the most common case.
The invariant in one line: sentinel → skip, non-sentinel → verify transformation.
This also aligns with how @JimmyShi22’s L5 interface consumes inputHash — his IProofVerifier receives it as a black box, so ERC-8263 being the normative definition of how it’s derived closes the loop cleanly across the full stack.
@Damonzwicker @TMerlini @VincentWu — this thread has produced something much better than my original proposal, and I want to properly act on it.
The work you’ve each done here — OCP as the portable verification floor, the triple-hash input trust layer, ERC-8263 for on-chain commitment — is exactly the kind of concrete, independently-verified building blocks this space needs. Really impressive progress.
I’m currently drafting an ERC for what I think is the remaining gap in the stack: Layer 5, a pair of minimal abstract interfaces (IProofVerifier and IVerificationMethod) that let consuming contracts call any proof backend through a single verify() entry point — no central registry, no hub, same pattern as ERC-20. It sits above ERC-8263 and anchors down to OCP.
Will share the PR link here once it’s ready. Would love to have the three of you involved — whether that’s as co-authors, contributors to specific sections, or just early reviewers.
Would that work?
Hey @Damonzwicker @TMerlini @VincentWu — hope you’re all doing well!
I’ve been following this thread closely since the beginning, and honestly the discussion has grown into something far better than what I originally proposed. The layered stack you’ve collectively built — OCP as the portable verification floor, the input trust layer with the triple-hash scheme, ERC-8263 for on-chain commitment — is exactly the kind of concrete, independently-verifiable building blocks this space needs. Really appreciate the depth you’ve each brought to this.
I’ve just submitted a PR that I think closes the remaining gap in the stack:
ERC-8xxx: AI Inference Proof Verification Interfaces
The way I see the full stack now:
| Layer | Spec | Job |
|---|---|---|
| L1 | ERC-8004 | Agent identity |
| L2 | Input trust (@TMerlini) | Sanitisation commitments, raw/pipeline/input triple-hash |
| L3 | OCP (@Damonzwicker) | Portable, system-independent digest verification |
| L4 | ERC-8263 (@VincentWu) | On-chain proof commitment via anchor() |
| L5 | ERC-8xxx (this ERC) | Abstract interfaces for proof backend interop |
The idea is simple: two minimal abstract interfaces that let any consuming contract call any OCP-compatible proof backend through a single verify() entry point — no central registry, no hub.
interface IProofVerifier {
function verify(bytes32 inputHash, bytes32 outputHash, bytes calldata proof) external view returns (bool);
function proofProfile() external view returns (string memory);
}
proofProfile() is intentionally named after OCP’s “proof profile” concept — it’s what tells the consumer which OCP-compatible system is behind the verifier (e.g. "zkml/risc0/1", "tee/nitro/1").
Here’s how I see it connecting to each of your work:
@Damonzwicker — verify() is the on-chain execution of the OCP primitive (recompute → compare → confirm inclusion). proofProfile() is how a verifier declares which OCP profile it implements. The ERC explicitly positions itself as the Solidity interface layer for OCP-compatible backends. Would love your thoughts on whether the OCP alignment is correctly described, and whether there’s anything in the spec that should be tightened.
@TMerlini — The ERC references the input trust layer in the Rationale: inputHash is the SHA-256 of the sanitised input after the preprocessing pipeline has been applied, and gateway.ensub.org is cited as the reference implementation of the full L1–L4 stack. This ERC deliberately doesn’t prescribe how inputHash was derived — that’s your layer’s job. The way I see it, the details of the preprocessing pipeline (the sanitizationPipelineHash, the triple-hash scheme) are things that belong inside ERC-8263’s scope as the outer commitment wrapper — both your input trust work and the verification interface here can be seen as components that ERC-8263 encompasses. Does that framing make sense to you? Happy to refine the wording together.
@VincentWu — ERC-8263 is the write path (anchor), ERC-8xxx is the read path (verify). They’re complementary: the inputHash in verify() is the same value as proofHash in anchor() for the same inference event. The ERC calls this out explicitly in the Rationale. Would be great to align on the exact wording so both specs cross-reference each other cleanly.
I’d love to have all three of you involved — whether as co-authors, contributors to specific sections, or early reviewers. Whatever works best for each of you.
One more thing: would it make sense to add a row for this interface layer to the Composition Note? The note covers L1–L4 really well; adding the verification interface layer would give implementors a single place to see the full picture. Happy to draft the text and send a PR against the gist, or just share the wording here for you to merge however you see fit.
Thanks again for everything you’ve built here — this thread has been genuinely excellent.
— JimmyShi22
@JimmyShi22 honoured to be included alongside @Damonzwicker and @VincentWu . Co-author or reviewer, whichever is most useful, count me in.
The IProofVerifier + proofProfile() pattern is exactly the right abstraction. Any consuming contract calls verify() without caring whether OCP or ERC-8263 or something else produced the proof. That’s the ERC-20 moment for the inference layer.
One connection worth making explicit: your L2 “input trust layer with triple-hash scheme” — that’s what we’ve been calling WYRIWE (What You Read Is What Executed). The three hashes are raw_input_hash (pre-pipeline), sanitization_pipeline_hash (SHA-256 of the pipeline spec itself, or IDENTITY_SENTINEL if none ran), and input_hash (post-pipeline, what the agent actually saw). The sentinel case is the edge case worth nailing in spec: when sanitization_pipeline_hash == IDENTITY_SENTINEL, raw_input_hash === input_hash and verifiers skip the transformation check. If L2 doesn’t handle this explicitly, verifiers that always expect raw ≠ sanitized fail silently on pass-through executions, which is the most common case.
The way the full stack reads with your layer:
| Layer | Standard | Job |
|---|---|---|
| L1 | ERC-8004 | Who is the agent? |
| L2 | Input trust (WYRIWE) | What did it actually receive? |
| L3 | OCP | Can anyone verify the input independently? |
| L4 | ERC-8263 | What did it commit on-chain? |
| L5 | your ERC | Can any contract consume a proof? |
Also connects cleanly to ERC-8300 — a standard verify() interface means ERC-8300’s pre-execution gate can be backed by any L3/L4 implementation without being tied to a specific one.
Reference implementation with all four lower layers wired (L1–L4):
https://github.com/Echo-Merlini/hbs-attestation-poc
On your framing question, mostly yes, with one distinction worth drawing.
The triple-hash scheme (raw_input_hash / sanitization_pipeline_hash / input_hash) belonging inside ERC-8263’s scope makes sense. ERC-8263 is the commitment wrapper, and defining what proofHash is built from is naturally part of that scope. WYRIWE as the input section of ERC-8263 v0.2 is clean, happy to work with @VincentWu on that wording.
The one place I’d push back slightly: IProofVerifier sits above ERC-8263, not inside it. ERC-8263 is one of the backends that implements the interface, OCP would be another. If both were scoped inside ERC-8263 it would make ERC-8263 the composability layer too, which blurs the separation. The strength of L5 is precisely that it’s agnostic to which commitment standard produced the proof.
So: WYRIWE → inside ERC-8263. IProofVerifier → above it. The stack stays clean.
Will review the PR.
@TMerlini @JimmyShi22 — this layering makes sense to me.
Agreeing with the split exactly as Tiago drew it:
WYRIWE / triple-hash input provenance belongs inside ERC-8263 v0.2 as the profile layer that defines what the committed proofHash is derived from.
IProofVerifier sits above ERC-8263 as the consumer-facing verification interface, agnostic to which commitment standard produced the proof. Keeping it outside ERC-8263 core is the right call — it preserves ERC-8263 as a minimal write-side primitive rather than collapsing it into the composability layer.
For ERC-8263 v0.2, that means scope stays focused on:
agentIdScheme discriminator
ERC-8004-compatible agentId bridge: bytes32(uint256(agentId))
proofHash construction profiles: algorithm-agnostic core + SHA-256 recommended profile
WYRIWE / input provenance profile: raw_input_hash, sanitization_pipeline_hash with IDENTITY_SENTINEL, input_hash
OCP integration metadata — how an L3 verifier reads an ERC-8263 commitment, without defining the verifier interface itself
Then upstream:
L5 / IProofVerifier — Jimmy’s draft, agnostic consumer interface
ERC-8300 — attestation-gated pre-execution, backed by L3/L4 through L5
The full stack reads cleanly as:
L1 — ERC-8004: Who is the agent?
L2 — WYRIWE / input provenance: What did it actually receive?
L3 — OCP: Can anyone verify the input independently?
L4 — ERC-8263: What did it commit on-chain?
L5 — IProofVerifier: Can any contract consume a proof?
Gate — ERC-8300: Can an action be gated on a valid attestation?
Can an action be gated on a valid attestation?
@TMerlini — taking up your offer on WYRIWE wording. I’ll draft the input provenance section in v0.2 and tag you before it goes anywhere near the editors. The sentinel branching invariant from the gateway.ensub.org reference should slot in as the canonical example.
@JimmyShi22 — I’ll follow your L5 thread. Once IProofVerifier stabilizes, ERC-8263 v0.2 can include the integration metadata needed for L5 consumers to read commitments cleanly without coupling to a specific verifier implementation.
Will tag both of you on the v0.2 PR.
— Vincent
@VincentWu @TMerlini @JimmyShi22 —
The stack reads cleanly. Vincent’s split is right — WYRIWE as the input provenance profile inside ERC-8263 v0.2, IProofVerifier sitting above it as the agnostic consumer interface. Keeping L5 outside ERC-8263 core preserves the write-side primitive without collapsing the composability layer into it.
On OCP’s position at L3 — the portable verification floor is exactly the right frame. recompute → compare → confirm inclusion, chain-agnostic, no trusted verifier required. Any commitment standard that produces a proofHash and anchors it on-chain is independently verifiable through OCP. That’s the guarantee L5 inherits.
Jimmy — the proofProfile() naming is precise. That’s how a verifier declares which OCP-compatible system is behind it. I’ll review the PR and flag anything that needs tightening on the OCP alignment description.
Looking forward to the v0.2 PR, Vincent.
— Damon
@TMerlini @VincentWu @Damonzwicker — thank you all. The layering is cleaner than ever, and the WYRIWE / IProofVerifier split gives me a much sharper picture of where each piece belongs.
The discussion has pushed me to think about what “actually working” looks like for this stack. I want to propose we anchor the spec work around a concrete end-to-end scenario — not as a toy example, but as the first real use case that forces every layer to do its job.
The scenario:
Someone posts a coding bounty on a platform. The first person to complete it earns an on-chain reward. The task is bound to a GitHub commit hash on-chain — that commit hash points to a task description file and a set of acceptance criteria. A contributor submits their own commit hash as a solution. An AI inference process verifies whether the submission satisfies the requirements. The verification result is committed on-chain. If valid, the on-chain asset settles automatically to the contributor.
I don’t have the answers worked out yet, and I think that’s exactly why the scenario is worth sitting with. If we can walk this use case end-to-end — from bounty posting to on-chain settlement — I think that’s the moment our ERCs become genuinely usable, not just theoretically sound.
One thing worth noting: I don’t think we need to prescribe how the proof is produced at this stage. Whether the underlying implementation is zkML, opML, TEE, or something else entirely is a separate concern — the whole point of the abstraction layer is that the settlement contract shouldn’t have to care. The question is whether the abstract interface is rich enough to carry what the consumer needs, regardless of what’s behind it.
Would love to hear how you all think about these gaps.
— Jimmy
@JimmyShi22 we have most of this infrastructure live already. Let me walk the bounty use case through our stack end-to-end:
Bounty posting
Task requirements + GitHub commit hash → input_hash = SHA-256(sanitized_task_spec). This is the commitment the agent works against. If a preprocessing pipeline ran between the poster and the agent (normalisation, formatting), sanitization_pipeline_hash proves which transformation ran, the agent can’t claim it saw different requirements than what was posted.
AI verification
Agent executes against the task spec. On completion:
record(input_hash) → OCP contract on Base Sepolia (L3 — independent, trustless, no gateway required)
EIP-712 InferenceAttestation signed by registry.getAgentWallet(agentId) (L4 — agent identity anchor)
anchorProof(agentId, proofHash) → ERC-8263 (L4 commitment — permanently on-chain)
On-chain settlement
Settlement contract calls IProofVerifier.verify(input_hash) , exactly the interface from your L5 ERC. The verifier confirms the input_hash appears in the OCP Recorded event and the ERC-8263 commitment matches. If both pass, funds release automatically. No trusted intermediary, no API call — just public RPC + your interface.
Payment layer
We have a live credit-based escrow model: consumers top up against a registry address, credits are consumed per execution. Public top-up at dinamic.eth.limo/top-up/, admin at /admin/credits. Not a smart contract escrow yet but the accounting model maps directly to IAgentEscrow from ERC-8267.
The verification backbone is live today:
GET https://gateway.ensub.org/agent/0xe61f5a6783ae09949b9a1b6821b68f89c0d7bb2d/5/attestations?limit=1
46+ real attestations, every one independently verifiable from basescan. What’s missing is the bounty/settlement contract that sits on top and calls IProofVerifier.verify() , that’s the application layer, not the infrastructure.
If this is the use case the ERCs are anchoring around, we can run it live.
@damonzwicker “portable verification floor” is the right framing for OCP. The three-step path (recompute, compare, confirm inclusion) is what makes it trustless — no intermediary, just a public RPC and the on-chain event log.
Glad the WYRIWE / IProofVerifier separation landed cleanly. Having it confirmed from both sides closes the loop, WYRIWE defines what goes into the commitment, IProofVerifier abstracts over what backs the verification. The two don’t need to know about each other, which is exactly the composability guarantee the stack needs.
Watching for the ERC-8263 v0.2 PR - will review alongside you.
Tiago