ERC-8404: Recomputable Verification Receipts

Abstract

This ERC defines Recomputable Verification Receipts (RVR), a six-field receipt format built from content-addressed claim, evidence-set, profile, and result identities for independently recomputing profile-defined verification results. An RVR commits to a claim, an evidence-set closure, a Verification Profile, and one canonical result while keeping the semantic verification outcome separate from the status of a later recomputation. The format does not make a producer implementation authoritative and does not require an on-chain registry.

Motivation

A stored boolean, verifier signature, or digest of an opaque report does not identify the claim, evidence closure, verification procedure, byte encoding, result semantics, and external context needed to derive the result again. Different implementations can therefore appear to agree while evaluating different inputs or interpreting the same data differently.

RVR makes those dependencies explicit and content-addressed. It separates two questions that are commonly collapsed:

• What did the identified verification procedure conclude?
• Could an independent implementation run that procedure and derive the identical canonical result?

This distinction is useful when Ethereum applications exchange off-chain verification results, optionally commit their digests on-chain, or compose semantic verification with observation commitments, proof-verifier interfaces, confidential-policy proofs, provenance records, or authenticated requests. An on-chain anchor can establish inclusion or ordering of receipt bytes, but it does not by itself establish that the committed semantic result is reproducible.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Terminology

The following terms are used:

• Receipt: the exact six-field RVR object.
• Verification Profile: the content-addressed authority defining one deterministic verification procedure, its proposition, closure, result contract, and reason codes.
• Canonical result: the single profile-defined result object from which receipt outcome and reasonCode are projected.
• Evidence-set descriptor: the content-addressed list of evidence-member identities and availability states.
• Profile package root: the explicit root against which profile-pinned dependency paths are resolved.
• Gate rejection: rejection of malformed, contradictory, or incompletely committed input before a verification outcome or recomputation status can be validly reported.
• Candidate input: the claim and evidence closure supplied for an independent recomputation against a fixed receipt and Verification Profile.

Independent status axes

The verification outcome is semantic and MUST be one of:

A profile MUST define the exact conditions and reason codes for every outcome. UNVERIFIABLE is not limited to unavailable evidence. A profile MAY use it for unavailable decisive evidence, insufficient quorum, ambiguity, an undecidable relation, or another explicitly defined indeterminate state.

The recomputation status concerns a later independent run and MUST be one of:

The recomputation status is not a seventh receipt field. It is the output of applying the recomputation procedure to a receipt and supplied dependencies.

An UNVERIFIABLE result MAY be REPRODUCED. CANNOT_RECOMPUTE MUST NOT be converted into UNVERIFIABLE, REFUTED, DIVERGED, or a default false value.

Receipt

An RVR receipt MUST be a JSON object with exactly these six members and no others:

claimDigest
evidenceSetDigest
verificationProfileDigest
outcome
reasonCode
resultDigest

The four digest members MUST be 64 lowercase hexadecimal characters without a prefix and identify SHA-256 digests. outcome MUST be one of the three verification outcomes. reasonCode MUST be a member of the Verification Profile's committed verification reason-code namespace.

The receipt is accompanied by, but does not embed, the claim object, evidence-set descriptor and payloads, Verification Profile package, and canonical result object.

Canonical byte contract

All identity-bearing RVR JSON objects MUST use rvr-canonical-json-v0.

Its input domain consists only of JSON null, booleans, Unicode scalar-value strings, arrays, and objects. JSON numbers are forbidden. Quantities such as byte lengths MUST be encoded as canonical unsigned decimal strings matching ^(?:0|[1-9][0-9]*)$, with no sign and no leading zeros except for the single string 0.

Canonicalization MUST apply these rules:

1. Reject duplicate object keys after JSON string decoding.
2. Reject lone Unicode surrogate code points. A well-formed escaped surrogate pair represents its single Unicode scalar value.
3. Apply no Unicode normalization.
4. Encode null as null and booleans as true or false.
5. Encode strings using the exact string-escaping rules below.
6. Preserve array order and duplicates.
7. Sort object keys by ascending Unicode scalar-value sequence.
8. Emit no insignificant whitespace.
9. Encode the resulting canonical string exactly once as UTF-8.

