Stargate V2

Summary

Stargate V2 can be the cheapest and most interoperable bridge in DeFi. Stargate V2 should be built to address some of the pain-points of Stargate V1; expensive onchain accounting, static credit mechanism and slow expansion to new chains. Stargate V2 will introduce transaction batching in order to provide the absolute cheapest bridging experience across all pathways. Stargate V2 also introduces dynamic credit allocation to better handle volume surges across particular pathways, managed by an AI Planning Module. Hydra is introduced as Stargate’s expansion into Bridging as a Service, allowing new chains to access unlimited liquidity across all Stargate chains.

Primo, MaxPower and Lamps ran through this entire proposal on Stargates recent community call.

Video link here: https://www.youtube.com/watch?v=mKcXOTYChB8

Background

Stargate Finance launched on 17th March 2022 and has lived immutably onchain for over two years. It launched on 7 chains and has since expanded via DAO mandate1 to 14 chains. It supports over 10 types of asset pools and has over 40 OFTs bridging through the UI.

Proposed Architecture for Stargate V2 The following section will break down proposed and potential architecture changes for the Stargate protocol. Each section will come with an Explanation and Proposal

The Bus - Transaction Batching

Introduction

Every single Stargate V1 transaction currently has three parts to the gas fee paid by the user;

-Source chain gas fee -LayerZero message fee (typically very low) -Destination chain gas fee With all three of these fees grouped into 1, and all paid on the source chain, Stargate V1 could sometimes become quite expensive, ranging from $0.50 on cheap pathways, to up to $50-$100 on pathways to Ethereum Mainnet.

With the introduction of LayerZero V2, applications can now batch their LayerZero cross-chain message - meaning that any arbitrary number of users can submit their source chain transactions and pay an amortized portion of BOTH the LayerZero message and destination transaction fee.

The Bus - This would be the option within Stargate for users to use batched transactions to reduce their costs by over 95% compared to Stargate V1. Users will still have the option to pay for a full cost, faster transaction if they so choose, meaning each individual user can make their own decision on cost vs. latency. This concept can be thought of through a “bus versus taxi” analogy in the example below.

Each bus would have a configurable number of ‘seats’, and once each of the seats has been purchased or someone pays for the bus to depart at less than full, the bus departs to destination chain. Each taxi is a 1-to-1 transaction that ‘departs’ to the destination chain as soon as source chain finality is achieved.

As a practical example, if user A wants to bridge from Arbitrum to Optimism and they are presented with two options;

-Buy a ‘bus ticket’ on a bus that has 6 seats. They will pay for a very cheap source chain transaction to record their transaction on source and pay ⅙th of the LayerZero message (and destination chain fee). The tradeoff is that the transaction only moves to the destination chain when the ‘Bus’ is full, i.e. when all 6 seats have been paid for (by other users, or the same user). The user trades off some speed for reduced cost. -Alternatively, the user may choose to take a Taxi. In this case, they pay the full message fee, but get the advantage that their transaction goes through immediately. It is worth noting that while this is akin to a regular transaction on Stargate V1, it is still significantly cheaper due to gas optimizations made to the contracts. The user trades of some cost for increased speed.

AI-Planning Module - Dynamic Credits & Fees

Proposal

The credit management system would still live onchain, such that destination state is known and finality is still guaranteed. However, credits are now able to be redistributed across pathways according to volume and user behaviour. The only actor that can do this is a whitelisted entity - dubbed the Artificial Intelligence Planning Module (“AIPM”). The AIPM is an off-chain entity that will be trained on, once available, Stargate V2s bridging data to ensure optimal liquidity, slippage and fees for the protocol.

The AIPM would be limited to the following abilities:

-The AIPM cannot control funds, LP, or any underlying assets within Stargates pools. -It can dynamically distribute credits across the pathways that have gone below a certain threshold, ensuring that liquidity is available on the busiest pathways. The result of this is deeper liquidity and less slippage for the user. -It can dynamically adjust fees and rewards, from a limitedfund pool, to ensure users are incentivised to balance Stargates pools across all chains. -It can adjust Stargate’s protocol fee to guarantee that Stargate is always the cheapest route, thereby maximising for volume and profit for the protocol.

Hydra: Bridging-as-a-Service

Hydra operates via Stargate’s core pools, which reside on chains with native assets (e.g., Ethereum, Arbitrum, Optimism, Base, etc.) and are leveraged to facilitate asset bridging to newer chains lacking native assets.

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).

The benefits to the Stargate protocol are;

-All assets that become locked in Stargates pools can be used as credits within Stargates internal accounting, deepening liquidity between liquidity pools. -Every $1 bridged using Hydra adds $1 to Protocol Locked Liquidity, reducing the need for incentives at all. -A chain electing to use Hydra assets as canonical ensures Stargate remains the best place for bridging to and from this new ecosystem into perpetuity.

The benefits to a Stargate Hydra chain are:

-Access to all core Stargate chains, along with all current and future Hydra chains -Bridging into Chain X from Stargate’s core pools is free, while bridging out of X has a low redemption fee. This encourages users to bridge into these new ecosystems -Bridging between X and Y (both Hydra chains) has a nominal convenience fee -Full composability between any chains that Stargate is connected to, with unlimited liquidity -Hydra eliminates the concept of pathway liquidity, meaning a dApp on Arbitrum could build a cross-chain implementation into Chain X with 0 limits on size. -Of course, the same goes for a user no limits on size. No extra fees, 0 slippage.

Execution

Upon approval by the DAO, the Stargate V2 protocol would launch according to the following execution plan:

-Incentives on the Stargate V1 pools should slowly be reduced, eventually falling to 0 after X amount of time. These pools must remain active for X months to ensure applications built on top of Stargate can complete their migration to V2 before shutting down pathways. It’s important to note that Stargate V2 pools/pathways will be redundant to V1, so user experience will not be affected. -The Stargate V2 protocol should be deployed to all chains that already have been approved by the DAO, along with the associated assets. A list of these can be found in the Appendix2. There are two notable changes to this list compared to V1: -All chains that have recently deployed a native USDC token (Arbitrum, Optimism, Polygon, Base) will have this native token supported rather than the bridged USDC.e token. -Klaytn will be the first Hydra chain supported. Future Hydra chains will be deployed in coordination with the Stargate Foundation. -48 hours prior to the intended launch date/time, Stargate should open V2 liquidity pools for depositing, with incentives ramped up to launch. This will ensure there is sufficient liquidity on all pathways for Stargate V2 launch. -The first version of the AI Planning Module has been built. As V2 goes live, the AI module will be trained on Stargates rolling data over the previous period to optimise for two things: -Stargate should always be the cheapest bridge, -Stargate should maximise its protocol revenue. -Additional fees on Stargate V2 will continue to accrue to the Protocol/DAO as POL. -Building on LayerZero V2 means Stargate must choose it’s DVN configuration. Stargate should deploy its own DVN, managed by the Foundation, and use that as a required signer on every Stargate message. Stargate should also use the Nethermind DVN for additional security verification.