Overview

Stargate is an omnichain protocol built on top of LayerZero V2 that allows users and dApps to transfer native assets cross-chain while accessing the protocol’s unified liquidity pools with instant guaranteed finality.

• Stargate V1 launched in March 2022, initially supporting 7 EVM-compatible chains. It introduced unified liquidity pools, allowing native asset swaps across chains with computations from the Delta Algorithm to solve the bridging trilemma, provide instant finality and shared liquidity.
• Stargate V2, launched in May 2024,  is the latest iteration of the protocol, expanding on the original protocol by introducing new features like transaction batching, dynamic credit allocation through the AI Planning Module (AIPM), and the Hydra for native swaps. These upgrades focused on reducing gas costs and improving capital efficiency. Stargate V2 presently supports bridging across over 10 EVM-compatible chains also supporting non-EVMs.

With Stargate, users can swap native assets cross-chain in a single transaction. For example, users can swap $USDC on Ethereum for $USDT on BNB.

Applications can also build on Stargate to enable cross-chain transactions at the application level. For example, a DEX can enable cross-chain swaps (i.e. swapping $OP with $ETH in a single transaction), yield aggregators can develop cross-chain strategies to capture new APY opportunities, lending protocols can allow users to deposit collateral on one chain and borrow debt on another, etc

Key features that separate Stargate from other bridges include:

• Instant Guaranteed Finality – any transaction committed on one chain will be successfully committed on the other chain.
• Low Bridge Costs: Stargate is the cheapest bridge in crypto, achieved by transaction batching and optimized contracts that are 90% more gas-efficient.
• Unified Liquidity – all transactions are deposited and withdrawn from a single liquidity source.
• Transactions on Native Assets – all transactions are done on native assets; no intermediary or wrapped tokens are needed.

Why the Project was Created

Stargate was developed as a community-driven organization with the vision to make cross-chain liquidity transfers a seamless and single-transaction process.

In the current multi-chain environment, bridges compete against each other to attract liquidity providers (LPs), leading to fragmented liquidity between bridges and their individual pairwise pools. LPs must choose a single pool that connects to one chain, rather than having one pool that provides liquidity for an asset to all connected chains.

Stargate came to the market to help solve the challenges that users face when it comes to performing cross-chain transactions. Through LayerZero, Stargate enables unified liquidity across all chains. This means that when a user transfers an asset from Chain A to Chain B, the user is guaranteed the asset on Chain B, and the LP providers receive fees from all incoming transactions to Chain B, regardless of the source chain.

This brings a series of benefits across multiple DeFi verticals:

• Lending and Borrowing: If a user wants to farm on Chain B but has assets on Chain A, they must go through a complex, multi-step process that involves collateralizing on Chain A, borrowing, bridging (incurring a fee), swapping (incurring another fee), farming on the destination chain, swapping back (another fee), bridging back (yet another fee), repaying the loan, and un-collateralizing. This process is not only cumbersome but also expensive due to the multiple fees involved.

• Swaps: While existing Automated Market Makers (AMMs) can perform swaps within a single chain, cross-chain swaps are more complex and often require additional steps and fees. For example, a user wanting to swap ETH on Ethereum to SOL on Solana would typically need to perform multiple transactions, each incurring a fee.

These inefficiencies and costs create barriers for users and limit the potential for cross-chain interactions, which are becoming increasingly important in the expanding blockchain ecosystem. Stargate was born as a solution that simplifies these processes and reduces the associated costs. This is the value proposition of Stargate: make cross-chain liquidity transfer a seamless, single transaction process.

As an omnichain asset bridge, Stargate can offer unified liquidity across 8 chains. This way, users and dApps can transfer native assets cross-chain with instant guaranteed liquidity.

• Users no longer have to bridge assets multiple times to acquire native assets on the destination chain, simplifying the asset transfer process and saving time.
• Liquidity Providers can achieve high capital efficiency by staking into a single-sided asset pool while collecting fees from all incoming transfers, regardless of the source chain. This increases the potential returns for LPs.

Sector Outlook

Despite growing demand to transfer native assets cross-chain, existing bridges are forced to make different trade-offs in an attempt to solve the bridging trilemma:

Currently, most asset bridges suffer from 3 major problems:

• They rely on intermediate or wrapped assets.
• They can only support a small number of chains.
• They don’t allow for composability with smart contracts on the destination chain.

The use of intermediate tokens enforces an additional swap on the destination chain to exchange those intermediate tokens for native tokens. This is a problem for scaling and causes inconveniences to users, who must often bridge assets multiple times across different

bridges to reach their final destination chain. What’s more, the additional swap on the destination chain cannot be composed with the original transfer. This creates unnecessary work for users, who must initiate the final swap manually.

As a result, the current blockchain ecosystem is fragmented, with many dApps like SushiSwap operating in siloed environments across multiple chains. For instance, SushiSwap runs on twelve different chains, each requiring unique code for syncing with the main Ethereum instance. This necessitates the use of multiple bridges like Wormhole, Rainbow Bridge, Polygon Network Bridge, Avalanche Bridge, etc., each with its own interface and security properties. As the ecosystem is constantly evolving, managing these multiple interfaces becomes a daunting task.

However, the advent of omnichain communication protocols like LayerZero offers a new alternative to approach the bridging trilemma. Omnichain communication enables reliable bidirectional inter-chain communication. Stargate’s rebalancing algorithm, known as the Delta algorithm, introduces a technique that works in conjunction with omnichain communication. This approach enables asset transfers through unified pools of liquidity while achieving instant. This eliminates the overhead associated with lock-and-mint mechanisms – users no longer have to bridge assets multiple times, and LPs can achieve high capital efficiency by staking into a single-sided asset pool that collects fees from all incoming transfers regardless of the source chain.

Stargate, through its LayerZero technology, simplifies this process by providing a single interface and codebase for all cross-chain pairs. This means that dApps like SushiSwap only need to implement send and receive functions, significantly reducing the complexity of managing multiple chains. The send function forms a message for the destination chain, while the receive function interprets that message.

In a fractured scheme, each chain maintains a separate liquidity pool per connection, whereas in a unified scheme, all connections share a single pool.

This offers a series of notable benefits:

• Unified Liquidity and scalability: Stargate provides a single pool that offers liquidity for an asset to all connected chains, eliminating the need for LPs to choose a single pool that connects to one chain.
• Instant guaranteed Finality: Stargate ensures that when a user transfers an asset from one chain to another, the user is guaranteed the asset on the destination chain.
• Fee Distribution: LP providers receive fees from all incoming transactions to a chain, regardless of the source chain, increasing the potential returns for LPs.
• Simplicity: Stargate simplifies the process of managing multiple chains by providing a single interface and code base for all cross-chain pairs.
• Security: Stargate offers a unified security property, reducing the risk associated with managing multiple bridging interfaces and codebases with unique security properties.
• Cross-chain composability: Composability in the context of blockchain refers to the ability to combine multiple smart contracts in a single transaction on a single chain. Existing bridges can only provide traditional composability, allowing composition with other smart contracts on the source chain but not the destination chain. In contrast, Stargate allows a cross-chain transfer to be composed of smart contracts on the destination chain.
• Compartmentalized risk:  The architecture of LayerZero limits exploit risk to the specific Oracle-Relayer pairing that was exploited. Middle-chain designs, however, expose the outcomes of an exploit to all of the liquidity on all paired networks.

Competitive Landscape

With an aim to facilitate seamless transactions across multiple blockchains, the cross-chain landscape has significantly evolved as various protocols implore new methods for fast, secure, and capital-efficient transfers across multiple blockchains. With its V2 update, Stargate focuses on capital efficiency, cost reduction, and ensuring that the exact value transferred is received on the destination chain without delays. However, with each new design to improve capital efficiency and scalability in an ever-evolving industry, the competition will always be steep.

Stargate, built on LayerZero, is a cross-chain bridge that focuses on capital efficiency, cost reduction, and ensuring that native assets are securely transferred between chains. Unlike wrapped or synthetic assets, Stargate V2 allows users to move native tokens with instant guaranteed finality, meaning users receive exactly the value they transfer without delays or risks of depegging.

