Reconfigure BSC governance forwarding after Wormhole auto delivery shutdown

Proposals
1

Removal of the Wormhole adapter from a.DI governance forwarding to BNB Chain and threshold change from 3/4 to 2/3

Summary

This proposal suggests removing the Wormhole adapter from Lido DAO governance forwarding to BNB Chain and lowering the required confirmations on BNB Chain from 3 of 4 to 2 of 3 bridges.

Wormhole shut down automatic delivery for its Standard Relayer on 1 April 2026. The Lido Wormhole adapter depends on that relayer, so only Chainlink CCIP, LayerZero and Hyperlane can still deliver Lido DAO messages to BNB Chain. With three working bridges and a threshold of three, an outage or delay of any one of them blocks Lido DAO decisions on BNB Chain. A 2-of-3 threshold restores tolerance to one bridge outage; forging a message would then require compromising two bridges instead of three.

Background

Lido DAO decisions reach BNB Chain through a.DI, the cross-chain messaging layer built by BGD Labs and adopted for Lido under LIP-24. The Lido DAO Agent sends a message to the CrossChainController on Ethereum, which forwards it through four bridges. The CrossChainController on BNB Chain accepts the message once 3 of the 4 bridges have delivered it. The CrossChainExecutor then executes it.

Bridge Ethereum adapter BNB Chain adapter
Chainlink CCIP 0x29D4fA5FCC282ba2788A281860770c166F597d5d 0x15AD245133568c2498c7dA0cf2204A03b0e9b98A
Hyperlane 0x8d374DF3de08b971777Aa091fA68BCE109b3a7F3 0xCd867B440c726461e5fAbe8d3a050b2f8701C230
LayerZero 0x742650E0441Be8503682965d601AD0Ba1fB54411 0xc934433f4c433Cf80DE6fB65fd70C7a650D8a408
Wormhole 0xEDc0D2cb2289BBa1587424dd42bDD1ca7eAbDF17 0xBb1E43408BbF2C767Ff3Bd5bBC34E183CC1Ef119

LIP-24 set the threshold at 3 of 4. With four working bridges, this setting tolerates the failure of any one bridge, and forging a message requires compromising three.

The CrossChainExecutor is the owner of the wstETH token on BNB Chain and of the NTT Manager, Wormhole Transceiver and Axelar Transceiver of the wstETH bridge (addresses in deployed contracts). A message accepted on BNB Chain can therefore call any owner function of these contracts.

Issue

The Wormhole leg of the route no longer has a committed delivery to BNB Chain, so every Lido DAO message now depends on CCIP, LayerZero and Hyperlane all delivering it. If one of them fails, the message waits until that bridge recovers or someone redeems the Wormhole copy manually.

  • Wormhole shut down its Standard Relayer service on 1 April 2026. Wormhole Guardians still sign messages, so a message can still be redeemed manually, but Wormhole no longer delivers it to the destination chain. The replacement service, Executor, requires a different adapter.
  • The Lido Wormhole adapters on both chains have the Standard Relayer address (0x27428DD2d3DD32A4D7f7C497eAaa23130d894911) fixed at deployment and cannot use the Executor.
  • The Standard Relayer on Ethereum still accepts requests. Its delivery quote for BNB Chain has been 0 since block 24788662 (2 April 2026, 01:34 UTC) and was non-zero before.
  • A request that pays nothing gives no operator a reason to deliver it. Other applications’ Standard Relayer messages to BNB Chain are still delivered by their own or third-party relayers (Wormholescan); Lido has no such arrangement.
  • The Ethereum CrossChainController records the Wormhole attempt as successful, so the failure is not visible on Ethereum. A forwarding simulated on an Ethereum mainnet fork at block 26126408 confirmed this: all four adapters reported success.

The issue was reported in lidofinance/aave-delivery-infrastructure#12 on 3 September 2026.

Rationale

