Zetachain Part 1: A Competitive Landscape of Blockchain Bridges

ZetaChain – Architecture & Key Features

Architecture

At a high level, the way we would explain ZetaChain is “THORChain with smart contracts” or “Axelar with the EVM on it”. Those are the two closest architectures. Zeta can offer many of the cross-chain messaging capabilities as the others, but it’s unique in its support for omnichain EVM contracts. We believe that this part of Zeta’s architecture is the most compelling and the one to focus on vs cross-chain messaging that just uses Zeta in the middle. Zeta should be the place users stay, not merely a tool they use to pass through. The upside for Zeta is with its omnichain EVM smart contracts.

ZetaChain is a PoS Blockchain built with the Cosmos SDK and CometBFT consensus. Zeta has their own L1 and token ZETA which is used to pay for gas on ZetaChain as well as staking. Like THORChain, Zeta uses their ZETA token as a routing token for cross-chain messaging, although the entire protocol does not depend on ZETA LPs to the same extent as THORChain, it does rely on it much more than a protocol like Axelar. We will discuss this aspect more in the next section. First, the overall architecture.

Below is the high-level architecture, with nodes running both the ZetaCore and ZetaClient software. ZetaCore is the client for producing blocks and running the L1, similar to any other PoS blockchains. ZetaClient is responsible for the cross-chain actions such as observing and signing events. Zeta’s nodes perform three key functions: validation, observation & threshold signing. They’re three distinct roles but are all run by each node operator.

• Validators: Standard CometBFT validators, they stake ZETA and vote on blocks like any other PoS chain
• Observers: Split into sequencers and verifiers. A sequencer listens to and sends an event from an external chain to the verifiers who vote and come to consensus on it. The sequencer role is just needed for liveness, and any node can sequence a transaction. Observers need to run full nodes of the external chains. This makes running a Zeta node more resource intensive than a standard chain, and is similar to THORChain. This is one of the reasons why THORChain has not added support for Solana.
• Signers: ECDSA/EdDSA keys are shared between nodes such that only a supermajority (2/3) can sign transactions on external chains. The signers are how Zeta custodies assets and signs messages on external chains. On smart contract platforms like Ethereum these can be used to interact with smart contracts and custody assets and to custody assets on non-smart contract chains like Bitcoin and Dogecoin. A chart of signing from the whitepaper is below.

This architecture enables two key features: Omnichain smart contracts and cross-chain message passing. Omnichain smart contracts are smart contracts on the zEVM (Zeta EVM). Cross-Chain Message passing, on the other hand, purely uses Zeta and the zEVM as a relayer of messages and of the ZETA token. We will explain CCMP first and why we think this should not be Zeta’s main focus. We will then discuss Zeta’s competitive advantage with the Omnichain smart contracts.

Cross-Chain Message Passing

CCMP is used to route messages to/from other chains by using ZetaChain in the middle. Numerous other protocols like LayerZero, Axelar, IBC, Chainlink CCIP and to an extent THORChain all compete in this domain. For ZetaChain, their cross-chain messaging protocol is facilitated by the use of their native token ZETA, which is fundamentally different than their competitors who do not rely on their native token for value transfer, save for THORChain.

The best way to visualize ZETA’s role in message passing is with an example from the whitepaper, a cross-chain DEX. Under this example, a user wants to swap 1.2 ETH on Polygon for USDC on Ethereum. The path is as follows:

1. ETH is swapped for ZETA on Polygon AMM
2. ZETA is sent to ZetaChain
3. ZETA is routed from ZetaChain to Ethereum
4. ZETA is swapped for USDC on Ethereum
5. User receives USDC on Ethereum

While workable, this is a very capital intensive architecture. We also do not believe a product like this is competitive for various reasons, such as intent protocols like Squid router and UniswapX and Circle’s CCTP taking significant marketshare as a settlement rail. We’ll dive more into these protocols later.

In addition to the capital efficiency, cross-chain message passing is a highly competitive area and not one where we believe ZetaChain can really offer a unique advantage. With omnichain smart contracts, on the other hand, we believe they can.

Omnichain Smart Contracts

Instead of using Zeta and the zEVM to merely facilitate transactions, deploying as an omnichain smart contract on Zeta has numerous advantages. First off, it allows for interactions with assets like BTC, DOGE, LTC and more that do not support smart contracts natively. Second, it reduces the attack surface of exploits as the application state sits on Zeta. Third, it creates an economy that resided on ZetaChain where users will stay and interact. And lastly, it does not rely on ZETA token liquidity for value transfer. This is a product that none of the competitors above have outside of Axelar, but Axelar uses CosmWasm instead of EVM and has not seen any adoption so far.

ZetaChain’s omnichain smart contracts are enabled by the TSS protocol. Since Zeta validators run full nodes and share signing on external chains, they can custody assets on behalf of ZetaChain and its users. The zEVM can then manipulate these assets as they desire. To be clear, the BTC does not actually move from Bitcoin to Zeta, the BTC is moved to an address that the Zeta validators custody, and then is represented on ZetaChain. This would be as if THORChain had smart contracts on top of the BTC the protocol custodies.

There are numerous unique protocols Zeta can build under this architecture. To name a few:

• A BTC backed omnichain CDP stablecoin
• Money markets with support for BTC, DOGE, LTC, and other non-smart contract assets
• Omnichain perp DEX
• Omnichain yield aggregator
• BTC AMMs

We will discuss some of these options in detail in the application deep-dive. In essence, ZetaChain’s zEVM, combined with the ZetaClient to custody and control assets on non-smart contract chains is the biggest differentiator. The cross-chain messaging platforms today are mostly used as back-end infra, but ZetaChain can create their own economy on ZetaChain. Now that we understand the ZetaChain architecture, we’ll compare it to the main competitors, both from an architecture design and adoption standpoint.

Zeta’s Competitors – Architectures & Adoption

In this section we’ll dive into notable competitors LayerZero, Axelar, IBC, THORChain and Chainlink CCIP. We’ll also touch on some other architectures like Circle’s CCTP & UniswapX to further define what ZetaChain’s competitive advantage can be compared to their competitors.

LayerZero

LayerZero is the largest competitor to ZetaChain when it comes to cross-chain message passing. While they do not compete in the omnichain smart contract area, their position in cross-chain messaging is strong. Their main go to market has first and foremost been the Stargate bridge, the second being pushing for adoption of their OFT standard. We’ll touch on Stargate first and then get into the more interesting OFTs.

Architecture

First, as a quick refresher, LayerZero is a protocol that allows “user applications” to send messages between blockchains. This architecture consists of 4 main components:

