Asem | LI.FI

Playing with blockchains' VMs

[Asem | LI.FI @el3osSH]

Today, https://t.co/kflkGmWPrI Intents goes live.

​What started as a small team is now part of something much bigger. Honestly, just grateful to be on this journey with the team (our internal catalysts).

[Asem | LI.FI @el3osSH]

We are live

[LI.FI @lifiprotocol]

Introducing LI.​FI Intents.

Infrastructure for apps, wallets, and neobanks to:
• Enable stablecoin payments
• Access real-world assets
• Tap into compliant onchain liquidity

Built for enterprises bringing financial products onchain.

[Asem | LI.FI @el3osSH]

I just published "Integrating Wormhole as a Cross-Chain Messaging Layer in Move VMs (Aptos and Sui) for EVM developers"

This is an intermediate level article

https://t.co/GYkacSWr71

[Jumper @jumperapp]

Jumper Earn and Portfolio are live.

You can now move, deploy, and manage capital within Jumper, your smart money app.

Jump Further: https://t.co/GFtm8YDGFg

[LI.FI @lifiprotocol]

2022: $327m

2023: $1.64bn

2024: $11.4bn

2025*: $36.9bn

[Asem | LI.FI @el3osSH]

I just published "Handling Tokens on Move VMs (SUI and Aptos) for EVM Developers ." This is a beginner friendly article. Hope it can help! https://t.co/7WYbFl9t8S

[Philipp Zentner | LI.FI @PhilippZentner]

One month left for https://t.co/DXycKl0iCc's intent system & solver market place to go live. It's gonna be 🔥

[LI.FI @lifiprotocol]

Today, we’re announcing our vision for LIFI 2.0

We see @lifiprotocol as core infrastructure that solves crypto’s deepest liquidity problems – at scale, across chains.

LIFI 2.0 combines aggregation with an intents protocol and native support for any interop token standard.

[Asem | LI.FI @el3osSH]

You know you've done something really good if you can make a 17:44 video about it

[Jim @jimchang]

some news: @CatalystSystem has been acquired by @lifiprotocol

i’ll be joining to lead their new intents team with the goal of connecting all chains (EVM and altVMs) truly permissionlessly — with my cofounder @stabiliseret and the Catalyst team coming along for the ride

i couldn’t find the words to fully articulate all the emotions i’ve felt during this process — so I figured i'd make a video instead lol

TLDR; i’m damn proud of what we’ve built and the team that we’ve assembled. thank you to my amazing team to getting us this far.

thank you to all of our customers who relied on Catalyst and CrossCats to fulfil their cross-chain needs these past 2 years. thank you to all who believed in me — who trusted in my vision for rollups back in 2022 and who continued to trust me about altVMs.

~~~

“if you want to go fast go alone, if you want to go far go together”

the stakes have never been higher. it’s become obvious that interoperablility is the single most important problem we face in crypto — a massive roadblock to breaking into the mainstream. the problem space is so large, and I knew we couldn’t do it alone.

so we made the hard decision to team up with @lifiprotocol to solve this issue — and I believe that we’re on the cusp of fixing the whole damn thing.

we’re building https://t.co/WAmNzwRlXP 2.0 — the most ambitious project I have ever been and will ever be a part of.

more details on it below. onwards 🫡

[Asem | LI.FI @el3osSH]

For future of cross-chain

[LI.FI @lifiprotocol]

Building the marketplace that solves crypto’s deepest liquidity problems requires expansion.

That is why we have acquired @CatalystSystem — to accelerate the future of intents and scale aggregation exponentially.

[Asem | LI.FI @el3osSH]

Fast, easy and cheap(cheapest). This is just the beginning!

[Asem | LI.FI @el3osSH]

@jimchang Will you be able to tolerate weather there? Summer is really tough in Dubai even for locals

[Jason Rodrigues @JasonRogues]

projects end. friendships end. but you know what doesn’t end? this mf devcon hallway

[Jim @jimchang]

look at my team dawg 🥹

[Asem | LI.FI @el3osSH]