The route has to keep delivering Lido DAO messages and stay hard to forge. Since Wormhole stopped delivering, the 3-of-4 setting keeps its forgery margin but tolerates no bridge outage. We compared four options:

Option Bridge outages tolerated Bridges to compromise to forge a message Needs new code and audit Needs a manual step per message
Keep 3 of 4 0 3 No No
Keep 3 of 4 and redeem Wormhole messages manually 1, while Wormhole redemption tooling is available 3 No Yes
Replace the Wormhole adapter with an Executor-based one, keep 3 of 4 1 3 Yes No
Remove Wormhole, require 2 of 3 (proposed) 1 2 No No

We propose 2 of 3 because it is the only option that restores tolerance to one bridge outage with no new code and no manual step for each message. The cost is a lower forgery margin: two bridges instead of three. The CrossChainExecutor has no execution delay and no guardian, so an accepted message executes without a veto window under either threshold.

For the amount at stake today, we consider confirmation by two independent bridges sufficiently reliable. About 1,189 wstETH is bridged to BNB Chain (supply), backed by wstETH locked in the NTT Manager on Ethereum. That is about 1,481 stETH, or $4.0M at Chainlink prices on 5 October 2026.

If the bridged amount grows substantially, a separate proposal can add a fourth working adapter, such as an Executor-based Wormhole adapter or another bridge, and restore 3 of 4.

Proposal

Disable the Wormhole adapters on both chains and require 2 of the 3 remaining bridges to confirm a message.

Parameter Current Proposed
Bridges, Ethereum → BNB Chain CCIP, Hyperlane, LayerZero, Wormhole CCIP, Hyperlane, LayerZero
Required confirmations on BNB Chain 3 of 4 2 of 3

Proposed vote items:

  1. The Lido DAO Agent calls forwardMessage on the Ethereum CrossChainController (0x93559892D3C7F66DE4570132d68b69BD3c369A7C) with the BNB Chain CrossChainExecutor as destination and a gas limit of 1,200,000. The bridge delivery that completes the quorum also queues the action set on BNB Chain, which takes about 880,000 gas. The message carries one action set that calls the BNB Chain CrossChainController (0x40C4464fCa8caCd550C33B39d674fC257966022F):
    • disallowReceiverBridgeAdapters([(0xBb1E43408BbF2C767Ff3Bd5bBC34E183CC1Ef119, [1])]) stops accepting Wormhole deliveries from Ethereum;
    • updateConfirmations([(1, 2)]) sets the required confirmations for messages from Ethereum (chain ID 1) to 2.
  2. The Lido DAO Agent calls disableBridgeAdapters([(0xEDc0D2cb2289BBa1587424dd42bDD1ca7eAbDF17, [56])]) on the Ethereum CrossChainController, which stops forwarding to BNB Chain (chain ID 56) through Wormhole.

Item 1 runs before item 2, so the message carrying the BNB Chain change still goes out through all four bridges. Under the current setting it needs CCIP, LayerZero and Hyperlane to deliver it. If one of them fails, the Wormhole copy of the message can be redeemed manually as the third confirmation.

No fee top-up is needed. The Ethereum CrossChainController pays bridge fees from its own balance, 0.497 ETH and 5.01 LINK today, and a fork simulation of item 1 with this gas limit spent about 0.0007 ETH and 0.041 LINK.

Next steps

  1. If there are no objections, the vote items above will be included in an upcoming Lido DAO on-chain vote, executed through Dual Governance.
  2. Once the message reaches BNB Chain, contributors will call execute on the CrossChainExecutor within 24 hours of the message’s arrival; after that, the action set expires.
  3. The deployed contracts page will be updated to mark the Wormhole adapters as disabled.

Feedback welcome before moving to an on-chain vote!

References

3 Likes
2

Dropping to 2 of 3 changes what the threshold is counting, and that seems worth pinning down first.