Stargate operates using LayerZero’s cross-chain messaging and an OFT (Omnichain Fungible Token) Standard, enabling efficient transfers between chains via a burn-and-mint mechanism. Thus, Stargate leverages cross-chain messaging to execute transactions while inheriting security and decentralization from Layerzero.

Intent-Based Bridges

Intent-based bridges abstract away the complexities of cross-chain transfers by allowing users to specify the outcome they want, without needing to understand the details of the bridging process. In this model, solvers or relayers fulfill the user’s intent by supplying liquidity on the destination chain. The solver network competes to provide the most efficient execution, theoretically minimizing costs and gas consumption.

Across V2 and DeBridge exemplify this intent-based design. These protocols aim to lower costs and reduce gas consumption by relying on third-party agents to carry out transactions. Across, in particular, allows solvers to competitively bid via a Request for Quote mechanism to fulfill user intents, fronting liquidity on the destination chain.

Benefits of Intent-Based Bridges:

• Cost Efficiency: Intent-based bridges can offer lower fees for smaller transactions, especially in low-liquidity environments. Solvers bid to fulfill user intents, driving down costs through competition.
• User Experience: By abstracting the complexity of cross-chain transactions, intent-based bridges offer a streamlined experience for users. They only need to specify the desired transaction, and solvers handle the rest.

Solvers are the backbone of intent-based protocols. They are the entities that actually execute a user’s intent, such as delivering an asset to chain A from chain B. Solvers competitively bid to fulfill the user’s intent by supplying liquidity on chain B. Once a solver completes the transaction, the user’s funds on chain A are released to the solver.

As solvers participate in various types of auctions (such as batch or Dutch auctions) to determine who fulfills the intent, the efficiency of the system often depends on the number of competitive solvers and their ability to access liquidity at low costs. In cases where only a few solvers dominate the market, fees may not be as low as expected due to limited competition. There is also the centralized risk within solver networks particularly in systems like Across, where a small number of solvers dominate the majority of order flows, creating potential single points of failure along with a possibility of censorship and reliability.

While Intent-based bridges offer a cheaper and potentially faster solution in low-liquidity environments and specicif cases, Stargate’s approach serves a broader use case with instant finality and scalability more effecitvely without the need for solvers or AMMs. Users have to make a decision on a tradeoff between translation speed and transaction finality, amongst other considerations.

Key Trade-offs Between Stargate and Intent-Based Bridges

 

Cross-Chain Models

Wormhole

While Stargate relies on a burn-and-mint model through LayerZero, other cross-chain protocols like Portal Bridge leverages on the lock-and-mint mechanism by Wormhole. When a user transfers tokens, from Chain A to Chain B, the assets on Chain A are locked in a smart contract. A wrapped version of the token is minted on Chain B, representing the locked token.

Source: Wormhole Docs

The original token remains locked on the source chain until the user wants to return it. At that point, the wrapped token is unlocked or burned, and is released back to the user. Wormhole’s Guardian Network is an off-chain entity that observes and verifies a transaction, this verified transaction becomes a VAA (Verified Action Approval) message containing the signature and metadata, the VAA is then sent to the destination chain, where it is verified and executed by the Wormhole smart contracts.

Wormhole’s model is flexible for protocols that offer wrapped or intermediate assets or those who want the option to revert their transfer by unlocking the original asset. It supports more asset types and works well in environments where wrapping tokens is acceptable.

Axelar

Axelar is a Proof-of-Stake network that allows cross-chain transfers using a general messaging protocol (GMP). Satellite.money is built on Axelar and allows users to transfer assets across chains using smart contracts.

Core Mechanisms:

• Validators: Axelar uses a set of permissionless validators to verify and secure cross-chain messages.
• Gas and Executor Services: Simplifies cross-chain transactions by bundling all fees into a single payment.
• General Message Passing (GMP): Enables cross-chain data and token transfers, allowing for advanced interactions between decentralized applications.

Cross-Chain Tradeoff Between Layerzero, Wormhole and Axelar

Criteria	Layerzero	Wormhole	Axelar
Message Verification	Decentralized; customizable with DVNs	Guardian-based (13/19 signatures)	Validators with multi-party cryptography
Execution	Separated from verification; permissionless	Combined with verification by Guardians	Validators execute after authorization
Cross-Chain Support	EVM, Solana, MoveVM (flexible)	30+ chains (EVM, Solana, Cosmos, Aptos, etc.)	60+ chains (EVM, Cosmos, Solana, Stellar, etc.)
Security Model	Modular, “X of Y of N” multisig setup	Guardian multisig (2/3 majority needed)	Validators control keys via cryptographic shares
Decentralization	Customizable DVNs	Moderate centralized risk with the Guardian	Distributed Validators
Major Use Cases	Cross-chain apps, Omnichain liquidity	Token bridging, NFT migration	Cross-chain DeFi, token bridging, data transfer
Gas	User-specific; executed on the destination chain	Paid per chain; relayers handle gas abstraction	Single payment for all chains (source-chain token)

Stargate V1

This was the first version of the Stargate protocol launched in March 2022, pre-assigning credits to pools on different chains through the Delta Algorithm for native asset swaps and instant guaranteed finality.

Delta Algorithm

The Delta Algorithm enables native asset transfers across chains with unified liquidity and instant finality by rebalancing liquidity across connected chains without the use of intermediate tokens. It leverages native assets in liquidity pools on each chain, providing efficient and scalable cross-chain transfers. The algorithm maintains balanced liquidity across chains, allowing cross-chain composability with smart contracts on both the source and destination chains. This improves capital efficiency and reduces user friction in cross-chain transactions.

Properties of the Delta Algorithm

• Unified Liquidity:
  The Delta Algorithm uses shared liquidity pools across multiple chains, eliminating the need for separate pools or intermediate tokens.
• Instant Finality:
  It ensures that cross-chain transfers are completed instantly, without any delays, providing a seamless user experience.
• Cross-Chain Composability:
  The algorithm enables interaction with smart contracts on both the source and destination chains within the same transaction, maximizing flexibility for developers and users.

How the Delta Algorithm Works

The three properties outlined above are made possible by the algorithm working in conjunction with LayerZero’s cross-chain messaging. This setup enables a rebalancing algorithm capable of efficiently managing and distributing liquidity across multiple chains.

For example, in a network of chains X, Y, and Z with $100 of liquidity available on chain X, the Delta Algorithm would soft-partition this liquidity, assigning $50 to chain Y and $50 to chain Z. This dynamic rebalancing ensures that liquidity is efficiently allocated across the network, enabling smooth and scalable cross-chain transfers.

 

With cross-chain liquidity, each chain in the network maintains a single pool of liquidity that is soft-partitioned into slices that belong to each of the remote chains in the network.

The key insight is that this algorithm makes it possible to borrow and return liquidity between soft partitions. By taking into account the race conditions that might occur, the delta algorithm is able to keep these partitions balanced in the event of imbalanced transaction volume. This is because each of the partitions represents the bandwidth available on each unidirectional channel connecting chain Y or Z to chain X. This way if the bandwidth falls below its initial value, the chain is said to have a deficit. Similarly, if the bandwidth exceeds the initial value, the chain is said to have a surplus. 

In Stargate, transfers consist of a deposit on the source chain and a corresponding withdrawal on the destination chain. Upon receiving a transfer request from chan X to chain Y, the delta algorithm follows the following logic:

1. If any channel on chain X has a deficit, distribute all or part of the newly deposited funds to end the deficit.
2. Any remaining funds after covering the deficit are distributed across all channels based on the associated weight.

In addition to those rules, the algorithm is also responsible for managing its local state to enable cross-chain liquidity with as few cross-chain messages as possible. The ultimate goal behind this design is to minimize the number of cross-chain messages that are required to rebalance assets cross-chain. This in turn optimizes the overall network operations.

The delta algorithm achieves this by meticulously tracking all funds distribution in locally stored credits. These credits are then tactically appended onto user transactions to communicate with the corresponding remote chain, making the process more efficient by leveraging user transactions to relay information.

