Enter the Stargate (Omnichain Strategy)

Proposals
#1

Co-Authored by Tangle and 0xMaki

TL;DR:
Implement Stargate Omnichain native asset bridge into Sushi to allow for Omnichain Token Swaps.

Abstract:
Sushi has been a first mover towards a multi-chain or cross-chain protocol, and is currently deployed across 16 different networks and counting.

It is currently extremely time consuming and a negative experience to swap native chain tokens against non-native ones e.g. BNB → AVAX → ETH

This currently requires multiple steps with various 3rd parties.

Months ago, a video was created by Primo which shows a swap and transfer across networks to a different asset. This shows a side by side comparison of swapping and using a 3rd party bridge, and another while remaining inside the same UI. https://www.youtube.com/watch?v=JFnF1dgbF00

Solution:
Stargate is the first User Application built on top of LayerZero, and is an Omnichain asset transfer protocol that leverages the Delta Δ Algorithm to solve the bridging trilemma:

  • Instant Guaranteed Finality: the guarantee of funds on the destination chain when a transaction is successfully committed on the source chain.
  • Unified Liquidity: the shared access of a single liquidity pool between multiple chains.
  • Native Assets: the user-desired assets (native or most liquid synthetic) on the destination chain.

Developer Docs : Stargate - Stargate

We propose to have Sushi integrate Stargate to facilitate Omnichain native asset swaps and transfers between networks. This will help unlock the power of Sushi by allowing users to move freely between assets and networks.

  • Integration to enable better UX for swaps across multiple networks.
  • Deploy supported assets in BentoBox as a strategy (LP on Stargate to earn additional yield for the users assets)
  • Receive Partner kickback to Treasury
  • Maximize volume on Sushi pools

Integration will support 7 networks at launch and will continue to expand to where Sushi has meaningful TVL.

  • Ethereum

  • Polygon

  • Avalanche

  • BSC

  • Fantom

  • Arbitrum

  • Optimism

Another interesting feature of Stargate is the ability to check and see if the user has enough native gas on the destination chain. If the user does not, it can take some of the users native source gas, and drop some native gas to the user on the destination chain so they can now transact with their assets. This eliminates the pains and struggles of trying to find a gas faucet, requesting gas from another user, or trusting that a User Application will send you enough gas after transferring.

Stargate has committed to help with resources for Sushi to help make this as light of a lift for the Sushi Team as possible. Stargate will help make this integration happen at no cost to the Sushi Community. Hurts nobody. Helps everyone.