The three remaining adapters are not interchangeable units. LayerZero has no protocol level verifier set of its own: each application configures its own DVN set and threshold, an X of Y of N arrangement, so whatever secures the a.DI leg to BNB Chain is a configuration a.DI chose rather than a property of LayerZero. CCIP is itself the bridge, and what secures it is a Chainlink oracle network that agrees off chain on which messages were sent before that summary is posted on chain.

So the question I would want settled before the vote: which entities sit in the required DVN set on the a.DI LayerZero adapter for BNB Chain, and does any of them also operate in the Chainlink network behind the CCIP leg?

If those two overlap, then the count of bridges to compromise in the rationale table is counting adapters rather than independent parties, and the forgery margin after the change is smaller than that row suggests.

2 Likes
3

The two bridges Lido would keep to BNB Chain run on the bridge’s own defaults. Each bridge admin can change what verifies a Lido message with no Lido vote, and with no delay on LayerZero and Hyperlane (CCIP: 3h, or none through its bypasser).

Thanks @arwer13 for the clear write-up, and @Foreshock, here is the answer to your question, read on BNB Chain at blocks 127,197,040 to 127,197,305, each change then simulated from its owner and from a random address (and, for the adapter config, from Lido’s executor).

Bridge What verifies a message today Who can change it Delay
LayerZero the default library: 15 confirmations, 4 of 4 DVNs (LayerZero Labs, Nethermind, Horizen, Canary) LayerZero’s OneSig, 5 of 7 none found
Hyperlane the default ISM: 6 of 9 validators, plus a pause switch Mailbox owner Safe, 6 of 10 none
CCIP Router 1.2.0, three Ethereum offRamps a 3h timelock, or its bypasser multisig 3h or none

• The LayerZero adapter has no owner, no delegate and no setConfig; the Hyperlane adapter has no ISM of its own. Lido cannot pin its own DVN set or validator set with the current contracts.
• Under 2 of 3, a forged message needs two bridges’ verifiers, or two of the three admins above. The BNB executor then runs it with no delay or guardian, and it owns wstETH and the NTT Manager.
• I did not compare the four DVNs with CCIP node operators, and signers are just addresses.

The same test on 14 other contracts, with the calls you can rerun, is on my site (RealSpap on GitHub, page oracle/roles); this account is too new to post a link.

Honest question, not a verdict: is relying on the bridge defaults the intended design, or would adapters that pin their own verifier set be worth the follow-up proposal?

1 Like
4

@Spap that settles the part I could not read for myself, and the shape of it matters more than the numbers: on all three legs the verifier set is the bridge’s own default, and the party who can change it sits outside Lido governance.

One line in your table decides whether 2 of 3 is really 2. You name the four DVNs as entities. CCIP is secured by a Chainlink oracle network that agrees off-chain on which messages were sent and posts that summary on-chain, so that leg rests on a signer set as well, and you say those signers are only addresses to you. If one operator sits in both sets, a forged message carries two of the three adapters on its own, and the threshold is counting one party as two.

So the thing I would want on the record before the vote: which entities operate the signer set on the three Ethereum offRamps the a.DI BNB adapter uses, and does any of them also run one of the four DVNs you listed? Both sets of addresses are on chain; the entity behind each is the half only the two networks can state.

1 Like
5

Thanks a lot for taking the time to review the proposal and for the thoughtful questions!

A single shared operator does not by itself compromise two bridges: controlling one DVN would not satisfy LayerZero’s 4-of-4 requirement, and one validator would not satisfy Hyperlane’s 6-of-9 quorum. Partial overlap can still reduce the number of independent operators needed for collusion. We consider the proposed trade-off acceptable given the amount currently bridged through this route.

Yes, this is how the current a.DI setup works: Lido relies on each bridge’s default verification and admin controls. The proposal keeps that trust model and changes the required confirmations from 3 to 2. Pinning verifier sets would give Lido control over their composition, but would also make Lido responsible for maintaining them as operators change or retire.