1. User Application: contract that interacts with the LayerZero endpoints and can send/receive messages to/from it (example: Stargate)
2. LayerZero Endpoints: a series of smart contracts on various chains (over 30 at time of writing). Endpoints allow UAs to send messages through the LayerZero backend and consists of 4 modules: communicator, validator, network and libraries. The former 3 are standardized across all chains while the libraries are customized for each chain’s logic. This standardized design is what allows LayerZero to add more chains quickly.
3. Oracle: the party responsible for reading block headers from one chain and sending it to another. Historically this role was defaulted to Chainlink, but as of September 2023 a new partnership with Google cloud has replaced it as the default.
4. Relayer: similar to the relayer but fetches proofs instead of block headers. While applications can become relayers themselves, it is handled by LayerZero in practice.

This design essentially boils down to a 2/2 multi-sig where the main trust assumption is that Google Cloud and LayerZero won’t collude. The benefit of relying on these off-chain components (oracle and relayer) is that the architecture is lightweight, cheap and easy to scale. The downside of course is that you’re relying on two centralized entities and may be prone to censorship. Applications seem to be content with not changing the default options and trusting LayerZero, even if they have the ability to relay themselves. Uniswap’s team also found LayerZero inadequate in their bridge assessment report due to the centralized nature of the relayer and oracle. However, recently LayerZero announced a zk light client from PolyhedraZK to replace the oracle role if applications don’t want to rely on Chainlink or Google.

All in all, LayerZero’s architecture is rather simple and depends on 2 parties not colluding. While L0 does not compete against Zeta in the Omnichain space, it does in messaging and cross-chain token transfers. The most successful of their applications to date being Stargate, the cross-chain bridge.

Stargate

While LayerZero has been successful in getting a few projects to develop their OFT standard (discussed later), the most popular application it’s known for is Stargate. Stargate is a token bridge that uses LayerZero’s messaging protocol in the back-end. Out of the top 20 LayerZero contracts, the top 5 and majority of them are due to Stargate.

 

Stargate allows users to swap cross-chain for native assets on the destination chain. In other words, they do not receive a wrapped asset that they then need to swap for the native. While Stargate has predominately been the most used bridge over the past year, the uptick coincided directly with the LayerZero fundraising announcement and airdrop speculation/farming.

 

While Stargate’s percentage of bridge volume spiked it has been trending down consistently since, now sitting at about 15-20% of total.

Over time, we don’t believe pure bridge designs to ever become economically sustainable for a few reasons.

1. The hurdle rate for LPing ETH in a bridge is > the staking rate of ~5-6%. While staking (and liquid staking) do have their own risks, we’d argue being an LP in a Stargate pool is riskier and thus would require an even larger premium.
2. The amount of volume bridges need to generate a 5-6% APY organically is astronomical. Annualizing Stargate volume from the past month, they’re doing $12.46b volume on $395m TVL and generating $8.35m in fees, good for a ~2.1% organic APY. In turn, a lot of Stargate LP TVL is incentivized by issuing STG tokens and people LPing for a potential airdrop. None of these are sustainable, however.
3. We expect Circle’s CCTP to dominate stablecoin bridging as Circle, as the sole issuer of USDC, can burn and mint on any chain they choose to integrate. While bridge protocols can integrate CCTP, users can bridge for free directly through Circle. This leaves token bridges for smaller, not officially supported chains with less volume.
4. The introduction of intent-based architectures like UniswapX are moving into the bridging space. We’ll talk more in-depth later, but we expect these designs to also put significant pressure on passive LP bridges, as they can offer a better UX and are synergistic with CCTP as a settlement layer for solvers/market makers.

Stargate introduced SushixSwap about a year and a half ago and is an example of a cross-chain DEX protocol that can be built utilizing Stargate. Again, we expect cross-chain intent architectures to outcompete on these basic cross-chain token swaps, discussed later.

Radiant Capital

Radiant is an “omnichain money market” built utilizing both LayerZero and Stargate. Essentially, Radiant allows users to lend and borrow cross-chain. 

It’s important, however, to understand what they’re actually using LayerZero and Stargate for. The way that the cross-chain borrowing works in Radiant is that the borrow takes place on original chain where the collateral is (say Arbitrum) and then is sent to any destination chain of a users’ choice, even if Radiant is not deployed there. In other words, the borrow happens on the origin chain and then in the background a Stargate transfer is triggered. While a convenient feature for borrowing, users still need to bridge funds back to the origin chain to pay off their debt. Radiant also utilizes LayerZero’s OFT standard for their native token which we will discuss in the next section.

After launching in late 2022, Radiant has become the #8 money market by TVL and the #1 on Arbitrum, barely squeaking by OG money market Aave.

 

They recently deployed their Ethereum mainnet instance, giving users the ability to keep their funds on L1 and borrow to use on other/cheaper chains. It should be re-iterated however, that the “cross-chain borrow” functionality is just removing a manual step for users, as the protocol takes care of the Stargate bridging for them (but of course a user could do this themselves with any other money market). Having these partnerships is a competitive advantage for Stargate as they become the default.

A unique money market would be one where the collateral is on one chain and the borrow is on another. This would allow someone to, say, deposit stETH on Ethereum, borrow USDC on Arbitrum and then pay off the loan on Arbitrum without having to bridge USDC back.

OFTs & ONFTs

The OFT standard is where LayerZero has been focusing a lot of their efforts recently and has been able to win over some protocols to adopt, mostly newer ones. It makes sense to focus here for LayerZero as standards benefit from network effects. The more projects they have adopt the OFT then the more useful they become. The OFT standard uses LayerZero to burn & mint tokens when crossing chains. This allows any token that’s adopted the OFT standard to issue their token and have it more freely between multiple chains without involving wrapping and locking in bridges. Some projects adopting the standard are as follows:

• Lido wstETH: Follow along here, L0 announced without Lido support.
• Magic Eden: Creators can launch ONFTs on ME. These are NFTs that can be burned/minted/held on any supported chain (currently Ethereum and Polygon). ME is also the first NFT platform supporting “Gas Station”. This is account abstraction for NFTs, allows users to bridge & swap to needed gas token for NFT. It’s unclear why people would want to hold NFTs are various chains but the claim is that this feature will be useful for gaming NFTs.
• Tavaera: Another NFT exchange focusing on gaming and launched on zkSync. They have added support for both Arbitrum & Linea with more to come, adopting the ONFT standard.
• Canto: Adopted the OFT standard for the tokenized deposit of NOTE, cNOTE. NOTE is a stablecoin built on the CANTO blockchain.
• Prisma Finance: LST backed stable mkUSD (~$30m mkUSD outstanding). Essentially, collateralize the stablecoin on Ethereum and then bridge/use everywhere. This type of stablecoin would be interesting to make on Zeta with the addition of BTC collateral.
• Lybra Finance: LST backed stable peUSD (eUSD) ($92m eUSD outstanding). eUSD is locked in a SC on Ethereum (earning yield) and then peUSD can be used across chains freely.
• Swell Network: swETH LST. Has launched on Mainnet, Arbitrum and soon Op, Mantle, zkSync, Base.
• Gravita Protocol: Another LST backed stablecoin.
• unshETH: LST index token, accepts deposits of various LSTs.
• mevETH: Another newer LST from Fold Finance. Originally adopted OFT for mevETH but removed the standard after for security reasons.
• stakestone: Another LST.
• Pancakeswap: Decided to use LayerZero’s OFT standard for their Aptos integration and token CAKE.

