Summary
Stargate is a fully composable cross-chain bridge protocol built on LayerZero that enables native asset transfers between different blockchain networks. A major shortcoming of most current bridges is that they are unable to send native assets from one chain to another. Instead, they rely on the use of a wrapped or "intermediate" token to complete the bridging process. The problem with this approach is that it is extremely inefficient and makes the user experience onerous. Stargate is designed specifically to remove the need for wrapped tokens and lets users send native tokens directly to non-native chains. The protocol is built around unified liquidity pools shared between chains that ensure instant guaranteed finality. Stargate's goal is to make cross-chain bridging a seamless and single transaction process.
Overview
Transferring liquidity between different blockchain networks is an integral part of Web3 interoperability. It lets users interface with a variety of dApps, creates greater interoperability between otherwise incompatible networks, and gives diverse ecosystems the means to interact with each other. The problem is that the native assets of one blockchain cannot be easily transferred and used on another. An intermediate step is required: bridging. Bridging lets users transfer liquidity across chains in many different ways. Currently, however, there is no way to efficiently complete a bridge transaction. The process involves many different steps, requires a non-trivial understanding of how a given bridge protocol works, and can be expensive.
The difficulty stems in part from the Bridging Trilemma that developers face when designing a bridge. They must make a compromise between native asset transaction requirements, instant guaranteed finality, and unified liquidity. Most bridge designs favor sacrificing the use of native assets and instead utilize a wrapped token to replace the native token. The end result is typically a Lock-and-Mint or Burn-and-Redeem mechanism. In general, the way these approaches work is by requiring the user to deposit the native asset of their source chain into the bridge’s smart contract, at which time the bridge then mints a wrapped version of the asset (e.g. $ETH → $WETH) on the destination chain. This achieves instant guaranteed finality since assets are minted 1:1 on the destination chain. It also removes the risk of reversion due to lack of liquidity. Yet a critical issue with this method is that once a wrapped token is minted on the destination chain, the user must then manually convert it into a native asset on the destination chain. Otherwise, they cannot use it; it merely serves as a vessel to complete the bridge.
Another issue is around liquidity and scaling. Bridges can only function properly if both the source chain and the destination chain have sufficient liquidity. So each time a new blockchain is integrated into a bridge protocol, the bridge must also bootstrap liquidity between each existing blockchain currently integrated. This places significant limitations on a bridge infrastructure's ability to quickly scale and adopt new networks.
To solve the Bridging Trilemma, Stargate has developed a novel cross-chain bridge mechanism, ∆Bridge, and balancing algorithm, the Delta (∆) algorithm. Paired together, they enable cross-chain liquidity and purely native token transfers. ∆Bridges let users send native assets directly and seamlessly between different blockchains, without the need for an intermediate token and without any deprecation of interoperability or composability. ∆Bridges are powered by a unified liquidity pool shared amongst chains to ensure that each side of the bridge has sufficient liquidity, prevent transaction reversion, and achieve instantly guaranteed finality. Stargate’s ∆algorithm can be thought of as the backbone here as it supports ∆Bridges by automatically rebalancing liquidity pools. This design lets the ∆Bridge framework integrate numerous blockchain networks and scale more quickly and efficiently than most alternative.
All of this is in part achievable because of LayerZero's infrastructure, which is an omnichain communication protocol that provides robust inter-chain communication between large blockchain networks. This foundation enables Stargate to effectively communicate bidirectionally between source and destination chains, and ultimately makes it possible to bridge native assets while preserving instant guaranteed finality and unified liquidity.
A Deeper Dive into the Bridging Trilemma and Stargate's Solution
(1) Instant Guaranteed Finality
This entails that any transfer request from the source chain will also be committed on the destination chain. In order for this to function properly, there must be enough liquidity available on the destination chain to facilitate the transfer. In practice, however, this is often not the case. Without instant guaranteed finality, transactions could be reverted. When a reversion occurs, the bridge must either allow the user manually revert, collect sufficient gas for reversion from the user upfront, or pay the reversion costs itself. All of these options are sub-optimal and create a poor user experience. So preserving instant guaranteed finality is critical for the success of any bridge protocol.
One workaround is the Lock-and-Mint or Burn-and-Redeem mechanisms. Instead of assuming that the destination chain does indeed have sufficient liquidity, a bridge will often lock the native asset and mint a wrapped asset, thereby guaranteeing sufficient liquidity insofar as the 1:1 ratio is preserved between the respective assets. While this approach can achieve instant guaranteed finality, it requires the user to manually swap the wrapped token on the destination chain to complete the bridge transaction.
Stargate's ∆Bridges eliminate the use of a wrapped token altogether and provide instant guaranteed finality of transfer using only the native asset from the source chain to the destination chain. Thus, there is no extra requirement for the user to manually perform swaps on the destination chain. This direct use of native assets is what enables ∆Bridges to scale better than other cross-chain bridges.
(2) Cross-Chain Composability
A core design feature of ∆Bridges is cross-chain composability. This means that the bridge can be composed with smart contracts on both the origin chain and destination chain. This is entirely novel from other bridge protocols and is quite powerful because it allows the bridge to communicate bidirectionally. Current bridges only have traditional composability which means that they only can be composed of smart contracts from the origin chain and cannot be composed of smart contracts from the destination chain. The option to be composed with other smart contracts on both the origin and destination chain gives ∆Bridges an extra layer of flexibility. The power here can be demonstrated in a user’s ability to complete many different swaps in a single cross-chain transaction. For instance, a Uniswap user on Ethereum could swap $wBTC for $JOE on Avalanche, all within a single transaction on the source chain (i.e. Ethereum) and without leaving the Uniswap interface. This enables a completely unified experience for multi-chain applications like Uniswap and would not be possible using existing bridge protocols.
(3) Unified Liquidity
Most existing bridges operate under conditions of fractured liquidity. In essence, this means that each chain integrated into the bridge’s network is assigned exclusive access to a designated liquidity pool for their users to deposit and withdraw from in order to bridge assets. So each chain maintains a separate liquidity pool per connection. As a result, different blockchain networks will have disparate levels of liquidity which lends itself to transaction reversion since there may not be sufficient liquidity on one connection. Another limitation is that whenever a bridge wants to add a new blockchain to their network, they must bootstrap a new pool to accommodate the new chain with sufficient liquidity on each existing chain. This presents significant limitations to scaling and also puts a heavy burden on LPs, requiring them to stake into each liquidity pool separately and separately fund multiple liquidity pools to collect fees from.
Stargate resolves this by way of unified liquidity. Under this approach, all connections deposit and withdraw from a single pool of liquidity. Again, this is all done through the use of native assets. As a result, ∆Bridges are able to achieve scaling that is otherwise not possible under Lock-and-Mint or Burn-and-Redeem.
However, a major potential risk of the unified liquidity approach is that if too many concurrent transactions occur to withdraw from the same liquidity pool it could potentially exhaust the pool before all of the transactions are completed, causing widespread reversion. To mitigate this risk, Stargate developed a balancing algorithm, the ∆ algorithm, to programmatically manage the shared liquidity pool in a way that prevents it from being exhausted before all competing transactions finish.
In short, the way this works is by enabling each chain in the network to maintain a single pool of liquidity that is “soft-partitioned” into different slices, with each slice corresponding to a specific chain in the network. For instance, Ethereum could have a single pool of liquidity (e.g. $1000), and within that pool, a designated slice is allotted to Avalanche (e.g. $500), a designated slice is allotted to Solana (e.g. $500), and so forth. The reason this is important is because in the event of a possible shortage in liquidity, pools can freely borrow from these allotted slices and then return the borrowed liquidity at a later time, after the transactions are completed. This gives the ∆ algorithm flexibility to handle large concurrent transactions and prevent gaps in liquidity.
One key limitation of the ∆ algorithm is that it is indeed possible for transactions to exhaust the available balance for a particular source-destination chain pair. Stargate uses equilibrium fees as a mechanism to proactively prevent this. These are essentially transaction fees that incentivize users to transfer liquidity in a way that keep all balances above their initial value. The key idea is to charge an extra fee for users transferring assets from a source chain to a destination chain when the last known balance on the source chain is high, and pay those fees back to users for conducting transfers when the last known balance on the source chain is low. The ideal outcome is that users are incentivized to deposit assets when the available liquidity is low and thereby to replenish the liquidity pool. The mechanism design is that equilibrium fees will result in the natural coordination of users balancing each connection in the network, ensuring ∆Bridges are able to continually service transfers without requiring the addition of morebase liquidity.
Mechanism Design and Tokenomics
$STG is the native utility and governance token of Stargate and can be used for staking, liquidity provision, and participating in protocol governance. Token holders can stake their $STG to receive Stargate's voting escrow token, $veSTG. The protocol uses a time-weighted reward system that boosts the amount of $veSTG that stakers receive the longer they keep it locked. This design keeps circulating supply pressure down and also helps align users that are interested in the long-term success of the protocol.
In terms of liquidity provision, users can add liquidity to the protocol and in return, earn stablecoin rewards on every Stargate transfer. Stargate charges a fee of 0.06% for each non-$STG transfer, with 0.045% going to the LPs of the destination pool and the remaining 0.015% being sent to the treasury. So if a user sends $USDC-Ethereum to $USDC-Avalanche, then the LPs for $USDC-Avalanche receive the fees.
LPs can also farm their LP tokens to receive $STG token rewards. Together, these fee and farming rewards act to incentivize sufficient liquidity to the shared liquidity pool to help service high volumes of bridge requests without transfer reversion.
The current rewards for staking and farming are quite high, with some LP token farming opportunities approaching 30% APY. Attractive yields will allow Stargate to continue to accumulate TVL.
In terms of token allocation and distribution, there is a max supply of 1,000,000,000 $STG. Leading up to launch, 10% (i.e. 100,000,000) of the tokens were auctioned off to generate liquidity across the seven blockchains that Stargate is currently integrating.
Of the remaining token supply, 35% is allocated to the Stargate team and to investors, about 30% is allocated to community initiatives, and the rest is split between bonding curves and emissions.
In terms of the unlock schedule, allocations for the team, investors, and the initial launch auction are locked for 12-24 months, which keeps circulating supply low during the protocol's earlier stages of development. Community reserves are unlocked immediately and enable the team and community to allocate resources effectively to grow the network.
Macroview
Stargate was launched roughly one week prior to the time of writing and has already amassed over $2.5B in TVL, putting it within the top 15 highest TVLs in the space. This TVL is composed of many major blockchain networks, including Ethereum, Avalanche, Polygon, and Arbitrum. Overall, there are seven networks that have been integrated into Stargate, with many others soon to follow, such as Solana, Terra, and Cosmos.
Meanwhile, $STG daily volume is over $71M and has gained considerable traction against $USD, $ETH, and $BTC. Part of this could be attributed to the high yields currently offered on Stargate farming and staking, which can be up to 30%.
Another useful metric to look at here is wallet distribution. Roughly 6,000 wallets have held $STG at some point since launch, and this number is quickly growing.
One concern, however, is around centralization risk. Alameda Research purchased 100% of the $STG tokens that were meant to be sold to the public to generate liquidity for the different blockchain networks being integrated into Stargate. While these tokens are scheduled to be locked for 12 months followed by a 6 month linear unlocking schedule, all 100,000,000 of this particular token allocation are now controlled by one central entity. This could have significant implications on price as the tokens are unlocked. It also allows one entity to control 10% of the max supply at a steep discount: each $STG was sold at $0.25 and is now trading for over $3.
Another concern is related to delta bridge’s ability to operate properly relies on the fee optimizing algorithm. If this breaks, then pools become insufficiently funded, and transactions get reverted. This mechanism should be proactively monitored and adjusted, particularly around times of high volatility and black swan events.
Sources and Further Reading
https://www.dropbox.com/s/gf3606jedromp61/Delta-Solving.The.Bridging-Trilemma.pdf?dl=0
https://stargateprotocol.gitbook.io/stargate/v/user-docs/tokenomics/allocations-and-lockups
https://medium.com/stargate-official/the-bridging-trilemma-d80788cce4ef
https://medium.com/stargate-official/stargate-a-farewell-to-bridges-28831d0f9439
Cryptofunds, market makers, and trading desks can engage in DeFi and Web3 with MetaMask Institutional
MetaMask Institutional offers unrivaled access to the DeFi ecosystem without compromising on institution-required security, operational efficiency, or compliance requirements. We enable funds to trade, stake, borrow, lend, invest, and interact with over 17,000 DeFi protocols and applications.
Learn more about MetaMask Institutional
Found this research useful? Connect with the Consensys Cryptoeconomic Research team at [email protected]
Return to the Cryptoeconomic Research Library
Disclaimer: Consensys Software Inc. is not a registered or licensed advisor or broker. This report is for general informational purposes only. It does not constitute or contain any individual investment advice and is made without any regard to the recipient’s objectives, financial situation, or means. It is not an offer to buy or sell, or a solicitation of any offer to buy, any token or other investment, nor is it intended to be used for marketing purposes to anyone in any jurisdiction. Consensys does not intend for any person or entity to rely on any facts, opinions, or ideas, and any financial or economic commentary expressed in this report may not be relied upon. Consensys makes no representations as to the accuracy, completeness, or timeliness of the information or opinions in this report and, along with its employees, does not assume any responsibility for any loss to any person or entity that may result from any act or omission based upon this report. This report is subject to correction, completion, and amendment without notice; however, Consensys has no obligation to do so.