Moreover, the delta algorithm helps each source chain to passively monitor an estimate of the channel bandwidth with every other chain in the network, a measure referred to as the ‘balance’. The algorithm ensures that this balance never surpasses the actual channel bandwidth. By doing so, it guarantees adequate liquidity for every transfer.

Name	Notation	Function
Liquidity provided	lps	(Initial) assets deposited
Assets	as	Size of liquidity pool  (on the local chain S)
Balance	bs,d	Local allocation of funds
Last known balance	lkbd, s	The last known value of bd,s observed by chain S
Credits	cs, d	Funds to be sent in next transfer from S to D

The delta algorithm requires the state represented above to be stored on each chain, where s and d are the source and destination chains respectively.

• Liquidity Provided (LP) refers to the amount of liquidity deposited into the liquidity pool on each chain without a corresponding withdrawal on any destination chain.
  • For simplicity, LP can be thought of as the initial size of the liquidity pool on the local chain, which corresponds to the asset deposits by the service provider during the initialization of a delta bridge.
• Assets represent the size of the liquidity pool on a given chain.
  • This changes as users deposit and withdraw liquidity as part of transactions.
• Balance describes the portion of the assets on the destination chain that can be used to facilitate transfers from the source chain. This essentially represents the maximum bandwidth of the connection from S to D, i.e., the maximum amount of funds that can be transferred from chain S to chain D.
  • The balance decreases when funds are transferred from chain S to chain D and may or may not increase when funds are transferred from chain D to chain S.
• Last Known Balance (LKB) describes the last known value of the balance from the perspective of chain S. This offers a (possibly outdated) view of how its assets are partitioned between all of the other chains in the network.
  • Note that LKBs are always larger or equal to the corresponding balance, making them more conservative than the true global state.
• Credits represent the number of funds to be sent to a particular remote chain the next time communication occurs with that remote chain. The delta algorithm uses credits as a method of batching many of these smaller transfers to reduce the operational overheads of the system, accumulating credits over multiple transactions and opportunistically communicating the total accumulated credits to the destination chain whenever a user transfers assets to that destination chain.
• Weights are the only parameter that needs to be configured for the delta algorithm. For each pair of chains S and X in the network, there are two weight parameters that must be set. The weight describes the proportion of LP to be allocated for transfers from chain S to chain X, allowing the protocol to allocate a higher proportion of the liquidity pool to particular chain pairs. This can be done to provide a larger liquidity buffer, allowing delta bridges to deal with higher transaction volume for those connections.

The figure above illustrates how the state is stored on a given chain. For instance, given a network containing chains X, Y, and Z, the local chain X keeps track of a balance, last known balance, and credit for each remote chain (Y and Z). Weights are assigned during initial configuration and can be modified as the system operates (e.g. when a new chain is added to the network).

The consequence of this careful management is that it allows for instant guaranteed finality, which is a significant advantage in blockchain transactions. This design ensures each transaction is confirmed immediately and irrevocably, enhancing the system’s reliability and efficiency.

Delta Algorithm Logic and Implementation

The goal of the delta algorithm is to enable each blockchain in the network to maintain a single pool of liquidity that is “soft-partitioned” into different sections, each corresponding to a specific chain in the network. For example, Ethereum could have a single pool of liquidity (e.g. $1000), within which a designated slice is allotted to Avalanche (e.g. $500), another to Solana (e.g. $500), etc.

In the event of a possible liquidity shortage, pools can freely borrow from these allotted slices and return the borrowed liquidity later after the transactions are completed. This flexibility allows the algorithm to handle large concurrent transactions and prevent gaps in liquidity.

One potential limitation of the algorithm is that transactions could possibly exhaust the available balance for a particular source-destination chain pair. To proactively prevent this, Stargate uses what it calls equilibrium fees. These are transaction fees designed to incentivize users to transfer liquidity in a way that keeps all balances above their initial value.

The 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 then pay those fees back to users for conducting transfers when the last known balance on the source chain is low.

This way, users are incentivized to deposit assets when the available liquidity is low, thus replenishing the liquidity pool. The intended outcome is that equilibrium fees will lead to users naturally balancing each connection in the network, ensuring that delta bridges can continually service transfers without needing to add more base liquidity.

The end goal is to maintain the proportional relationship between each remote balance and its respective asset pool while also keeping each balance at or above its initial value. This is represented as:

At this point, the algorithm is calculating for every chain X that chain S is connected to, whether chain X has enough balance to continue facilitating transactions to chain S.

11. Finally, chain D is notified of the transfer amount and outstanding credits, and the transaction is committed on chain S.

This concludes the delta algorithm.

Delta Algorithm Example

The example below shows how the delta algorithm works without applying any equilibrium or rebalancing fees.

Each horizontal row represents a transaction and, for simplicity, its execution is split into two phases per transaction.

 

Stargate V2

Stargate V2, launched in May 2024, introduced several significant improvements and features over Stargate V1, focusing on reducing gas fees, optimizing credit allocation, and scaling liquidity to support the growing number of Layer 1s, Layer 2s, and emerging chains. Stargate V2 aims to be the cheapest and most interoperable bridge in DeFi, whilst maintaining secure cross-chain communication.

Stargate V2 is necessary to compete with the costs, inefficiencies in asset adoption, and the need for seamless interaction across an increasing number of blockchain networks.

Comparison between Stargate V1 and V2

Feature	V1	V2
Messaging Cost	High	Low
Emissions	High	Low
Transaction Batching	No	Yes
Protocol Fee	Fixed	Flexible
Liquidity Management	Delta Algorithm	AI Planning Module
Number of Supported Chains	12	13+ Hydra Chains

Transaction Batching

Stargate V2 introduces a transaction batching feature that allows multiple users to share the cost of cross-chain messages, reducing gas costs in the process.

Users can choose between two transfer types, Economy (Stargate Bus) and Fast (Stargate Taxi).

Stargate Bus (Economy)

This is a shared transaction system where users pool together to split gas fees across several participants. The Stargate Bus distributes messaging costs among users by aggregating multiple transactions, reducing per-transaction costs by over 90%. For example, If 6 seats are available for a Bus on a popular pathway like Optimism <> Ethereum, each user pays one-sixth of the total gas and messaging fees.

The Bus departs once all seats are filled and or after a waiting time or when someone pays for the remaining seats. A user seeking a faster transaction time may decide to pay for the remaining seats on the bus for a quicker departure time. A user paying for the entire Bus is still relatively cheaper than using a Taxi.

Stargate Taxi

A faster, more expensive option where users pay the full gas and LayerZero message fees for immediate execution.

For users seeking immediate transaction processing, Stargate Taxi offers a direct, one-to-one transfer option. While it incurs the full gas cost, it remains cheaper than V1 due to the optimized contract design.

Hydra

Hydra is the multi-chain solution used by Stargate for efficient cross-chain transfers and to solve the problem of liquidity fragmentation. Designed as a Bridging-as-a-Service (BaaS) solution that enables new chains to integrate with Stargate using Hydra-wrapped assets, and built on the Omnichain Fungible Token (OFT) Standard, Hydra enables seamless asset transfers across Hydra-wrapped versions of $USDC, $USDT, and $wETH to Hydra chains (and between Hydra chains) quickly.

Hydra works through a burn-and-mint model and allows Stargate to expand to chains without native assets and generates Protocol Locked Liquidity (PLL). For instance, $1 bridged via Hydra adds $1 to PLL, reducing the need for additional incentives.

The minting of Hydra assets on a new Hydra chain uses the Omnichain Fungible Token (OFT) Standard. This process is initiated when an asset, such as $USDC, is bridged from a core chain (e.g., Arbitrum) to a Hydra-enabled chain (referred to as Chain X in this context). The bridged assets are securely locked within Stargate’s pool contracts on the origin chain, while an equivalent asset is minted on Chain X. A basic outline of the Hydra process goes as follows:

• When a user bridges $USDC from Arbitrum to Chain X, their USDC assets get locked in the secure $USDC pool on Arbitrum, and an asset minted on Chain X.
• The user’s $USDC will always remain in the Pool contract until they decide to return to Arbitrum (or any other Stargate core chain).

