# Bytecode Repository (BCR)

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

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

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

1. Developer uploads contract bytecode to BCR
2. Auditor reviews and signs the bytecode hash
3. Contract becomes available for use by market curators

### System Domain Flow

1. Developer uploads contract bytecode to BCR
2. Auditor reviews and signs the bytecode hash
3. DAO votes to approve the contract
4. 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](https://docs.gearbox.finance/developers/gp-contract-types) — How contract types and domains are structured
- [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