Guardrails & Role Separation
Most systems fail when one role has too much power. Gearbox achieves permissionless market operation by limiting power rather than adding trust.
Three Governance Layers
1. Protocol DAO (Global)
Manages the codebase and high-level protocol parameters across all chains.
- Approves new contract versions for the Bytecode Repository
- Authorizes chain deployments
- Manages GEAR token incentives
- Cannot alter curator parameters or access user funds
2. Instance Owner (Per-Chain)
A technical multisig on each chain that maintains infrastructure.
- Manages the Price Feed Store (whitelists oracle feeds)
- Executes protocol upgrades on the specific chain
- Operates on a neutral principle: verifies technical correctness, not financial viability
- Composed of diverse ecosystem participants (curators, chain foundation, auditors, core team)
3. Market Curators (Per-Market)
Independent operators of specific lending markets.
- Set risk parameters: liquidation thresholds, adapters, fees, debt limits
- Non-custodial — manage parameters, not funds
- Subject to hardcoded safety constraints (see below)
The Ramping Mechanism
Rather than allowing instant parameter changes, Gearbox enforces linear ramping for critical updates:
- Liquidation threshold changes interpolate linearly over a minimum 24-hour period
- This minimum is hardcoded and immutable — not even curators can bypass it
- Prevents sudden liquidation cascades or market manipulation via parameter changes
- Users have time to react and adjust positions before new parameters take full effect
Emergency Toolset
Curators have access to immediate intervention capabilities for genuine emergencies:
| Emergency Action | Effect | Constraint |
|---|---|---|
| Prohibit a token | Immediately blocks a risky collateral token | Instant |
| Adjust interest rates | Change rate curves to manage liquidity | Instant |
| Increase liquidation thresholds | Make accounts safer (never riskier) | Instant |
| Switch oracle feeds | Switch to an alternative approved feed | Feed must have been in catalog for 2+ days |
The oracle switching constraint is critical: even during emergencies, newly added oracle feeds must have existed in the on-chain catalog for at least 2 days before they can be deployed. This prevents an attacker from adding a malicious oracle and immediately switching to it.
Key Design Principle
Even if governance were compromised, it cannot directly change user positions or interfere with curated markets. Each layer's power is bounded by smart contract logic, not by trust in the operators.
Learn More
- Bytecode Repository (BCR) — How code verification prevents unaudited deployments
- Cross-Chain Multisig (CCM) — How governance decisions synchronize across chains