RFC: Expand OHM Bridging with Chainlink CCIP

amnoodle

Summary

This RFC proposes using Chainlink CCIP for OHM transfers across Ethereum, Arbitrum, Optimism, Base, and Berachain. It would supersede the previously proposed path of redeploying the disabled LayerZero bridge on LayerZero V2 and extend the CCIP integration already used between Ethereum and Solana.

The provider change reflects developments in Olympus' broader relationship with Chainlink and the benefit of expanding an integration that is already live.

The design keeps OHM backed on Ethereum, limits how quickly OHM can move over each route, and separates routine bridge maintenance from emergency and governance powers. It also introduces a one-day review period for routine route changes.

Motivation

The LayerZero Bridge Security Upgrade RFC and OIP-197 proposed replacing the disabled LayerZero V1 bridge with a hardened V2 deployment. They established the case for restoring transfers across the target networks and the need for route limits, transparent configuration, and emergency controls. This RFC does not repeat that case. It updates the proposed infrastructure partner and implementation.

Chainlink has committed to the ongoing upkeep of price feeds used by Olympus and to other forms of support. These commitments strengthen the long-term alignment between both organizations and make Chainlink CCIP integration a more preferable option to Olympus.

CCIP is already used for OHM transfers between Ethereum and Solana, so expanding it to the EVM networks also avoids operating separate bridge systems. The proposed implementation retains the core protections from the earlier design: Ethereum backing, independent limits for every route, delayed routine changes, and immediate emergency containment.

Proposed Network

The bridge would support Ethereum, Arbitrum, Optimism, Base, Berachain, and Solana.

The planned routes are:

	Ethereum	Arbitrum	Base	Optimism	Berachain	Solana
Ethereum		✓	✓	✓	✓	✓
Arbitrum	✓		✓	✓	✓
Base	✓	✓		✓	✓
Optimism	✓	✓	✓
Berachain	✓	✓	✓
Solana	✓

Optimism and Berachain would not have a direct route because Chainlink does not currently provide that lane. Users could still move OHM between them through another supported network.

How It Works

Ethereum backing pool

In contrast to LayerZero’s burn (on the source chain) and mint (on the destination chain), OHM sent from Ethereum is held in a Chainlink lock/release pool. When OHM returns to Ethereum, the same pool releases existing OHM rather than minting new supply.

The pool must hold at least 130,720.915993693 OHM before the new routes can be activated. This amount covers the OHM supply that exists on the four EVM destination networks at launch. To avoid minting new OHM tokens and increasing total supply any more than needed, it is planned to seed the pool by depositing OHM from the DAO MS.

L2 burn/mint pools

Each EVM destination uses an Olympus-controlled burn/mint pool:

OHM leaving an L2 is burned.
OHM arriving on an L2 is minted.
An L2-to-L2 transfer burns OHM on the source and mints the same amount on the destination.

This avoids creating a second wrapped version of OHM and keeps the token address already used on each network.

User-facing bridge

Each EVM network has a user-facing bridge contract that prepares the CCIP message, quotes the fee, and sends the transfer. On receipt, it forwards OHM to the intended user and records a failed delivery so that anyone can retry it later.

The user-facing contract is a convenience layer. Users can also interact with Chainlink's router directly. Disabling the convenience layer alone therefore does not halt OHM transfers; emergency containment is enforced at the token pools.

The DAO Multisig has control over the convenience layer and can update its trusted counterpart and gas settings without the one-day configuration queue. Those settings do not change the routes or limits enforced by the token pools.

Transfer Limits

Every route has separate limits for each direction. The limits use a refillable bucket: a route can move up to its current capacity, and that capacity gradually refills over approximately one day. This is not a fixed daily reset.

Direction	Source capacity	Destination capacity
Ethereum to an EVM L2	100,000 OHM	110,000 OHM
An EVM L2 to Ethereum	50,000 OHM	55,000 OHM
One EVM L2 to another EVM L2	100,000 OHM	110,000 OHM
Ethereum to Solana	10,000 OHM	11,000 OHM

The destination capacity is slightly higher than the matching source capacity because Chainlink may deliver several transfers together after the source bucket has already begun refilling.

The limits are independent per route. They reduce the amount that can move during the period between an incident beginning and the community responding, but they do not remove the underlying risks of cross-chain messaging.

Governance and Emergency Controls

Routine configuration

Routine changes (configuring routes, remote pools, allowlists, and transfer limits) use a dedicated configuration policy. The DAO Multisig can queue changes with an initial one-day delay. Once the delay passes, anyone may execute the action during a three-day window.

