Verifying an alkane

Verification answers one question: does this on-chain contract really come from the source someone claims? The explorer answers it by rebuilding the source and comparing the result to the bytecode that is actually deployed.

The verdicts

The diff engine emits one of five verdicts. The first two earn a badge on the alkane page.

Why isn't every honest build reproducible? Because a wasm embeds things the compiler put there from its environment – the build's HOME, the crates.io index source-dir hash, git-checkout hashes, the toolchain host triple, and the clang vendor/version in the producers section. Reproduce all of them and you get byte-exact; miss one and the bytes shift. Cross-host C code (secp256k1) is the one axis that doesn't fully reconstruct, which is exactly the gap between reproducible and verified.

reproducible vs verified, concretely

Cross-host builds still reach reproducible when the only host-dependent input is the toolchain path or host triple – those we reconstruct exactly. The one axis that doesn't fully reconstruct is a C object linked from a foreign host (secp256k1), which is the gap that leaves a build at verified instead.

• 4:797 (free-mint) – pure Rust, Linux. Once the registry path, Ubuntu clang 14.0.0, and the bare alkanes-rs git source-id were pinned, a Linux box reproduced it byte-for-byte → reproducible.
• 2:0 (DIESEL) – originally built on an Apple Silicon Mac. Reconstructed on Linux by copying the toolchain into a …-aarch64-apple-darwin path (rustc canonicalizes symlinks) and assembling the origin's Homebrew clang – byte-for-byte → reproducible (proven against minibot).
• 4:9200 (predicates pair-equality) – originally built with Windows rustc 1.86.0 (x86_64-pc-windows-msvc). Reproduced on Linux by running that Windows toolchain under Wine: the residual was the rustc -vV host: line, folded into every crate's -C metadata / StableCrateId, which only a genuine Windows host triple fixes. Same architecture, so Wine reproduces it bit-for-bit → reproducible.
• 4:76 (busd) and the oyl implementations – these link secp256k1 built by a foreign host's clang, whose C-object footprint shifts the memory base by ~6 bytes. Code and producers are exact; the tiny residual keeps them at verified (~99.997%). See Reproducible builds explained.

How the explorer verifies

1. You (or the contract author) submit a build recipe for an alkane id – either through alkanes-cli or by POSTing to /api/v1/{key}/verify. In practice the recipe is tiny: { alkane, repo_url, commit, package, subdir } is enough for most alkanes – see below.
2. The verifier fetches the on-chain bytecode (metashrew_view getbytecode) and rebuilds the source in a sandbox that pins the recipe's axes.

The recipe reverses itself

You rarely spell out the environment axes. The verifier reads the on-chain bytecode once and reverses the recipe straight out of it – the embedded panic paths carry the exact git-dep revs, the build HOME, the toolchain host triple, and the clang/rustc versions, and the deploy transaction's confirmation time gives the crates.io freeze date. So a submission of just the repo, commit, and package reproduces most contracts with no hand-tuning; any field you do pass simply overrides its auto-reversed value. This is why the /verify body is almost always four or five lines. 3. It diffs the rebuilt wasm against the bytecode and records the verdict. A reproducible/verified result auto-promotes the source to the alkane's verified-source panel – there is no trusted manual step for these. 4. The alkane page then shows the badge, a browsable source tree (served from our DB, so it works even for private repos), and the reproduction recipe.

Because the verifier only promotes on an actual byte match, the verify endpoint is safe for any valid API key – a bad recipe simply fails to promote. The only trusted write path is /api/v1/{key}/attest, which is admin-gated because it records a result without a sandbox rebuild (used for builds the Linux verifier can't itself reproduce byte-exact).