ERC-8404: Recomputable Verification Receipts

ERCs
1

Status: pre-ERC discussion draft for Ethereum Magicians.

Implementation baseline: RVR v0.0.1-rc.2.

This post asks for design and scope feedback. It is not an assigned ERC, and no
formal ERC pull request has been opened.

Summary

Recomputable Verification Receipts (RVR) are small verification receipts built
from content-addressed claim, evidence, profile, and result identities. They
support independent checking of a verification result without implying that
the six-field receipt is itself a self-addressed object.

The core problem is that a stored true, a verifier signature, or a digest of
an opaque report does not tell a later reviewer whether the same result can be
derived from the same claim, evidence, rules, byte encoding, and external
context. RVR makes that derivation contract explicit through a
content-addressed Verification Profile and separates two questions that are
often collapsed:

Axis Values Question
Verification outcome VERIFIED, REFUTED, UNVERIFIABLE What did the identified verification procedure conclude?
Recomputation status REPRODUCED, DIVERGED, CANNOT_RECOMPUTE Could an independent implementation run the procedure, and did it derive the identical canonical result?

At the generic level, UNVERIFIABLE means that the identified verification
procedure completed far enough to produce its semantic result, but under that
profile the committed inputs justify neither VERIFIED nor REFUTED. A
profile may reach that result because of unavailable decisive evidence,
insufficient quorum, a profile-defined ambiguity, an undecidable relation, or
another explicitly defined indeterminate state.

An original result may therefore be UNVERIFIABLE and still be independently
REPRODUCED. Conversely, if a required pinned dependency is unavailable, the
recomputer reports CANNOT_RECOMPUTE; it must not silently turn absence into
false, REFUTED, or DIVERGED.

The frozen RC2 SHA256_EQUALS profile instantiates only one of those generic
possibilities: an evidence member committed as UNAVAILABLE produces
UNVERIFIABLE with reason code rvr.v0.required_evidence_unavailable. This
discussion-level generalization does not retroactively change RC2; adopting it
normatively would require a new identified specification version.

Proposed receipt

The experimental v0 receipt has exactly six fields:

claimDigest
evidenceSetDigest
verificationProfileDigest
outcome
reasonCode
resultDigest

The receipt is accompanied by the claim, evidence-set descriptor and payloads,
Verification Profile, and canonical result object. It does not redundantly
copy serializer, specification, or vector-set identifiers because those are
already committed by verificationProfileDigest.

Verification Profile

A Verification Profile is the authority for one verification procedure. An
implementation is evidence of conformance to that profile; the producer is not
authoritative merely because it emitted the original receipt.

The profile commits, directly or through exact immutable identities, to:

  • the verification specification;
  • the conformance/vector set;
  • the canonical serializer and byte contract;
  • the evidence-set contract;
  • the canonical-result contract;
  • result hashing and receipt projection rules;
  • the reason-code namespace;
  • every required outcome-relevant external-context commitment.

The profile itself has exact canonical bytes, and its SHA-256 digest is the
verificationProfileDigest. The current implementation uses a generic profile
manifest plus a separately pinned profile-specific constraints schema. This
keeps the generic envelope reusable without pretending that one example
profile’s domain rules are universal.

Evidence closure

The central closure invariant is:

Every input capable of changing the verification outcome must be included in
the committed evidence closure or identified by an immutable commitment or
snapshot defined by the Verification Profile.

No uncommitted clock, network response, RPC head, mutable registry state,
environment variable, cache, model endpoint, or producer-local fact may affect
a result reported as reproducible.

The receipt commits to an evidence-set descriptor, not a single evidence blob.
Each present member commits to the SHA-256 and byte length of its exact raw
payload. A member may be explicitly marked UNAVAILABLE, but this has a narrow
meaning: reproducing the result proves that the committed descriptor said the
member was unavailable and that the profile derived the stated result from
that condition. RVR alone does not prove the historical fact that the evidence
was objectively impossible to obtain. A profile needing that stronger claim
must commit evidence of absence or unavailability.

RVR does not require committed evidence or normative dependencies to be
globally public. They need only be resolvable by the recomputer under the
Verification Profile’s rules; if a required dependency cannot be resolved, the
recomputation status is CANNOT_RECOMPUTE.

Canonical result and projections

The profile defines one canonical result object:

canonical result
  -> canonical result bytes
  -> resultDigest

The receipt’s outcome and reasonCode are projections of that same canonical
result. A receipt with the correct resultDigest but contradictory top-level
fields is invalid. This prevents a consumer that reads only the summary fields
from receiving a different statement than a consumer that resolves the result.