If you couldn’t tell, there’s a theme here. Most of these are newer LSTs or stablecoins, which makes sense. Both of these products want their tokens to be viable on as many chains as possible and integrating with LayerZero early means no need to wrap and have them sitting in bridges. However, while the cross-chain burning and minting does not need any liquidity to facilitate the bridge, to actually use these LSTs or stables on numerous chains they will all need some level of liquidity to make them viable. For example, LSTs need on-chain liquidity to be added as collateral. For stablecoins, for people to accept them they also need to be easily sold. It’s unclear what users’ desire to use these across multiple chains is, and liquidity will likely stay within a few.

There’s also the security angle, and how protocols who adopt these standards move their trust models from the chains/L2s they’re on to LayerZero. Also, LayerZero isn’t the only one doing a standard with seemingly every messaging protocol doing one (like Connext or Axlear’s IST). LayerZero has done a good BD job here but it’s arguably not the right architecture for protocols to adopt, especially as liquidity congregates around a few chains in the long-run. Moving security models of tokens from their native chains or L2 bridges to LayerZero is a massive decision. There’s a world where OFT gets so much adoption that the majority of tokens rely on LayerZero’s 2/2 architecture for security.

Other Notable Projects/Hackathon Ideas

Lastly, some other notable projects (or ideas) using LayerZero.

• Vector Finance: Vector is a Convex-like protocol launched on Avalanche. They use LayerZero for their token zJOE. zJOE is a liquid staking representation of sJOE in which the protocol moves sJOE between chains for the optimal yield. Essentially, zJOE removes the manual bridging of sJOE to different pools/chains and does it automatically for the user.

• Uroboros Wallet: “omnichain wallet”, handles bridging and cross-chain swaps in-wallet (currently in waitlist).
• Hackathon Ideas: see link here
  • Cross-chain KYC: KYC on one chain and transfer that proof wherever
  • BasePoint: point of sale app, cross-chain payments
  • Arc: ONFT contract management, no code for people to build omnichain NFT contracts quickly

Overall, LayerZero has gotten the most traction out of the cross-chain protocols with projects directly. Their google partnership and BD efforts of pushing adoption of the OFT standard has so far been fairly successful. LayerZero cannot enable certain usecases that Zeta can however (e.g. BTC CDP) which we’ll touch on later.

Axelar

Axelar has a more similar construction to Zeta than LayerZero albeit with notable differences. Like ZetaChain, Axelar is built on the Cosmos SDK and specializes in arbitrary, cross-chain message passing. Unlike ZetaChain, however, it does not host an EVM directly and thus does not support the same omnichain smart contracts as Zeta. Axelar’s target market is thus in cross-chain message passing, similar to LayerZero.

Architecture

Axelar is a PoS chain with its own validator set (75 at the time of writing) and staking token, AXL. The components and message flow are as follows:

• Cross-Chain GMP Requests: APIs that allow an app to send arbitrary data cross-chain. These message requests are sent to Axelar Gateways.
• Gateways: This is where a cross-chain message initiated by a user/app first passes through to be routed from the source chain to the destination chain. For EVM chains these are smart contracts and for Cosmos they’re application logic. Gateways are secured by the Axelar validators using MPC, with shares weighed by AXL tokens delegated.
• Message Processing & Relayers: Relayers listen for events (Gateway messages) and submit to the Axelar network to be processed. While anyone can run a relay there’s not an incentive and are run by Axelar.
• Message Validation: Validators vote on messages received from relayers. Each Axelar validator runs a full node for every source chain and thus is able to verify message validity. In turn, Axelar validators are much more resource intensive than a typical Cosmos PoS blockchain where validators rely on light clients and IBC to pass messages. This model is, of course, less scalable in a sense than LayerZero’s but is more decentralized. Axelar incentivizes validators by issuing them more staking rewards the more chains they support. In the long-run, supported chains will need to generate enough fees from cross-chain activities as token incentives to support validators running 50+ full nodes will run out. Supporting every chain may not be feasible, and instead will congregate around the major liquid ones.
• Submitting Message to Destination: Relayers listen for authorized messages from Axelar validators and push to destination chain Gateways. When the destination chain receives the approved message its payload is marked approved by Axelar validators. Anyone can now execute the payload.
• Gas & Executor Services: The final step, Axelar deploys contracts called “Gas Receivers” on EVM chains which cover the destination chain’s gas fees and execute the cross-chain payload (send it to desired app). Users can pay in source-chain gas tokens and Axelar abstracts away the destination chain gas.

Axelar makes one unique twist to its PoS consensus, which is that it allocates voting power quadratically based on stake (more specifically, the square root of one’s stake). What this means is that a validator’s voting power does not increase linearly with % of the network, rather the rate of change that voting power increases slows down as stake % gets higher. For example, the top validator owns 6.8% of stake but has 3.3% of voting power. The underlying consensus for Axelar block production & rewards still follows the linear stake weight rule but the validation and processing of cross-chain actions are what use quadratic.

In addition to quadratic voting, which is a slower safety > liveness modification, Axelar takes some other pre-emptive measures:

• Rate Limits: Caps on how much can be bridged through in a certain time period. IBC Chains have implemented similar limits since the IBC-bugs uncovered last year.
• Key Rotation: Validators are required to rotate keys periodically.
• App-Level Security Customizations: Applications can add their own modifications (transfer limits, address limits, signing policies, etc).

Overall, it’s a similar construction to what ZetaChain is, outside of the support for EVM on its own chain. For security, we’d argue it’s more secure than LayerZero’s 2/2 model, although there are still tradeoffs and the odds of Google & LayerZero colluding are extremely low (and ofc the app can run its own relayer).

Overall Metrics

Axelar is predominately a way to connect Ethereum and Cosmos based chains. Below is the map of connected chains.