Since the asset minted on Chain X is an OFT, it can be horizontally composed across all current and future Hydra chains. The user could bridge from Chain X to Chain Y, and always unlock their asset back through Stargate on Arbitrum (or again, any other core chain). In other words, underlying assets are always redeemable from any core Stargate chain. As Stargate expands Hydra to more chains, the network effects of Hydra grow exponentially, as more chains are connected and the protocol generates additional protocol-locked liquidity.

Bridging into Hydra chains is free, while bridging out incurs a low redemption fee. Assets transferred to Hydra networks are securely stored in Stargate’s core pools on the original chain, ensuring liquidity while reducing the need for emissions, hence improving the protocol’s economic sustainability. Users also gain flexibility by being able to bridge assets across many chains and redeem them through any primary Stargate chain, giving them more asset availability options. Hydra also lowers asset fragmentation because its OFT assets are horizontally composable across new ecosystems, acting as a unified wrapped asset rather than fragmenting liquidity. Hydra as essential for making Stargate a scalable, efficient, and reliable infrastructure for a multi-chain DeFi future.

AI Planning Module (AIPM)

In Stargate V1, the credit system was based on a static credit accounting rebalancing mechanism. When liquidity was deposited into a pool, it generated credits, which were distributed along various cross-chain pathways according to predetermined weights. These credits were recorded on-chain as chainPath.Balances, which effectively soft-partitioned the liquidity across different pathways. This mechanism guaranteed instant finality for cross-chain transactions, however, the static nature of credit allocation and rebalancing had some drawbacks:

• No dynamic redistribution: Credits were not reallocated based on changes in volume or demand across pathways. As a result, unused pathways would have excess liquidity, while high-volume pathways could face liquidity shortages, leading to higher fees and reduced efficiency.
• Inefficient capital utilization: Pathways with low or no volume would continue to hold liquidity, while busier pathways would experience liquidity constraints, causing slippage for users and driving up fees.

To resolve these inefficiencies, Stargate V2 introduces the AI Planning Module (AIPM). The AIPM is an off-chain entity that leverages real-time data to dynamically manage credit distribution across the network. It is specifically trained on Stargate’s V2 bridging data and acts as a liquidity optimization tool, ensuring that the protocol operates with optimal liquidity allocation, minimal slippage, and the most competitive fees.

The AIPM is designed with a limited but impactful scope of control over the Stargate network:

• Dynamic Credit Allocation:
  • The AIPM rebalances credits across different cross-chain pathways based on changes in volume and user activity. For instance, if a specific pathway experiences a surge in volume, the AIPM can reallocate credits from less busy pathways to ensure that high-demand routes have enough liquidity. This reduces the risk of slippage and ensures that liquidity is available where it’s most needed.
• Fee and Reward Adjustment:
  • The AIPM has the ability to adjust fees and rewards within the protocol to balance liquidity across chains. It manages a limited reward fund that can be used to incentivize liquidity providers (LPs) or users to rebalance Stargate’s pools across different chains.
  • By dynamically adjusting the fees, the AIPM ensures that Stargate remains the cheapest bridging option, encouraging higher volume and profitability for the protocol.
• Protocol Fee Optimization:
  • The AIPM can also adjust Stargate’s protocol fee to maximize efficiency. It ensures that Stargate remains cost-competitive by adjusting fees in real-time to guarantee that it provides the most economical route for cross-chain transactions.

This table highlights how the AIPM improves on Stargate V1’s static credit allocation method.

Aspect	Stargate V1 (Static Credit Accounting System)	Stargate V2 (AIPM – Credit Allocation System)
Liquidity Management	Static, pre-allocated credits to specific chains, irrespective of demand fluctuations.	Dynamic, AI-driven redistribution of liquidity across chains based on real-time demand.
Capital Efficiency	Lower, since credits could be underutilized on low-volume chains, leading to inefficiency.	High, as liquidity is directed only where needed, reducing idle liquidity and optimizing usage.
Flexibility	Inflexible, as credits are assigned in advance and don’t easily adapt to changing network conditions.	Adjusts liquidity flow dynamically in response to network activity and demand shifts.
Slippage Reduction	Higher risk of slippage on certain chains if credit allocation doesn’t match real-time demand.	Minimizes slippage by ensuring that liquidity is always available where it’s most needed.
Utilization	Potential for over-provisioning on low-demand chains and under-provisioning on high-demand ones.	Maximizes liquidity utilization by avoiding over- or under-provisioning.
Risk Averseness	Can dynamically withdraw or allocate liquidity to protect against exploits or liquidity crises.	Less adaptable, meaning it can’t react as quickly to emerging risks or liquidity shortages.
Operational Complexity	Simpler, but less responsive to real-time network conditions and inefficiencies.	Higher complexity due to AI-driven decisions and real-time optimization.

Safeguards of the AIPM

Despite its wide-ranging influence over credit distribution and fee structures, the AIPM operates under strict limitations to ensure the safety and stability of the protocol:

• No control over funds or LP assets: The AIPM cannot control or access user funds, LP assets, or any liquidity within Stargate’s pools. This separation ensures that the AIPM only influences credit distribution and fee mechanisms without touching the actual underlying assets.
• Liveness Issues & Protective Functionality: While the AIPM optimizes liquidity distribution, there could be situations where it temporarily withdraws credits from certain pathways, causing liveness issues (i.e., pausing activity between two pools). This can protect the protocol in cases of chain exploits or asset depeg, as the AIPM can prevent liquidity from flowing through compromised pathways. This capability adds an extra layer of security to the protocol.

Using the Protocol

Transfer

Users can swap native assets 1:1 cross-chain accessing Stargate’s unified liquidity pools. Stargate transfers have instant guaranteed finality, meaning that a transfer submitted on the source chain is guaranteed on the destination.

1. Go to stargate.finance.
2. Connect your wallet.
3. Select the transfer tab in the navigation bar.
4. Select the transfer mode
5. Select the token, from network, to network, and transfer amount.
6. Approve the transaction.

While each non-STG token transfer has a 0.06% fee, there is no protocol transfer fee associated with these swaps and users will only pay for the gas fees associated with these transactions.

Transfer by the Stargate Bus (Economy)

 

Transfer by the Stargate Taxi (Fast) 

If the user wishes to transfer tokens to a different wallet address, they can select the option for a direct transfer to a specific address. Once the user enters the appropriate wallet and network, they can complete the token transfer securely.

Native Gas Transfers

With Stargate, it is possible for users to transfer gas from the source chain and get it on the destination when completing a transfer.

The options to choose from depend on the transfer mode selected.

• None: No native gas will be included in the Transfer.
• Medium: This amount will be enough to perform a couple of transactions (e.g. Approve and Swap) based on the average gas price on the Destination Network at that time.
• Maximum: The protocol has set a maximum delivery amount.
• Custom: The user will be able to specify between None and the Maximum amount.

Bus Mode gas transfers are limited to only Medium while Taxi Mode transfers have the levity to select a custom option between None, Medium or Max.

After approving the transaction, the user will receive the specified native gas amount on the destination chain.

Pools

Users can provide liquidity to Stargate and earn rewards on every Stargate transfer. Liquidity providers can also farm their LP tokens to receive $STG rewards.

1. Go to stargate.finance.
2. Connect your wallet.
3. Select the pool tab in the navigation bar.
4. Select a liquidity pool.

   

5. In exchange for adding liquidity to a pool, users receive LP tokens that represent the proportional share of the pooled assets, allowing them to claim the underlying share at any time.

To migrate your liquidity from Stargate V1 to Stargate V2 find more information here.

Farms

With Stargate farms, liquidity providers can farm their LP tokens in exchange for $STG rewards.

1. Go to stargate.finance.
2. Connect your wallet.
3. Go to the farm tab.
4. Select the LP tokens in your wallet (you must have provided liquidity to a pool before).
5. Select a farm.
6. In exchange for adding the LP tokens to a farm, the user will receive $STG rewards. These $STG rewards can be staked to earn $veSTG, the protocol’s governance token.

Staking in the farm allows you to earn rewards, which you can claim at any time. When you withdraw LP tokens from the farm, any unclaimed rewards will automatically be claimed.