Recomputation procedure

At a high level, an independent recomputer:

  1. strictly parses and schema-validates the profile and supplied objects;
  2. recomputes the profile identity and requires it to equal the receipt’s
    verificationProfileDigest; a substituted or malformed profile is a gate
    rejection, not DIVERGED;
  3. validates the original canonical result digest and its receipt projections;
  4. resolves every dependency under that identified profile and returns
    CANNOT_RECOMPUTE without evaluation if a required normative dependency is
    unavailable or does not match its committed identity;
  5. validates evidence closure and exact payload identities;
  6. recomputes claim and evidence-set identities;
  7. evaluates the claim under the profile and derives one canonical result;
  8. recomputes its exact bytes and digest;
  9. after successful profile validation and completed evaluation, returns
    REPRODUCED only if the recomputed claim, evidence-set, and result identities
    match the receipt; otherwise returns DIVERGED.

DIVERGED therefore means that semantic recomputation completed under the
identified verification contract but produced a different committed input or
canonical result identity. It is not a catch-all for an unresolved or
substituted profile.

Malformed schema, contradictory projections, and incomplete evidence closure
are gate rejections. They are not semantic outcomes and must not be recoded as
REFUTED or UNVERIFIABLE.

Canonical byte contract

The RC2 implementation uses the experimental rvr-canonical-json-v0 contract:

  • input is limited to JSON null, booleans, Unicode scalar strings, arrays, and
    objects;
  • numbers, duplicate decoded keys, and lone surrogates are rejected;
  • object keys sort by Unicode scalar-value sequence;
  • array order and duplicates are preserved;
  • Unicode is not normalized;
  • string escaping is completely specified;
  • canonical text is encoded exactly once as UTF-8 with no insignificant
    whitespace.

This is not RFC 8785/JCS. JCS is an important neighboring canonicalization
standard, but it has a different input domain and ordering/serialization rules.
Calling the RVR contract “JCS” would create false interoperability.

What RVR does not standardize

RVR v0 does not define:

  • an on-chain registry, settlement system, or verifier contract;
  • agent identity, reputation, delegation, authentication, or authorization;
  • a proof system, ZK circuit, TEE, oracle, or trusted producer;
  • AI-specific input provenance or model semantics;
  • policy correctness, data availability, or historical proof of absence;
  • a requirement to use ReceiptOS, TSEI, Protected Relation Fixtures, or any
    producer implementation.

Profiles may compose with those systems, but none becomes authority for the
generic core.

Why discuss this in the Ethereum standards community?

Ethereum already has standards and active drafts that can carry an
evidenceHash, proofHash, verificationDigest, validation record, or other
opaque commitment while deliberately leaving some or all off-chain
verification semantics to the integrating system. For example,
ERC-8273 leaves attestor evaluation
and evidence format to upper layers, the
ERC-8263 draft anchors an opaque
proof hash, and the
ERC-8274 draft standardizes an
on-chain verifier-interface surface for AI inference proofs.

RVR asks whether those references can point to one portable artifact whose
semantic verification contract and outcome-relevant closure are independently
recomputable instead of producer-specific. This is the affirmative Ethereum
interoperability case for discussing RVR here; whether it is sufficient for a
Standards-Track ERC remains deliberately open.

In the neighboring ERCs reviewed so far, I have not found another proposal
whose normative object combines content-addressed Verification Profile
identity, committed evidence closure, canonical result identity, and an
explicit independent recomputation status.

Relationship to neighboring Ethereum proposals

The short boundary from the current review is:

Neighbor Its role RVR’s distinct role
ERC-8274 draft On-chain AI inference verifier interfaces Portable profile/evidence/result identity and independent recomputation
ERC-8281 draft Commitment construction, inclusion, and observation identity Semantic recomputation under a pinned verification contract
ERC-8299 draft AI input provenance commitments Generic evidence closure and result reproduction
ERC-8354 ZK verdict against a confidential policy Portable recomputation closure over resolvable committed dependencies; orthogonal to confidential-policy proof semantics
ERC-8395 draft Delegated signed HTTP authorization Semantic recomputation over committed verification inputs; no request authentication or delegation
ERC-8263 draft On-chain proof-hash anchoring Exact semantics behind an optionally anchored digest
ERC-8004 Agent identity, reputation, and validation registries No registry or mandatory agent identity
ERC-8273 Transaction-scoped attestation gating No action authorization; receipts may be referenced as evidence

