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

Proposals
31

Update and Mainnet Configuration

Wormhole and Axelar Contributors have added Axelar verification to the mainnet deployment. The mainnet deployment configuration is now set for the DAO to vote on and adopt.

To provide complete transparency into the mainnet deployment, we are sharing information below on the mainnet contract addresses, parameters, and a breakdown and explanation of all administrative configuration transactions that were performed during the deployment. We will describe the testnet deployment in similar detail in a follow-up post.

Mainnet

Contracts

Description of contracts:

  • WstEthL2Token: This is the wstEth token contract deployed on BNB.
  • NTT Manager: The manager contract contains the core logic for the NTT framework. To perform transfers, users call into the transfer entry point, which then sends the cross-chain token transfer instruction through all of the registered transceivers. On the destination chain, the transceivers deliver the verified messages to the NTT Manager. The Manager then handles replay protection, enforcing the threshold attestation, and finally transferring tokens to the user to complete the cross-chain transfer. Read more about the NTT design, including the roles of the Manager and Transceivers here: GitHub - wormhole-foundation/example-native-token-transfers: Open, flexible, and composable framework for transferring tokens across blockchains without liquidity pools
  • Wormhole Transceiver: This is the transceiver implementation for Wormhole. It handles sending and receiving messages via Wormhole.
  • Axelar Transceiver: This is the transceiver implementation for Axelar. It handles sending and receiving messages via Axelar.
  • Transceiver Structs: This is a general library that is used to properly encode and decode NTT messages. It’s used by the NTT Manager and both Transceivers.

Parameters

Description of parameters:

  • WstEthL2Token
    • Owner: This address has the ability to upgrade the contract and set the minter address.
    • Minter: This address has the ability to mint new tokens. It is set to the NTT Manager contract, since that is the only contract that should be capable of minting new tokens when cross-chain transfers are performed from Ethereum.
  • NTT Manager
    • Outbound Rate Limit: This defines the total number of tokens that can leave a source chain during a 24 hour period. Rate limits are refreshed linearly. If a transfer violates the rate limit, users can choose to either revert the transaction to try again later, or queue the transaction for 24 hours and come back later to “complete” the transaction by taking it out of the queue and processing it on the source chain.
    • Inbound Rate Limit: This is a per-chain limit that defines the total number of tokens that can enter a given chain from another specified chain. The only other chain in this deployment is BNB, so we have set the same value as the outbound limit of 30,000 tokens. If a transfer violates the rate limit, it’ll get queued for 24 hours. Users can return after 24 hours to “complete” the transaction by taking it out of the queue and processing it.
    • Owner: This address has the ability to upgrade, set rate limits, add/configure Transceivers, set the threshold attestation requirement, and transfer ownership/pauser capability. The owner is also the only address allowed to unpause the contract.
    • Pauser: This address has the ability to call the pause function, which prevents anyone from initiating new outbound transfers or redeeming inbound transfers. The pauser is only allowed to pause the contract; they are not allowed to unpause the contract. The pauser can also transfer the pauser role to another address.
    • _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
    • Core Contract: The Wormhole core bridge contract is responsible for emitting messages (when sending) and verifying messages (when receiving). The Wormhole Transceiver calls into the Wormhole core contract to send and verify messages properly.
    • Standard Relaying Contract: This is the contract that is used for Wormhole Standard Relaying. Wormhole Standard Relaying improves the user experience for bridging by allowing users to pay up front to automatic message delivery to the destination chain. The Wormhole Transceiver is integrated with Wormhole Standard Relaying so that the user experience of performing cross-chain wstEth transfers is as smooth as possible.
    • Special Relaying Contract: This is the contract that is used for automatically relaying Wormhole messages to/from Solana. While properly set to the correct address, it is currently unused since the Lido deployment only concerns Ethereum and BNB mainnets.
    • _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.
    • Contract addresses and Wormhole registered chain IDs can be verified against the docs:
  • Axelar
    • Axelar Gateway: This is the contract that apps initiate or receive Axelar-powered cross-chain messages
    • Axelar Gas Service: This is an optional contract that apps can use to pay a relayer to execute their cross-chain message end-to-end
    • Axelar Transceiver Storage: The Axelar transceiver stores the bidirectional mapping between Axelar and Wormhole chain identifiers. Axelar uses string chain names as chain identifiers. The storage also contains a mapping from Wormhole chain identifier to the Axelar transceiver address and it’s hash, to know the trusted Transceiver address on remote chains for sending/receiving cross-chain messages.
    • Contract addresses and Axelar registered chain names/identifiers can be verified against Axelar docs or configs

Configuration Transactions

Note that the NTT Manager transfer ownership operation was executed twice to test that contributors could pass ownership back and forth between the multisig. Contributors ran this test because we did not want to raise a governance proposal for an accidentally bricked deployment.

The only transactions executed between transferring ownership back and forth on Ethereum and BNB were:

  1. Setting the NTT Manager outbound rate limit to 30,001
    1. Ethereum: Ethereum Transaction Hash (Txhash) Details | Etherscan
    2. BNB: BNB Smart Chain Transaction Hash (Txhash) Details | BscScan
  2. Setting the NTT Manager outbound rate limit back to the correct value of 30,000
    1. Ethereum: Ethereum Transaction Hash (Txhash) Details | Etherscan
    2. BNB: https://bscscan.com/tx/0xe5810f53c16136a9a042897c03b49e6ff07e286bad784810017ced83c0f6d42e

Contributors made these two “dummy” transactions in between transferring ownership to sanity check that the new owner was still able to execute admin commands.

5 Likes