Stake

$STG holders can lock their STG tokens for $veSTG. The longer users stake their $STG tokens, the more $veSTG they will receive. Holders of veSTG get governance power in the Stargate DAO, where their power is determined by their $veSTG balance.

1. Go to stargate.finance.
2. Connect your wallet.
3. Go to the stake tab.
   
4. Click on the staking pool of your choice.
5. Input the amount of STG token you would like to stake.
6. Select a lock duration between a minimum of one month and a maximum of three years (36 months).

A user cannot unstake their locked $STG until the staking period ends. Once the $STG is unlocked, the user can either unstake the tokens manually or restake them. If the user already has $STG staked on a specific network, they can choose to either increase the lock period or add more tokens to the staked amount. However, all STG tokens staked on the same network will be unlocked at the same time.

Business Model

As a native asset bridge and the first dApp built on LayerZero, Stargate’s business model is based around capturing fees from bridging transfers. Users pay fees for cross-chain transfers, and these fees cover the costs of bridging assets, gas fees, and using the LayerZero messaging system. While the V1 encountered a lot of computational overhead with the Delta Algorithm, optimizations on Stargate V2 captured a larger share of the total fees, with the reduction in overhead from gas fees and other costs.

These fees are redistributed to Liquidity Providers, veSTG holders and the protocol treasury, supporting the protocol’s operations, liquidity, and governance.

Fee Breakdown

Every non-STG transfer through the protocol incurs a 6 bps fee, allocated as follows:

• Protocol Treasury: 4 bps
• veSTG Holders: 1 bp
• Liquidity Providers: 1 bp

If there are emissions on the source pool for a transfer, this fee is reverted to the protocol.

The fee structure was voted on in SIP: Value Accrual for STG stakers.

Stargate Whitelist Partner Program

Partners that integrate Stargate in production and receive significant transaction volume through their integration can apply to participate in Stargate’s whitelist partner program. In doing so, they are requesting to become eligible to receive .3 bps for the transactions they have sent through the Stargate protocol. This will be settled in stablecoins on a monthly basis, and the funds will come from Stargate’s Treasury baseline fee.

Tokenomics

$STG is the native token of protocol and it is used for governance, staking, and incentivizing liquidity providers through farming rewards. A total of 1 billion $STG tokens have been minted at the genesis and will be the entire finite supply of $STG.

$STG has the following distribution:

• 17.50% allocated to the team (Stargate core contributors)
  • 1-year full lock-up and 2-year linear unlock thereafter.
• 17.50% allocated to investors
  • 1-year full lock-up and 2-year linear unlock thereafter.
• 65.00% allocated to the Stargate community
  • 15.00% for the Stargate protocol launch, with 10.00% going to STG launch auction purchasers and 5.00% to an STG-USDC pool on Curve.
  • 15.95% for the Bonding Curve, post-launch
  •  2.11% for the initial emissions program.
  • 1.55% added to decentralized exchanges (DEXs) on BNB, Avalanche, Polygon, Arbitrum, Optimism, and Fantom.
  • 30.39% dedicated to future community initiatives.

Bonding Curve & DEX Liquidity tokens are available at the time of purchase.

Launch Auction tokens have a 1-year full lockup, followed by a 6-month linear unlock.

Supply Schedule

$STG was launched on 17 March 2022.

$STG has a max supply capped at 1,000,000,000.

Token Launch

Initial Launch

The initial token launch was held on March 17 2022 and separated into 2 phases:

• Phase 1 – Launch Auction
  • To bootstrap an STG-USDC pool on Ethereum.
• Phase 2 – Bond
  • To build protocol-owned liquidity with Stargate.

Phase 1: Launch Auction

Users can swap $USDC for $STG to create a $STG-$USDC pair for DEX liquidity.

How it works:

• The launch auction will remain open for 48 hours or until 25M $USDC is added to the launch auction contract, whichever occurs first.
• 10% of the $STG token supply will be auctioned and locked for 1 year and unlocked linearly over 6 months thereafter.
• This liquidity plus an additional 5% of the $STG supply will bootstrap the $STG-$USDC Curve pair and will be protocol-owned.
• Because their $STG is locked, contributors will receive $aSTG, which represents their ownership share of the 10% STG token. Here’s how contributors can calculate their share of the auction:
  • (Contributor $aSTG balance / Total $aSTG balance) * 100M $STG = contributor $STG balance
• While their $STG is locked, contributors will also receive $veSTG (voting escrow $STG). Learn more on Stargate governance and $veSTG here.
• Once the launch auction closes:
  • The $STG-$USDC Curve pair will go live.
  • The bonding phase will begin.

Phase 2: Bonding

Users can add stablecoins to Stargate bonding curves and receive $STG tokens while building Stargate’s protocol-owned liquidity.

How it works:

• 15.95% of the $STG supply will go towards 12 $STG bonding curves.
• The initial bonding price will be the opening $STG price on the $STG-$USDC Curve pool.
• The bonding price will increase linearly as contributors purchase STG tokens on individual chains.
• Unlike the Auction, contributors will receive their $STG tokens immediately.
• Bonding curves will stay open for 72 hours or until $STG reaches 3x the opening bonding price, whichever occurs first.
• Token allocations across all chains are:
  • Ethereum – 40M $STG
  • BNB – 22M $STG
  • Avalanche – 27M $STG
  • Polygon – 27M $STG
  • Fantom – 22.5M $STG
  • Arbitrum – 13M $STG
  • Optimism – 8M $STG

The launch was fully allocated by only 2 participants, with Alameda Research having bought all the supply at a significant gas cost. As a result, a 2nd launch called the Community Auction was held for those who had missed out, and to further decentralize the $STG supply.

Community Auction

The community auction was held on March 30, 2022, and was intended to extend the $STG holder base to those who missed the Launch Auction and broaden participation in governance long-term, due to the first auction being held overwhelmingly by Alameda Research.

Eligible participants included wallets that pre-approved the Stargate Launch Auction or bonded before March 17, 2022, at 21:22 UTC and were eligible to buy $STG at the price of $0.25 with the original Launch Auction terms (STG locked for 1 year and unlocking linearly for 6 months thereafter).

The auction was split into 2 Rounds, with any unsold $STG being purchasable by round 1 participants who had maximized their round 1 allocation.

Post-auction, any remaining Community Auction $STG and all $USDC received would be protocol-controlled.

Governance

Stargate is governed by the Stargate DAO, via $STG token holders, under the $veSTG system and plays a crucial role in deciding various aspects of the Stargate network, such as protocol development, integrations, tokenomics, and the distribution of emissions to stablecoin liquidity providers.

Time Weighted Voting

Time-weighted voting is used to provide long-term Stargate token holders greater governance weight and control of the Stargate protocol.

$veSTG is the unit of Stargate governance voting power. It is received by staking locked Stargate tokens and is non-transferable. The $veSTG balance decays linearly as the remaining time until the staked or locked STG unlock decreases.

Launch Auction and Team & Investor Weighting

Launch Auction and Team & Investor $STG tokens receive $veSTG equal to the weighted-average duration of their token lockup.  This normalizes these $veSTG balances with the voting escrow model.

• Launch Auction $STG tokens receive $veSTG equal to a 15-month lock up.
• Team & Investor $STG tokens receive $veSTG equal to a 24-month lockup.

Multisig

From time to time, a vote may require a change to the Stargate protocol or its treasury that requires action via multi-sig.  A multi-sig comprised of a group of trusted community members is responsible for signing on behalf of $STG holders and must strictly adhere to any directives given via the governance process.

Stargate Foundation

The Stargate Foundation is dedicated to supporting the growth, development, and sustainability of the Stargate protocol. Their efforts will include:

• Community-led initiatives, including grants to contributors.
• Partnerships with other DeFi & crypto organizations.
• Marketing & communication initiatives.
• Day-to-day operations and maintenance of the Stargate protocol.

Proposals & Voting

Proposals

Changes to the Stargate protocol must go through the Community Forum with a proposal. Proposals can be discussed in the Forum to gain sentiment and are classified as “Core” and “Protocol”.

Core Proposals

