Skip to content

Conformance

This page defines what external implementations must preserve to remain conformant with the currently published bounded profile.

Conformance Scope

Protocol conformance is about preserving protocol authority and verifier-boundary semantics. It is not a requirement to copy the reference wallet or runtime internals line-for-line.

Required Conformance Invariants

  1. Protocol object continuity: continuation output remains the authoritative next-hop protocol source.
  2. Boundary integrity: runtime-produced proof and Proof Blob version 1 (PBv1) bytes are preserved into transaction carrier bytes.
  3. Verifier profile alignment: Trustless Relation Query 1 (TRQ1), backend id 2, and Public Inputs version 1 (PIv1) encoding are respected.
  4. Fail-closed behavior: boundary mismatches reject rather than silently degrade.
  5. Claim-boundary discipline: proof-enforced semantics are not conflated with artifact-described behavior.

Protocol Conformance vs Implementation Detail

  • Protocol conformance: authority continuity, accepted boundary formats, bounded lane assumptions, and truthful public/non-public classification.
  • Implementation detail: UI flows, local storage layout, scheduling, provider selection, and non-normative wallet heuristics.

Conformance And Public Claims

Conformant docs/artifacts must separate:

  • current truth
  • proof-enforced semantics
  • artifact-described behavior
  • public observables
  • future optional aggregation

Conformance does not authorize broad full-system zero-knowledge claims.

Code Mapping