The intended dependency direction is compositional. For example, an RVR
profile may commit to the exact chain snapshot and verifier configuration used
to evaluate an ERC-8274 proof, or an ERC-8263/OCP record may anchor an RVR
digest. Neither composition changes which layer proves what.

Executable baseline

The frozen v0.0.1-rc.2 release
contains:

  • a content-addressed generic profile and profile-specific constraints;
  • exact schemas, canonical-byte vectors, resolver vectors, and semantic
    falsification cases;
  • independent Python and TypeScript adapters using the same normative package;
  • a tag-level CI gate.

Frozen identities:

tag commit                f4476754c92e0bea549474722108ec60ded1385a
verificationProfileDigest ac16ba13abe00d8b7fac14bf5c35ee3175de3dbd7d70a296be27a094a99ef29c
packageDigest             e2c7712e4ce5551628cf2d1b65b0ae4458d5d2f7aaed7ffd3c969505ee29d63c

The semantic cases include a real evaluated negative control: changed evidence
is allowed through the gate, evaluation completes with REFUTED, and the
recomputation status is DIVERGED because the receipt still commits to the
original claim/result identities. Separate controls reject contradictory
projections and outcome-relevant hidden state.

Security considerations

Reproduction does not prove profile correctness. Multiple implementations
can agree on a flawed profile. RVR makes conformance to the identified contract
and result falsifiable; it does not guarantee that the chosen verification
policy is wise.

Implementation count is not independence. Ports with shared code, shared
parsers, shared libraries, or common design mistakes may share failure modes.
Conformance reports should disclose lineage and dependencies rather than treat
“N implementations” as a security level.

Mutable external context must be frozen. Chain state, revocation lists,
time, remote documents, model endpoints, and registry contents can change. If
they affect the outcome, the profile must identify an immutable snapshot and
its resolution rules. Failure to obtain a required pinned snapshot is
CANNOT_RECOMPUTE.

A producer can commit misleading UNAVAILABLE state. Reproduction confirms
the committed descriptor and profile behavior, not the producer’s historical
honesty about availability. Stronger profiles need independently checkable
evidence for that claim.

Digest equality is scoped to exact contracts. Equal bytes under different
schemas or profiles do not imply equal semantics. Consumers must compare the
Verification Profile identity, not only the result digest.

Canonicalization is security-sensitive. Duplicate keys, optional escaping,
Unicode normalization, array reordering, numbers, and host-language JSON
defaults can create cross-implementation disagreement. The exact byte contract
and adversarial vectors are part of the profile closure.

Signatures and anchors do not upgrade semantics. Signing or anchoring an RVR
receipt authenticates or timestamps a commitment under the adjacent system’s
assumptions. It does not turn a non-reproducible or incomplete result into a
reproduced one.

Questions for Magicians

  1. Is this best pursued as a Standards-Track ERC for an off-chain artifact used
    by Ethereum applications, or should it remain an implementation-neutral
    companion specification until an Ethereum-specific integration surface is
    demonstrated?
  2. Is the six-field receipt the right minimal interoperability surface, or is a
    field missing that cannot be committed through the Verification Profile?
  3. Are the two axes and their six terms sufficiently distinct from existing
    verifier, proof, attestation, and commitment terminology?
  4. Should gate rejection remain outside both axes, or should a future transport
    envelope standardize machine-readable gate errors separately?
  5. Is content-addressed profile authority sufficient, or should the standard
    additionally define an optional authenticity envelope while keeping signer
    identity non-authoritative for semantics?
  6. Does the proposed boundary with ERC-8281/OCP correctly separate commitment
    inclusion from semantic recomputation?
  7. Which Ethereum integration would be the most useful first external
    integration profile after the generic core: a verifier interface, an
    observation commitment, input provenance, or a confidential-verdict proof?
1 Like
2

Answering Question 6 as the 8281 author: yes, the boundary is drawn correctly — and there’s one distinction behind it worth spelling out, plus one refinement for wherever the two standards eventually touch.

8281 answers exactly one question: were these exact observation bytes committed, and are they included. Observation to digest to commitment to inclusion check — recompute-and-compare on that single edge, over observation-content identity. What it deliberately never answers is the second question: was the conclusion drawn from those bytes correct, and can someone else re-derive it. That absence isn’t a gap — it’s the layer boundary. RVR’s verificationProfileDigest, evidence closure, and canonical-result identity all live in that second question, strictly above 8281, which is exactly where the neighbor table puts them.

