The Omni-Layer Underneath
The LayerZero thesis
If you've read any of my previous articles, then I've probably made it quite clear that we're living in a multi-chain world currently. While we live in such a world, it is vital that there's a way to connect all the various chains. To connect them all seamlessly, would create great value and further interoperability. If such a protocol were to exist, it would certainly need to be extremely secure, and further composability more so than its competitors.
While crypto natives continue to push for rapid blockchain ecosystem expansion, developers are tasked with overcoming the challenges that this expansion creates. As new blockchains continue to emerge, developers are provided with the freedom to run their smart-contract applications on the chain that suits their specific requirements - namely a specific combination of throughput, security, costs, and user popularity. However, a consequence of this expanding choice is the fragmentation of liquidity. As liquidity remains ‘finite’ in nature while ecosystems continue to expand, liquidity issues will only continue to grow.
So, what then is the solution?
Assuming a ‘multi-chain’ future, it certainly cannot be to limit the innovation of blockchains most prolific developers. Therefore, we can assume the issue lies not on the ‘ecosystem side’ of developmental expansion, but rather with the current liquidity architecture in blockchain technology. The solution? Shared liquidity between layer 1 blockchains and their applications - in other words, unified liquidity.
The second issue is the ability for protocols to be composable with one another. By that, we mean being able to share state. State sharing is the ability for one chain to make ‘calls’ to another chain and execute various tasks such as staking, voting and so on. State sharing is genuinely incredible for everything from unified liquidity to cross-chain swaps to increased security - as we've seen with the hype in regards to interchain accounts and security.
Preface; LayerZero is the underlying protocol that will enable many different applications to function with it as the base layer.
The future of blockchains:
A once contrarian viewpoint has now become commonplace among blockchain developers and users - “the future is a multi-chain world”. This phrase has been used extensively, but what does it actually mean from a development perspective?
To put it simply, all innovation in blockchain technology has come from a desire to solve current sociological or financial problems. In a ‘single-chain world’ (i.e., a single blockchain forms the base layer for all applications), all solutions to these problems are constrained to the limits of the underlying blockchain (i.e., security, throughput, etc.). In essence, this places a cap on the extent to which applications can evolve. In a ‘multi-chain world’, however, the most effective blockchain for the solution that the application intends to solve will be used. In other words, in a ‘multi-chain world’, multiple blockchains must continue to innovate in order to remain most effective for the applications it supports. As an added note, applications may even prefer to partition particular parts of their protocol onto multiple, separate chains.
An example in gaming might look something like this:
Gameplay occurs on [high throughput chain]
NFT-based rewards (and their associated marketplace) live on [low fees, high popularity chain]
(This design structure is already becoming popular in current and future gaming projects)
The issue, therefore, is how can these applications communicate efficiently between the separate chains that they live on.
LayerZero’s solution: omnichain interoperability through cross-chain bridging and messaging.
Most current bridge protocols are multi-chain, so what does it mean when LayerZero touts that it is capable of Omnichain bridging?
Omnichain refers to the fact that the LayerZero solution allows for more than 2 chains to cross-chain communicate simultaneously. In current bridge solutions, most cross-chain messaging would happen between two different chains. However, with LayerZero omnichain messaging becomes possible through the usage of relayers and oracles.
What is LayerZero?
LayerZero is an omnichain interoperability protocol. Its mission is to connect every contract on every chain to every contract on every other chain - pure interoperability.
A common question often arises here - so is LayerZero like a bridge?
No. LayerZero is purely focused on allowing interoperable on-chain generic messaging between user applications on separate chains. Bridges (each with potentially different designs for asset transfer) can then be built on top of LayerZero and will utilize its underlying messaging capability. We will discuss potential use cases for generic messaging in a later section. For now, let’s focus on how LayerZero approaches cross-chain messaging.
Let's first dissect the current approaches to cross-chain messaging before we expand upon LayerZero’s novel approach:
Middle chain approach:
This approach requires a ‘middle chain’ to receive, validate, and forward messages between chains such as Gravity or Axelar for example. Therefore, you are relying on this chain to perform your validation and trust its consensus. The middle chain has full signing authority to write its own transactions to destination chains, and these destination chains trust these transactions implicitly.
The obvious concern here is the potential for exploits/attacks. If the middle chain consensus is exploited, all liquidity on all paired networks can be stolen almost immediately. Considering the need to secure billions of dollars, this middle chain will inevitably become a key point of failure for future attacks.
Important to note, the middle chain approach is typically significantly cheaper than other solutions.
On-chain light node:
On-chain light nodes receive and validate every block header for each pairwise chain. To put it simply, you take the entire sequential history of block headers and store them on the opposite chain (and vice versa). Then, transaction proofs containing messages are forwarded and validated on-chain against the block headers.
This is the most secure approach to transmitting messages between chains. However, it is also the most expensive solution.
So how does LayerZero’s unique ‘Ultra Light Node’ approach differ?
Ultra light node:
The Ultra Light Node (ULN) approach from LayerZero Labs claims to reduce costs (i.e., closer to that of middle chains) while maintaining the high security of a light node.
How does it do this?
This is achieved by performing the same validation as an on-chain light node; but instead of keeping all block headers sequentially, block headers are instead received on-demand by decentralized oracles such as Chainlink.
Two separate parties are required to independently relay information from the source chain to the destination chain:
The Oracle (i.e., Chainlink, Band, etc.), which relays generic block information like the block header.
The Relayer, which relays transaction proofs against the relayed information by the Oracle.
Outcomes and their implications: Let's take a look at the basic security-specific outcomes that can occur between the two parties (i.e., Oracle and Relayer) within the Ultra Light Node architectural design.
Both parties are honest: If both the Oracle and the Relayer are honest, the transaction is validated on-chain and forwarded to the destination application.
Oracle honest, Relayer dishonest: Transaction fails to validate.
Relayer honest, Oracle dishonest: Transaction fails to validate.
Both parties are dishonest: This is the only scenario where exploitation can occur. This requires both the Oracle and Relayer to be acting in malicious collusion with one another. However, this is very unlikely to occur - and if in the unlikely scenario that it does occur, the exploit is limited in the extent of its damaging capabilities. This is for two reasons:
If, for example, you choose Chainlink as your oracle. For malicious action to occur, it requires both the Relayer and the Chainlink Decentralised Oracle Network to be exploited. In other words, even if the Relayer is acting with malicious intent, it only reduces the security to that of the Oracle (i.e., Chainlink).
Even in the situation where an Oracle (i.e., Oracle ‘A’) is in direct collusion with a Relayer (i.e., Relayer ‘A’), all risk is positioned only within the Oracle A - Relayer A pairing. In other words, anyone using Oracle ‘B-Z’ or Relayer ‘B-Z’ (or relaying their own transactions) are unaffected. However, if the A-A pairing is more extensive, more problems could arise.
This compartmentalization of risk is, therefore, an attractive property when compared to current middle chain solutions. Important to note, this also means that any application can decide to rely on their own transaction proofs (i.e., as the Relayer) and maintain total control of their own security.
To summarize, LayerZero’s Ultra Light Node approach will be more expensive than middle chain solutions (as LayerZero performs validation of the transaction directly on-chain) but will benefit from extreme fragmentation of risk and no central point of failure (i.e., high security).
What are the use cases that LayerZero provides?
People might confuse LayerZero with a protocol that only allows for cross-chain asset transfers (i.e., bridging assets across chains). However, it is much more than that. LayerZero’s general approach to data messaging actually provides a much wider range of potential use cases. In essence, any message or shared state that you require between two separate chains can be unified across LayerZero.
Here are a few example use cases discussed by Bryan Pellegrino (Co-founder and CEO at LayerZero Labs) in a recent Delphi Podcast:
Currently, if a single application is built on multiple chains, it is difficult to sync the state of these applications with each other. For example, SushiSwap exists on twelve separate chains. To sync state with their main Ethereum instance, code is required for each associated bridge (i.e., Wormhole, Avalanche Bridge, etc.). Furthermore, if SushiSwap ever decided to expand to a new ecosystem, more unique code would be required. LayerZero allows a single interface and code base for all cross-chain pairs, greatly simplifying the developer and user experience - comparable to Interchain Accounts on Cosmos.
Unified liquidity bridge:
In the current system, bridges compete to attract liquidity providers (LPs) to use their services. This has the effect of fragmenting the finitely available liquidity between bridges and their individual pairwise pools. For example, if you wanted to connect a chain with multiple other chains, a massive amount of liquidity is required to make using each pairwise pool a decent user experience. This is capital inefficient.
LayerZero changes this - it allows a single pool of liquidity tied to all connected chains (but with liquidity on various chains), with guaranteed finality of asset transfers on the source chain. This means that when a user makes any asset transfer between two chains, they are guaranteed the asset on the destination chain. Additionally, LP providers receive fees from all transactions to the destination chain, irrespective of the source chain it was received from.
Cross-chain lending and borrowing:
Let’s use an example to highlight the benefit of lending/borrowing using LayerZero:
Let’s say you have ETH on Ethereum and want to participate in a farm on Avalanche, here are the current steps required:
Lend ETH on Ethereum
Borrow against your collateralized ETH
Bridge to Avalanche (fee)
Swap to AVAX (fee - requires already owning AVAX)
Enter farming opportunity
Swap from farm token to the native asset (fee)
Bridge back to Ethereum (fee)
Repay the loan on Ethereum
Take back collateral
Now compare with LayerZero:
Lend ETH on Ethereum
Borrow directly in AVAX on Avalanche
Enter farming opportunity
Repay the loan on Avalanche
Collateral is released on Ethereum
Put simply, LayerZero provides a far simpler and cheaper user experience.
Currently, swapping from an asset on one chain to another asset on a different chain can be inconvenient for the user, especially between assets with limited pairs. In most cases, this also requires the user to already own the native asset of the destination chain (or go externally to acquire it) to execute swaps.
With LayerZero, cross-chain swaps only require a single transaction on the source chain. For example, a user will be able to swap from ETH on Ethereum to SOL on Solana in a single transaction from the source chain (i.e., Ethereum) without needing any SOL on Solana to execute the swap.
Multi-chain yield aggregator:
Current yield aggregators usually operate within a single ecosystem. Therefore, a key weakness of these aggregators is the inability to take advantage of lucrative farming opportunities on different chains. Considering the exponential expansion of blockchain ecosystems, it is vital that yield aggregators can take advantage of newly arising opportunities without having to be built on top of a separate chain. LayerZero’s architecture is perfectly placed to take advantage of this current blockchain drawback. Additionally, multi-chain yield aggregators provide beneficial network effects to the ecosystems they connect to - such as reducing market inefficiencies (i.e., a form of arbitrage) and increasing liquidity (i.e., enhanced user experience).
This means that Layerzero gives you the ability to seamlessly bundle complex transactions together into a single one: unstake, swap, bridge, swap, stake from one protocol to another anywhere supported. There's even the added possibility for dApps to run their own relayer/oracle and have control over their own security.
Will LayerZero have a token in the future?
The answer is most likely yes. Although we've seen several people from their team come out and say that it won't happen for a while, but in all likelihood, it will happen eventually. Also, check out the contracts of LayerZero:
LayerZero vs IBC
One of the other super popular ways of relaying data and making complex transactions simpler is IBC. IBC is about to get a lot more interested down the line with Interchain Accounts (check my Twitter thread on them) as well, so how do the two compare?
Let's first describe what is needed for IBC to function:
For direct IBC you need a few things: fast finality and state inclusion proofs that both counterparties can verify. However, you can still use IBC without using it directly, through a bridge like Gravity/Axelar and others that has their own validator sets, fast finality and state verifiability.
So how is IBC different? How it differs from normal bridging solutions is that it uses the counterparty’s validator set and not an additional one. Which means it relies on both chains. IBC is, as a result, a general framework for blockchain interoperability and can allow for complex composability. IBC works through a networking specification that can work across all chains with ICS. ICSs are basically module specifications for IBC transactions between chains. It enables interoperability by enabling chains to scale horizontally by spawning their own validator sets and their own replicated state machines fit for their application and communicating with other chains over IBC.
Then how about LayerZero?
LayerZero can work seamlessly with transactions of both deterministic and probabilistic (PoW) finality chains. In the latter case, the oracle would act as the agent that enforces the necessary finality threshold, however, some danger exists here as it isn't real deterministic finality. However, IBC only works directly with deterministic (fast finality) chains, unless a middle chain solution or similar is being used. Although, because LayerZero uses both Oracles and Relayers then it is only as secure as the Oracle being used. Although, we've covered further up how this is compartmentalized.
LayerZero could possibly be more expensive than bridges using technology like ZK light clients to handle proofs together with IBC. ZK light clients would similarly to LayerZero make verification of batches of block headers more efficient. There are also many that believe that IBC and as a result, ICS will become the standard for bridging in the future.
Furthermore, there’s a lot of the DeFi 1.0 and Ethereum community that are not necessarily that happy to use something like LayerZero because of who their backers are, and would instead prefer to use other bridges like Connext etc.
There's a lot of innovation happening from various protocols across the space, so even though LayerZero's functionalities look incredible at the moment, it doesn't mean it is the end-all to bridges and its functionalities beyond merely cross-chain assets. Although, for now, LayerZero is certainly innovative beyond any other current bridging/interchain shared state services.
What changes in an omnichain blockchain future?
Perhaps the most interesting side-effect of a truly interoperable blockchain future is the indirect effect this may have on other Layer 1 blockchains. For example, if applications can partition their protocol to chains that specifically suit their needs, blockchains may become inclined to specialize based on their greatest (or most lucrative) attributes. If, for example, developers continue to choose a specific high throughput blockchain over others, what does this mean for other blockchains? Perhaps they may specialize in another application requirement (such as security, costs, etc.). For example, monolithic blockchain designs (i.e., where a single blockchain attempts to provide solutions to scalability, consensus, and data availability) may become redundant. Modular blockchain designs or blockchains that focus on enhancing a specific desirable attribute seem poised to benefit the most from approaches to cross-chain messaging.
Preface: Stargate and the STG token are not the same entity as LayerZero, but is rather the first dApp to be released on top of the LayerZero protocol.
Stargate will be the first project based entirely on the LayerZero protocol. The best way to describe the concept is - multichain single-sided stablecoin curve pools. This means that, let's say you're swapping USDC from ETH → Avax you would let StarGate handle ETH USDC Eth Pool → USDC Avax pool in one transaction. This allows you to bridge value extremely efficiently. The pool arbitrage hunters would then rebalance the USDC pools when they deviate from the targeted balance.
So in more technical terms, Stargate is basically a composable native asset bridge with unified liquidity and fast finality built with the LayerZero protocol.
Stargate aims to be the first bridge to solve what we call the bridging trilemma, so let's take a look at what that trilemma actually is:
There are three main dilemmas to solve when you're trying to create a bridge, these are instant finality, unified liquidity, native assets on the destination chain. This means you want to receive the desired funds, on the destination chain, immediately when a transaction is successful. Also, having access to a single liquidity pool between several chains (ala multichain curve in one pool). As well as the desired asset on the destination chain.
By being able to do all three you allow for the ability to do much more than just swap a certain asset. Stargate could for example allow you to swap any asset between any chain in a single window - that's pretty incredible UX. This is still early on, and for now, most of the functionalities are simple omnichain stablecoin transfers, but the possibility for more is there.
On what chains will Stargate be available?
It will be going live on Ethereum, Avalanche, Polygon, BNB Chain, Fantom, Arbitrum and Optimism, and in 6–to 8 weeks other chains such as Solana, Terra, Cosmos Hub and Osmosis.
LPs on Stargate
Users can add liquidity to token-chain pools (i.e., USDC-Ethereum) and receive stablecoin rewards for every transfer, as well as farm their LP tokens in exchange for STG rewards
Stargate makes use of a unique algorithm known as Delta (Δ). It is basically an algorithm for keeping track of pools across chains. LPs will be able to collect fees from all connected chains, which means that if you're LPing stablecoins on Ethereum or Avalanche you would collect fees from all incoming swaps from other chains to those chains. Also, LPs will not be penalized for negative flow, rather the swappers of coins will.
That penalty is then saved in a reward pool which is used to incentivize arbitrage hunters to close the gap in the balance, which as we've seen with other arbitrage like systems, works quite well.
Tokenomics - STG
As we've made quite clear previously tokenomics often make or break the longevity of a protocol, so let's take a look at the tokenomics of STG - Stargate's native governance token.
At launch 1B STG has been minted, and this supply is finite. The allocations are as such:
The team and investors have a 1-year full lockup with a 2 year linear unlock afterwards. 15% will be allocated to auction purchasers and for the STG-USDC pool on Curve. While 16% will be sold in bonding curves on various chains.
Furthermore, 2.11% will be used for the initial emissions program to cater to LPers. Also, 1.55% will be added as liquidity to various DEXs on a wide variety of chains. That leaves around 30% for community incentives etcetera.
This is honestly a relatively decent allocation compared to many other protocols. However, I imagine a lot of that has to do with the fact, that the investors are happy to receive fewer STG tokens, and rather wait for the big payday when the ZRO token launches. If we assume that the investors have signed on to receive both the STG tokens and also the ZRO token. Why do we think that? Because at the valuation that LayerZero received, doing an auction and bonding pools for a token at a much lower valuation than the one it received from investors makes no sense. So therefore we can conclude that the investors are certainly going to be receiving ZRO tokens when that launches.
Now, with that said, the entire emission scheme is brilliant. Here we are specifically referring to the curve pool, as well as the bonding curves on various chains - which incentivises people to buy early since they will pay less.
There will most likely be three types of tokens at launch:
STG: Stargate Protocol Token
s*: Stargate LP Token
veSTG: Stargate voting power
Community members can participate in Stargate DAO governance with an account that has a balance of vote-escrowed STG (veSTG). Emissions to various pools will be decided through governance, much like we know from previous alliterations of various swapping protocols using pools. The longer you lock your STG tokens for, the more voting power you will receive.
Auction / LGE of STG
The launch of the STG token will happen in two phases.
Launch Auction which will help to bootstrap an STG-USDC pool on Ethereum
Bonding w/ protocol owned liquidity.
The first phase will be a 25M USDC auction in a first-come, first-serve function. This means that it is quite likely that the auction will be scooped up in one block. Although, these tokens will be locked for 1-year with a linear unlock over 6 months. By participating in the auction you receive aSTG which will represent that you took part in the auction, and will therefore receive veSTG that can be used in governance.
The second phase will consist of bonding curves which will help built liquidity of STG on various protocols. The allocations are seen below:
Ethereum - 40M STG
BNB - 22M STG
Avalanche - 27M STG
Polygon - 27M STG
Fantom - 22.5M STG
Arbitrum - 13M STG
Optimism - 8M STG
Now, if you're unsure of what a bonding curve is, then allow me to explain. A bonding curve is a contract wherein you continuously mint and burn tokens. So in this case you would buy into the contract, which then mints STG for you, as well as raises the price as more people buy. The bonding curve for STG will raise the prices as people buy into the contract on various chains, and will stay open for 72 hours or until STG reaches 3x of the opening bonding price (so 1.5$). Let's take a look at how a bonding curve can look so that you can get a better idea of how the auction will function:
Bonding curve models don’t have central authorities responsible for issuing the tokens. Rather, users can buy a project’s token through a smart contract. The cost to buy these tokens is defined by the supply and demand of the tokens. Unlike traditional models, the cost of these tokens increases as the supply increases
LayerZero has laid the groundwork for composability and interoperability. However, what remains to be seen now, is what kind of dApps will be built on top and what existing dApps will implement their protocol with their own oracles and relayers. Regardless, it's certainly an exciting time to be a multi-chainer.
This article is written in collaboration with my ‘intern’ @intern_mickey check us both out on Twitter - @0xrainandcoffee