The top routes historically were between Terra and the EVM chains Avalanche (c-chain) and Polygon. Even with the Terra depeg happening ~1.5 years ago, this two routes still rank #1 and 2 by transactions count, highlighting the magnitude that Axelar depended on Terra. These days, Axelar has predominately been used to onboard users to Osmosis and Sei from Ethereum and BNB chain. Below are the top routes by $ value over the past year.

 

As for contracts, there’s one app that stands out, and that’s Squid router. We’re going to dive more into squid router below, but it enables cross-chain swaps through Axelar’s GMP and is doing some cool things with NFTs as well. The other top 3 contracts are:

• MintDAO: Cross-chain NFT platform. Note that MintDAO has also added support for LayerZero’s ONFT standard recently, going with an interoperability-agnostic approach.
• Prime Protocol: Cross-chain prime brokerage (again supports both Axelar and LayerZero)
• The Junkyard: NFT project that lets you dump worthless NFTs for junkcoin. They then let you “fish” for NFTs (win NFTs others dumped) and use Axelar for the communication between Ethereum and Polygon.

 

The launch and adoption of Squid router is directly responsible for the % of volume through Axelar due to GMP rising >50%. Historically most of the volume was pure token transfers, but Squid has changed that with the cross-chain swaps. The outlier month below (Aug ’23) was due to the Sei launch and billions of dollars being bridged between BNB chain and Sei.

 

When it comes to Axelar TVL, their flagship asset has been axlUSDC which we’ll talk about more below. The other main assets are liquid assets like ETH, WBTC & USDT. Recently, Axelar partnered with Lido to bring wstETH to Cosmos. With Lido phasing out support for ecosystems like Polkadot, Polygon, Solana and more, they’ll be focusing all of their efforts on stETH. The partnership with Axelar allows them to export stETH to Cosmos, and has garnered ~$2.5M minted so far, predominately sitting in an Astroport pool on Neutron. It’s possible Axelar’s wstETH becomes Lido’s preferred canonical non-Ethereum version with support for chains like Solana in the future. This would be a big win for Axelar, assuming there’s demand for stETH in non-ETH ecosystems (and those ecosystems flourish).

 

Those are Axelar’s metrics as an overview. Now we will dive into their flagship products, Squid Router and axlUSDC.

Squid Router

Like Stargate is LayerZero’s flagship project, Squid is Axelar’s. There are differences, however. Squid does not have liquidity providers as Stargate does. Instead, Squid taps into existing DEX’s and sends messages between them. It is the “glue that connects DEX’s on different chains”. It still does need to tap into Axelar’s liquidity, of course, and does this through axlUSDC pools on various DEX’s. So, while it does not need its own LPs it does need Axelar minted assets to facilitate the swaps, and thus LPs to provide liquidity. All of Squid’s cross-chain swaps are facilitated around stable pools of USDC/axlUSDC, which has the benefit of USDC already being widely held in liquidity pools across all chains and limited volatility for LPs.

Swaps go: TKN A → USDC → axlUSDC (chain A) → bridge axlUSDC (Axlear) → USDC → TKN B

While the model is quite simple, it does still depend on Axelar’s own representation of USDC. It is likely with Circle CCTP, and the ability for cross-chain message protocols to implement it, that the axlUSDC portion will be phased out and Circle will just burn and mint the USDC on each chain instead. In this case, Squid’s moat is not around axlUSDC liquidity but rather their front-end, integrations and UX.

Outside of pure cross-chain swaps, Squid has some notable features such as:

• Hooks: A more advanced feature that lets users do things like swap a token for an NFT cross-chain, stake cross-chain or deposit to a money market or other DeFi protocol. A simple example is a cross-chain NFT swap. One could buy a Bad Kids NFT on Stargaze with ETH on Ethereum, using the swap method highlighted above and then swapping the STARS for NFT on Stargaze.
• Boost (Intents): Boost is a feature that allows one to utilize intents/solvers and have their cross-chain swap executed & settled in ~20 seconds. Like any other intent-based protocol, solvers deliver the assets faster and take the settlement risk, for a fee. Boost is limited to cross-chain swaps <$20k. Non-boosted swaps are of course subject to the source chains’ finality. Boost, like other intent based apps, is a UX improvement that abstracts away the back-end.
• Widgets: Easy to implement UI through Squid’s API and SDK.
• dYdX Onboarding: Nothing really unique here, but a win to be a canonical onboarding provider for dYdX’s v4 Cosmos chain.
• Integrated Apps: MetaMask, ****PancakeSwap, SpookySwap, KyberSwap, StellaSwap, DODO, Quickswap and ~50 more

axlUSDC

As we mentioned above, axlUSDC is the glue that makes Squid Router work. It was also the primary way to get USDC liquidity into Cosmos over the past year, notably on Osmosis and more recently Neutron. However, with Noble launching support for native USDC in Cosmos, axlUSDC will be phased out as canonical for Cosmos chains. It’s also why Base is relatively high, but again it will probably be phased out as Circle launched CCTP for Base on October 26th.

 

Where this tends to leave axlUSDC (or any wrapped USDC for that matter) is onboarding to new ecosystems/chains that do not yet have a Circle CCTP integration. Circle won’t offer support for every new chain launched, and will need time to vet them, and so this is where wrapped versions of USDC are to be achieved. However, the market is much smaller, and if a chain/rollup gets large enough then it will be in Circle’s interest to add native support anyways.

On Osmosis, axlUSDC is still slightly larger than native USDC ($3.3M vs $2.8M) but that will change soon. As mentioned prior, we expect the Axelar partnership with Lido to make Axelar the canonical supplier of wstETH in Cosmos the path they will focus on more. axlUSDC is not really a defendable product in the long run, while a partnership with Lido and stETH is (Lido will prefer a canonical representation in Cosmos).

Other Products

• Sommelier Arbitrum Vaults: Using Axelar’s GMP to manager their Arbitrum vaults. Sommelier is a yield-farming protocol (like Yearn Finance) but deployed as a Cosmos appchain. All of the vaults are managed on Ethereum but the strategies are done on the appchain. Sommelier will use Axelar to send vault strategies and rebalancing messages on Arbitrum. This integration opens up the possibility for Sommelier to build vaults on top of Arbitrum protocols like GMX, Gains and more.

• Interchain Token Service: This product is similar to LayerZero’s although with less adoption. In testnet, SUSHI is the first to adopt.****
• Axelar Virtual Machine: This is just the addition of a cosmwasm module on Axelar. Announced in Feb ’23 with a $5M grant budget, have yet to see anything meaningful yet.