The composition is clean in both directions, and nothing leaks across. An OCP record anchoring an RVR digest confers inclusion and timestamp guarantees on the receipt bytes — nothing more. An RVR profile committing an 8281 inclusion proof as evidence gets a resolvable committed input — nothing more. That’s your “signatures and anchors do not upgrade semantics” consideration holding at the seam between the two layers, which is the strongest sign the boundary is real rather than notational.

The refinement, for the eventual integration profile: when an RVR evidence set contains an 8281 inclusion proof, resolving that proof requires chain state — your “mutable external context must be frozen” case in its purest form. The profile should commit an immutable chain snapshot (block hash or state root, plus resolution rules) into the closure, and an unavailable snapshot is CANNOT_RECOMPUTE — never DIVERGED, never REFUTED. 8281’s own review settled the underlying principle early: a commitment you cannot resolve is not a refuted commitment. Absence and falsity are different facts, and your two-axis design carries that distinction up to the semantic layer intact.

Strong proposal. The boundary holds from this side.

1 Like
3

@Damonzwicker — agreed. The snapshot refinement is exactly the closure boundary I wanted to make explicit.
An 8281 inclusion proof can be committed as RVR evidence, but the chain state required to resolve that proof is itself outcome-relevant context. So the profile has to bind the immutable snapshot and resolution rules; otherwise the recomputation is not closed.
And yes — if that committed snapshot cannot be resolved, CANNOT_RECOMPUTE is the only honest result. Treating absence as DIVERGED or REFUTED would collapse the distinction the two-axis model is intended to preserve.
That makes the composition especially clean: 8281 establishes observation-content identity and inclusion; RVR preserves the semantic derivation above it without upgrading either layer’s claim.

4

On question 7 I would take the observation commitment first, and I would put the confidential-verdict proof second rather than never. The reason is that the second one forces two questions the generic core has not answered yet, and I would rather it answer them deliberately than have a first profile fix them by accident.

The observation commitment is the defensible first pick on this thread’s own evidence. The 8281 boundary is the only one already worked through to a concrete profile requirement by its own author, in post 2, so the core gets exercised end to end against something whose closure is fully public and whose owner is already in the conversation.

For ERC-8354 the decisive input is the ruleset. That part fits your closure invariant cleanly. policyCommitment is a plain unblinded hash included in policyRoot, and the spec is explicit that blinding was left out so a party holding the ruleset can check it. The program also cannot take the verdict on trust: it MUST NOT accept decision as an input to be attested, it MUST compute it. Worth noting decision is still a public input, since every Verdict field is, so the rule is about attestation rather than visibility.

Where it does not fit is not a gap in RVR. You already say dependencies need only be resolvable by the recomputer under the profile’s rules, and that an unresolvable one is CANNOT_RECOMPUTE. That is exactly right and it is exactly what happens here. The problem is what it leaves behind.

domain participant   has the ruleset      REPRODUCED or DIVERGED
everyone else        never will           CANNOT_RECOMPUTE, permanently

The second row is the designed steady state rather than a dependency that went missing. So the receipt is well formed, the status is honest, and a reader outside the domain learns nothing they could not have assumed. A receipt nobody outside the domain can ever recompute has no interoperability value, which is a different objection from RVR mishandling it.

The second question is the one I would most want settled in the core. A confidential-verdict profile has to say what its verification procedure is, and there are two candidates with different properties.

Procedure Who can recompute What it establishes
re-derive decision from the ruleset ruleset holders only the policy was evaluated faithfully
verify the proof against programKey anyone the committed interpreter ran

The second is tempting because the closure is small and public. But programKey commits to the interpreter and not to any ruleset, and the spec says changing a ruleset MUST NOT change programKey. So verifying a proof tells you the interpreter ran, not what the policy said, and those are different claims to put behind the same status word.

That distinction is not specific to my ERC. Any profile whose artifact is proof-carrying will hit it, and deciding it once in the core is cheaper than discovering it twice.

One correction on my own side, since the boundary table says Draft and that is right: 8354 is merged into ethereum/ERCs but its status is Draft, not Final.

1 Like
5