@CatalystSystem Catalyst rules

[Asem | LI.FI @el3osSH]

@stabiliseret @CatalystSystem @jimchang I really should have paid more attention in the calculus II class

[Asem | LI.FI @el3osSH]

@jimchang @solana @movementlabsxyz @EclipseFND @ton_blockchain @fluentxyz lets go!!

[Jim @jimchang]

some news: going forward, my team is focusing 100% of our efforts on altVMs

that means building on @solana, @movementlabsxyz, @EclipseFND, @ton_blockchain, @fluentxyz & others that we’re bullish on

it also means much less building on Ethereum.

this was a hard decision for me and @stabiliseret. we both have built on Ethereum for many years and have spent the last 2 years building Catalyst on Ethereum

i, like many first time founders, thought that if we built something, then the users would come. but 8 months since Catalyst mainnet launch, it has achieved lukewarm adoption at best.

we tried to expand to new chains, but found it hard to attract liquidity. there seemed to be little demand in the market for another AMM.

i didn’t know what to do. nothing seemed to work, and i felt like a failure. it seemed like every other cross-chain protocol has been kicking ass. every week, a new volume ATH.

during ethcc, i was asked to be on a panel. it had all the big interop builders on it, with projects processing billions of dollars in volume.

i declined. i felt like I didn’t deserve to be there.

~~~~~~~~

confidence at an all time low, i went back to the drawing board. i re-read every book that I bought as a bright-eyed college kid dreaming of starting a business: the lean startup, zero to one, how google works, etc

i had ignored something that was so obvious, that EVERY book on entrepreneurship talked about — but I was too arrogant to heed, somehow thinking that crypto was different.

i needed to talk to users.

so i did. i asked everyone who would spare the time (you know who you are - THANK YOU!!), what was missing from cross-chain?

the takeaways were clear:

(1) bridging within EVM chains is crowded and has found its winners.
four projects do 90% of all volume. the rest of the 53(!!) bridges fight for the scraps.

(2) bridging within EVM chains is “good enough”, with each incremental innovation giving marginal returns.
thanks to @AcrossProtocol, @StargateFinance and @RelayProtocol, it now costs half a cent, and takes 2 seconds to bridge between EVM chains. what more can a user ask for?

(3) the vibes in EVM are off.
we were promised sovereign money. we were promised the world computer, the future of finance. instead, we got empty promises and the same copy-paste primitive again and again.

we’re tired, boss.

(4) in contrast, altVMs are bringing a new wave of hope
this one, i had to confirm with my own eyes.

i said gmove in the the @movementlabsxyz discord. i went to the @superteam bounty board. i chatted with the @SolanaFndn team, the @eclipsefnd team, and the @fuel_network team.

something was different there.

they were excited. they stood for something. believed in something.

new VMs bring new technologies that allow the next generation of builders to reimagine what’s possible onchain, things are not possible on evm.

for the first time in a long while, my old heart felt something that i hadn’t felt since DeFi Summer. i actually wanted to play these apps. Because they were fun.

only one problem stood in my way: getting on to these chains. which leads me to my last takeaway.

(5) people want access to altVMs, but they are hard as hell to get to.
in my mind, the story is clear.

altVMs will create a whole new design space. a whole new design space allows never-before-seen applications to be built. never-before-seen applications will bring in millions of mainstream users. millions of new users will result in billions of dollars of new tokens and yield.

only one thing stands in the way: how do we get there?

there’s no @jumperapp for altVMs. there’s no one product that opens the doors to all altVMs.

until today.

~~~~~~~~

we’re building a brand-new product: the only bridge built for altVMs.

our mission is to take you beyond Ethereum.

Movement, Solana, TON, @fuel_network, even Bitcoin — our goal is to make accessing them even easier than EVM chains today.

i can’t share too much right now, but here's what it’ll look like:
- incredibly simple. < 1 month to connect a new VMs
- best-in-market cross-chain UX (we absolutely cooked on this)
- competitive pricing and speed
- only one EVM connection: Base. we rely on smarter ppl than us (like @lifiprotocol @BungeeExchange and @SkipProtocol) to connect users to the rest of EVM Land

