Wormhole x Axelar | Lido Bridge: Implementation for wstETH on BNB Chain

Proposals
42

Thank you to the Lido contributors and Oxorio for compiling the verification report on the wstEth BNB deployment. We appreciate the thorough reviews throughout this process.

Addressing each finding from the above report individually, we’ve completed the following:

“2.4 Deploy script check [FAIL]”

The configuration transactions detailed in Wormhole x Axelar | Lido Bridge: Implementation for wstETH on BNB Chain - #31 by Wormhole-Axelar are ordered top to bottom and divided into semantic sections (NTT manager, Wormhole Transceiver, Axelar Transceiver, WstEthL2Token).

The forum post immediately preceding this one details the ownership/pauser transfer transactions to the publicly verified multisig and the WstEthL2Token configuration transactions: Wormhole x Axelar | Lido Bridge: Implementation for wstETH on BNB Chain - #41 by Wormhole-Axelar

“2.6 Initialization params check [FAIL]”

We have updated the forum post which details mainnet deployment with the additional parameters specified in the report as well as more links to documentation: Wormhole x Axelar | Lido Bridge: Implementation for wstETH on BNB Chain - #31 by Wormhole-Axelar. We are restating the parameters here as well:

  • Ethereum:
    • NTT Manager:
      • _mode: 0 (LOCKING)
      • _chainId: 2
      • _rateLimitDuration: 86400
      • _skipRateLimiting: False
    • Wormhole Transceiver:
      • _consistencyLevel: 1
  • BNB:
    • NTT Manager:
      • _mode: 1 (BURNING)
      • _chainId: 4
      • _rateLimitDuration: 86400
      • _skipRateLimiting: False
    • Wormhole Transceiver:
      • _consistencyLevel: 15

Description of parameters:

  • NTT Manager:
    • _mode: This enum value specifies whether the deployment is in LOCKING or BURNING mode. In LOCKING mode, tokens are locked/unlocked by the NTT Manager contract when sending/redeeming cross-chain transfers. In BURNING mode, tokens are burned/minted by the NTT Manager contract when sending/redeeming cross-chain transfers. The NTT Manager on Ethereum is set in LOCKING mode since wstEth on Ethereum mainnet cannot be burned/minted. The NTT Manager on BNB is set in BURNING mode since the WstEthL2Token can be burned/minted and allows setting a minter address (which is the NTT Manager).
    • _chainId: This value specifies the chain ID that the NTT Manager is deployed on. The chain IDs are formatted based on Wormhole Chain IDs.
    • _rateLimitDuration: This value sets the refresh basis for rate limiting and the duration for which queued transfers are held (in seconds). NTT rate limiting is based on a linear refresh. The value of 86400 sets the refresh basis to 24-hours. Read more about NTT rate limiting here.
    • _skipRateLimiting: This value specifies whether to skip the rate limiting feature entirely. It is set to False on both Ethereum and BNB, since rate limiting is used.
  • Wormhole Transceiver:
    • _consistencyLevel: This value specifies the level of finality to reach before the Wormhole Guardians will observe and attest the emitted event. This is a defense against reorgs and rollbacks since a transaction, once considered final, is guaranteed not to have the state changes it caused be rolled back. Read more about the consistency level here. See the Ethereum consistency level values here, and the BNB consistency level values here. The values used on Ethereum (1) and BNB (15) both instruct the Wormhole Guardians to wait until blocks are finalized before attesting to transfers.

“2.8 Storage check [FAIL]”

These checks are addressed in the Initialization section (#2.6) above.

“2.9 Documentation verification checks [FAIL]”

The NTT framework is documented both on the official Wormhole docs website and in the Github README. The EVM cross-chain message lifecycle is documented here. E2E tests can be found here and here.

4 Likes