Core Proposals include changes to the governance process itself and Multisig. These proposals are material to the governance process or major structural changes and, as such, carry higher quorum and support thresholds.

• Quorum Threshold: 10%
• Support Threshold: 80%

Protocol Proposals

Protocol proposals include all other changes to the Stargate protocol, including parameter changes (e.g., changing fee structures, changing Stargate Unified Liquidity Pool connections & weights), protocol code changes, and protocol treasury allocations.

• Quorum Threshold: 2.5%
• Support Threshold: 70%

The Voting Process

The voting process is designed to drive discussion for all proposals, which are then effectuated upon community approval and voting. Proposals must adhere to the below governance process.

• Proposal Stage – All $STG token holders are eligible to submit non-binding proposals, which may result in a governance vote by holders of $veSTG voting power.
• Voting – Proposals with a positive poll sentiment can be submitted to Snapshot by any holder of 50,000 $veSTG, or from Admin wallets on Snapshot. Core and Protocol proposals have voting periods ranging between 24 hours & 120 hours.

Proposal Blocktimes

Note: When voting on a proposal, a $STG holder’s voting power equals the holder’s $veSTG balance at the blocktime that the proposal was submitted. As such, any $veSTG acquired after the submission of a proposal cannot be used to vote on the proposal.

Risks

Bridge exploits account for ~50% of all DeFi exploits, totaling ~$2.5B in lost assets.

• BSC Bridge Hack: $568m – Bug in the way that the Binance Bridge verified proofs which allowed attackers to forge messages. Resulted in a hard fork of the chain.
• Nomad Hack: $200m – Attackers bypassed the message verification process and drained the tokens from the bridge contract.
• Harmony Bridge Hack: $100m – Compromised private keys.
• Ronin Bridge Hack: $650m – Compromised private keys.
• Wormhole Bridge Hack: $325m – The attacker bypassed the “verify signature” with a malicious sysvar account that forged the message to mint the wETH on Solana. The bridge minted wETH without an equivalent deposit on the Ethereum network.
• Multichain (Anyswap) Bridge Hack: $1.4m – A vulnerability in the code for the $ANY intermediary token’s contracts allowed an attacker to steal funds from users who had previously created approvals for them.
• QBridge Hack: $80m – Bypassed the verification process by evading the bridge’s smart contract.
• Polynetwork Bridge Hack: $600m –  The hacker exploited a vulnerability in the way the bridge verified smart contracts. By changing a list of public keys to match their private keys, the hacker could reroute the funds to personal wallets.
• THORChain Bridge Hack: $7.6m – Exploited a bug in Bifrost, THORChain’s Ethereum bridge via abusing an override loop (designed only to be used in a vault transfer incident).

Most bridges rely on wrapped assets. These are synthetic tokens that represent an underlying asset and they are supposed to be backed by that asset. The backing value is put in a vault called a “wrapper”. However, this design introduces a security problem: if the smart contract controlling the underlying assets is hacked and the funds are stolen, the wrapped assets are unbacked and have no value. This leads to capital losses due to custody risk.

In order to achieve true interoperability and connect multiple heterogeneous networks, additional smart contract deployments create extra layers of risk. For example, SushiSwap is present on 17 different networks. In the event that Sushi desired to synchronize states between their Ethereum contracts and their whole alt chain executions, they would have to write code for every single bridge present on each of these. The outcome is dozens of distinct sets of code (more risk), with different interfaces and security characteristics.

Instead of wrapping assets, Stargate uses LayerZero for interoperability. LayerZero is a communications protocol that enables smart contract execution across multiple chains.

LayerZero endpoints exist on each supported chain, and any chain with a LayerZero endpoint can conduct cross-chain transactions involving any other chain with a LayerZero endpoint. These endpoints are implemented as a series of smart contracts that allow domains to communicate with each other, with each chain having its own “Library” within LayerZero, which can be extended via append-only libraries. Each endpoint comes with its own messaging library and proxy, which makes sure that the endpoint uses the correct library version. Once deployed, endpoints act like smart contracts that cannot be shut down, allowing for an immutable flow of messages.

In LayerZero V2, the concept has evolved from using Ultra Light Nodes (ULNs) to a more decentralized structure involving Decentralized Verification Networks (DVNs).

DVNs are responsible for verifying cross-chain messages. This is a permissionless role, and any entity capable of verifying cross-chain data can join LayerZero and start participating as a DVN. Once verified, the next step is execution. On that note, LayerZero V2 allows applications to select their own Executor, responsible for quoting prices and managing transaction complexities. The simplicity of running Executors compared to Relayers encourages competitive pricing and service quality.

Instead of fixed oracle-relayer setups, DVNs verify cross-chain messages independently, enhancing security and flexibility. Protocols can customize their verification process, choosing from various DVNs and Executors for transaction execution. This modular design allows for adaptable rules and consensus mechanisms, improving cross-chain messaging reliability.

Whenever a message M is sent from chain A to chain B, the following occurs:

1. DVNs verify the message instead of relying solely on an oracle. They confirm data like block headers or transaction proofs, ensuring accurate cross-chain communication.
2. Executors handle the transaction’s execution on Chain B. This decoupling of verification and execution improves decentralization.

A LayerZero transaction/message only requires gas of the source chain in a single call. The transaction then handled by the DVNs verifying cross-chain data, ensuring message validity, and Executors handling execution. Once the DVNs confirm the information, the LayerZero Endpoint facilitates message translation and execution on the destination chain.

For context, critics in the past compared the oracle/relayer setup to a 2/2 multisig. Even though such a comparison is not accurate either, v2 introduces what’s called the “X of Y of N” approach.

X of Y of N allows applications to combine DVNs however they like. For instance, a “1 of 3 of 5” combination of DVNs would include one required DVN and two arbitrary DVNs out of a total of five to verify a message before moving on to execution. This means that if two DVNs outside the required DVN were unresponsive out of five, the message flow could continue. This solves the hypothetical risk in v1 where the relayer could experience downtime.

In LayerZero V2, the execution of transactions shifts to end-users, reinforcing the permissionless nature of transactions. The idea behind this self-execution model is to ensure that actions are registered without intermediaries while offering gas abstraction to the end user.

To support new chains, protocols like Stargate do not need to deploy their core smart contracts to each chain. Instead, they can deploy a proxy contract that will be used to send and receive messages from the newly supported chain to the host chain.

For example:

1. The user sends a transaction to transfer $USDT from Polygon to Avalanche.
2. The LayerZero endpoint sends the message to a Decentralized Verification Network (DVN), which consists of independent entities verifying the cross-chain message.
3. The DVN confirms the data.
4. The Executor handles the transaction execution.
5. If the verification is successful, $USDT is received on Avalanche. If there is any discrepancy during verification, the transaction is paused.

Security

The security profile of Stargate is heavily dependent on LayerZero. LayerZero Labs has commissioned over 35 audits with the most recent ones available on Github. Almost all the code they’ve written since inception, which is largely immutable smart contracts, have been externally audited and internally reviewed at least three times each.

Additionally, LayerZero has instituted a bug bounty program with a commitment to continuous security evaluation and improvement. Their bug bounty program on Immunefi is one of the largest in the industry, offering up to $15 million for identifying security vulnerabilities. Also, LayerZero has already awarded almost $1 million to white hat hackers for their disclosures. There is also a separate bug bounty of up to $2 million that specifically covers The Aptos Bridge.

Regardless, LayerZero makes a series of trust assumptions:

• The network’s DVNs support a more decentralized structure by allowing any entity to join and verify cross-chain messages.
• Since message verification and execution are decoupled, there will be no liveness issues at the core protocol level, as execution is a permissionless role outside the protocol and away from the verification process.
• There are operational risks – LayerZero relies on third parties (DVNs and Executors) for its functioning, which adds operational risks beyond LayerZero’s control.
• Reliance on chains’ security – LayerZero does not add an intermediary step to cross-chain transactions. However, it relies on the native chain’s endpoint to function correctly. For instance, if a chain suffered a 51% attack, it is unclear how LayerZero would be able to handle such an event.

PreCrime