We propose keeping this motion focused on restoring tolerance to one bridge outage. Further hardening could include a delay and guardian, pinned verifier sets, and a fourth adapter to restore 3 of 4, if the rote usage justifies the work.

1 Like
6

@Foreshock @Spap thank you for raising these questions! I agree these concerns must be addressed when selecting the set of cross-chain messaging protocols (CCMPs).

I now prefer a variant: keep all four adapters and require 2 of 4 and support @tamtamchik suggestion to keep this proposal focused on restoring availability.

Nevertheless, here are more analysis of the the security setup.

What forging each leg takes

Names are what each bridge’s own registry attributes; key custody behind them is not verified anywhere, and for LayerZero I could not enumerate the signer keys inside the DVN contracts.

Leg Required for a confirmation Names
LayerZero All four required DVNs, each a contract with its own signer quorum (2, 1, 1 and 2): at least six signatures. Horizen, Nethermind, Canary, LayerZero Labs
Hyperlane 6 of 9 validator keys. Abacus Works, Mitosis, Zee Prime, Luganodes (AVS), Substance Labs, Enigma, Citrea, DSRV, Staked
CCIP 6 of 16 commit keys on either legacy offRamp, or 9 of 16 committee keys on the 2.0.0 offRamp. The Router accepts all three, so six is the figure that matters. Sixteen operators in Chainlink’s on-chain registry: DexTrac, Fiews, Galaxy, Kytzu, LinkForest, LinkPool, LinkRiver, NewRoad, NorthWestNodes, Omniscience, P2P, Piertwo, Prophet, Syncnode, ValidationCloud, Wetez. Chainlink’s operator page lists ChainLayer and Deepbase in place of Piertwo and Prophet. No source maps the live keys to these names.
Wormhole 13 of 19 Guardian keys, plus a delivery transaction that anyone can send. Nineteen Guardians, self-named in their signed heartbeats.

No name appears in two of the LayerZero, Hyperlane and CCIP sets. Wormhole shares DSRV and Staked with Hyperlane, and P2P, Syncnode and (on the operator page only) ChainLayer with CCIP. Each is attributed one member per set, so none reaches a threshold anywhere.

A forged message needs two legs under either 2-of-N setting. Summing two thresholds gives a lower bound on names, not on organizations:

Pair of legs Distinct names needed
LayerZero + Hyperlane 10
LayerZero + CCIP 10 or 13
Hyperlane + CCIP 12 or 15
LayerZero + Wormhole 17
Hyperlane + Wormhole 17
CCIP + Wormhole 17 or 19

The smallest pair is LayerZero plus Hyperlane under 2-of-3 and 2-of-4 alike. The Wormhole pairs are the ones 2-of-4 adds, and they are the hardest by names. Whether ten names are ten organizations, and whether one organization holds several keys in a set, is open.

Administrative paths

@Spap’s point stands: each bridge’s administrator can change what verifies a Lido message without a Lido vote. I read the administrative contracts on 16 October 2026.

Leg Who can change the verifiers Delay Effect
LayerZero OneSig, LayerZero’s own multisig: 5 of 7 signers, with one designated submitter. The same seven signers own the Ethereum endpoint. none; a signed batch carries only an expiry Replace the default DVN set the adapter uses, on every chain from one signing session.
Hyperlane Abacus Works’ governance Safe, 6 of 10, no modules or guard; the same ten owners own the Ethereum Mailbox, and one is their published deployer key. A separate service-held pauser key can pause verification alone; unpausing needs their root approval. none Replace the default ISM. The pauser can stall, not forge.
CCIP RBACTimelock: a proposer (two multisigs of 42 signers needing four, or a Safe 6 of 12), then three hours; or the bypasser, 69 signers needing at least eight correctly grouped signatures, the same 69 as on Ethereum. 3 h, or none Register another offRamp on the Router; its messages reach Lido’s adapter as if the Ethereum controller had sent them.
Wormhole 13 of 19 Guardians, through a governance message anyone can submit. none; the replaced Guardian set stays valid for 24 h Replace the Guardian set or upgrade the Standard Relayer contract the adapter trusts.