The delay can be set between one and thirty days by the local admin (OCG Timelock). A queued action is rejected if the affected route changes before execution. A narrower proposer role limited to rate-limit changes will remain unassigned at launch.

Access control

The full access-control matrix, including role holders and every immediate and timelocked setting, is in Appendix A. The DAO Multisig uses bridge_admin to queue routine changes, while admin can make direct changes: the OCG Timelock holds that role on Ethereum and the local DAO Multisig holds it on the L2s. The DAO Multisig also controls the user-facing bridge settings, which sit outside the token-pool queue and do not change the routes or limits enforced by the pools.

Emergency

The Emergency Multisig can cancel queued changes and reduce one route or every route to an effectively unusable capacity. This containment remains available even if the configuration policies are disabled.

After a disable, the DAO Multisig can restore the configuration policy or its timelock without changing configuration during a three-day grace period. After that period, restoration requires admin. On Ethereum, that means an on-chain governance action. The L2 burn/mint pool does not have this grace-period recovery path: once disabled, only local admin can re-enable it.

Benefits

One consistent CCIP-based bridge model across Ethereum, Solana, and the four EVM networks.
No third-party wrapped version of OHM.
Independent limits for every route and direction.
A visible review period for routine configuration changes.
Permissionless execution and retry once an action or failed delivery is ready.

Risks and Trade-offs

Risk	Mitigation
Chainlink dependency	Per-route limits and pool-level emergency controls constrain exposure, but Chainlink outages can still delay transfers.
Compromised L2 or pool	Route limits restrict onward movement, while the finite Ethereum pool limits the OHM amount that can be released.
DAO Multisig compromise	Ethereum token-pool changes use the one-day queue, and the Emergency Multisig can cancel queued actions. On L2s, the DAO's `admin` role permits direct changes.
Rollout misconfiguration	Readiness checks and staged activation verify ownership, registry authority, backing, and gas configuration before routes open.
Smart-contract vulnerability	Contract-level tests, cross-chain fork rehearsals, and final security audit must be completed before activation.

Next Steps

Gather community feedback and complete contract testing and final security review.
Deploy the contracts and transfer ownership and registry authority to the intended Olympus authorities.
Complete the readiness checks, confirm Chainlink's delivery-gas configuration, fund the Ethereum pool, and submit the on-chain governance proposal.
Configure the L2 policies and execute the Ethereum proposal.
Enable and register the L2 pools and user-facing bridges.

Appendix A: CCIP Access Control Matrix

Holders

Authority	Ethereum	Non-Ethereum EVM chains
Kernel executor	DAO MS	Local DAO MS
`RolesAdmin.admin`	OCG timelock	Local DAO MS
`admin` role	OCG timelock	Local DAO MS
`bridge_admin` role	DAO MS	Local DAO MS
`emergency` role	Emergency MS	Emergency MS
`bridge_rate_limiter` role	Unassigned	Unassigned
OHM administrator in `TokenAdminRegistry`	OCG timelock	Local DAO MS
Token pool owner	`CCIPTokenPoolConfig`	Local `CCIPTokenPoolConfig`
Config operator	`CCIPTokenPoolConfigTimelock`	Local `CCIPTokenPoolConfigTimelock`
Native pool `rateLimitAdmin`	Zero address	Zero address
Lock/release pool rebalancer	OCG timelock	Not applicable; burn/mint pool
`CCIPCrossChainBridge` owner	DAO MS	Local DAO MS

Holder	Address
OCG timelock	`0x953EA3223d2dd3c1A91E9D6cca1bf7Af162C9c39`
Ethereum DAO MS	`0x245cc372C84B3645Bf0Ffe6538620B04a217988B`
Arbitrum DAO MS	`0x012BBf0481b97170577745D2167ee14f63E2aD4C`
Optimism DAO MS	`0x559a14a2219Ae81f9a9f857CF31407de2b07F36c`
Base DAO MS	`0x18a390bD45bCc92652b9A91AD51Aed7f1c1358f5`
Berachain DAO MS	`0x91494D1BC2286343D51c55E46AE80C9356D099b5`
Emergency MS	`0xa8A6ff2606b24F61AFA986381D8991DFcCCd2D55`
Zero address	`0x0000000000000000000000000000000000000000`

