Summary:
This OIP proposes to upgrade the OHM bridge to a hardened LayerZero V2 architecture, and re-enable cross-chain OHM transfers across Ethereum, Arbitrum, Optimism, Base and Berachain.
The old single contract is replaced by a four-contract architecture:
LZBridgeGateway (policy) - the OApp: endpoint messaging, OHM mint/burn, rate limiting, and bridged-supply accounting.
LZCrossChainBridge (periphery) - the user-facing facilitator, with zero protocol permissions.
LZEndpointDelegate (policy) - the gateway's registered endpoint delegate, through which library selection, ULN/Executor config, and inbound channel-management calls are routed.
LZBridgeAndDelegateConfig (timelock policy) - queues security and accounting- elevant configuration changes behind a delay before they apply.
On top of this, four independent layers of protection ensure no single failure can drain the protocol: four required DVNs per route with the optional slot pinned to NIL, mandatory bidirectional per-route rate limits, a bridged-supply cap on Ethereum, and a timelock over configuration changes. Every endpoint parameter is explicitly pinned and validated after write, so the bridge inherits no LayerZero default.
Specification:
Four required DVNs per route – LayerZero Labs, Canary, Nethermind, and Google Cloud (Horizen substitutes for Google Cloud on Berachain routes). No optional DVNs; optionalDVNCount is pinned to a NIL sentinel so a future change to LayerZero defaults cannot change the set of validators. Verification is split across multiple operators, so no single party (including LayerZero's own DVN) can pass a message alone.
Bidirectional per-route rate limits – independent inbound/outbound limits on a 24h sliding window, with offsetting accounting so balanced round trips free capacity faster.
Bridged-supply cap on Ethereum – every outbound transfer increments bridgedSupply; every inbound receive decrements it with an underflow check. More OHM cannot return than was sent out, capping worst-case exposure to legitimate non-canonical supply (130,000 OHM, ≈0.66% of total) regardless of rate-limiter headroom.
Timelock on configuration changes – DVN sets, message libraries, rate limits, and bridged-supply adjustments are not freely mutable. Changes are queued through LZBridgeAndDelegateConfig behind a configurable delay (1–30 days, suggested 1 day, with a 3-day execution window), giving the community an observation window to detect and cancel a malicious or mistaken re-configuration. The emergency role can cancel any queued action.
Configuration:
Every parameter is explicitly pinned and validated post-activation – no LayerZero default is inherited. This covers the V2 endpoint, SendUln302/ReceiveUln302 message libraries, per-chain confirmations (ETH 15, ARB 20, OPT 20, BASE 10, BERA 20), a Type 3 enforced-options floor of 200,000 gas for lzReceive, the per-chain executor, and a 10,000-byte max message size. A dedicated LZEndpointDelegate policy is explicitly set as the gateway's endpoint delegate; library and ULN/Executor config flow through it and are therefore timelocked, while the inbound channel-management functions remain immediate for incident response.
Rate limits (per remote, 24h sliding, offsetting).
ETH outbound 100,000 / inbound 55,000 OHM;
L2 outbound to Ethereum 50,000; L2 outbound to another L2 100,000;
L2 inbound 110,000.
Access control and re-enable. Configuration authority is split across Kernel roles:
bridge_configurator – granted to the timelock policy;
bridge_admin – DAO MS;
bridge_rate_limiter – this role can be granted to an off-chain keeper in the future to adjust rate limits based on demand (e.g. HyperNative);
bridge_facilitator – bridging periphery contract.
The full configuration (endpoint addresses, message libraries, DVN addresses, executors, EIDs) and the per-function timelock matrix are documented in the RFC appendices.
Migration plan:
Migration is sequenced so the old bridge stops accepting sends before any new bridged supply is written, and the new bridge goes live on Ethereum only after all L2s are configured:
- Deploy the four contracts on all five chains, plus the single-use LZBridgeActivator on Ethereum (batches the full canonical configuration into one call).
- Pre-OCG MS batch on Ethereum activates the gateway, delegate, and config policies in the Kernel (no user-visible change).
- OCG proposal on Ethereum grants the permanent roles, runs LZBridgeActivator.activate() (sets the delegate, pins libraries and ULN/Executor with four required DVNs and the NIL-pinned optional slot, sets peers, options, and rate limits, enables the gateway), revokes the activator's temporary roles, and grants bridge_configurator to the timelock – every value validated on write.
- Confirm old-bridge traffic is stopped on every chain.
- Set the bridged-supply snapshot on Ethereum via the one-time initializeBridgedSupply, after clearing any in-flight or failed V1 messages.
- Configure and activate each L2 bridge in order via DAO MS batches (configureAndEnable), then hand bridge_configurator to each L2's timelock policy.
- Pin each periphery's configurator to its timelock, confirm the old CrossChainBridge is deactivated, and enable LZCrossChainBridge.
Next steps:
OIP vote
Contract deployment:
OCG vote
Proposal execution and bridge activation.
Discussion:
https://forum.olympusdao.finance/d/5365-rfc-layerzero-bridge-security-upgrade