Availability and the options

Wormhole’s shutdown announcement says Standard Relayer automatic delivery stopped on 1 April 2026 while Guardians keep signing. A signed message still has to be delivered by someone. Today every message needs CCIP, LayerZero and Hyperlane all to deliver, and each has a short stall path: any one of the four required DVNs, Hyperlane’s service-held pauser key, an RMN curse or an offRamp removal on CCIP.

Option Automatic stalls tolerated With one manual Wormhole delivery Legs to forge; smallest coalition by names What it takes
Keep 3-of-4, as is or with an arranged manual fallback 0 1 3; 16 A manual delivery whenever any leg stalls. The arranged version adds tested tooling, a funded operator and an agreed response time.
Executor-compatible Wormhole adapter, keep 3-of-4 1 automatic 3 New code, review, deployment, support. Cost and lead time not estimated.
Remove Wormhole, require 2-of-3 (as posted) 1 none 2; 10; three sufficient pairs Three configuration calls across two chains.
Keep all four, require 2-of-4 (preferred) 1 2 2; 10; six sufficient pairs One call on BNB Chain, updateConfirmations([(1, 2)]).

Under 2-of-4 the Ethereum controller keeps forwarding through Wormhole at the current zero quote, so every message has a Guardian-signed copy that anyone can deliver; a double stall costs one manual delivery instead of blocking governance. If Wormhole retires the Standard Relayer contracts, the setting degrades to the posted 2-of-3 by itself.

1 Like
7

Thanks @arwer13, that answers it. 2 of 4 with Wormhole kept as a manually deliverable leg looks like the better trade for availability. Worth writing into the proposal who does the manual Wormhole delivery and within what time, so a double stall has a named owner.

1 Like
8

@Foreshock, that is the right question, and it decides whether “2 of 3” counts two parties or one. Two limits up front.

  1. An address is not an entity: the chain gives me addresses, and the networks alone can say who stands behind each.
  2. I cannot list the signers of three of the four LayerZero DVNs (Horizen, Nethermind, LayerZero Labs): the public RPC nodes I tried refuse the event logs that would show them. So for those three, “none” below means none among the 74 addresses I tested, not none in general.

Measured on BNB Chain on 15 October (blocks 127,797,956 to 127,798,134, two providers agreeing):
• CCIP: the older Ethereum offRamps (1.2.0, 1.5.0) and their two commit stores share one group of 16 signers and 16 transmitters. The 2.0.0 offRamp uses a separate committee of 16 signers (9 needed).
• LayerZero: Lido’s receive config for Ethereum messages is 15 confirmations and 4 of 4 DVNs, the same four addresses as on 12 October.
• Across the three bridges: seven distinct sets, 75 distinct addresses, none in two sets. Of the 74 I tested, none is a member of the Horizen, Nethermind or LayerZero Labs DVNs; Canary’s single signer is in none of the other sets.

A shared address would have been a signal; its absence does not show distinct operators, since one operator can use separate keys on separate networks.

Chainlink’s CCIP Node Operators page (read 15 October) lists 20 operators and says each lane uses 16, without saying which serve these offRamps or who holds which key. None of LayerZero Labs, Nethermind, Horizen or Canary is on it. Nethermind’s blog post of 19 August says it joined Chainlink as a CCIP node operator; its title mentions migrating its DVN operations, and its DVN is still required here.

So I draw no conclusion on whether 2 of 3 is really 2. Chainlink and LayerZero are the ones who can name the entities behind each set. I can send the address lists from my read-only script on request.

My earlier line that signers are just addresses was too quick: for this threshold the entity is what counts.

RealSpap

1 Like
11

Thanks @Spap, that answers it as far as the chain can. Since the open point is who stands behind each set, a direct question to Chainlink and LayerZero in this thread would settle whether 2 of 3 means two independent parties.

1 Like