The non-Ethereum EVM chains are Arbitrum, Optimism, Base and Berachain. Each carries its own CCIPTokenPoolConfig, CCIPTokenPoolConfigTimelock, CCIPBurnMintTokenPool and CCIPCrossChainBridge, and its own DAO MS.

Timelock parameters

Parameter	Value
Initial delay	1 day
Delay bounds	1 to 30 days
Execution window	3 days
Max sub-actions per batch	15
Max configuration keys per batch	24
Grace period	3 days

Contracts

`CCIPTokenPoolConfig` policy

Owns the local CCIP token pool.

Function	Access	Holder
`acceptPoolOwnership`	`admin`	OCG timelock
`transferPoolOwnership`	`admin`	OCG timelock
`setConfigOperator`	`admin`	OCG timelock
`setRouter`	`admin`	OCG timelock
`setRateLimitAdmin`	`admin`	OCG timelock
`setGracePeriod`	`admin`	OCG timelock
`enable`	`admin`	OCG timelock
`addChain`	config operator or `admin`	`CCIPTokenPoolConfigTimelock`; OCG timelock
`removeChain`	config operator or `admin`	`CCIPTokenPoolConfigTimelock`; OCG timelock
`setRemoteToken`	config operator or `admin`	`CCIPTokenPoolConfigTimelock`; OCG timelock
`addRemotePool`	config operator or `admin`	`CCIPTokenPoolConfigTimelock`; OCG timelock
`removeRemotePool`	config operator or `admin`	`CCIPTokenPoolConfigTimelock`; OCG timelock
`applyAllowListUpdates`	config operator or `admin`	`CCIPTokenPoolConfigTimelock`; OCG timelock
`setChainRateLimits`	`bridge_rate_limiter`, config operator, or `admin`	unassigned; timelock; OCG timelock
`disable`	`emergency` or `admin`	Emergency MS; OCG timelock
`disableChain`	`emergency`, `admin`, `bridge_admin`, or `bridge_rate_limiter`; works while disabled	Emergency MS; OCG timelock; DAO MS; unassigned
`disableAllChains`	`emergency`, `admin`, `bridge_admin`, or `bridge_rate_limiter`; works while disabled	Emergency MS; OCG timelock; DAO MS; unassigned
`reEnable`	`bridge_admin`; within the grace period	DAO MS
`changeKernel`	Kernel	Kernel
`configureDependencies`	unrestricted, invoked by Kernel	-

All functions require the policy to be enabled, except enable and reEnable (require disabled), the two containment functions, and the Kernel-invoked ones.

The two functions below are present on every deployment of the config policy, but revert unless the owned pool supports ILiquidityContainer, which only LockReleaseTokenPool does.

Function	Access	Holder
`setRebalancer`	`admin`	OCG timelock
`transferLiquidity`	`admin`	OCG timelock

`CCIPTokenPoolConfigTimelock` policy

Function	Access	Holder
`enable`	`admin`	OCG timelock
`setGracePeriod`	`admin`	OCG timelock
`setTimelockDelay`	`admin`	OCG timelock
`queueAddChain`	`bridge_admin`	DAO MS
`queueRemoveChain`	`bridge_admin`	DAO MS
`queueSetRemoteToken`	`bridge_admin`	DAO MS
`queueAddRemotePool`	`bridge_admin`	DAO MS
`queueRemoveRemotePool`	`bridge_admin`	DAO MS
`queueApplyAllowListUpdates`	`bridge_admin`	DAO MS
`queueSetChainRateLimits`	`bridge_admin`	DAO MS
`queueBatch`	`bridge_admin`	DAO MS
`executeQueuedAction`	permissionless after the delay	any address
`cancelQueuedAction`	`admin`, `emergency`, or the original proposer; works while disabled and after expiry	OCG timelock; Emergency MS; DAO MS
`disable`	`emergency` or `admin`	Emergency MS; OCG timelock
`reEnable`	`bridge_admin`; within the grace period	DAO MS
`changeKernel`	Kernel	Kernel
`configureDependencies`	unrestricted, invoked by Kernel	-

All functions require the timelock to be enabled, except enable and reEnable (require disabled), cancelQueuedAction, and the Kernel-invoked ones. Queueing and execution both additionally require the config policy to be enabled and to still name this timelock as its config operator.

The admin role is not a queue proposer: every queued action targets a function it can call directly on the config policy.

`CCIPBurnMintTokenPool` policy (non-Ethereum chains)

Deployed with an empty allowlist, so applyAllowListUpdates reverts with AllowListNotEnabled. The pool keeps the legacy enabler, so it has no reEnable and no grace period: once disabled, only the local admin restores it through enable.

