How Verification Works

A Vrfier verification answers one question with cryptographic precision:

Does this source code, built deterministically, produce exactly the bytecode running at this contract address?

The pipeline

1. Resolve on-chain bytecode

Soroban separates a contract instance from the WASM code it points to. Vrfier reads the contract’s installed code entry from the ledger and derives its canonical hash — the ground truth every verification is measured against.

2. Reproducible rebuild

The submitted source is compiled in a pinned environment:

a fixed Rust compiler version,
the wasm32v1-none target,
locked dependency versions, and
a normalized build configuration.

Determinism is the whole game here: if two honest parties can’t get the same bytecode from the same source, a hash comparison proves nothing.

3. Hash comparison

The rebuilt WASM is hashed with the same scheme used in step 1 and compared byte-for-byte against the on-chain hash.

Outcome	Meaning
Match	The deployed contract was built from exactly this source.
Mismatch	The bytecode differs — different source, build settings, or tampering.

4. Recorded, re-checkable verdict

A successful verification stores the inputs needed to reproduce it — contract address, source location, commit, and toolchain metadata — so the result is independently verifiable. The trust model is “verify, then trust,” not “trust Vrfier.”

Why reproducibility is hard

Small things break determinism: build timestamps, absolute paths embedded in binaries, non-pinned dependencies, or compiler version drift. A large part of Vrfier’s job is eliminating these sources of nondeterminism so that a legitimate match is reliable and a mismatch is meaningful.

Limitations

Verification proves source ↔ bytecode correspondence. It does not prove the source is bug-free or secure — that’s the job of an audit.
A contract must use a reproducible build setup for verification to succeed.

Introduction — the problem and the high-level approach.
Quick Start — verify a contract yourself.