String encoding MUST emit an opening quotation mark, process each Unicode scalar value in order, and emit a closing quotation mark. The exact escapes are:

The solidus U+002F, line separator U+2028, and paragraph separator U+2029 MUST be literal. No other optional JSON escape spelling is permitted. These rules apply to both object keys and string values.

Identity rules

The following identities MUST be computed over exact canonical bytes:

claimDigest =
  SHA-256(rvr-canonical-json-v0(claim))

verificationProfileDigest =
  SHA-256(rvr-canonical-json-v0(verificationProfile))

resultDigest =
  SHA-256(rvr-canonical-json-v0(canonicalResult))

The SHA-256 output MUST be encoded as lowercase hexadecimal without a prefix.

Evidence set

An evidence-set descriptor MUST be an object with exactly:

schema
members

schema identifies the profile-pinned evidence-set contract. members MUST be a non-empty array. Member IDs MUST be unique.

A present member MUST contain exactly:

id
status = PRESENT
mediaType
byteLength
digest

byteLength MUST be the canonical unsigned decimal length of the exact raw payload bytes. digest MUST be the SHA-256 digest of those exact bytes. A resolved PRESENT member MUST have exactly one supplied payload whose byte length and digest match the descriptor. If the committed-present payload cannot be resolved, the descriptor remains valid but recomputation MUST return CANNOT_RECOMPUTE with evaluationPerformed = false and MUST NOT run evaluation.

An unavailable member MUST contain exactly:

id
status = UNAVAILABLE
reasonCode

An unavailable member MUST have no supplied payload. The profile determines whether and how that committed availability state affects the semantic result.

Before evidence-set canonicalization, members MUST be normalized by ascending member id under Unicode scalar-value ordering. The evidence-set identity is:

evidenceSetDigest =
  SHA-256(rvr-canonical-json-v0(normalizedEvidenceSetDescriptor))

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. Outcome-relevant ambient input is forbidden.

RVR does not require evidence to be globally public. Required committed dependencies need only be resolvable by the recomputer under the profile's rules. If a member is committed as present but its payload cannot be resolved, the status is CANNOT_RECOMPUTE and evaluation MUST NOT be reported as performed.

Reproducing a result derived from an UNAVAILABLE descriptor proves that the descriptor contained that state and that the profile derived the result correctly. It does not by itself prove the historical fact that evidence was objectively impossible to obtain. A profile requiring proof of absence or unavailability MUST commit that proof as evidence or immutable external context.

Verification Profile

The Verification Profile is the semantic authority. A producer implementation, signer, or registry is not authoritative merely because it emitted or stored a receipt.

A Verification Profile MUST be an rvr-canonical-json-v0 object and MUST commit, directly or through exact immutable dependency identities, to:

• a unique profile identifier;
• the exact verification specification;
• the exact proposition established by each possible canonical result;
• a pinned conformance-vector set;
• the canonical serializer and byte contract;
• the receipt, claim, evidence-set, and canonical-result contracts;
• result-hash and receipt-projection rules;
• the verification, recomputation, and gate-rejection reason-code namespaces;
• profile-specific constraints;
• dependency-resolution rules;
• every required outcome-relevant external-context commitment.

profileId MUST match [A-Za-z0-9][A-Za-z0-9._-]*.

The verification specification and canonical-result contract MUST jointly make the recomputation target unambiguous. 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.

The common profile envelope MUST contain these members:

schema
profileId
profileSchemaContract
dependencyResolution
verificationSpecification
conformanceVectorSet
canonicalByteContract
schemaContracts
evidenceSetContract
canonicalResultContract
resultHashRules
reasonCodeNamespace
externalContextPolicy

The common envelope and every common nested object defined below MUST reject additional members. Profile-specific semantics belong in the pinned verification specification, schemas, and constraints rather than as unidentified envelope extensions.

A dependency identity MUST contain exactly:

id
path
sha256
requiredForRecomputation

id MUST be unique within its containing dependency set. path MUST follow the resolution rules below. sha256 MUST be a lowercase hexadecimal SHA-256 digest. requiredForRecomputation MUST be a boolean. Any dependency whose bytes can affect validation, evaluation, the canonical result, or recomputation status MUST set requiredForRecomputation to true. A dependency marked false MUST be non-semantic conformance or provenance material and MUST NOT influence recomputation.

profileSchemaContract MUST identify both the generic manifest schema and a profile-specific constraints schema. The constraints schema MUST NOT be parsed or applied before its exact bytes match its committed digest.

profileSchemaContract MUST contain exactly manifest and constraints, each encoded as a dependency identity. dependencyResolution MUST contain exactly base, pathFormat, locatorRole, and verificationOrder, with the following values:

base = SUPPLIED_PROFILE_PACKAGE_ROOT
pathFormat = relative-posix-no-empty-dot-dotdot-or-colon-segments
locatorRole = NORMATIVE_PACKAGE_RELATIVE_PATH
verificationOrder = resolve-read-sha256-match-use

verificationSpecification MUST be one dependency identity.

conformanceVectorSet MUST identify its member files and an aggregate digest. The aggregate digest MUST be SHA-256 over UTF-8 rows sorted by path, with each row encoded exactly as:

<path>\t<SHA-256(exact-file-bytes)>\n

conformanceVectorSet MUST contain exactly id, members, digest, and digestRule. members MUST be a non-empty array of dependency identities, paths MUST be sorted by Unicode scalar-value sequence for the aggregate, and digestRule MUST equal sha256-utf8-sorted-path-tab-file-sha256-lf-rows.

canonicalByteContract MUST identify rvr-canonical-json-v0 and its rules exactly as specified by this ERC.

canonicalByteContract MUST contain exactly id, encoding, domain, objectKeyOrder, arrayOrder, unicode, numbers, stringEscaping, solidus, lineSeparators, and whitespace. Their exact values MUST be:

id = rvr-canonical-json-v0
encoding = UTF-8
domain = null-boolean-unicode-scalar-string-array-object
objectKeyOrder = unicode-scalar-value-ascending
arrayOrder = preserved-with-duplicates
unicode = scalar-values-only-no-normalization
numbers = forbidden
stringEscaping = rvr-json-string-escaping-v0
solidus = literal
lineSeparators = U+2028-and-U+2029-literal
whitespace = none

schemaContracts MUST be a non-empty array of dependency identities with unique IDs.

evidenceSetContract and canonicalResultContract MUST identify exact schema bytes and JSON Schema pointers. canonicalResultContract MUST define JSON Pointer projections for outcome and reasonCode. The pinned verification specification and result contract MUST define the exact proposition represented by the result.

evidenceSetContract MUST contain exactly schemaPath, schemaSha256, schemaPointer, and digestRule. canonicalResultContract MUST contain exactly schemaPath, schemaSha256, schemaPointer, outcomeProjection, and reasonCodeProjection. The evidence-set digestRule MUST equal sha256-utf8-rvr-canonical-json-v0-normalized-member-order.

resultHashRules MUST require SHA-256 over the exact rvr-canonical-json-v0 canonical result bytes and lowercase hexadecimal output without a prefix.

resultHashRules MUST contain exactly algorithm, input, encoding, and output, with the following values:

algorithm = SHA-256
input = rvr-canonical-json-v0(canonicalResult)
encoding = UTF-8-exactly-once
output = lowercase-hex-no-prefix

reasonCodeNamespace MUST enumerate all permitted verification, recomputation, and gate-rejection reason codes. Each set MUST contain unique values.

reasonCodeNamespace MUST contain exactly verification, recomputation, and gateRejections, each encoded as an array of strings.

externalContextPolicy MUST forbid uncommitted ambient inputs and MUST enumerate every immutable external-context commitment required by the profile. Mutable chain state, registry state, time, policy, model output, resolver output, or API response MUST NOT affect a reproducible outcome unless frozen by a profile-defined immutable commitment or snapshot.

