# Roles & Permissions

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

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

Gearbox governance is divided into distinct roles with carefully scoped authority. No single role can unilaterally modify a live market — this separation of concerns is the foundation of the permissionless design.

## Role Summary

| Role | Scope | Can Affect End Users? | Primary Responsibility |
| --- | --- | --- | --- |
| **DAO** | All chains | No | Protocol-level governance, code approval |
| **Technical Multisig** | All chains | No | Execute DAO decisions (temporary) |
| **Auditors** | All chains | No | Verify and sign contract bytecode |
| **Instance Owners** | One chain | No | Chain-specific infrastructure and PFS |
| **Financial Representatives** | One chain | No | Fee management per chain |
| **Market Curators** | Specific markets | Yes (with timelock) | Create and manage markets |
| **Emergency Admin** | Specific markets | Yes (immediate) | Emergency response |
| **Pausable/Unpausable Admins** | Specific markets | Yes | Pause/unpause market components |
| **Emergency Liquidators** | Specific markets | Yes | Special liquidation during emergencies |

## DAO (Token Holders)

The DAO represents GEAR token holders and governs protocol-level decisions across all chains. Critically, none of the DAO's actions can modify existing markets.

| Aspect | Detail |
| --- | --- |
| **Scope** | All chains |
| **Voting power** | Proportional to token holdings |
| **Current process** | Snapshot voting, then technical multisig executes |
| **Future process** | On-chain voting directly on transaction batches |

### DAO Authority

| Area | Actions |
| --- | --- |
| **CCM Management** | Manage the Cross-Chain Multisig configuration |
| **BCR Management** | Add auditors, allow system contracts in the Bytecode Repository |
| **Instance Management** | Activate instances, set global addresses |

### Key Constraint

None of the DAO's actions can modify existing markets. The DAO governs the protocol infrastructure, not individual market parameters.

## Technical Multisig

A temporary measure that exists solely to execute DAO decisions. The Technical Multisig has no autonomous decision-making authority.

| Aspect | Detail |
| --- | --- |
| **Scope** | All chains |
| **Autonomy** | None — executes DAO decisions only |
| **Implementation** | Legacy Safe multisig + Cross-Chain Multisig contract |
| **Interaction** | Strictly forced to interact with CCM on Ethereum Mainnet only |

This role is designed to be eliminated once on-chain voting is fully implemented.

## Auditors

External parties who audit smart contracts and sign verified bytecode. They are the gatekeepers for what code can be deployed.

| Aspect | Detail |
| --- | --- |
| **Scope** | All chains |
| **Interaction point** | BCR on Ethereum Mainnet exclusively |
| **Management** | Added and removed by DAO |

### Auditor Authority

| Action | Function | Description |
| --- | --- | --- |
| Submit audit report | `submitAuditReport()` | Add an audit report to the BCR |
| Assign contract type | via `submitAuditReport()` | Assigns contractType ownership to the verified bytecode |

## Instance Owners

Instance Owners manage chain-specific infrastructure through a soft power mechanism. Their authority is limited to preparing the environment — they cannot force changes onto existing markets.

| Aspect | Detail |
| --- | --- |
| **Scope** | One chain |
| **Current composition** | 3 core Gearbox members + 9 tech multisig members, threshold 4 |
| **Neutrality requirement** | Must remain impartial regarding price feed brands |

### Instance Owner Authority

| Area | Actions |
| --- | --- |
| **PriceFeed Store** | Add, update, and remove token/feed mappings |
| **Local addresses** | Manage chain-specific address configuration |
| **Bot management** | Forbid specific bots |
| **Infrastructure** | Manage router and internal systems |

### Key Constraint

None of their actions can modify existing market behavior. PFS changes are not auto-applied to existing markets — they only affect future configuration transactions.

## Financial Representatives

Each chain has a Financial Representative who manages fee-related operations. This role requires cooperation with market curators through a 2/2 approval mechanism.

| Aspect | Detail |
| --- | --- |
| **Scope** | One chain |
| **Appointment** | Set during instance activation |
| **Replacement** | Changed via DAO vote |