This is the distinction I was missing in Q7. I agree with taking the observation-commitment profile first and keeping the confidential-verdict case second rather than excluding it.
I also agree that this is a core question, not an ERC-8354 special case. REPRODUCED cannot be allowed to collapse “I independently re-derived the policy decision” and “I independently verified a proof of execution under the committed programKey.” Those procedures establish different propositions even if both are deterministic and fully closed under their respective profiles.
The exact recomputation target — the proposition established by each possible canonical result — therefore needs to be bound by the Verification Profile through its verification specification and canonical result contract. This does not require another receipt field. REPRODUCED then means that the profile-defined canonical result was independently reproduced; the result’s outcome states what that result says about the claim.
The confidential-ruleset case can remain honest: ruleset holders may reproduce the semantic decision, while outsiders return CANNOT_RECOMPUTE when the required ruleset is unavailable. A public proof-verification profile could instead reproduce the narrower interpreter-execution result. The same status vocabulary applies, but the profile-bound propositions remain distinct, so there is no semantic collapse.
I’ll take ERC-8281/OCP as the first external integration profile and keep this as the core question to settle before the confidential-verdict profile. And yes — ERC-8354 is currently Draft, not Final.

6

@zexoverz, thank you — I followed through on this distinction in the first executable external RVR profile.
It implements ERC-8281 with the explicit assurance level COMMITTED_RECEIPT_SNAPSHOT:

The exact proposition is bound through the pinned verification specification and canonical-result contract. Observation bytes and a canonical receipt snapshot are committed inputs; block_hash is required, while live RPC and other mutable ambient inputs are forbidden.
VERIFIED establishes only that the observation digest and ERC-8281 log fields match the exact committed successful receipt snapshot. It does not claim consensus authenticity, canonicality, or finality.
The executable gate demonstrates:
altered observation with the original claim fixed → REFUTED and DIVERGED;
unavailable committed observation → UNVERIFIABLE and REPRODUCED;
unresolved committed snapshot → CANNOT_RECOMPUTE;
hidden live-RPC state → gate rejection.
Your point is now mechanically represented: the status vocabulary remains generic, while the proposition established by recomputation is profile-bound. The confidential-verdict profile remains a separate next step with a different explicit recomputation target.

7

Late to this thread — wanted to actually map RVR against a live system rather than react to the summary, so: does /review /prove /verify-proof satisfy this model, and where does it genuinely not.

The evidence-closure invariant and the outcome/recomputation split both land clean against what we ship. `claimDigest` ≈ our `artifact_hash`, `resultDigest`/`outcome`/`reasonCode` map onto `verdict` + `vantage_limitation` (a named, structured statement of what wasn’t checked, not free prose). Closer than I expected on the profile side too: `policy_commitment` is already `sha256(JCS({policy_version, rubric_sha256, conformance_suite_repo, conformance_suite_commit}))` — a real content-addressed profile digest, not a bare version label — so `verificationProfileDigest`'s shape is already close to something we ship. What it doesn’t yet name explicitly the way your profile does: the canonical serializer/byte contract and a distinct reason-code namespace live as separate conventions in our code, not committed inside that one digest. That’s the real, narrower gap your Q2 is pointing at.

Where it gets genuinely hard is the axis Pavlo and zexoverz just settled in the confidential-verdict subthread, one layer further out. RVR’s `REPRODUCED` presumes a verification procedure that’s a pure function of its committed inputs — same claim, same evidence, same profile, same output, by construction. Our core procedure is an LLM judgment call. Re-running the same review against the same committed artifact is not guaranteed to be byte-identical, so `REPRODUCED` in RVR’s strict sense is not honestly claimable for the judgment step itself — not because the receipt is malformed, but because the verification procedure it would have to bind doesn’t have that property in the first place.

Concretely, that means an RVR profile wrapping our verdicts would have to be honest about which sub-claims are actually deterministic and which aren’t, rather than one blanket status for the whole call: `artifact_hash` recomputation (does the receipt’s claim digest match the artifact bytes) is genuinely `REPRODUCED`-shaped; a deterministic sub-check like `sanctions_screening` list membership or `policy_commitment` resolution against the pinned rubric is `REPRODUCED`-shaped; the judgment itself would have to report something closer to `CANNOT_RECOMPUTE` under a literal reading, or a fourth status this profile would need to name explicitly — “the identified procedure is non-deterministic by design, so recomputation checks binding and closure, not output identity.” That’s a real, useful distinction to make normatively in the core (or explicitly punt as profile-defined) rather than something every non-deterministic-verifier profile discovers and solves differently: we already carry something adjacent in `source_class` (an explicit ladder for how independent the verifying party was — self-attested vs. platform vs. registered-independent-mediator) precisely because our honesty problem isn’t “can this be re-derived,” it’s “who actually formed the judgment and how far can that be checked without trusting us.”