Axelar has made good ground in applications like Squid and getting wstETH, but it falls behind LayerZero significantly in token standards (OFTs vs ITS) and has had little demand for AVM apps thus far. With the phase out of axlUSDC, it will be critical for Axelar to start making ground in these two areas. Also, while the Axelar architecture can support BTC, it hasn’t thus far. We should see a re-emphasis on BTC at some point, either as a bridge or with the AVM.

IBC & Atomic IBC

IBC

IBC is the communication standard for Cosmos based chains. Cosmos chains run light clients of other Cosmos chains that they want a connection to, and the block headers are verified when receiving messages from external chains. This model works because of Tendermint/Comet’s instant finality and Cosmos chains having support by default. From a security perspective, users need to trust the validators (honest majority 2/3) on both chains they are interacting with.

The main drawback to IBC is that tokens are path dependent and that it’s hard to extend to Ethereum. IBC is unopinionated and is agnostic to how the topology will take shape. Essentially, IBC is a point to point model vs the Hub & Spoke of that of Zeta.

In practice, what this means is that tokens from one chain may end up on the same destination chain, but since they took a different path to get there they’re not fungible with one another. Consider the slide below (from our Cosmos report in 2022), Chain A’s token from path 1 is not fungible from that of path 2. This means they would need to be underwritten differently for DeFi, would have separate liquidity pools, separate prices, etc. It also means that a chain’s tokens can end up on a chain they don’t support through a mutual connection of another.

This path dependency has led to a path-unwinding standard, a collaboration between Strangelove, Skip, Stride and Squid. Essentially, tokens can be unwound with a one-click single transaction instead of manually sending through each chain step by step. Consider a transfer of ATOM from Osmosis to Stargaze. First, path unwinding will use “denom_trace” to find the token’s path (Hub → Osmosis), then it will unwind this back to the Hub with a memo, and finally the Hub parses the memo and sends to Stargaze. This ATOM on Stargaze is now the canonical Hub → Stargaze path which is needed to be fungible on Stargaze.

The “Packet Forward Middleware (PFM)” allows for token transfers through n-chains. The most vital usecase for this standard is Noble’s USDC, the canonical supplier of USDC on Cosmos. Every time a user wants to send USDC from one chain to another it needs to be routed back through Noble. This is, in a way, creating a Hub & Spoke model on top of the unopinionated IBC.

As for adoption, it’s limited to Cosmos chains today but there are teams working on expanding to other eco’s like Ethereum, albeit with notable challenges.

IBC Adoption Metrics

At this point in time there are now 64 zones (chains) connected through IBC, although the majority of volume is routed through a select few (these are the 10 chains in the middle). The chart below is an easy way to visualize the point to point model. While there are 64 zones, there are a few orders of magnitude more connections as each chain has their own point-to-point connection with numerous peers. The recent dYdX launch is looked at as a catalyst for IBC.

As for IBC volume, while the snapshot below is from a 30 day time period, it’s representative of what IBC volume has typically looked like throughout the past year. Volume has congregated around a few chains, notably Osmosis, Axelar and the Cosmos Hub. More recently Neutron has seen an uptick with its launch and wstETH onboarding, plus other chains like Stride, Umee, Akash and Noble (USDC).

 

Compared to other bridge volumes, IBC is kind of disappointing at this point. This doesn’t really have much to do with IBC itself, more so that Cosmos chains have struggled to attract liquidity over the past year. Although, some of the metrics below (like zkSync Era) are boosted by pure airdrop farming, something IBC does not benefit from. One thing to note on these metrics is that they’re a snapshot from before the dYdX & Celestia launches. It will be important to monitor these launches’ impact on Cosmos and, by extension, IBC.

 

Still though, if Cosmos chains do not get substantial adoption over the next cycle then IBC will follow with it. However, IBC is not necessarily a finished project, with numerous teams working on extending IBC to other chains.

Exporting IBC

There are a few teams working on trying to bring IBC to other ecosystems. There are numerous teams working on zk bridges which include Succint Labs, Polymer, Electron Labs and zkBridge. Succint is the leader in this space right now.

The hard part about bringing IBC to Ethereum has to do with Ethereum’s 400k+ validators. Most of these designs center around using Ethereum committees instead of the full validator set (e.g. using Altair client). Polymer announced zkMint in February, a zk-friendly Tendermint/Comet consensus engine. Proving Tendermint/Comet consensus on Ethereum is expensive and using zk-proofs is a way to gain significant cost reductions. None of these IBC to Ethereum solutions are live yet and we wouldn’t expect fully-fledged out & live designs for some time, while Ethereum adding single slot finality would help immensely. On this topic, Polymer recently announced their OPStack rollup (a pivot from their Cosmos appchain) to bring IBC to Ethereum. The architecture is one to watch, and Polymer is probably the most hyper-focused team on bringing IBC to Ethereum in the market.

In addition to Ethereum, an ICF partnership with Landslide Network is working on bringing IBC to Avalanche. Incentivize testnet launched in November. Expanding to Avalanche has been critiqued fairly heavily, with people like Zaki calling it a “sidequest”. We would agree that IBC is basically Ethereum/L2s or bust at this point and will be the only way for it to truly break out into the mainstream.

Atomic IBC

An extension of Interchain Security, Atomic IBC is essentially a way for Cosmos Hub consumer chains to share a mempool and have cross-chain transactions committed to atomically. The main tradeoff with Atomic IBC is that chains aren’t sovereign and need to adopt the Cosmos Hub validator set. It’s not a real competitor to Zeta but worth mentioning here in the IBC section as it is relevant and will be a version of IBC some chains will adopt. More details here.

The biggest risk to IBC in our opinion is lack of adoption for Cosmos chains. While IBC is arguably the gold standard for bridging, if Cosmos chains do not see significant adoption over the next couple years then IBC will most likely be left aside as well.

Chainlink CCIP

Architecture

At a high level CCIP isn’t too different from other cross-chain messaging platforms. A user sends a message on one chain, it gets routed to CCIP, then CCIP relays it to the destination chain. CCIP differs in how it uses its Oracle Networks and the introduction of another entity, the Risk Management Network.

CCIP is split between its on-chain and off-chain components.

On-Chain Components

• Router: Initiates cross-chain transactions. Routes transactions to the destination specific OnRamp contract. Receive message from OffRamp on Destination chain and routes to end user/contract.
• Commit Store: Committing DON (discussed below) stores Merkle root from source chain on destination chain. Merkel root must be “blessed” by Risk Management Network (again discussed below).
• OnRamp: One contract per lane (blockchain to blockchain). Verifies messages and tracks things like token transfer/message, manages billing, etc. Emits the event monitored by the Committing DON.
• OffRamp: Like OnRamp, one contract per lane. Makes sure message is authentic by verifying Executing DON against the committed and blessed Merkle Root. Transmits messages to router.
• Token Pools: Tokens can be either ‘lock and mint’ or ‘burn and mint’, depending on token. For example, native gas tokens must be lock and mint as CCIP has no minting authority. USDC can be burn and mint if integrating CCTP.
• Risk Management Network Contract: Contains list of Risk Management Network nodes that can bless (approve) or curse (disapprove) transactions.