### Financial Representative Authority

| Action | Function | Requires 2/2 Approval |
| --- | --- | --- |
| Set default fee split | `setDefaultSplit()` | Yes |
| Set token-specific split | `setTokenSplit()` | Yes |
| Set insurance amount | `setTokenInsuranceAmount()` | Yes |
| Withdraw collected fees | `withdrawToken()` | Yes |

## Market Curators

Market curators are the most powerful market-level role. Anyone can become a curator — the DAO cannot deny participation. The DAO has no responsibility for or control over curated markets.

| Aspect | Detail |
| --- | --- |
| **Scope** | Specific markets |
| **Entry barrier** | None — anyone can become a curator |
| **Primary gateway** | MarketConfigurator contract (supports Ownable2Step) |
| **Default timelock** | 24 hours (hardcoded minimum) |

### Governance Flow

```mermaid
flowchart LR
    Gov[Governor] -->|"submits batch"| TL[Timelock - 24h min]
    TL -->|"executes after delay"| MC[Market Configurator]
    MC -->|"applies changes"| Market[Market]
```

### Market Curator Authority — Configurator Level

| Action | Description |
| --- | --- |
| Set emergency admin | Assign or change the emergency admin for the market |
| Grant/revoke roles | Manage role assignments within the market |
| Create markets | Deploy new markets |
| Shutdown markets | Permanently close markets |
| Add periphery contracts | Register additional contracts for the market |

### Market Curator Authority — Market Management

| Action | Description |
| --- | --- |
| Add collateral tokens | Extend accepted collateral types |
| Create/shutdown credit suites | Manage credit account configurations |
| Upgrade oracles | Change price oracle implementations |
| Upgrade IRM | Change interest rate model |
| Upgrade rate keeper | Change rate keeper implementation |
| Upgrade loss policy | Change loss handling policy |
| Set fees | Configure fee parameters |
| Set limits | Configure borrowing and position limits |
| Ramp LTs | Gradually adjust liquidation thresholds |
| Forbid/allow tokens | Restrict or permit specific tokens |
| Pause/unpause | Halt or resume market operations |

## Emergency Admin

The Emergency Admin can act immediately without timelock delays. This role exists for rapid response to security threats or market anomalies.

| Aspect | Detail |
| --- | --- |
| **Scope** | Specific markets |
| **Timelock** | None — effects are immediate |
| **Appointment** | Set by market owner, can be changed anytime |

### Emergency Admin Authority

| Area | Actions |
| --- | --- |
| **Timelock management** | Cancel pending batches in the timelock |
| **Role management** | Revoke roles |
| **Oracle management** | Configure PriceOracle |
| **Pool emergency** | Set credit manager debt limit to zero, set quota to zero, pause pool |
| **Credit suite emergency** | Emergency credit suite management |

## Pausable/Unpausable Admins

Specialized roles that can pause or unpause specific market components. These provide granular control over market operations during incidents.

| Aspect | Detail |
| --- | --- |
| **Scope** | Specific markets |
| **Authority** | Pause or unpause individual market components |
| **User impact** | Can affect end users |

## Emergency Liquidators

Accounts with special liquidation rights that are only active during emergency conditions.

| Aspect | Detail |
| --- | --- |
| **Scope** | Specific markets |
| **Activation** | Only during emergencies |
| **Authority** | Special liquidation permissions beyond normal liquidator access |

## Learn More

- [PriceFeed Store](https://docs.gearbox.finance/developers/gp-pricefeed-store) — How price feeds are approved and managed
- [Treasury & Insurance](https://docs.gearbox.finance/developers/gp-treasury) — Fee collection and distribution mechanics
- [Guardrails & Role Separation](https://docs.gearbox.finance/developers/gp-guardrails) — The three-layer governance model
- [Cross-Chain Multisig (CCM)](https://docs.gearbox.finance/developers/gp-ccm) — How governance synchronizes across chains
- [Bytecode Repository (BCR)](https://docs.gearbox.finance/developers/gp-bcr) — How code is verified before deployment