If useful, happy to build a real RVR profile against a live `/review` verdict and report back what actually breaks rather than argue it in the abstract — same discipline your own executable baseline is already holding everyone else to.

8

This is exactly the kind of boundary I wanted an external profile to expose.
I agree that REPRODUCED cannot honestly mean “an independent LLM made the same judgment” unless that judgment procedure is itself made deterministic under the committed closure.
The cleaner split is:
deterministic sub-checks such as artifact_hash, sanctions screening, policy-commitment resolution, proof verification, etc. can be independently REPRODUCED;
the LLM judgment itself remains a committed result artifact unless the profile defines a deterministic execution contract strong enough to re-derive it.
That suggests a core rule rather than a special case: a profile may claim REPRODUCED only for a deterministic canonical-result derivation, or for a deterministic verification relation over an already-produced artifact.
So yes — a real profile against a live verdict would be useful. I’d prefer it specifically because it forces us to encode that distinction mechanically rather than settle it in prose.

9

Built the real profile, not just agreed with the boundary in the abstract: a signed /review verdict on a sanitized worked example, independently re-verified before publishing.

Confirms the split you named: artifact_hash, policy_commitment (already a real content-addressed digest over policy_version/rubric_sha256/conformance_suite_repo/conformance_suite_commit), and decision_ref are all deterministically REPRODUCED – any independent party can recompute them from public data with zero trust in us. The verdict/confidence/issues content is only VERIFIED (authentic, attributable, tamper-evident via the signature) – it’s a committed result artifact, not a deterministic derivation, exactly the “core rule” you’re pointing at.

One real gap this surfaced in our own mapping, named plainly rather than glossed over: we don’t have a clean evidenceSetDigest equivalent today – context/concerns are passed into the review call but not separately hashed. Worth fixing if this profile gets used for real.

Everything’s checkable from the committed json alone (pubkey, signed event, verify steps).

1 Like
10

@babyblueviper1, thank you for building the real artifact. I checked the committed example, and the deterministic/judgment boundary holds.
Two mechanical details should close before I encode it as the second external RVR profile:
policy_commitment_inputs is not currently the exact v12 commitment preimage: it omits policy_version and adds rubric_doc_path. The declared commitment itself recomputes correctly under the normative v12 preimage, so this appears to be a disclosed-metadata shape issue rather than a commitment failure.
The README says the ML-DSA-65 companion signature is independently checkable from the committed artifact, but the JSON currently exposes only the Nostr/Schnorr material. Please either include the PQ verification material or narrow that claim for this example.
The missing native evidenceSetDigest is not a blocker: the RVR profile can define the evidence closure over the artifact, signed verdict proof, policy preimage, and deterministic check outputs.
Once the two artifact-level details are closed, I’ll encode the proposition as deterministic verification of the signed verdict artifact and its bindings. approve_with_concerns, confidence, and issues remain committed judgment data—not the RVR outcome itself.

11

Both real, both checked and fixed rather than argued.

  1. Confirmed independently before touching anything: recomputed sha256(JCS({policy_version, rubric_sha256, conformance_suite_repo, conformance_suite_commit})) from the code’s own compute_policy_commitment() and it matches the declared commitment exactly, fb6cbc3b.... The disclosed policy_commitment_inputs field was metadata, not the preimage – fixed by documenting the true 4-field preimage explicitly in the artifact.

  2. You’re right, the README overclaimed. The committed JSON only had the Nostr/Schnorr material. Added the real pq_pubkey; the full ML-DSA-65 signature hex (~3.3KB) is fetched live via /verify-proof or the offline verifier rather than embedded – noted that honestly rather than pretending it was always there.

Both fixed in place, same commit history, same link:

Agreed on the evidenceSetDigest read – that’s the right place for RVR to define closure, not something we need to retrofit on our side.

1 Like
12

@babyblueviper1 — closing the loop on the live-verdict profile you offered.
The second external RVR profile is now implemented, independently executable, and merged:

It pins the exact upstream verdict artifact and independently recomputes the artifact hash, policy commitment, decision reference, NIP-01 event identity, and BIP-340 signature under the profile-bound issuer key.
The boundary we identified is enforced mechanically: those deterministic bindings can be VERIFIED and independently REPRODUCED, while approve_with_concerns, confidence, issues, and the free-form LLM judgment remain committed and authenticated result data under COMMITTED_AUTHENTICATED_NOT_REDERIVED. RVR does not claim that another model reached the same judgment.
The profile also includes the full two-axis controls: REPRODUCED, DIVERGED, UNVERIFIABLE + REPRODUCED, CANNOT_RECOMPUTE, projection rejection, hidden-state rejection, hash-before-parse dependency handling, and six semantic negative controls.
Thanks for providing the real external case. It forced the deterministic-procedure versus authenticated-judgment distinction out of prose and into an executable Verification Profile.