if you love this pivot, great! dm me, i’d love to show you what we’re building and partner.

if you hate this pivot, great too! let me know why I suck. for me, its better to stand for something (even if it turns out wrong) than to not stand for anything at all

gmove, gsvm, gblend and GMEOW 🫡

[monty @pizzamonty]

why are bridges gaslighting projects to adopt their cross-chain token standards?

as a builder, when chosing an interop provider you should keep in mind that:

- these standards are not interoperable with each other

- you have vendor lock in with the bridge you pick

[Alexander @stabiliseret]

Ever wondered what messaging protocols look like on-chain? Let’s explore @wormhole , @LayerZero_Core , and @hyperlane to discover how to send & receive cross-chain messages and what is required to make it happen.

Wormhole
The simplest messaging protocol with 1 massive contract that has been assigned the task of everything, fittingly called `Implementation.sol`. It implements 3 key features:
- A list of the current approved Guardians along with a governance structure.
- An endpoint that allows someone to send messages.
- And lastly, the logic to verify messages.

To send a message with Wormhole, first call `messageFee()` to get the fee. Then call `publishMessage(…)` to send the message. On `publishMessage` you specify an optional nonce, your message, and a consistencyLevel. `publishMessage` emits a message log and then returns a unique sequence number to you. Notice that you don’t specify a chain. This is because Wormhole messages are broadcast. A Wormhole message can be verified everywhere. It is the caller’s job to encode some kind of restricting logic.

Once the message is considered final as by the included consistency level – which can be set to anything from 1 confirmation to final – your message will get signed and becomes available to pickup in the gossip network. It can then be verified by calling `parseAndVerifyVM` on the destination chain, the signatures are extracted and compared against the hash of the message.

Notice that this implementation has no relaying logic or on-chain storage usage. It is pure: sending a message is done by emitting an event on their contract, and verifying it is done by comparing the configured guardians against the signatures. The best part about this structure is that if you wanted, you can ignore everything but the `publishMessage` call. You can copy `parseAndVerifyVM` into your own contract, choose your own relayers, implement your own relayer scheme. You can even implement `parseAndVerifyVM` on a chain not supported by Wormhole!

Hyperlane
As I have previously written, Hyperlane supports a wide range of verification pathways. As a result, their complexity can range from fairly simple to very complex. However, they have done a stellar job at abstracting a lot of this logic. For simplicity, let’s focus on their core product: Multisig ISM. ISM means Interchain Security Modules and is what Hyperlane uses to describe security models. This allows them to essentially collect all the other messaging protocols, which I have previously described as a Zoo. Instead of 1 big contract, logic is delegated to smaller contracts:
- `Mailbox.sol` is the main interface contract and implement handlers to handle message execution regardless of the security model.
- Various hooks are used to manage fees & relaying.
- External ISMs are used to verify the authenticity of messages.

Assuming you want to use default settings, sending a message requires calling `quoteDispatch(...)` to get the fee and then `dispatch()`. On this call you specify: the destination chain, the destination recipient, and the message. Optionally, you can also specify a hook like InterchainGasPaymaster to pay for relaying. Hyperlane allows for a significantly increased customization at the cost of simplicity, though at no point does it get out of hand. Additionally, it is expected that a system which has built in support to pay for relaying is slightly more complex than one without.

Hyperlane uses signed checkpoints to verify messages, designed such that any later signing checkpoint also signs previous checkpoints. Once a checkpoint has been signed, all message inside it and all previous messages can be verified. The Hyperlane Mailbox calls verify(...) on the ISM contract.

Since message verification happens outside the mailbox with no on-chain commitments, you can in theory call `ism.verify` yourself to avoid interacting with the Mailbox or even implement the associated logic yourself. Additionally, the destination field is only enforced in 1 line of code so if you wanted, you could in theory move the `process` (and/or the multisig ISM `verify`) logic to your contract and get the ability to broadcast messages like Wormhole. (Though you need to keep track of the validators yourself).

