Deployed bytecode reproducibility
A post-deploy hygiene & change mgmt factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score#
What this measures
This factor checks whether the protocol's deployed bytecode is independently reproducible from the public repository and the protocol's declared build toolchain — meaning a third party can clone the repo, install the declared compiler version and dependencies, run the declared build command, and produce bytecode that matches the deployed runtime bytecode byte-for-byte. Reproducible builds are a necessary condition for independent verification of any deployment claim.
Why it matters
Build reproducibility is the technical foundation for auditability. Without it, even a fully audited and source-verified protocol cannot be confirmed to deploy what it published: compiler version drift, dependency version differences, and build-environment assumptions can all produce materially different bytecode from identical source. The StableMagnet exploit ($27M) demonstrated this attack class: Techrate audited code from the GitHub repository while the deployed BSC library was a completely different binary — users had no way to detect the discrepancy because build reproducibility was not established. Reproducible builds create a deterministic verification path from source to deployment that any party can independently audit.
Green / Yellow / Red
Green is assigned when the protocol provides a documented build configuration (Dockerfile, pinned foundry.toml, or equivalent) and independent reproduction of the deployed bytecode is confirmed for at least the most recent deployment. Yellow covers cases where build instructions are published but contain environment-specific assumptions, or where reproducibility has been verified for earlier versions but not the current deployment. Red is assigned when no build reproducibility documentation exists and independent bytecode reproduction cannot be performed.
Common gray cases
This factor is grayed when the protocol operates on a non-EVM chain where deterministic compilation tooling is not yet standardized, or when the deployment predates the availability of reproducible build tooling for the relevant compiler.
Notable historical examples
No cross-hacked incidents currently linked in database for this factor.
Measurement what to look for#
Determine whether anyone can independently reproduce the deployed bytecode from the repo and declared build toolchain.