externalContextPolicy MUST contain exactly mode, ambientInputs, and immutableCommitments. ambientInputs MUST equal FORBIDDEN, and immutableCommitments MUST be an array of profile-defined immutable identity strings.

Dependency resolution

The recomputer MUST receive an explicit profile package root with the profile package. A dependency path is a normative package-relative locator, not a process-working-directory path, URL, Git reference, or advisory hint.

Dependency paths:

• MUST use / as the separator;
• MUST be relative;
• MUST NOT contain empty, . or .. segments;
• MUST NOT contain reverse solidus or colon characters;
• MUST resolve within the supplied package root, including after resolving filesystem links.

For each dependency, the only permitted order is:

resolve under the supplied profile package root
  -> read exact bytes once
  -> verify SHA-256 against the committed digest
  -> parse or use those same verified bytes

Bytes MUST NOT influence validation or evaluation before their committed digest matches. Re-reading a locator after verification and using different bytes is forbidden.

The generic profile schema is the bootstrap contract supplied to the verifier. After strict parsing, the profile's generic-schema pin MUST identify byte-for-byte that same bootstrap schema. The profile-specific constraints schema MUST be hash-verified before parsing or application.

Canonical result and receipt projections

Each profile MUST define exactly one canonical-result contract. Every canonical result MUST contain profile-defined data sufficient to identify the exact proposition, semantic outcome, reason code, and relevant evaluation facts.

The receipt outcome MUST equal the result selected by the committed outcome projection. The receipt reasonCode MUST equal the result selected by the committed reason-code projection.

A receipt with contradictory top-level projection fields is invalid even if resultDigest correctly identifies the canonical result. This is a gate rejection, not DIVERGED or REFUTED.

Recomputation procedure

Given a receipt, original canonical result, candidate claim and evidence, and a supplied profile package, a recomputer MUST perform these steps in order:

1. Strictly parse the receipt and generic Verification Profile envelope. Reject duplicate keys, forbidden numbers, lone surrogates, and schema-invalid shapes.
2. Recompute verificationProfileDigest and require equality with the receipt.
3. Resolve every required profile dependency using hash-before-parse rules and resolve every candidate evidence payload whose descriptor is committed as PRESENT. If a required profile dependency or committed-present payload cannot be resolved, return CANNOT_RECOMPUTE with evaluationPerformed = false. If a required profile dependency resolves to bytes whose SHA-256 digest does not equal its committed pin, return CANNOT_RECOMPUTE with evaluationPerformed = false; those bytes MUST NOT be parsed or used.
4. Validate the original receipt, canonical result identity, and result projections. Contradictory projections or malformed committed objects are gate rejections.
5. Validate the candidate evidence closure. Duplicate members, uncommitted outcome-relevant input, a resolved PRESENT payload whose byte length or digest does not match its descriptor, or an UNAVAILABLE member with a payload are gate rejections.
6. Recompute the candidate claimDigest and evidenceSetDigest.
7. Execute the profile's deterministic verification procedure and derive exactly one canonical result.
8. Recompute the canonical result bytes and resultDigest.
9. Return REPRODUCED only if the candidate claim, evidence-set, Verification Profile, and canonical-result identities equal the receipt commitments.
10. Otherwise, if evaluation completed under the fixed profile, return DIVERGED and preserve the newly derived verification outcome and reason code as diagnostic data.

A recomputer MUST NOT trust stored expected output in place of executing the verification procedure.

Conformance requirements

A conforming profile suite MUST mechanically demonstrate at least:

• an identical recomputation producing REPRODUCED;
• an evaluated, internally self-consistent claim- or evidence-relevant mutation producing DIVERGED for the intended semantic reason rather than failing only because of unrelated descriptor drift;
• an original UNVERIFIABLE result independently producing REPRODUCED;
• an unavailable required normative dependency producing CANNOT_RECOMPUTE without evaluation;
• a required normative dependency resolving to bytes that fail its committed digest producing CANNOT_RECOMPUTE without parsing or evaluation;
• an unavailable committed-present evidence payload producing CANNOT_RECOMPUTE without evaluation;
• rejection of a resolved committed-present payload whose byte length or digest does not match its descriptor;
• a control proving that withholding or substituting the bytes of a dependency marked requiredForRecomputation = false cannot change validation, evaluation, the canonical result, or recomputation status;
• rejection of a contradictory receipt projection while preserving resultDigest;
• rejection of outcome-relevant hidden state;
• a hash-before-parse negative control for profile-specific constraints;
• at least one counterfactual demonstrating that the evaluator can fail for the intended semantic reason.

The local conformance entry point and continuous-integration entry point SHOULD execute the same logical gate.

Rationale

Acknowledgements

Special thanks to Tiago Merlini (@TMerlini), Fede / Baby Blue Viper (@babyblueviper1), Faisal Firdani (@zexoverz), and Damon Zwicker (@damonzwicker) for independent review, executable counterexamples, external integration work, and semantic boundary analysis that materially improved this proposal.

Six receipt fields

The receipt contains only the identities and projections required to identify a verification result. Serializer, vector-set, schema, and specification digests are not copied into the receipt because they are already committed by verificationProfileDigest. Adding them would create redundant values that could contradict the profile.

The receipt itself is not self-addressed. resultDigest identifies the canonical result, not the receipt object containing it.

Profile authority

Different domains require different claims, evidence, reason codes, and external-context rules. Placing those semantics in a content-addressed Verification Profile permits independent implementations without treating one producer binary as authoritative.

The exact proposition is profile-bound because successful execution of different deterministic procedures can establish different facts. Re-deriving a policy decision and verifying a proof emitted by a committed interpreter are not interchangeable even if both procedures are deterministic.

Evidence-set identity

A single evidence-blob digest cannot express multiple inputs, explicit unavailability, media types, or independently resolvable members. The evidence-set descriptor closes every outcome-relevant input while allowing payloads to remain separately stored or private.

No mandatory registry

RVR is a portable artifact format. A receipt digest MAY be anchored by an application, but this ERC does not define a registry, settlement mechanism, timestamp authority, or finality rule. Anchoring bytes does not upgrade their semantic meaning.

Relationship to neighboring proposals

RVR is complementary to application-layer mechanisms that authenticate requests, commit observations, prove private-policy evaluation, record provenance, or verify inference proofs.

ERC-8354 defines confidential agent policy verdicts. RVR does not define its proof system or policy semantics; a Verification Profile can identify such a deterministic proof-verification relation and its committed inputs.

ERC-8004 defines agent identity, reputation, and validation registries. RVR requires neither an agent identity nor a registry.

The open Observation Commitment Protocol, AI Inference Proof Verification Interfaces, AI Input Provenance, and Delegated Signed HTTP Requests proposals address commitment, proof, provenance, and authorization layers. RVR addresses the distinct layer of reproducing a profile-defined semantic result over committed verification inputs.

Backwards Compatibility

This ERC introduces a new off-chain artifact format and does not change Ethereum consensus, transaction validity, existing contracts, or existing receipt formats.

Experimental pre-standard RVR profiles remain identified by their exact profile bytes and digests. This ERC does not retroactively reinterpret those profiles. Applications adopting this ERC MUST use a profile whose exact specification and contracts conform to this document.

Test Cases

All strings in this section are shown without a trailing line feed unless explicitly stated.

Canonical bytes

The following inputs MUST be rejected before identity computation:

• any JSON number;
• duplicate decoded object keys;
• a lone high or low surrogate;
• an optional escape spelling where this ERC requires a literal scalar value.

Arrays ["a","a","b"] and ["a","b","a"] MUST produce different canonical bytes. Strings encoded as precomposed U+00E9 and decomposed U+0065 U+0301 MUST produce different canonical bytes.

Identity example

For exact evidence bytes abc, the SHA-256 digest is:

ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad

The canonical claim bytes are:

