Lido on BNB Chain bridges

Lido's governance on Ethereum sends messages to its executor on BNB Chain through bridge adapters: the controller allows four today (LayerZero, Hyperlane, CCIP and Wormhole), and a proposal in the forum thread would remove Wormhole and leave three. This page reads, at fixed blocks, what verifies a message on the LayerZero, Hyperlane and CCIP routes today, who can change it, and with what delay. It asks whether this is the intended setting; it does not say it is wrong. Every row can be replayed with a public RPC and no key.

What verifies a message today, who can change it, with what delay

Route	What verifies a message today	Who can change it	Delay
LayerZero	All 4 verifiers (DVNs) must sign, after 15 confirmations. It is the default configuration: the Lido adapter has none of its own. The DVN names come from the LayerZero metadata API: Horizen, Nethermind, Canary, LayerZero Labs.	A OneSig contract owns the endpoint and the receive library: threshold 5, 7 signers. By simulation it can replace the default verifier set for this route; the Lido executor cannot (LZ_Unauthorized).	None found
Hyperlane	The Mailbox default applies (the adapter has no ISM of its own). For messages from Ethereum: a multisig of 9 validators, threshold 6, behind a pause switch.	A Safe owns the Mailbox and the routing module: threshold 6, 10 owners, no module. By simulation it can replace the default ISM and the Ethereum route. A separate account owns the pause switch and can pause the route.	None found
CCIP	Chainlink's network, through Router 1.2.0 and the off-ramps registered for Ethereum. How that network is composed was not read.	A timelock owns the router. By simulation, a call to change the registered off-ramps works from the timelock, and a bypass call through the timelock also works.	3 hours through the timelock. Through the bypass call, no delay found (simulated).
Lido executor (receiving side)	The controller requires 3 confirmations out of the 4 adapters it allows, Wormhole included. The proposal in the forum thread would change this to 2 of 3; it has not been executed.	The executor owns the controller, the bridged wstETH and the NTT Manager on BNB Chain. It obeys Lido's governance on Ethereum.	0 seconds after a message arrives; no guardian

Method

Blocks read

Replay it

Each call sends nothing and needs no key. The commands read the latest block, not the blocks above, so a value can differ if something changed since.

Lido side on BNB Chain: the controller and the executor

Expect: 3 confirmations required, 4 adapters allowed (the Wormhole adapter included), an owner that is the executor, no guardian, a delay of 0 seconds.

The three adapters have no owner, no delegate and no setConfig

Expect: each call reverts. A revert means the function does not exist on the adapter, so there is no admin call on the Lido side that changes what the adapter accepts.

LayerZero: what verifies a message and who can change it

Expect: 15 confirmations and 4 required verifiers (all four); no configuration of the adapter's own; the owner of the endpoint and of the receive library is a OneSig contract with threshold 5 and 7 signers.

LayerZero: the simulation (nothing is sent)

Expect: the OneSig call returns and the witness reverts with Ownable. On the endpoint, setConfig returns from the adapter itself and reverts with LZ_Unauthorized from the Lido executor and from the witness.

Hyperlane: what verifies a message and who can change it

Expect: the adapter has no ISM of its own, so the Mailbox default applies; an aggregation of a pause switch and a routing module; for Ethereum, two multisig modules (1 of 2 must accept), each reading the same 9 validators with threshold 6; the Mailbox owner is a Safe with threshold 6, 10 owners and no module.

Hyperlane: the simulation (nothing is sent)

Expect: each call from the Safe (or from the owner of the pause switch, read just above into PAUSE_OWNER) returns; the same call from the witness account reverts with Ownable.

CCIP: the router, its owner and the delay

Expect: Router 1.2.0 owned by a timelock whose minimum delay is 10800 seconds (3 hours).

CCIP: the simulation (nothing is sent)

Expect: applyRampUpdates returns from the timelock and reverts from the witness; a bypass call through the timelock returns from the account used in the simulation and reverts from the witness with a missing-role error. The bypass call does not wait for the delay.

The proposal (3 of 4 to 2 of 3), simulated from the executor

Expect: both calls return from the executor and both revert from the witness (0x...dEaD) with Ownable. This shows who can run these calls; it does not show that a vote has been scheduled.

What I did not read

Where this was asked

This is the longer form of a reply in the Lido research forum thread on the proposal to remove the Wormhole adapter: The thread on the Lido research forum. The question is whether the setting above is the one intended; this page does not say that it is wrong.

Built 2026-10-15 21:09 UTC from facts read directly from the chains. Not an audit, not investment advice. Research · Method · Dashboard.

Lido on BNB Chain: who can change what verifies a message, and how fast?