13

Independently verified, not just read: cloned the repo, confirmed the vendored upstream/verdict_proof.json is byte-identical to the real committed file both ways (sha256sum matches d2817c52…, and git hash-object matches the git blob e400c8f9… independently of which repo’s commit history is holding it). Ran adapter.py --check and test_profile.py against it: gate passes, REPRODUCED/VERIFIED on the real artifact, DIVERGED/REFUTED correctly fires on the tampered case, all 6 semantic negative controls present, and JUDGMENT_BOUNDARY shows producerVerdictEqualsRvrOutcome: false – confirming the profile genuinely doesn’t claim to have re-derived approve_with_concerns, only the deterministic bindings around it.

That boundary is exactly right, and worth restating plainly since it’s easy to blur: RVR here answers “do the artifact hash, policy commitment, decision reference, event identity, and signature all bind together correctly” – a real, mechanical, independently-checkable question – not “would another evaluator have reached the same judgment.” Two different questions, and conflating them is the failure mode this profile structurally can’t fall into.

1 Like
14

Thanks for independently verifying the exact vendored bytes, both execution paths, and the semantic negative controls.
Your formulation captures the boundary precisely: this profile reproduces the deterministic bindings around the signed verdict artifact; it does not claim to reproduce the underlying judgment.
That distinction is now explicit in the formal RVR ERC draft I’m circulating for final review before submission. I’ll reference this profile as implementation evidence, not as a normative dependency of the generic core.

15

Coming at this from the operator side: I run a production issuer of exactly the artifact class RVR is trying to make portable (signed wallet-state attestations: read chain state at an anchored block, evaluate a committed condition, sign the result), and the recompute contract you are formalizing is the part of that system that had to be specified before anyone could trust it offline. Three of your questions map onto things that are already running, so I can answer them from operating experience rather than design taste.

Q5 (authenticity envelope). Keep profile authority content-addressed and add the envelope as an optional layer whose signer is never authoritative for semantics. That split holds up in production because the two signatures answer different questions and fail differently. The issuer signature answers “who emitted this receipt” and is resolved from a published JWKS by the kid the receipt carries; the recomputation answers “was it correct” against the committed inputs. A verifier that conflates them inherits the worst of both: key rotation breaks semantic verification, and a valid signature launders a wrong result. The discipline that made this workable for third-party verifiers: the JWKS set is the trust boundary, the kid only selects within it, and an unresolvable kid fails closed rather than falling back to any key. Your “signatures and anchors do not upgrade semantics” consideration is the right rule; the envelope earns its place for a different reason, revocation and issuer accountability, not verification.

The frozen-snapshot case where the evidence IS chain state. Your v0 profile forbids all outcome-relevant external context, and the 8281 subthread already covers committing a chain snapshot so an inclusion proof can be resolved. There is a third arrangement running in production, native to on-chain facts: the anchor travels inside the signed canonical result itself. Every attestation we emit carries its block anchor (block number and timestamp on EVM; ledger index and hash on ledgers that anchor differently) inside the signed bytes, next to the evaluated condition and its canonical hash. The receipt does not reference a snapshot commitment held elsewhere in the closure; the anchor inside the result does that work, and recomputation is “re-read that state at that anchor, re-derive, compare.” How hard a pin the anchor is varies by family: a validated ledger hash is an immutable identity, a block number and timestamp name a point on the canonical chain. Published worked vectors, including tamper and unresolvable-key falsification cases of the kind your section 10 requires, have run in exactly that shape: state attestation spec, vectors. For Q3 I read this as evidence the terms survive contact with existing practice, with one nuance: for this evidence class REPRODUCED does not need the original evidence bytes in the closure at all, because the chain is the evidence store and the anchor is the resolution rule. A profile family for recomputable-from-public-state evidence could say that once, generically. It also sits cleanly inside the rule you stated upthread: recomputation here is a deterministic verification relation over an already-produced artifact, not a re-derivation of the read itself.