PreCrime is an off-chain security mechanism used within LayerZero’s design that adds an additional layer of protection for applications (OApps) built on top of the protocol, such as Stargate. PreCrime works by analyzing and filtering verified but potentially harmful messages before they are delivered, based on predefined security criteria set by the OApp.

PreCrime allows Stargate to simulate the effects of cross-chain messages (packets) before they are delivered. This helps detect any anomalies, such as discrepancies in liquidity across chains. For example, if a cross-chain transaction tries to mint tokens on one chain without locking corresponding liquidity on another, PreCrime will detect this and halt the transaction to prevent malicious minting or liquidity manipulation.

Source: LayerZero Whitepaper v2.0

The system ensures that only legitimate cross-chain transfers are executed. If an attacker compromises one chain and tries to execute unauthorized token minting or unlocking, PreCrime compares metrics like total locked liquidity (∑lock) and total minted tokens (∑mint) to detect inconsistencies, thus preventing the fraudulent release of assets.

PreCrime runs simulations of packet deliveries, testing whether the resulting actions violate the security rules defined by Stargate or other applications. By simulating the outcome of transactions, PreCrime helps ensure that only valid and safe transactions are executed, thereby reducing the risk of exploits or faults at the OApp level.

Audits

There have been multiple audits done by Zokyo, Quantstamp, Ackee Blockahin, and Zellic.

• Stargate audit 1.0 – December 22, 2021 – Quantstamp
  • High – 3 (3 Fixed)
  • Medium – 3 (3 Fixed)
  • Low – 5 (3 Fixed, 2 Acknowledged)
  • Informational – 3 (2 Fixed, 1 Acknowledged)
• Smart Contract Security Assessment – March 6, 2022 – Zellic
  • High – 1
  • Medium – 1
  • Low – 1
  • Informational – 4
• Stargate Audit Report – 16 March 2022 – Quantstamp
  • High – 1 (1 Fixed)
  • Medium – 2 (2 Acknowledged)
  • Low – 9 (2 Fixed, 7 Acknowledged)
  • Informational – 1 (1 Acknowledged)
• Smart Contract Audit – March 21, 2022 – Zokyo
  • Medium – 1 (1 Resolved)
  • Low – 2 (2 Resolved)
  • Informational – 3 (3 Resolved)
• Stargate DAO / Voting Escrow Audit – April 13, 2022 – Ackee Blockchain
  • The review resulted in 5 findings, mainly informational regarding the code quality and one warning.
• StargateEthVault and RouterETH – June 12, 2022 – Ackee Blockchain
  • The review resulted in 9 findings, ranging from Informational to Medium severity.
• Stargate Fee Library V4 – June 28, 2022 – Ackee Blockchain
  • The review resulted in 7 findings, ranging from Informational to Medium severity.
• LPStakingTime.sol, WidgetSwap.sol – July 12, 2022 – Ackee Blockchain
  • The review resulted in 5 findings, ranging from Informational to Medium severity. The code quality was excellent, as with the previous LayerZero audits.
• Smart Contract Update Review – December 14, 2022 – Zellic
  • Fee Library Updated (v05.1) – A few minor concerns were listed.
  • Stargate Router – This was thoroughly reviewed by the Zellic team and no issues were found.

Bug Bounty

LayerZero has a bug bounty program with Immunefi.

Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.2. This is a simplified 5-level scale, with separate scales for websites/apps, smart contracts, and blockchains/DLTs, focusing on the impact of the vulnerability reported.

Bounties include:

• Critical
  • Group 1 – $250K to $15M
  • Group 2 – $25K to $1.5M
• High
  • Group 1 – $25K to $250K
  • Group 2 – $10K to $25K
• Medium
  • Group 1 – $10K to $2K
  • Group 2 – $5K to $10K
• Low
  • Group 1 – $1K to $10K
  • Group 2 – $1K to $5K

Economic Attack Vectors

With Stargate, there is no need to lock and mint synthetic assets. As a result, the liquidity is not fragmented. This way, it becomes possible to have multiple pools of native assets that are linked to all chains at the same time. This allows LPs to invest single-sided liquidity without impermanent losses and earn fees from all incoming transactions, regardless of the chain where they originate.

With Stargate, users don’t have to exchange synthetic assets on the destination chain, nor do they have to worry about transactions failing due to a state change.

Dependencies and Access Controls

When LayerZero describes their security model regarding DVNs and Executors, they assume that application owners (or someone in possession of their private keys) won’t do anything irrational. Note that that assumption may be incorrect in an adversarial environment. Moreover, it requires the users to trust the application owners as a trusted third party.

Team

Stargate is a project founded by the LayerZero Labs team and is a DAO-owned operation.

• Angus Buttar – Lead, Stargate Foundation
  • Bachelor of Arts, Biological Natural Sciences at the University of Cambridge.
  • Previous experience as Life Sciences Associate at L.E.K Consulting.

Some members of the LayerZero Labs team include:

• Bryan Pellegrino, CEO and Co-Founder
  • Computer Science at the University of New Hampshire.
  • Currently also an Entrepreneur In Residence at Rho AI.
• Ryan Zarick, Co-Founder and CTO
  • Master of Science, Computer Science at the University of New Hampshire.
  • Previous experience as Co-Founder of Minimal AI and Coder Den.
• Richard Dietrich, Head of Talent
  • Bachelor of Science, Business Administration, at the University of the Pacific.
  • Previous experience as Recruiting Manager at Uber, Talent Acquisition at Chartboost.
• Irene Wu, Head of Strategy
  • Joint Concentration, Computer Science at Harvard University.
  • Currently also an Angel Investor.
  • Previous experience as an Investor at Insight Partners.
• Carmen Cheng, Software Engineer
  • Master of Science, Big Data Technology at The Hong Kong University of Science and Technology.
  • Previous experience as Founder at Wolo Technology Limited, and Software Engineer at AQUMON.
• Austin C., BD, and Market Research
  • Bachelor of Science, Finance and Economics at NYU Stern School of Business.
  • Previous experience as Principal Investments at TPS Capital.

Additional Information

Project Investors

Stargate was funded by 2 community raises. There was also a token allocation to team and investors, with some from the LayerZero Lab raises, however, not much information is known about this.

LayerZero Labs

• Seed Round
  • Raised $2M in April 2021.
  • Participants are unknown.
• Series A Round
  • Raised $6M in September 2021.
  • Co-led by Binance Labs and Multicoin Capital.
  • Participants include Sino Global Capital, Defiance, Delphi Digital, Robot Ventures, Spartan, Hypersphere Ventures, Protocol Ventures, Gen Block Capital and Echelon Capital.
• Series A+ Round
  • Raised $135M in March 2022.
  • Co-led by Sequoia Capital, Andreessen Horowitz, and FTX Ventures.
• Series B Round
  • Raised $120M in April 2023.
  • Participants include Christies, Samsung, OpenSea, Circuel Ventures, A16z, and others.
    
    

Stargate

• Community Round 1 
  • Raised $25M on 17 Mar 22 with an average price of $0.25.
  • There were only 2 participants, with Alameda Research getting almost the entire allocation.
• Community Round 2
  • Raised $5M on 30 Mar 22 with an average price of $0.25

FAQ

• What makes Stargate different from other bridges? Stargate is the first bridge to attempt to solve the bridging trilemma through the use of native assets and by not fragmenting liquidity. Existing bridges are forced to make trade-offs on the following core bridge features:
• Cheapest Bridge: Stargate is the cheapest bridge in crypto, achieved by transaction batching and optimized contracts that are 90% more gas-efficient. The Stargate Bus is now the cheapest bridge in DeFi.
• Instant Guaranteed Finality: Users & Applications can trust that when they successfully commit a transaction on the source chain, it will arrive on the destination chain.
• Native Assets: Users & Applications swap in native assets as opposed to wrapped assets that require additional swaps to acquire the desired asset and corresponding fees.
• Unified Liquidity: Shared access of a single liquidity pool across multiple chains creates deeper liquidity for users & applications that trust in the bridge’s reliability.
• Is Stargate V2 Built on LayerZero V2: Yes. Stargate V2 is utilizing LayerZero V2 to achieve cost reduction and flexibility of expanding to more chains.
• Is Stargate V1 Still Available: Stargate V1 remains operational until further notice. However, it is recommended to migrate your liquidity to V2. While a deadline date has not been established yet, it is advisable to transfer your liquidity to V2 as soon as possible.