Off-Chain Components

• Committing DON: As explained above, the Committing DON monitors events from the OnRamp contract. They then wait for source chain finality, creates the Merkle Root (signed off by a quorum of Committing DON oracle nodes), and writes to the CommitStore contract on the destination chain.
• Risk Management Network: A network of nodes that essentially double-check the Committing DONs Merkle root. They monitor the OnRamp contract and what the Committing DON posts to the commit store. CCIP will freeze if the RMN doesn’t bless (i.e. verify/confirm) the Merkle Roots.
• Executing DON: Similar to committing but listens to messages like the Risk Management Network. Once RMN has blessed, the Executing DON calls OffRamp contract to complete CCIP tx on destination.

In addition to the above, CCIP also has rate limit measures by specific token (eg. snxUSD) or lane (eg. Ethereum → Arbitrum). Like other cross-chain messaging protocols, latency is determined by source chain finality.

Adoption

CCIP went live in the summer and has mostly been in alpha/test phase first. While revenue was hitting $1k/day in the summer it’s slowed down considerably since.

 

This is due to the fact that Synthetix makes up >90% of CCIP’s revenue YTD. Synthetix uses CCIP to bridge sUSD cross-chain. It should also be noted that Synthetix is working on their own cross-chain unified liquidity solution outside of CCIP as they look to expand to other ecosystems. The tl;dr reasoning is in this tweet here. The other main protocol is Aave, but usage is far lower.

 

While there isn’t a lot of data to go off of yet due to CCIP’s recent launch, we can look to what their target market is with CCIP, which differs from the crypto-native focus of some of the other cross-chain protocols: RWAs.

RWA Focus

Chainlink has a fairly targeted focus with CCIP and that’s getting financial institutions to adopt it for RWAs. This differs significantly from other protocols whose core focus is crypto native.

There’s not much to say on this other than to monitor Chainlink’s announcements and blog posts (here, here and here) as they continue to push this direction. CCIP can, of course, facilitate other crypto native use cases like cross-chain swaps, NFTs, etc, it’s just that their only integrations to date are Synthetix and Aave and RWAs seem to be the focus. While early, CCIP is an ambitious project, although it is not competing against Zeta’s omnichain smart contracts, which as we continue to re-iterate, is Zeta’s biggest differentiating value prop.

On the RWA front, there was actually a noticeable announcement on November 15th from Apollo Global and Onyx (JPM) to tokenize RWAs and bring them on-chain. The partners for this are LayerZero and Axelar, a big win in the RWA narrative for these two protocols, notably absent of Chainlink’s CCIP.

As for now, LayerZero and Axelar are the clear leaders with respect to adoption in the cross-chain messaging space. It’s early days though and no one really has any major lead here. I’d expect to hear more about RWAs and CCIP over the coming year as it’s still in a test-flight stage.

THORChain

Architecture

THORChain is an application-specific blockchain functioning as a cross-chain liquidity hub between independent heterogeneous chains such as Bitcoin, Ethereum, Cosmos Hub etc.

At the time of writing THORChain is run by 100+ nodes. In addition to running a PoS-based consensus protocol (Tendermint) to update the THORChain state machine, THORNodes collectively own and manage addresses on external chains known as vaults. These vaults are used to custody native external assets (BTC, ETH, ATOM etc.) which are used to enable 3 core products THORChain offers: cross-chain swaps, savings (interest accounts), and lending.

• Swaps: Swap X for Y
• Savers: Earn X for X
• Lending: Borrow X for Y

Bridging is a core part of the THORChain architecture. Each THORNode runs THORChain’s own bridge design known as Bifröst. Bifröst is often described as a “one-way peg” because the state is only transferred from supported chains to THORChain and not vice versa. Below we take a closer look at the Bifröst architecture.

Under Bifröst, each THORNode runs full nodes of external chains that THORChain supports. This allows each one of them to independently observe “incoming txs” concerning a THORChain vault; an external address collectively owned and managed by THORNodes.

When a THORNode observes an incoming txs, it transforms it from its native chain-specific format into a standard, chain-agnostic format that the THORChain state machine understands and can process. This is known as the witness tx.

Once all THORNodes observe the same incoming tx, the witness tx is finalized on THORChain and can be acted on. This moves THORChain from one state to another triggering an action related to one of the 3 products: e.g. a swap, a lending/savings deposit, a refund, etc.

At the end of execution, an outgoing tx is generated and assigned to an external vault. This outgoing tx is once again, transformed from a standard THORChain format into its chain-specific format via the respective chain client. THORNodes managing the assigned external vault then sign on this tx via TSS at which point the tx can be mined/finalized on the external chain. Once again the outgoing tx may be anything related to one of the 3 products: a swap, a withdrawal etc.

THORChain’s Economic Security & Churns

As mentioned, THORNodes collectively own and manage certain addresses on external chains known as vaults. These vaults are used to custody native external assets (BTC, ETH, ATOM etc.). Each external asset is paired 1:1 with THORChain’s native token RUNE forming a cross-chain AMM pool. All 3 products (swaps, savers and lending) use the same pools.

External assets paired 1:1 with Rune enable THORNodes to know and keep track of the total value being pooled ($$ value of external assets = $$ value of Rune pooled) w/o having any dependencies on an external asset or protocol. It also lays the foundation for THORChain’s crypto-economic security which is designed to have more value at stake (Rune bonded) than value secured (Rune pooled).

Similar to your typical PoS chain, in order to earn a portion of the total earnings (fees + block rewards), nodes have to bond in Rune. Unlike your typical chain, however, THORNodes are frequently churned in and out of the active node set. Approximately every 3 days the oldest and worst performing few nodes are churned out of the active node set and replaced by a few nodes waiting in the standby with the largest Rune bondings. This not only creates an auction amongst nodes (nodes bid up their Rune bondings when user activity increases) but also makes it drastically costlier for an attacker to maliciously take over the chain. Importantly, as part of the churn process, THORNodes also migrate external assets from old vaults to new vaults, which acts as a constant solvency check for the network.

