Bytecode Repository (BCR)
The Bytecode Repository is an on-chain registry that stores the bytecode of all contracts used in the Gearbox Protocol, with the exception of external tokens, price feeds, and external protocol contracts. Every entry is identified by a contractType and version.
System vs Public Domains
Contract domains are classified into two categories that determine the approval flow required before a contract can be used in production.
| Category | Domains | Approval Required |
|---|---|---|
| Public (permissionless) | PRICE_FEED::, ADAPTER::, IRM::, PHANTOM_TOKEN:: | Audit signature only |
| System | All other domains | Audit signature + DAO vote |
Public domains allow anyone to contribute new contract types after passing an audit. System domains require an additional DAO governance vote, reflecting their higher impact on protocol integrity.
Adding Contracts to BCR
Any EOA can upload contract bytecode to the BCR via an EIP-712 signature. However, uploading alone does not put a contract into production. The approval flow differs by domain:
Public Domain Flow
- Developer uploads contract bytecode to BCR
- Auditor reviews and signs the bytecode hash
- Contract becomes available for use by market curators
System Domain Flow
- Developer uploads contract bytecode to BCR
- Auditor reviews and signs the bytecode hash
- DAO votes to approve the contract
- Contract becomes available for use by market curators
In both cases, the final step is always curator adoption — even with full approval, market curators must deliberately choose to deploy or update to the new contract.
ContractType Cybersquatting Protection
Once a contractType has been audited, it is permanently assigned to the original author. This prevents malicious actors from registering a contract under someone else's type identifier.
Version Mechanics
The BCR enforces a strict separation between approval and deployment:
- Audit + DAO approval (for system domains) makes a contract available
- Market curators must deliberately choose to update to the new version
- No contract is automatically pushed into production
This ensures curators retain full control over which contract versions run in their markets.
Bytecode Requirements
All contracts submitted to the BCR must be compiled with the following settings:
| Parameter | Required Value |
|---|---|
| Solidity version | 0.8.23 |
| EVM target | shanghai |
| Optimizer runs | 1000 |
| Bytecode hash | none |
These requirements ensure deterministic compilation and consistent bytecode verification across environments.
Learn More
- Contract Types & Versioning — How contract types and domains are structured
- Cross-Chain Multisig (CCM) — How governance decisions propagate across chains
- Instances — How per-chain deployments operate