{"evidenceMember":"artifact","expectedDigest":"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad","operation":"SHA256_EQUALS","schema":"rvr.claim.sha256-equals.v0"}

Its claimDigest is:

1a3e1868528b22a4a7b33943922cc968ae84c5d3a8b588b56ccb17c6e4d022c9

The normalized evidence-set descriptor bytes are:

{"members":[{"byteLength":"3","digest":"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad","id":"artifact","mediaType":"application/octet-stream","status":"PRESENT"}],"schema":"rvr.evidence-set.v0"}

Its evidenceSetDigest is:

ad2e277f24b256b63cbdfffefa750fa2fea84b93dea0cb18a38ba52ec66e2f99

The canonical result bytes are:

{"evaluation":{"evidenceMember":"artifact","expectedDigest":"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad","observedDigest":"ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad","operation":"SHA256_EQUALS"},"outcome":"VERIFIED","reasonCode":"rvr.example.digest_match","schema":"rvr.canonical-result.example.v0"}

Its resultDigest is:

6b5d6e0529e10b3bda66e187b774942cab2d7e69a579222f4892168bb28894dd

Status separation

Security Considerations

Misleading unavailability

A producer can commit misleading UNAVAILABLE state. Reproduction proves correct derivation from that committed descriptor, not objective historical unavailability. Profiles requiring a stronger claim must commit evidence proving absence or unavailability.

Signatures and anchors do not upgrade semantics

A signature can authenticate an artifact and an on-chain transaction can anchor its bytes. Neither establishes that the artifact's semantic result is correct or reproducible. Such mechanisms are evidence inputs unless the profile defines a stronger proposition.

Nondeterministic judgments

A profile MUST NOT label a nondeterministic judgment REPRODUCED merely because another implementation produced similar prose or the same coarse verdict. It MAY reproduce deterministic sub-checks or a deterministic verification relation over an authenticated judgment artifact, but the profile must name that narrower proposition.

Procedure completeness

REPRODUCED establishes stability under the profile-defined procedure; it does not establish that the procedure is complete with respect to any broader claim not committed by the Verification Profile.

Mutable external context

Live RPC responses, registries, clocks, mutable policies, model endpoints, and resolver results can change outcomes. They MUST NOT influence a reproducible result unless the profile commits an immutable snapshot and exact resolution rules. An unavailable required snapshot produces CANNOT_RECOMPUTE.

Canonicalization disagreement

Host-language JSON defaults differ in key ordering, escaping, number handling, normalization, and treatment of malformed Unicode. Implementations MUST use the byte contract in this ERC and MUST execute negative vectors. Agreement between two implementations is not a substitute for the normative byte definition.

Dependency substitution and time-of-check/time-of-use

Applying a schema or specification before checking its digest permits substituted bytes to influence validation. Re-reading a dependency after verification permits time-of-check/time-of-use substitution. Implementations MUST hash before parsing and use the same verified bytes.

Incomplete evidence closure

If an outcome-relevant input is omitted, a result may appear reproducible while depending on hidden state. Implementations MUST reject incomplete closure and MUST NOT report REPRODUCED.

Hash collisions

RVR identity relies on SHA-256 collision and second-preimage resistance. A future hash transition requires a newly identified profile and explicit migration rules. Existing profile identities MUST NOT be reinterpreted under another hash function.

Confidential evidence

RVR does not require globally public evidence. Applications must separately control authorization, disclosure, retention, and transport. A party lacking a required private dependency reports CANNOT_RECOMPUTE; it must not infer REFUTED from non-disclosure.

Resource exhaustion

Profiles can reference large evidence sets or expensive verification procedures. Profiles SHOULD define size and resource limits. Implementations MAY refuse work exceeding local limits, but such refusal MUST NOT be reported as a semantic verification outcome.

Producer and implementation authority

A producer implementation is not authoritative. Contract and profile identity define semantics; implementations provide evidence of conformance. A verifier signature MUST NOT override a profile mismatch, failed closure, contradictory projection, or divergent canonical result.

Copyright

Copyright and related rights waived via CC0.