Another important aspect of THORChain’s economic security is its incentive pendulum mechanism. The incentive pendulum splits total earnings (fees + block rewards) between liquidity providers and THORNodes. The split favors one or the other depending on whether the protocol is over or under-bonded at any point in time. When the network is under bonded, more of the earnings are directed towards THORNodes which increases competition between standby nodes looking to churn in. As standby nodes with the largest bonds churn in, the balance between pools and bonds gets restored back to safe equilibrium. Similarly, it’s undesired for the network to be over-bonded as it causes THORChain to operate in a capital-inefficient way. If this is the case more of the earnings go to pools, increasing the APR of liquidity providers and encouraging users to provide more liquidity into the pools.

Adoption & Protocol Reflexivity

We have some more THORChain metrics in the BTC section but will be going over a few unique/notable ones here as well related to its sustainability.

The first is the breakdown of THORChain LPs. The entire suite of THORChain’s products run off of THORChain’s liquidity pools and so the entire protocol is dependent on them. The majority of THORChain LPs are smaller, but there are still 260 providing >$100k.

 

Lately, THORChain has seen a significant pick-up in trading volume. Swap volume has increased substantially over the past few months and with that, outperformance from RUNE.

 

The third chart to highlight is the % of volume on THORChain that comes from synths. Synths are wrapped assets that are native to THORChain and only trade there. It is notable how high the ratio of synth to native volume is, which is driven by two factors:

1. They’re used to arb pools
2. They’re faster and cheaper than doing native swaps

The synth volume on THORChain can be a signal for ZRC20 activity on Zeta. While a native BTC to ETH swap would take ~10 mins and Bitcoin’s gas fees, a synthetic BTC to ETH swap on THORChain would cost 0.02 RUNE and take ~5 seconds. We believe using SC’s directly on Zeta and ZRC20’s will have a similar distribution. Synths, like other THORChain products, are reflexive with the price of RUNE as synthetic assets are backed by liquidity pools and hence 50% native (eg. BTC) and 50% RUNE. If RUNE underperforms then the protocol needs to mint RUNE to cover the shortfall. Synths have caps for this reason.

 

The fourth chart is the % of fees THORChain generates from token inflation or trading fees. Token inflation is, of course, not a sustainable way to run a protocol, and so organic fees need to increase over time. Over the past year, with the reduction of block rewards and return of trading, we have seen that. As highlighted above, a large portion of volume is driven by synths.

 

The fifth chart is more so on decentralization. THORChain the protocol itself doesn’t provide any front-ends for users to use the protocol, these are all done by third parties. Third party providers (like THORSwap) are incentivized by the trading and protocol fees their front-ends generate.

 

Next, with the outperformance and general bullish trend of RUNE over the last few months we’ve seen a significant divergence between RUNE bonded (staked) and in pools. As RUNE increases vs other assets, RUNE is essentially removed from pools. Some of this RUNE has moved to bonding, as bonding, while securing the network, does not suffer from IL like the two sided pools do.

 

 

Lastly, the amount of RUNE minted/burned. Burning has picked up since they introduced lending. Lending takes the collateral asset (eg. BTC), swaps it to RUNE, burns the RUNE and issues a loan in the borrower’s desire. When repaying, RUNE is minted and sold for the collateral asset (eg. BTC) to return to the borrower. In essence, RUNE needs to outperform the collateral asset for the protocol to come out on top. This type of product carries significant risk to protocol solvency. Zeta can implement safer CDP or money market type borrow-lend with their omnichain smart contracts.

 

The tl;dr is that THORChain is, at a fundamental level, a place to natively swap assets between blockchains without wrapping. Since RUNE is used for every LP, bonding, and the new products, the protocol is highly reflexive with the price. The Pools, synths, savers and lenders are all dependent on the price of RUNE. THORChain as a pure native swap DEX may not be able to generate enough fees in perpetuity to make it sustainable, which is why THORChain has started to offer new, riskier products to generate income.

While THORChain is close to Zeta in terms of the MPC/TSS design, the ability to have smart contracts on Zeta opens up the design space considerably, and allows Zeta to offer more traditional products like CDPs, money markets, and more, without being over-exposed to the price of ZETA. Zeta will still, of course, need to create sustainable economic activity in other ways as the staking token for ZetaChain.

Other Considerations (Circle CCTP, UniswapX, Intent Protocols)

Circle CCTP

As mentioned a few times, we expect Circle’s CCTP to take the majority of USDC bridging volume over time. Why? Simply, Circle is the issuer and creator of USDC and they have authority to burn & mint on any chain they wish to integrate. This is a fundamental advantage no 3rd party messaging protocol can compete with. 3rd party bridges can integrate CCTP, which leads to competing on front-ends, integrations & UX as we highlighted in the Squid router section. Incentivizing stablecoin bridging is not an area Zeta should aim to compete in as it would be a waste of resources.

CCTP adoption has been slow but trending up, usually sitting around a few million USDC bridged per day. As more chains are integrated, along with 3rd party bridges integrating we expect this to shoot up dramatically. The Solana integration is a big catalyst in our opinion, both for Solana and CCTP as bridging USDC to/from Solana from EVM chains is still not great UX.

 

Transaction wise tells a similar story but is easier to visualize the recent growth as it removes the impact of the one large transfer day in the above chart in August.

 

While 3rd party bridges have been slow, they have no choice to integrate. Synapse, Celer, MetaMask, LiFi, Socket and more have all integrated CCTP and have started routing through it.

 

While Circle’s CCTP will of course be used by end-users, we actually believe the main use case may be for solvers using as a settlement back-end. To illustrate, we’ll look at UniswapX and their cross-chain intent protocol and how it will compete with cross-chain swaps and how solvers (or “fillers”) are likely to use CCTP for settlement.

UniswapX

UniswapX is a shift from the Uniswap AMM, similar to CoWSwap and 1inch Fusion. In UniswapX, orders are filled by “fillers” which are solvers who settle users’ trade requests on-chain. But UniswapX is not just for token swaps on a single chain, there’s also a cross-chain angle to it as well. Fillers on UniswapX will be able to fill users’ cross-chain swap requests for a fee, similar to how solvers who provide the “boost” feature on Squid Router operate.

Some early data from UniswapX highlighted in our “Future of On-Chain Liquidity” report highlights this well. The first caveat we should add here is that these are orders that “didn’t” go through Uniswap AMMs first, and instead went to fillers for a better price. In other words, the % of total Uniswap volume that X takes up is low. However, it’s clear that when orders are routed to UniswapX that fillers prefer to use their own inventory to settle trades and take the settlement risk on themselves.

