mikko.build
← Back to posts

Institutional-Grade Security. Chapter 2: Onchain Github for bytecode

securitysmart-contracts

Audits don't matter if deployments can be tampered with.

– Verified bytecode lives on-chain
– Only code signed by both developer and auditor can run
– No unaudited or modified code reaches production
– Typed metadata makes upgrades safe and predictable

4 min read

Header

This chapter covers one of the most fascinating parts of Gearbox Permissionless: the Bytecode Repository — a completely new concept that functions as an on-chain GitHub for smart contracts. It reshapes how contracts are deployed, audited, and upgraded across all networks.

This is the second chapter in the series. If you missed Chapter 1 ("Guide Rails & Roles"), you can read it here: Institutional-Grade Security. Chapter 1: Guardrails and Role Separation

From personal pain to protocol design

This system was born out of personal pain. Every time we deployed a new market or plugin, I had to manually confirm that the generated bytecode perfectly matched the audited version. To reduce the risk of a compromised build environment, we compiled contracts on two independent machines and compared bytecode manually—often directly in the GitHub tab in IDE.

It was tedious, slow, and error-prone, but absolutely necessary. Deployment is just as critical as auditing: if the build process is compromised, the audit loses all meaning. A single altered byte during compilation can silently invalidate all prior security guarantees.

Tweet

Auditors 👏 should 👏 audit 👏 deployments 👏 also

One of the main things the security team at Polygon does is verify every deployment before it gets used.

The teams who don't have an internal security team MUST demand demand their auditors to verify all deployments.

— Mudit Gupta (@Mudit__Gupta) December 5, 2025

The Bytecode Repository was designed to eliminate this entire class of risk.

Security and guaranteed use of audited code

Security

The first and most important goal of the Repository is security. All contract bytecode is uploaded, verified, and stored on-chain. A contract cannot be used in production unless its exact bytecode has been cryptographically signed by both the developer and an independent auditor.

This removes one of the most underestimated attack vectors in DeFi: compromised developer machines, CI pipelines, or off-chain build tooling. The blockchain becomes the single source of truth for what code is allowed to run.

Strict quality control: no unaudited code in production

Quality Control

The second milestone is enforcing mandatory audits at the protocol level. Any contract passing through this pipeline must be validated by an auditor. If it is not audited, it simply cannot be deployed or used by curators.

This guarantees that:

  • no unaudited code reaches production,
  • no contract can be silently swapped or modified,
  • all upgrades and patches are fully transparent and verifiable.

The Bytecode Repository acts as a cryptographic gatekeeper for protocol safety.

Domains, types & version control

Version Control

Each contract in the Bytecode Repository includes typed, on-chain metadata that defines how it can be safely used. This metadata consists of a domain, type, and version, all embedded directly in the bytecode and read automatically by the protocol.

The domain defines the expected interface, while the type specifies the concrete implementation (for example, a linear or fixed interest rate model). Versioning follows strict semantic rules: major versions may introduce breaking changes, minor versions extend behavior without breaking compatibility, and patch versions apply safe fixes only. Because this information is machine-readable, the system can automatically recognize backward-compatible upgrades and propose patch-level updates to curators without ambiguity or manual checks.

With this foundation in place, Gearbox can safely manage upgrades, audits, and deployments entirely on-chain—removing reliance on developer environments and off-chain processes. In the next chapter, we'll build on this and explain how these guarantees translate into full protocol autonomy.

More ideas →