EVM and IBC tokens integration

Hello,

I would simply like to know if some people in the Jupiter team are working on integrating the NEAR-Staknet intent layer or IBC Solray to Jupiter to make EVM or IBC tokens tradable on Jupiter.

Thanks to the team for their work btw :slight_smile:

isn’t this already happening via https://sunriselayer.io/?

1 Like

I didn’t know about Sunrise. I researched what it is and… it’s quite different.

Sunrise is a L1 by itself. As far as understood, Sunrise won’t make you able to interact with smart contracts and other non-wallet elements outside of the network where the order comes from, so no possibility to place an Arbitrum token in an order book from a Solana account for example. Going through another L1 implies more protocol exploit surface, governance manipulation risk… all the risks linked to a new blockchain. And Sunrise rely on off-chain data to function so it also has this vulnerability.

With the (few) infos I got, Nolus IBC Solray seems to be the most secure, polyvalent… and efficient structure. But only between Solana and Cosmos IBC networks.
For the others something like NEAR intents would be required.

Sunrise looks quite limited from what I saw. It can receive tokens from an adress to its native LP and send tokens to another adress from its LP, but it doesn’t look to be able to transfer complex smart-contract logics. Or is it?

Btw, someone (probably a dev in the team) replied to me by PM that the team is working on the further integration of NEAR intents and IBC Solray.

Some tokens on Jupiter are already routed through NEAR intents layer, but only those on fast networks. Maybe it is not so easy to integrate something much slower than Solana in Jupiter…

As far as I know Sunrise are trying to be Omnichain Tokens (LayerZero) Omnichain Tokens - LayerZero only for Solana.

But you’ve been able to bring tokens onto Solana from various other blockchains, via Wormhole, for ages. A lot of the ETH on Solana is a Wormhole bridged token, and BONK has been multichain, via Wormhole, for ages.

MON is multichain via Wormhole.

Picasso was a thing for a (very) brief moment Picasso on Solana: Project Review, Programs, Token, Metrics | Solana Compass

There’s something to the liquidity that Solana has vs pretty much every other chain. So I guess the interchain thing is being able to fund raise on Solana with your token from another chain?

For example:

  • I launch a new chain on Celestia
  • I create an LST of the staking token
  • I bridge it to Solana to access the liquidity

I don’t know if that would technically work, but there’s heap of these other blockchain staking tokens out there that have decent sounding yields that are kinda linked to something productive and as SOL LST yields continue to drop maybe that makes these more appealing.

I just realized there is no need for ZK-proof verification for each trade with Sunrise, trades are executed like with a native token.
So Sunrise is the best solution… I suppose.

edit: this message comes chronologically after the one underneath

Do you mean controlling the staking and unstaking of tokens on other chains from Jupiter’s UI before trading them in Jupiter?

Sunrise would definitely help launch new networks by giving them access to Solana’s liquidity, but I was thinking about what Jupiter could get from cross-chain communication networks.

I realise that I didn’t consider the computational cost of signature verification. With IBC Solray, Solana network has to compute the verification of at least 2/3 of Nolus validators signatures. It’s worse than verifying Sunrise’s ZK-proofs. IBC Solray is probably not going to be used for real-time trading as I thought.
But ZK-proofs verification is also too heavy computationally for that.
I guess creating a L2 dedicated to Sunrise interactions would solve this issue, but Jupiter’s team is not going to build a whole new L2 just to trade through Sunrise / IBC Solray.

NEAR-itents seems to be the valid option for cross-chain real-time trading without traditional bridge.

But I don’t really know, I’m not a dev :sweat_smile:

1 Like

Probably not the staking/unstaking part. I’m not a dev either, but I assume that part lives back on the native chain. Much like you see decentralised wrapped BTC like sBTC (Stacks), strkBTC (Starkware) etc.. lock and unlock the underlying BTC directly on the Bitcoin L1, whilst the wrapped token is able to be freely used on other chains.

It’s a good call out about the fees. Whilst you’re right about the trading aspect not being viable, I wouldn’t discount this because of the fees involved. In fact I think it’s an opportunity.

To go back to wrapped BTC as an example, a lot of the current innovation in BTCfi is around using the fees associated with securing native BTC inside a wrapper as yield. Threshold (tBTC), Stacks (sBTC), Lombard (LBTC), Babylon (whitelabel service for wrapped/staked BTC products) all follow a basic model of paying fees to lock/unlock and transfer and those fees become the ‘yield’.
I use these as an example because they’re quite complex (though many are quite elegant at the same time) due the fact BTC is very hard, technically speaking, to work with and has no native yield attached.

The opportunity, in my mind, would be to port tokens with existing yield attached (e.g., stNEAR, stATOM, stTIA, slisBNB, stETH etc…) to Solana and using the lock/unlock & transfer fees as a form of boosted yield. So you get all advantages of trading on Solana (low fees, great trading infra, lots of users, large potential liquidity) with the underlying yield from the native chain. As you can always redeem the wrapped receipt for the native token (like you can redeem stablecoins for the underlying fiat) then that solves a lot of the peg problem as as soon as the Solana version trades far enough below the native chain version people will be able to arbitrage that opportunity… which will further boost the Solana version’s yield due to the increase in transfer & lock/unlock fees.

I only see this really working (if it even technically is possible that is) with LSTs due to the native yield already being handled for you. The demand side is less complicated: Most crypto (and tradfi for that matter) only want to buy and hold. If you can also offer them yield then it’s even better.

But I’m just spit balling at the end of the day.

I do agree NEAR intents are very good at cross-chain communication having used them a bit here and there. Maybe they are, as you say, all the solution anyone needs.

2 Likes

Ok I understand now what you mean!

Yes, that would be great to be able to trade on Solana LST tokens from other chains. Sunrise could bridge LST tokens, but afaik that has to be decided by the people in Wormhole Labs.

I also prefer keeping tokens on their native chains because I can earn yield by staking them.

The ideal scenario would be to have a tool that make anyone able to bridge an arbitrary token from another chain into Solana and trade it effectively.

1 Like