So how does this tie in with Circle’s CCTP above? Simply, we believe fillers on UniswapX and other cross-chain intent protocols will use CCTP as their main settlement rail. For users, using UniswapX over CCTP directly is faster (near-instant) than CCTP’s ~20 minute wait time. For solvers and/or marker makers, it reduces risk.

As an example, a user wants to swap ETH on Ethereum for AVAX on Avalanche. The filler, who has USDC on Avalanche, will buy AVAX and fill the user’s order for ETH. Then, after the trade is settled for the user, will swap the ETH on Ethereum for USDC and send the USDC through CCTP to their Avalanche address. Even for pure USDC bridging, UniswapX and other intent protocols will offer faster execution than CCTP directly, and solvers can even execute destination chain actions besides just bridging (i.e. bridge USDC and deposit in protocol x). Fillers and solvers will be able to utilize CCTP whenever they want to settle their inventory between chains, and we expect them to be one of CCTPs largest customers.

Intents

We’ve mentioned a few intent-based protocols so far, and rightly so; it’s a trend the industry is moving towards. UniswapX, CoWSwap, Fusion, Across protocol, Anoma, Squid Router, and many more are all building towards this paradigm. It’s tough for on-chain liquidity to compete for end-users due to the vast UX improvement they get using intent based protocols, and is why we think on-chain liquidity for bridging will mostly be replaced by intents in the long run.

xERC20 Standard

We spoke about LayerZero’s OFT standard and Axelar’s IST, but there’s actually another cross-chain standard developed by the Connext team that removes any specific vendor lock-in. The main difference with xERC20 vs LayerZero’s OFT or Axelar’s IST is that projects can allow any canonical or third part bridge protocol the ability to mint & burn tokens, as opposed to a single centralized provider. A recent example of this, outlined in the Lido gov forums by Arjun Chand (Li.Fi), was Beefy’s token BIFI. Using the xERC20 standard, BIFI can be burned/minted by all three of LayerZero, Axelar and Chainlink’s CCIP with a rate limit of 2.5k/day.

This model makes more sense to adopt when considering security & decentralization of Ethereum bases tokens. We would expect that this type of model wins out in the long-run vs protocols relying solely on third party bridges for burning/minting. More details can be found here.

Comparison to Competitors

In this section, we’re going to summarize the notable differences between ZetaChain and their 5 main competitors. At a high-level, the table below outlines the main differences.

Protocol	Architecture	Bitcoin Support	Omnichain Smart Contracts	Token Use	Main Focus
ZetaChain	PoS L1, TSS	Yes	Yes (EVM)	CCMP, Staking, Gas	TBD
LayerZero	2/2 Oracle + Relay	No	No	n/a	OFT Standard
Axelar	PoS L1, TSS	Yes (not live)	No	Staking, Gas	Bridging Cosmos ↔ Ethereum
Chainlink CCIP	Oracle + Risk Management Network	No	No	Staking, Gas	RWA
THORChain	PoS L1, TSS	Yes	No	Bonding, Liquidity Pools, Lending	Native BTC Swapping

While we have gone deep into every protocol in this report, a concise summary of the differences/tradeoffs to Zeta is presented below.

Zeta vs LayerZero

LayerZero is quite different from ZetaChain and only shares similarity when it comes to competing in the cross-chain messaging market. L0’s focus so far has been on their OFT and ONFT standards, giving L0 the ability to burn and mint tokens on any supported chain for projects who adopt it. Zeta will not be competing here, as the only native representation of value cross-chain is ZETA.

L0 is also a completely different architecture, relying on a 2/2 oracle (Google default) and relay (L0 default). Zeta, as a full PoS L1, is more decentralized and with the TSS custody can support non-smart contract chains that L0 does not. The one area where L0 and Zeta could conceivably compete is in cross-chain bridging or swaps, but as we’ve outlined in this report, that’s not an area we think Zeta should spend many resources towards. Also, with L0, users of OFT/ONFTs are always exposed to L0 risk where as in Zeta’s CCMP this is not the case as users are always using their native representations, and are only exposed to ZETA while sending messages/bridging. For omnichain smart contracts, of course, users are subject to ZetaChain risk. But they are fully aware as they are using ZetaChain intentionally, like any other L1.

Zeta vs Axelar

Axelar is the closest construction to Zeta as validators, like in Zeta, control contracts and accounts on other chains through TSS. While Axelar does have their own VM, the AVM (Wasm), it has seen little support and it’s not targeting the same EVM-like smart contract experience with ZRC20 tokens like Zeta is. The first product of the AVM is the “Interchain Amplifier”. This is kind of a “deploy once on Axlelar, end up everywhere” solutions and is more so targeting cross-chain messaging. The second role of the AVM will be for light client verification.

Axelar’s main product is Squid router, which makes up >75% of Axelar contract interactions and the majority of funds bridged. Squid has adopted and intent architecture for fast bridging, and as we have stated numerous times throughout the report, is a direction we only see the industry moving in more strongly. While Axelar did try and support BTC over a year ago, there was little demand, and at the moment they do not support. Axelar does not offer the same type of composable omnichain market as Zeta does.

Zeta vs IBC

IBC is arguably the gold standard when it comes to light client bridging, and one we hope to see gain more adoption within Ethereum as technological advancements are made. The main drawback to IBC is the path dependency of tokens and need for solutions like multi-hop routing. Zeta cannot really compete with IBC when it comes to Cosmos chains, nor should they. When it comes to integrating EVM and non-smart contract chains Zeta has the upper hand, although as we mentioned strides are being made to bring IBC to EVM, notably with Polymer.

IBC is just a standard; a public, non rent-seeking protocol. IBC is a viable long-term competitor to Zeta in the CCMP area.

Zeta vs Chainlink CCIP

Like LayerZero, Chainlink CCIP uses an off-chain oracle, diverging substantially from thr Zeta architecture. CCIP is relatively new with low adoption outside of Synthetix and Aave but are making a push towards RWAs. Like L0, we do not see CCIP as intersecting with ZetaChain from a competitive standpoint too much. CCIP’s long-term goal is to be the protocol that banks and other real world companies use to issue their assets across chains. CCIP does not compete in the omnichain smart contract space as they are not an L1, and do not support BTC.

Zeta vs THORChain

“THORChain with smart contracts”, ZetaChain does share notable similarities to THORChain. For native BTC swaps, THORChain is the market leader, and there’s no second best. Unlike THORChain, ZetaChain does not need to rely on their own token for every application like THORChain does for swaps, savers, lenders and upcoming perps. The ratio of synths to native asset swap volume on THORChain can give us insight into what type of volume Zeta can see with its omnichain smart contract vs native asset swaps.

While they both support native BTC, the addition of an EVM and smart contracts makes Zeta a fairly different protocol than THORChain.