VERIFY-5 — bytecode comparison and classification¶
VERIFY-5 classifies reproducible build evidence against canonical deployment evidence without weakening byte-for-byte comparison.
Result classes¶
FULL_MATCH: deployed runtime bytecode matches exactly and, when canonical creation bytecode is recoverable, creation bytecode also matches exactly.PARTIAL_MATCH: runtime bytecode matches exactly but canonical creation bytecode cannot be recovered, so creation equivalence cannot be proven.MISMATCH: canonical and reproduced bytecode differ in runtime or in recoverable creation bytecode.UNVERIFIABLE: required canonical evidence or reproduced build evidence is missing, malformed, or insufficient for a valid comparison.
Exactness rules¶
Runtime bytecode is never compared after stripping metadata, masking linked-library addresses, or masking immutable-reference bytes. Creation bytecode is handled the same way when canonical creation input is recoverable. Metadata hash mode, linked libraries and immutable-reference presence are emitted as diagnostic comparison context so differences remain visible instead of being silently normalized away.
A runtime match alone cannot become FULL_MATCH when creation bytecode was recoverable but failed comparison. Conversely, an unavailable creation transaction cannot force a false mismatch; it yields PARTIAL_MATCH with CREATION_CONTEXT_UNAVAILABLE.
Stable diagnostics¶
VERIFY-5 emits machine-stable reasons including:
EXACT_RUNTIME_MATCHEXACT_CREATION_MATCHCREATION_CONTEXT_UNAVAILABLERUNTIME_BYTECODE_MISMATCHCREATION_BYTECODE_MISMATCHCOMPILED_RUNTIME_MISSINGCANONICAL_RUNTIME_MISSINGINVALID_CANONICAL_EVIDENCEINVALID_BUILD_EVIDENCEMETADATA_DIFFERENCE_RELEVANTLIBRARY_LINKS_RELEVANTIMMUTABLE_REFERENCES_RELEVANT
Every valid comparison remains bound to the VERIFY-2 chain ID + address + canonical runtime-code-hash binding key. Verification remains non-canonical evidence and does not imply audit, safety, endorsement, Registry legitimacy, Wallet authority or immutability.