Transfer: 

• Can I use the Stargate Bus When it is not full?: Yes. If a bus is not full, users have the option to cover the message fee of the entire bus to initiate the bus’ departure.
• Can I drive the bus when it is not full?: Yes. If a bus is not full, users have the option to cover the message fee of the entire bus to initiate the bus’ departure.
• How much cheaper can I get if I take the bus instead of Taxi: It depends on the bus size and how many tickets you pay for on the bus. For instance, in a 6-seat bus, if you pay for 1 ticket, the cost would be around 1/6th of the total ticket cost. But gas price can fluctuate so every passenger may have a slightly different fare at time of transaction.
• When will the Bus depart from source network : The bus will leave the source network once all seats are paid for, or the max. waiting time has been reached after the first transaction is submitted, whichever occurs first.
• What is the waiting time for the bus to drive: The estimated waiting time will be shown on UI. The bus will depart from source network
  • once the bus is full,
  • or once the max. waiting time is reached (max. waiting time is set by the Stargate Foundation)
• Why is the taxi option sometimes the only one available?: If the pools you choose are only accessible on V1, the bus option will not be available. Generally, V2 tends to be more cost-effective in most situations. However, in certain rare cases where a route is available on both V1 and V2, the V1 taxi might be slightly cheaper. In these instances, the V1 taxi option will be selected automatically.

AI Planning Module (AIPM):

• What are the risks of the AI Planning Module?: At its most malicious, the AIPM could cause liveness issues for certain pathways if it, for example, withdrew 100% of credits on a pathway meaning no volume can move between those two pools. This mechanism can also be protective in case of chain exploit, or asset depeg. Stargate V2 separates the messaging used for funds and credits, and as such, the AIPM cannot at any point touch any LP or user funds at all.
• Who is running the AIPM?: The first iteration of the AIPM will be run by the Stargate Foundation on behalf of the DAO. The Foundation will provide updated reports on how the planner is performing and changes being made. Future iterations will very likely also be maintained by the Foundation but doesn’t necessarily have to be built by the Foundation.

Pool:

• Is there a deadline for migrating the pools from V1 to V2?: The deadline has not been established yet, but it is advisable to transfer your liquidity to V2 as soon as possible.
• I Have removed my liquidity from a pool but the funds have not arrived, How long does it take to remove liquidity: It takes one message from source chain to another chain then another message from the other chain to source chain. If the remote chain is Polygon then the processing time could take more than 20 mins; If the remote chain is Ethereum, a higher amount of gas is expected.

Hydra:

• What is OFT: The Omnichain Fungible Token (OFT) Standard allows fungible tokens to be transferred across multiple blockchains without asset wrapping or middlechains.
• What kind of assets are supported by Hydra: Hydra currently supports $USDC, $USDT and $WETH.

$STG Token: 

• What is STG, aSTG, & veSTG?

• • • $STG is the native token of Stargate.
    • $aSTG is the auction token that the users receive if they purchased $STG in Stargate’s Launch Auction.
    • $veSTG is the voting escrow token that the users receive if their STG is locked or staked. $veSTG represents the voting power.
    • $aSTG and $veSTG may have different forms but they function similarly, e.g. the Community Auction holders receive $aaSTG and $sveSTG instead.

• Who incurs impermanent loss?

• • • As the liquidity pools are composed of stablecoins and assets that maintain a 1:1 ratio, there is no impermanent loss. This is because pools are single-sided and only accept deposits in one asset. The user simply stakes a token to a unified pool of liquidity and gains access to all pools in Stargate’s network.

• Why did my $STG rewards disappear?

• • • When a user adds liquidity to the protocol, the contract claims the user’s current rewards and resets them to zero.

• Why does my voting power show 0 veSTG when I vote?

• • • If you are seeing 0 $veSTG when you vote, please check the following steps first.
    • 1) The time that you acquired your $veSTG must be prior to the proposal Snapshot time in order to vote on the Snapshot. If you staked your $STG later than the Snapshot time, your $veSTG will show 0 for the latest Snapshots.
    • 2) If you staked before the Snapshot time, please make sure you still have the $veSTG balance in order to vote. Go to https://stargate.finance/stake to check your balance and make sure the $veSTG balance is not 0.
    • 3) If you staked $STG before the Snapshot time and you still have $veSTG balance in your wallet, double-check if you have connected with the correct wallet on Snapshot.
    • 4) If you have passed the checks from 1) to 3), and you are still seeing 0 veSTG, go to https://snapshot.org/#/delegate/stgdao.eth and switch to the Ethereum network. You will see your delegation. If you have delegated your voting power to another address for “All spaces” or “stgdao.eth”, your voting power will be 0 for the proposal Snapshot. You can’t vote from your wallet as the voting power has been delegated.
    • To be able to vote for the next proposal, you need to remove your delegation for “All spaces” or “stgdao.eth”.
    • If you have checked from Step 1 to Step 4, and you still can’t vote, please head to Discord #help-zone: https://stargate.finance/discord

• How long can I stake my $STG for?

• • • You can stake your $STG for 1-36 months.

• How to delegate your voting power?

• • • Delegation on Snapshot is to delegate your voting power to another address. If your voting power is delegated, you can’t vote from your own wallet.
    • Step 1: Go to https://snapshot.org/#/delegate and connect your wallet
    • Step 2: Enter the address you want to delegate to.
    • Step 3: Limit your delegation to a specific space.
    • To limit delegation to a specific space, tap the on switch button and enter the space key (example: `balancer.eth`) you want your delegation to take effect on. If no space is selected, the effect will take place for all spaces.
    • Step 4: Click confirm to save your delegation.

• I don’t receive my funds instantly. Why?

• • • If you are removing liquidity and experiencing a longer processing time than usual, it is likely that the transaction has triggered the redeem local function that requires two cross-chain messages to complete the transactions. This is one message from the source chain to another chain and then another message from the other chain to the source chain. If the other chain is Polygon then the processing time could take around 20-30 minutes as it requires 512 block confirmations on Polygon for security reasons. If the other chain is Ethereum, a higher gas fee is expected. You can check the fee before you remove the liquidity.

• Why are both Snapshot and Commonwealth used for governance? 

• • • Changes to the protocol are determined by $STG token holders who use their voting power to submit and vote on proposals.
    • Commonwealth is a community forum, whereas Snapshot is a decentralized voting system. Both platforms play different but complementary roles.
    • Proposals can be discussed in the forum to gain sentiment and be classified as “core” and “protocol”. Commonwealth helps the Stargate community to submit well-structured and comprehensive governance proposals. Next, those proposals that gain sufficient positive sentiment with strong polling from the community can be brought to Snapshot for a formal and official governance vote.
    • Proposals are thoroughly discussed before being executed, allowing community members to fully grasp the new concepts and debate over the pros and cons.

• How can I trace my transaction?

• • Track transactions on Stargate

• • • After each transaction, you can find your transaction record on the transaction window.

• • Track transactions on your wallet

• • • Find the transactions that interacted with [Stargate.finance] then click the transaction to view the details. You can also go to the explorer of each network to check the transaction hash.

• • Track transactions on each network

• • • You can also use the specific block explorers for each of the seven chains compatible with Stargate. You can search your transaction hash by pasting your wallet address into the search bar on the explorer.

Community Links

• Website: https://stargate.finance/
• App: https://stargate.finance/transfer
• Docs: https://stargateprotocol.gitbook.io/stargate/v/user-docs/
• Blog: https://medium.com/stargate-official
• LinkedIn: https://www.linkedin.com/company/layerzerolabs/
• Discord: https://stargate.finance/discord
• Telegram: https://t.me/joinchat/LEM0ELklmO1kODdh
• Twitter: https://twitter.com/StargateFinance
• CoinGecko: https://www.coingecko.com/en/coins/stargate-finance
• DefiLlama: https://defillama.com/protocol/stargate