# Contract Types & Versioning

> Markdown export of the Gearbox Protocol documentation page for agents and retrieval systems.

Canonical page: https://docs.gearbox.finance/developers/gp-contract-types
Source file: content/developers/gp-contract-types.mdx
Section router: https://docs.gearbox.finance/developers/llms.txt
Section full export: https://docs.gearbox.finance/developers/llms-full.txt

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:

1. **Patched versions only** — updates are only permissible via patched versions of an existing contract type, ensuring interface stability
2. **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)](https://docs.gearbox.finance/developers/gp-bcr) — How contract bytecode is stored, audited, and approved
- [Cross-Chain Multisig (CCM)](https://docs.gearbox.finance/developers/gp-ccm) — How governance decisions propagate across chains
- [Instances](https://docs.gearbox.finance/developers/gp-instances) — How per-chain deployments operate