L2BEAT Bridges is a work in progress. You might find incomplete research or inconsistent naming. Join our Discord to suggest improvements!
Stargate v2 (LayerZero v2)
About
Stargate v2 is a Hybrid Bridge (mainly Liquidity Network) built on top of the LayerZero messaging protocol.
About
Stargate v2 is a Hybrid Bridge (mainly Liquidity Network) built on top of the LayerZero messaging protocol.
Stargate v2 is a Hybrid Bridge (mainly Liquidity Network) built on top of the LayerZero messaging protocol.
It uses liquidity pools on all supported chains, supports optional batching and a Token Bridge mode called Hydra that can mint tokens at the destination.
Funds can be stolen if
Funds can be frozen if
Users can be censored if
Principle of operation
On chains where assets are available through other bridges, Stargate acts as a Liquidity Bridge. This requires Stargate liquidity pools for assets at the sources and destinations.
While liquidity providers need to keep all pools buffered with assets, users can deposit into a pool on their chosen source chain and quickly receive the equivalent asset at the destination through an Executor. Users can choose between an economical batched bridge mode (‘bus’) or an individual fast ‘taxi’ mode that delivers the bridging message as soon as the user deposits.
The Executor is a permissioned actor that withdraws the asset from the liquidity pool at the destination directly to the user. They are only a relayer and depend on LayerZero DVNs (distributed validator networks) to verify the message coming from the source chain. These DVNs can be freely configured by the OApp owner (Stargate) for each pair of endpoints. Stargatev2 currently has two DVNs configured: Stargate and Nethermind. From the viewpoint of the LayerZero message protocol, each DVN is a single signer and the current threshold for verification is 2.
Just like the assets themselves, so-called credits are bridged among the supported pools in the Stargate v2 system. Credits can be seen as claims on assets, so a liquidity pool needs credits for a remote pool to be able to bridge there. These credits can be moved and rebalanced (but not minted) by a permissioned Planner.
LayerZero messaging
The LayerZero message protocol is used: For validation of messages from Stargate over LayerZero, two DVNs are currently configured: Nethermind and Stargate. If both DVNs agree on a message, it is verified and can be executed by a permissioned Executor at the destination. This configuration can be changed at any time by the StargateMultisig.
Users can be censored if both whitelisted DVNs or the LayerZero Executor fail to facilitate the transaction.
Funds can be stolen if both whitelisted DVNs collude to submit a fraudulent message.
Destination Tokens
Since Stargate is mainly a Liquidity Network, its liquidity pools at the destination are filled with tokens from canonical or other bridges than Stargate. As no new tokens are minted, the users do not inherit the risk of the Stargate bridge as soon as the bridging is complete. For chains where a destination asset is not available, Stargate v2 offers a Token Bridge mode called Hydra that locks the asset at the source and mints a Stargate OFT at the destination.
The system uses the following set of permissioned addresses:
This is a Gnosis Safe with 3 / 6 threshold. Owner of all pools and the associated OApps, can create new pools and endpoints, set fees and modify the OApp configuration to change DVNs and executors.
Used in:
Those are the participants of the Stargate Multisig.
This is a Gnosis Safe with 2 / 4 threshold. The owner of the LayerZero contracts EndpointV2, Uln302 and Treasury. Can register and set default MessageLibraries (used e.g. for verification of Stargate messages) and change the Treasury address (LayerZero fee collector).
Used in:
Those are the participants of the LayerZero Multisig.
Central actor who can move credits (see CreditMessaging contract) among chains and thus move liquidity claims of the Stargate pools. Abuse of this permission can impact liveness but not security.
The system consists of the following smart contracts on the host chain (Ethereum):
A LayerZero OApp owned by Stargate that manages bridging messages from all pools on Ethereum. It can batch messages with a ‘bus’ mode or dispatch them immediately for higher fees.
A LayerZero OApp owned by Stargate that is used for the virtual accounting of available tokens to the local pools. A local pool thus has a record of how many tokens are available when bridging to another remote pool. The permissioned Planner role can move these credits.
One of the registered DVNs for the OApp acts through this smart contract. They are allowed to verify LayerZero messages for the Stargate bridge and enable their execution at the destination.
One of the registered DVNs for the OApp acts through this smart contract. They are allowed to verify LayerZero messages for the Stargate bridge and enable their execution at the destination.
Value Locked is calculated based on these smart contracts and tokens:
Stargate liquidity pool for USDC on Ethereum.
Stargate liquidity pool for ETH on Ethereum.
Stargate liquidity pool for USDT on Ethereum.
Stargate liquidity pool for METIS on Ethereum.
Stargate liquidity pool for mETH on Ethereum.
Stargate liquidity pool for USDC on Arbitrum.
Stargate liquidity pool for USDT on Arbitrum.
Stargate liquidity pool for ETH on Arbitrum.
Stargate liquidity pool for USDC on Optimism.
Stargate liquidity pool for ETH on Optimism.
Stargate liquidity pool for USDT on Optimism.
Stargate liquidity pool for USDC on Base.
Stargate liquidity pool for USDC on Base.
Stargate liquidity pool for USDC on Scroll.
Stargate liquidity pool for ETH on Scroll.
Stargate liquidity pool for ETH on Metis.
Stargate liquidity pool for METIS on Metis.
Stargate liquidity pool for USDT on Metis.
Stargate liquidity pool for ETH on Linea.
Stargate liquidity pool for ETH on Mantle.
Stargate liquidity pool for USDT on Mantle.
Stargate liquidity pool for USDC on Mantle.
Stargate liquidity pool for mETH on Mantle.
The current deployment carries some associated risks:
Funds can be stolen if the OApp owner changes the configuration of the OApp to malicious DVNs and executors.
Funds can be frozen if the permissioned Planner moves all credits away from the users' chain, preventing them from bridging.
