Contract Types & Versioning
Every contract in Gearbox is identified by a contractType (bytes32) and a version (uint256), enabling precise classification and safe modular upgrades without proxies.
Domains and Contract Types
Contract types are organized into domains based on functionality. Domains and subtypes are separated by :: notation.
| Domain | Example Types | Description |
|---|---|---|
IRM | IRM::FIXED, IRM::LINEAR_MODEL | Interest rate models |
PRICE_FEED | PRICE_FEED::CHAINLINK, PRICE_FEED::REDSTONE | Price feed implementations |
ADAPTER | ADAPTER::UNISWAP_V3, ADAPTER::CURVE | Protocol integration adapters |
PHANTOM_TOKEN | PHANTOM_TOKEN::STETH | Phantom token wrappers |
Contract types within the same domain share the same programming interface, but their configurations may differ. For example, IRM::FIXED and IRM::LINEAR_MODEL both implement the interest rate model interface, but accept different constructor parameters.
Version Control
Versions are encoded as uint256 integers (e.g., 3_10 represents version 3.10). The versioning scheme uses three levels:
| Level | When to Use | Compatibility |
|---|---|---|
| Major | Significant interface changes | Breaking — not backward compatible |
| Minor | Minor interface changes | May require integration updates |
| Patch | Same interface, no behavioral changes | Fully backward compatible |
Module Replacement, Not Proxies
Gearbox upgrades contracts through module replacement rather than proxy patterns. When a new version is available:
- The new contract is deployed as a standalone module
- The old module is swapped out for the new one
- No proxy delegation or storage layout concerns
This approach eliminates the risks associated with proxy-based upgrades (storage collisions, delegatecall vulnerabilities) while keeping the system modular.
Upgrade Rules
Two critical constraints govern upgrades:
- Patched versions only — updates are only permissible via patched versions of an existing contract type, ensuring interface stability
- No forced updates — system upgrades are managed exclusively by market curators. The DAO cannot force a curator to adopt a new contract version
Even when a new version passes audit and DAO approval, it remains opt-in. Market curators deliberately choose whether and when to update their deployments.
Learn More
- Bytecode Repository (BCR) — How contract bytecode is stored, audited, and approved
- Cross-Chain Multisig (CCM) — How governance decisions propagate across chains
- Instances — How per-chain deployments operate