Config for hyperlane messaging is stored on the recipient, so it doesn’t suffer from an problem where you need to set new configs for every single support chain as you expand to new chains, since you can programmatically predict various config settings.

After the message is deemed final by validators, they will sign it and make it available to relayers. Unlike Wormhole, Hyperlane doesn’t have the concept of finality levels. That is because the economic security module assumes that all signed checkpoints are final otherwise validators can get slashed. Let’s also address the elephant in the room – final. Both Wormhole and Hyperlane allows dApps to set the confidence of inclusion to final. Final by Hyperlane is defined as: When validators deem that their economic security is not at risk of a reorg, where for Wormhole it is slightly more fluffy. However, abstracting confirmations & time into a single “final” is helpful for applications, since they can now delegate the concept of finality to messaging protocols that have spent more time to think about it. Kudos to Hyperlane and Wormhole.

LayerZero
Sending and receiving messages through LayerZero acts is more complicated than both Wormhole and Hyperlane. Considering I am guaranteed to get something wrong, I will focus on the highlights. LayerZero contains 2 main components:
- `EndpointV2.sol` is responsible for message flow: quoting, sending, verifying, and executing.
- Ultralight Nodes (ULNs) of which there are 2 types: Receive and Send.
- Additionally, DVNs are expected to implement a contract to quote the cost to submit message and for them to be paid.

Before we can begin sending messages with LayerZero, we may want to configure out dApp. LayerZero has a wide set of available configs, significantly more than both Wormhole and Hyperlane combined. You can configure: block confirmations, security threshold, custom receive & send libraries, executor, max message size, and DVN set. When sending the fee currency – LZ token or gas – can be configured. For each chain you are deployed on, you need to set the config for that chain specifically. Luckily, LZ does allow an array of configurations in a single call. However, once you add a new chain to your existing 20 chains, you need to configure that new chain for your 20 other deployments.

To send a message, you need to call `quote(...)` to get the fee estimation and then call `send(...)` with the fee. For both Wormhole & Hyperlane this fee doesn’t change very often (ignoring relayer fees), however, for LayerZero you need to pay DVNs (either LZ or — god forbid if you are deployed to many chains — your configured DVNs) to submit message validations on the remote chain. They do this by calling `verify(...)` on the receive library on the remote chain. Each and every message send with LZ needs to have every single DVN call `verify`.

Once the configured DVNs have all called `verify` (after your configured number of confirmations) the `verifiable(...)` function will return `true` for the message and the committer can call `verify` on the Endpoint. This deletes the proof inside the receive library and stores it in the endpoint. Then `lzReceive(...)` can be called which deletes the proof from the endpoint, increments a lazy nonce (to allow previously verified messages with lower nonces to be executed), and calls the receiver.

Unlike both Hyperlane and Wormhole, LayerZero has no concept of finality. They have some default confirmation recommendations, but that is it. Once the configured number of confirmations have been reached, DVNs will submit it.

Indeed, I am actually ignoring some details of LayerZero here: DVNs configs, gas price feeds, message configuration, message limits, allow lists, and message nonces & order. All of this adds up. LayerZero have so much on-chain logic – paying DVNs, DVNs submitting proofs, moving verifications from the receive library into the endpoint, calling verify and then lzReceive, paying the executor, and along the way quoting every single entity – and it uses a lot of gas. Based on our testing, sending a LayerZero sometimes costs twice that of the same Wormhole message. Using LayerZero instead of Wormhole for a @CatalystAMM swap — in its entirety — 40% more expensive.

Everything I have praised either Wormhole or Hyperlane for: simplicity, no on-chain message commits, flexible message verification, placing configuration inside the sender or recipient, ability to set finality levels instead of just confirmations, lightweight protocol, few important contracts, and relayer flexibility LayerZero doesn't have. Additionally, LayerZero contracts by themselves are significantly more complex to understand since they are spread across projects. LayerZero is spaghetti.