Function	Access	Holder
`acceptOwnership`	pending owner	local `CCIPTokenPoolConfig`
`transferOwnership`	owner	local `CCIPTokenPoolConfig`
`applyChainUpdates`	owner	local `CCIPTokenPoolConfig`
`addRemotePool`	owner	local `CCIPTokenPoolConfig`
`removeRemotePool`	owner	local `CCIPTokenPoolConfig`
`applyAllowListUpdates`	owner	local `CCIPTokenPoolConfig`
`setRouter`	owner	local `CCIPTokenPoolConfig`
`setRateLimitAdmin`	owner	local `CCIPTokenPoolConfig`
`setChainRateLimiterConfig`	owner or `rateLimitAdmin`	local `CCIPTokenPoolConfig`; zero
`setChainRateLimiterConfigs`	owner or `rateLimitAdmin`	local `CCIPTokenPoolConfig`; zero
`enable`	local `admin`	local DAO MS
`disable`	`emergency` or local `admin`	Emergency MS; local DAO MS
`lockOrBurn`	on-ramp of the configured router	Chainlink
`releaseOrMint`	off-ramp of the configured router	Chainlink
`changeKernel`	Kernel	Kernel
`configureDependencies`	unrestricted, invoked by Kernel	-

`LockReleaseTokenPool` (deployed on Ethereum)

Its owner changes from the DAO MS to CCIPTokenPoolConfig. Deployed with an empty allowlist, so applyAllowListUpdates reverts with AllowListNotEnabled.

Function	Access	Holder
`acceptOwnership`	pending owner	`CCIPTokenPoolConfig`
`transferOwnership`	owner	`CCIPTokenPoolConfig`
`applyChainUpdates`	owner	`CCIPTokenPoolConfig`
`addRemotePool`	owner	`CCIPTokenPoolConfig`
`removeRemotePool`	owner	`CCIPTokenPoolConfig`
`applyAllowListUpdates`	owner	`CCIPTokenPoolConfig`
`setRouter`	owner	`CCIPTokenPoolConfig`
`setRateLimitAdmin`	owner	`CCIPTokenPoolConfig`
`setRebalancer`	owner	`CCIPTokenPoolConfig`
`transferLiquidity`	owner	`CCIPTokenPoolConfig`
`setChainRateLimiterConfig`	owner or `rateLimitAdmin`	`CCIPTokenPoolConfig`; zero
`setChainRateLimiterConfigs`	owner or `rateLimitAdmin`	`CCIPTokenPoolConfig`; zero
`provideLiquidity`	rebalancer	OCG timelock
`withdrawLiquidity`	rebalancer	OCG timelock
`lockOrBurn`	on-ramp of the configured router	Chainlink
`releaseOrMint`	off-ramp of the configured router	Chainlink

Depositing does not require the rebalancer role: a direct ERC20 transfer has the same effect as provideLiquidity minus the LiquidityAdded event.

`CCIPCrossChainBridge` periphery

Disabling it does not stop CCIP transfers of OHM: the pool only checks that the caller is an on-ramp of the configured router, so any address can call Router.ccipSend directly.

Function	Access	Holder
`transferOwnership`	owner	DAO MS
`setTrustedRemoteEVM`	owner	DAO MS
`unsetTrustedRemoteEVM`	owner	DAO MS
`setTrustedRemoteSVM`	owner	DAO MS
`unsetTrustedRemoteSVM`	owner	DAO MS
`setGasLimit`	owner	DAO MS
`enable`	owner	DAO MS
`disable`	owner	DAO MS
`withdraw`	owner; native balance only, not OHM	DAO MS
`ccipReceive`	configured router	Chainlink
`receiveMessage`	this contract	self
`sendToEVM` payable	unrestricted	any user
`sendToSVM` payable	unrestricted	any user
`retryFailedMessage`	unrestricted	any address

`TokenAdminRegistry` (Chainlink global registry)

Function	Access	Holder
`setPool`	administrator of the token	OCG timelock for OHM
`transferAdminRole`	administrator of the token	OCG timelock for OHM
`acceptAdminRole`	pending administrator of the token	OCG timelock during migration
`proposeAdministrator`	registry module or registry owner	Chainlink
`addRegistryModule`	registry owner	Chainlink
`removeRegistryModule`	registry owner	Chainlink
`transferOwnership`	registry owner	Chainlink
`acceptOwnership`	pending registry owner	Chainlink