Learn more about Stargate here:
[https://Stargate.Finance]
[https://twitter.com/stargatefinance]
Stargate [Discord]

Learn more about LayerZero here:
[https://layerzero.network]
[https://twitter.com/LayerZero_Labs]
[https://layerzero.network/discord]


For
Unlock a new feature in DeFi to make Sushi remain one of the top innovators in the space.

Against
Too much work and effort with not enough benefit.

  • Yes - Embrace the Omnichain Future

  • No - This is fine

0 voters

8 Likes
#2

its a good idea conceptually. but the optics are not great

tangle and maki are involved in both projects.

clearly stargate isn’t being chosen b/c of the tech. its b/c there is a relationship here. no other solution is “really” being considered, nor will it.

2 Likes
#3

This will be a game-changer going forward. :fire:

2 Likes
#5

Just want to make myself available here if anybody has any questions on technicals or broad questions about LayerZero or Stargate. I’ve written extensively on this exact use case for months and made the demo with exactly this in mind. I’d say this is a great starting point for what this might look like and my broad thoughts on it:

So many amazing ux flows that Sushi can create via this, extremely excited to see the current Sushiswaps connected and more of a single entity vs distributed outposts. Pumped!

2 Likes
#6

Curious to know how cross-chain swaps would handle the time delay in bridging (currently takes around 5mins or so to bridge from my experience).

For example if there is only eth-usdc (on ethereum) and usdc-avax (on avalanche) liquidity available on sushi a user wants to swap ETH for AVAX. Is process :
ETH → USDC (ETH) (swap) → stargate (bridge) → USDC (AVAX) → AVAX (swap)
If so, wouldnt the delay in bridging make it harder to lock in a price during times of volatility?

I guess an alternative would be to send the user avax on destination chain before the bridged funds arrive and then the protocol takes the USDC whenever it does show up (and hence locking in a price at time of transaction on source chain). This would require a way to transmit the event (swap tx from user) from source chain to destination chain in an efficient manner (faster than the time it takes to bridge) otherwise it doesnt solve the original issue. Could Layerzero be used here? What would the delays look like for such a scenario

1 Like
#7

So it’s a great question and definitely something to be considered. Latency at the source chain matters, and it’s different for each chain. With Stargate (which will be the primary driver of latency, Sushi only requires 1 block on each chain) it’s about probabilistic finality which is just another measure of security.

Right now leave Ethereum is set to 15 blocks (3m15s) and leaving Avalanche is only a couple of seconds. So going ETH → Avax would take just over 3 minutes which might mean you have to set your slippage slightly higher but the tradeoff is you get to go to bundle the entire transaction bundle into 1 single click, so rather than the current flow of:

Swap ETH/USDC
leave Sushiswap and find some external bridge to bridge USDC to avalanche (usually end in wrapped synthetic)
hopefully make it back to sushiswap and execute USDC → AVAX

In order to do this the user need to click a solid 30-40 times, sign multiple transactions, and have both ETH and AVAX in their wallet. Quite the hassle for a casual user.

Replace that with:

User signs 1 tx, entire flow is executed, AVAX is dropped in their wallet on the destination chain

see the demo I linked for the visceral representation of this

Also obviously when leaving almost any other chain but ETH it will be much much faster, AVAX → ETH will only be a matter of seconds + the additional benefit of being able to submit to flashbots/manifold/some other MEV suppression service which is an added benefit in getting efficient execution

edit: (also A+ hand of midas avatar :D)

1 Like
#8

Agree with @katsuSando. Both tangle and maki are biased, so the market analysis is needed to pick interoperability solutions that work best for the Sushi ecosystem.

I saw 1inch and deBridge launched deSwap last week that enables cross-chain swaps between arbitrary assets in a single transaction. You can check the app here and from my experience, it’s pretty cool and solves all the problems listed: app.debridge.finance

I wonder how you guys different from deSwap and what’s the competitive advantage. Should we ask 1inch/deBridge teams to prepare a similar proposal to weigh all the pros and cons of each solution?
Wormhole is another good candidate and I’m keen to hear how Stargate is different

1 Like
#9

Im not against using these guys over others given their intimate knowledge of the platform already, assuming the offering is on par with the others

Id vote for

1 Like
#10

Deswap introduces a Blockchain in between with its own consensus mechanism and security tradeoffs. Wormhole is centralized and works with wrapped assets.

Stargate avoids both a consensus layer and wrapped assets.

4 Likes
#11

0xmaki studied all available Omnichain solutions and decided he wanted to get involved with Layer Zero and Stargate because it was the best tech. Of course he wants Sushiswap to integrate it because he is interested in its long term survival.

3 Likes
#12

Always thought it would be great to have a convenient bridge for the DEX that could allow easy accessibility between all the chains without people having to jump around and play guesswork with what particular assets they have to move where. In the case of Layer Zero, that’s a real game changer, so I would dare say yes to this one.

3 Likes
#13

I wasn’t bullish on the idea of integrating any bridge just cus it always seemed like such an attack vector.
But I like the Layer Zero solution, from what I gather it is quite different.
No middle chain, managing security on an application level, ability to isolate risk to oracle and relay.
I like that Stargate is facilitating native swaps with no minting or burning, as that was always a main concern.

I love that this would be more of an ecosystem partnership with deep roots. Over just an integration.

Seems like it would make a great Bentobox strategy, and that has just seen a boost in utilisation with the role out of the Aave strats.
So this could assist in realising that vision of the yield bearing vault, while still keeping it comparatively low risk.

Also appreciate that this wouldn’t require so much work from core team to implement.

4 Likes
#14

I was so focused on the security concern, the responsibility bridging brings. I did not give enough respect to the optics and possible conflict of interest.
For sure also because it’s tangle and maki, so I am bias. Is a reasonable concern.

But I also remember one of the things I admired when I found Sushi, was Maki saying they don’t just do business deals. They have to be partnerships with likeminded protocols.
This feels like that, with both of them involved. I would rather have a direct line to people who give a shit and feel some responsibility if difficulties do arise.

If it wasn’t them I’d feel different, but as this isn’t setting a president for governance, assessing case by case the actors involved seems reasonable.

I do think it would benefit everyone to clarify guidelines going forward, on staff split between projects, suggesting partnerships etc, so it does not turn into a cabal.

1 Like
#15

If I understand correct, the flow contains 2 swaps. Both of those swaps need enough liquidity, otherwise you will get a bad trade price. Is it possible to see in advance at what price the cross-chain swap will execute?

#16

Lots to unpack here - as well as massive potential for the Sushi end-user.

The networks you outline above attract the most users and have strong overlap - I am aligned in the selection here.

A few questions:

  1. Stargate is built by Layer-Zero? Am I correct in my understanding?

Seeing a few mentions about Stargate on a range of forums this AM.

  1. The bridge would not be owned nor built by Sushi - it is simply a UI integration?

If so this relieves some concerns as expressed by @maka. Sushi owning it would make them culpable for any possible exploits or hacks - yet I acknowledge the crossover between teams and risk there.

  1. Has this fee been discussed? Is it fixed or variable?

Look forward to digging in deeper here.

1 Like
#17

@fig @jn_r that’s right, so to be clear Stargate is built by LayerZero Labs and leverages LayerZero. What would happen on a per-swap basis is something like this:

ETH/USDC (swap on Sushi, atomic, exactly how Sushi works now)
USDC routes over Stargate (i.e. add on Stargate(Ethereum), remove on Stargate(Polygon)
all messaging risk / risk to liquidity / etc lives here in Stargate
USDC/X (swap on Sushi, atomic, exactly how Sushi works now)

So the integration on the Sushi end requires:

0 changes to core protocol
0 liquidity to put up / 0 liquidity to incentivize
0 risk to existing Sushi LP / risk at the messaging layer

It’s extremely simple to integrate (wrap sushiswap’s existing contracts + compose Stargate) and an update to the UI.

Obviously there are plenty of eventual optimizations that can be done in terms of pathing/routing, but overall this gives Sushiswap a very easy way to leverage the fact it has been so progressive in deploying multichain and become one of the first user protocols to really harness that and harness it well.

2 Likes
#18

Straight up HELL YES for me

12 Likes
#19

But this requires trust in the bridge provider, not? i.e. you can not just send from chain x to chain y just like that, there is no on-chain guarantee on the sender-chain that something on the other chain will happen. Just trying to understand how it works and what the risks are …

n.b. I like the added value this would give to Sushi in concept, the risk is decoupled from other sushi functionality so as long as people know and understand the (if any) (liquidity)risk involved when using the bridge, I guess I would be ok with it…But still would like to see it minimized

#20

can you expand on this? wormhole requires a multisig from a supermajority of its 19 guardians, while layer zero provides the singular relayer that operates the bridge. to me layer zero sounds more centralised, they run the relayer, and the bridge relies on the relayer

#21

I’m not sure I can post images so I’m going to pull a conversation where I walked through this on Discord

" 1. great question. Light nodes are great, you take the entire history of block headers (sequentially) and store them on the other chain, and vice versa. Then with this history you can submit a tx proof against it and easily confirm validity. The problem? Writes on blockchains are notoriously expensive, $10s of millions per day per pairwise chain to do something like this on Ethereum so it’s not something that’s viable in the current environment.

Middlechains, however fundamentally the tradeoff you are making is that you are relying on this chain to perform your validation and trust it’s consensus. It has full signing authority to write it’s own transactions out to destination chains and those chains trust it implicitly. Typically if this consensus can be attacked/exploited even for a short matter of blocks it has the ability effectively take all liquidity on all paired networks almost instantly (This was seen recently with the PolyNetwork hack). So you have these networks that typically are something like 10-30 validating nodes and anywhere from 50-300m bonded value meant to secure 10s of billions of dollars of value on connected chains… while also aspiring to become as decentralized as possible. These systems are some of the single most attractive honeypots in all of crypto because unlike reorging an entire chain typically a viable attack requires much fewer resources and almost immediately results in the ability to then write those transactions out to the paired networks and say “Hey, all of that liquidity belongs to me”

So, now we have an Ultra Light Node which is basically taking a single block header and streaming it on demand. 2 parties in this process, the Oracle (Chainlink, Band, etc.) responsible for passing the block header and the Relayer responsible for forwarding the transaction proof. The outcomes here are fairly straightforward, but the implications are really interesting. The outcomes are basically (honest, honest), (honest, dishonest), (dishonest, honest), (dishonest, dishonest). In the case that both the relayer and the oracle are honest the transaction is validated on-chain and forwarded to the destination application. In the case Oracle is honest and Relayer is dishonest – fails to validate, Oracle dishonest and Relayer is honest – fails to validate. So now the only case for malaction is the case in which both the Oracle and the Relayer are in active malicious collusion together. Now what this means is that first off say for example you choose Chainlink for your oracle. That means any malicious action is first predicated on defeating the Chainlink DON, meaning that in the worst case (the case the Relayer is fully colluding with the oracle) it still reduces to being as secure as the Oracle. The Second thing is that even in the extreme case where you do have this malicious Oracle who is colluding directly with a Relayer (say Relayer A). All risk is 100% siloed to the Oracle - Relayer A pairing. Anybody using Relayer B-Z, unaffected. Anybody relaying their own tx, unaffected. Anybody using Oracle B-Z, unaffected. This sharding of risk is a super super attractive property when compared to current middlechain solutions. Now lastly, what this means is that any User Application can always relay their own transaction proofs and have 100% control over their security. Even in the case of a malicious oracle, as long as they are not actively colluding maliciously with the oracle against themselves they remain completely unaffected.

So, in summary the tradeoffs are – We will be slightly more expensive than a middlechain (since we’re performing validation of the tx directly on-chain) but the benefit is no catestrophic central point of failure and the extreme fragmentation of risk

all of that is just on the security properties though so that’s ULN specific, many of LayerZero most interesting benefits lie in what can be built and how easily it can be built across all L1, L2, EVM, non-EVM, etc."

2 Likes