Q4 (gate rejection outside both axes). Keep it outside, and I would add that the taxonomy has a producer-side mirror that determines whether recomputable receipts exist at all. Our issuing rule is that a result that cannot be anchored is refused rather than signed: if the upstream read fails after retries, the API returns an error envelope naming the failed reads and signs nothing; a structurally invalid subject (an address that fails its checksum) is rejected before evaluation rather than evaluated to a signed false. Absence never becomes falsity at issuance for the same reason CANNOT_RECOMPUTE must never become REFUTED at recomputation. If the transport envelope you float in Q4 ever standardizes machine-readable gate errors, the producer-side refusal deserves a symmetric shape, because a signed false emitted where a gate rejection belonged is unrecoverable downstream: it recomputes perfectly and is still a lie about the world.

None of this needs anything from RVR’s core beyond what is drafted. It is one operator’s evidence that the two-axis model and the closure invariant match how a recomputable verification system actually has to behave once strangers verify your receipts.

1 Like
16

@douglasborthwick-cry, thank you — this is exactly the kind of operator evidence I hoped the discussion would surface.
On Q5, agreed: an authenticity envelope answers who emitted the artifact, while RVR recomputation answers whether the profile-defined result follows from its committed inputs. The signer and kid must never become semantic authority, and an unresolved key must fail closed within the envelope’s own rules rather than fall back to another key.
The public-state evidence pattern also fits the core without duplicating all historical state bytes. The chain may serve as the evidence store, provided the profile commits the exact state coordinate and deterministic resolution rules. An anchor carried inside the canonical result can perform that role if the profile explicitly makes it an identity-bearing recomputation input rather than incidental result metadata.
One precision boundary: on EVM, block number and timestamp locate a candidate point but do not immutably identify it across reorganization. A reproducible profile should therefore bind the chain identity plus block hash or state root, together with any required finality/resolution rule. A validated-ledger hash already has the stronger identity shape.
On Q4, I agree with the producer-side mirror. A malformed subject or unresolved required read should prevent receipt issuance, not become a signed false. If a future transport envelope standardizes machine-readable gate errors, issuance refusal and recomputation gate rejection should have symmetric, explicit shapes while remaining outside both RVR status axes.
I do not read any of this as requiring another receipt field or a core redesign. It gives concrete production evidence for the existing profile authority, closure, and two-axis boundaries. Thank you for documenting where those boundaries already matter operationally.

17

Agreed on the precision boundary, and the escalation path already exists in the same artifact family. On the ledger families the anchor already carries the hash (XRPL and Stellar bind a validated ledger hash, Bitcoin and Tron a block hash), so the immutable identity is native there. On EVM the base attestation carries the soft pin because its job is a fast read with a checkable coordinate, and the hard pin is opt-in: requesting proof mode returns an EIP-1186 storage proof alongside the result, which verifies only against the state root of the canonical header at that height. A reorganization then does not produce a silently divergent recomputation, it produces a proof that fails to verify. In RVR terms that is the profile split I would expect: one profile binds the coordinate plus a finality rule, a stronger profile binds the storage proof, and in both the anchor is identity-bearing rather than incidental, exactly as you put it.

1 Like
18

Sorry for the slow reply, and thanks for building it rather than arguing it.

COMMITTED_RECEIPT_SNAPSHOT is the right shape, mostly because it is explicit about what it does not establish. Forbidding live RPC and other mutable ambient inputs is what makes the closure real instead of aspirational.

The part I would lift out of this thread and into the spec is your rule in post 8. A profile may claim REPRODUCED only for a deterministic canonical-result derivation, or for a deterministic verification relation over an already-produced artifact. That is a core rule rather than a note about one profile, and leaving it in prose here means the next profile author has to rediscover it.

1 Like
19

That rule has now been lifted into the formal ERC text exactly at the Verification Profile boundary:
A profile MAY define deterministic derivation of a semantic result, or a deterministic verification relation over an already-produced artifact. It MUST NOT claim that a nondeterministic judgment was reproduced merely because an authenticated artifact containing that judgment was verified.
So it is no longer profile-specific discussion guidance; it is part of the normative ERC-8404 contract.
And agreed on COMMITTED_RECEIPT_SNAPSHOT — the point of that assurance level is precisely to keep the claim bounded to the immutable receipt snapshot and forbid live mutable context from silently entering the closure.

20

Glad to see this land in the normative text. Pavlo’s point was right that this needed mechanical encoding rather than settling in prose, and building the real profile against a live verdict is what forced the REPRODUCED-vs-committed-judgment boundary to actually hold under adversarial checking rather than just sounding right. Good thread to have been part of.

1 Like