ZetaChain: A New Competitive Landscape for Multi-Chain and Cross-Chain Communication

Author: YBB Capital Researcher Ac - Core

ZetaChain (ZETA) is a Layer 1 blockchain designed to bridge the gaps between various blockchain networks, utilizing the Cosmos SDK and Tendermint consensus mechanism, allowing developers to custom-build scalable interoperability applications. The platform enables decentralized applications (DApps) to leverage the capabilities of multiple blockchains to address the issues present in current cross-chain protocols and achieve full-chain cross-chain functionality, using Omnichain smart contracts and the ZetaEVM engine to facilitate interoperability, making ZetaChain an integration hub.

How ZetaChain Works

Image source: ZetaChain official website

ZetaChain utilizes the Cosmos SDK, based on the Tendermint consensus engine and Proof of Stake (PoS) model, showcasing unique capabilities for full-chain interoperability and using its own token as gas fees, with advantages in scaling full-chain EVM smart contracts. According to Jed Barker, the operation of ZetaChain is described as follows:

1. OmniChain Smart Contracts: The core of ZetaChain is smart contracts that can interface with multiple blockchains. These smart contracts are supported by the ZetaEVM engine, compatible with the Ethereum Virtual Machine, enabling data interaction across different blockchains;
2. Seamless Asset Transfer: Simplifying asset transfers between blockchains without complex bridging. This includes support for blockchains without native smart contract functionality, such as Bitcoin;
3. Cross-Chain Messaging: For simpler data exchanges (like NFT transfers), ZetaChain provides cross-chain messaging capabilities, facilitating lightweight data transfer between different networks;
4. Managing External Assets: ZetaChain extends its functionality to manage assets on other blockchains, applying smart contract logic to chains that typically lack this capability.

ZetaChain Architecture

Like other architectures, Zeta can provide many cross-chain messaging functionalities, but its unique advantage lies in supporting full-chain EVM contracts, i.e., "THORChain with smart contracts" or "Axelar with EVM." It builds a PoS blockchain using the Cosmos SDK and CometBFT consensus, similar to THORChain, with ZETA tokens used as routing tokens for cross-chain messaging.

The following explains that Zeta Core is the client that generates blocks and runs Layer 1. Similar to other PoS blockchains, the Zeta Client is responsible for cross-chain operations, with other nodes needing to run both Zeta Core and Zeta Client simultaneously. Zeta nodes perform three key functions: validation, observation, and signing, with each node responsible for these three different roles. This architecture enables two key functionalities: OmniChain smart contracts and cross-chain messaging.

Image source: Delphi Creative

• Validators: Standard CometBFT validators who, like other PoS chains, stake ZETA and vote on blocks;
• Observers: Observers categorize full nodes that need to run external chains into sorters and validators. Sorters monitor events on external chains and send them to validators, who vote on the events and reach consensus. The role of sorters is merely to ensure validity; any node can sort transactions. This makes running Zeta nodes more resource-intensive than running standard chains, similar to THORChain, which is one reason why THORChain has not added Solana support;
• Signers: Nodes share ECDSA/EdDSA keys, requiring a supermajority (2/3) to sign transactions on external chains. Signers are Zeta's method of safeguarding assets and signing information on external chains. On smart contract platforms like Ethereum, they can interact with smart contracts and manage assets, and they can also manage assets on non-smart contract chains like Bitcoin and Dogecoin. The following image is a signing diagram from the white paper.

Image source: Delphi Creative

Cross-Chain Information Transmission

CCMP routes information between other chains using ZetaChain in the middle. Other protocols like LayerZero, Axelar, IBC, Chainlink CCIP, and THORChain are competing in this direction to some extent. However, for ZetaChain, their cross-chain messaging protocol is achieved through the use of the native token ZETA, which fundamentally distinguishes them from their competitors, as all other competitors, except THORChain, do not rely on their native tokens for value transfer. An example from the white paper—cross-chain DEX—intuitively demonstrates ZETA's role in messaging. In this example, if a user wants to exchange 1.2 ETH on Polygon for USDC on Ethereum, the path is as follows:

1. Swap ETH for ZETA on Polygon AMM;
2. ZETA is sent to ZetaChain;
3. ZETA is routed from ZetaChain to Ethereum;
4. Swap ZETA for USDC on Ethereum;
5. The user receives USDC on Ethereum.

Image source: Delphi Creative

While the logic is feasible, this solution requires substantial capital. This somewhat diminishes product competitiveness, as intention protocols like Squid and UniswapX, as well as Circle's CCTP as a settlement track, occupy a significant market share. Beyond capital efficiency, cross-chain messaging is also a fiercely competitive field.

Full-Chain Smart Contracts

Developers deploying full-chain smart contracts on Zeta have many advantages over merely using Zeta and zEVM to facilitate transactions. First, it allows interaction with native assets that do not support smart contracts, such as BTC, DOGE, and LTC. Secondly, since the application state is located on Zeta, it somewhat reduces the attack surface for vulnerabilities and does not rely on the liquidity of ZETA tokens for value transfer. Except for Axelar, the aforementioned competitors currently lack this type of product, as Axelar uses CosmWasm instead of EVM and has not yet gained any adoption.

Full-chain smart contracts on Zeta Chain are supported by the TSS protocol, where its validators run full nodes on external chains and share signatures, allowing them to safeguard assets on behalf of Zeta Chain and its users, with zEVM able to manipulate these assets at will. It should be noted that the process is akin to BTC; it does not actually transfer from Bitcoin to Zeta but rather to an address hosted by Zeta validators and then manifests on Zeta Chain, similar to how THORChain adds smart contracts to BTC hosted by the protocol.

Image source: Delphi Creative

Under this architecture, Zeta can build many specialized protocols, including but not limited to:

• A full-chain CDP stablecoin backed by BTC;
• A money market supporting BTC, DOGE, LTC, and other non-smart contract assets;
• A full-chain Perp DEX;
• A full-chain yield aggregator;
• BTC AMMs.

Essentially, the distinctiveness of ZetaChain's zEVM combined with ZetaClient lies in the custody and control of assets on non-smart contract chains. Most current cross-chain platforms serve primarily as backend infrastructure, but ZetaChain can create its own crypto economy on ZetaChain.

Utility of the ZETA Token

ZETA is the cornerstone of the ZetaChain ecosystem, playing a crucial role in functional programmability and governance. ZetaChain is most notable for its interoperability and support for full-chain dApps, with its key network activities relying on ZETA.

Overview of the main functions of the ZETA token:

• Network Incentives: The ZETA token incentivizes validators through block rewards, transitioning from a fixed pool to variable inflation. This system aligns the interests of validators with the long-term security of the network;
• Transaction Fees: Transactions within ZetaChain require ZETA to pay gas fees, which are distributed to validators and network participants, preventing spam and DDoS attacks;
• Cross-Chain Messaging and Value Transfer: For cross-chain transactions, ZETA is burned on the source chain and minted on the destination chain, eliminating the need to create new wrapped assets;
• Core Liquidity Pool: ZetaChain's liquidity pool consists of ZETA and other assets, facilitating user trading and paying transaction fees and rewards to liquidity providers;
• Governance Role: ZETA holders participate in network governance, influencing key decisions and policy changes, ensuring the network's development is community-driven.

Overall, the multifaceted utility of ZETA supports the security, efficiency, and decentralized governance of ZetaChain, making it an essential component of network functionality.

ZETA Token Economics and Distribution

The initial total supply of ZETA tokens is 2.1 billion, with a planned inflation rate of about 2.5% per year after four years. Token distribution (see reference link 1) will be strategically allocated across various aspects of the ecosystem:

• User Growth Pool (10%): Aimed at expanding the user base through measures like airdrops and community rewards;
• Ecosystem Growth Fund (12%): Supporting ecosystem development and assisting partners and dApp developers;
• Validator Rewards (10%): Transitioning from block rewards to inflation-based network security rewards after the initial phase;
• Liquidity Incentives (5.5%): Encouraging liquidity for core ZRC-20 pools, which are crucial for effective value transfer;
• Protocol Treasury (24%): Funding operations, development, and ecosystem strengthening;
• Core Contributors, Advisors, and Purchasers (22.5% and 16%): Rewarding contributions to the development and growth of ZetaChain.

Full-Chain DEX

Unlike the current state of cross-chain deployments, Zeta Chain, as the foundational layer of the protocol, can achieve liquidity interoperability across all different deployments. For example, users on Zeta Chain can deposit their margin into a central contract and hold positions on GMX. This is the core assumption of Zeta cross-chain applications (the position management layer will be located on Zeta), meaning that users wishing to utilize the full liquidity of GMX must use Zeta Chain.

In addition to ensuring execution quality, there are two key advantages:

• Similar to MUX aggregators (see reference link 2), it can split asset orders between various liquidity sources;
• Access to more trading pairs without manually connecting all relevant chains.

Smart contracts on ZetaChain can directly deposit the required margin amount into the relevant chain, along with information on how to use these assets. While this process can technically be achieved without ZetaChain, it improves user experience:

• Inter-chain interaction;
• Comprehensive management rather than isolated management.

The market leader in DEX, UniSwap, would shift its foundational center from Ethereum to any other chain, but theoretically, by deploying on ZetaChain and using the ZRC-20 standard, users can swap in and out of any asset (on any chain) and host the said assets on any chain they wish.

Competitors of Zeta Chain

LayerZero

Image source: LayerZero official website

In the cross-chain transmission market, LayerZero is ZetaChain's biggest competitor. While they do not compete in the full-chain smart contract space, they have a very solid market position in cross-chain transmission. Their main advantage comes from Stargate, followed by promoting the adoption of their OFT standard (which provides a new solution for cross-chain token transfers, making it simpler and more efficient to transfer tokens between different chains).

LayerZero Architecture

First, a brief introduction: LayerZero is a protocol that allows "user applications" to send information between blockchains. The architecture consists of four main components:

1. User Applications: Contracts that interact with LayerZero endpoints and send/receive information (such as Stargate);
2. LayerZero Endpoints: A series of smart contracts on different chains (currently supporting over 40+, see reference link 3). Endpoints allow user protocols to send information through the LayerZero backend, consisting of four modules: communicator, validator, network, and library. The first three modules are standardized across all chains, while the library is customized based on different chain logic, allowing LayerZero to quickly add more chains;
3. Oracles: Responsible for reading the header block from one chain and sending it to another chain. This role is currently defaulted to Chainlink, but starting in September 2023, a new partnership with Google Cloud has replaced Chainlink as the default role;
4. Relayers: Similar to relayers but obtain proofs instead of header blocks. While applications themselves can also act as relayers, it is primarily handled by LayerZero.

This design can essentially be summarized as a 2/2 multi-signature, where the main trust assumption is that Google Cloud and LayerZero do not collude. The benefit of relying on these off-chain components (like oracles and relayers) is that the architecture is lightweight, cheap, and easy to scale, while the downside is the reliance on two centralized entities, which may be susceptible to censorship-related risks.

Axelar

Image source: Axelar official website

Compared to LayerZero, Axelar's structure is more similar to Zeta but has notable differences. Like Zeta Chain, Axelar is also developed based on the Cosmos SDK. The difference is that it does not directly host EVM, thus not supporting full-chain smart contracts like Zeta. Therefore, Axelar's target market is cross-chain messaging, similar to LayerZero.

Axelar Architecture

Axelar is a PoS chain with its own set of validators and staking token AXL, with the following components and information flow:

• Cross-Chain GMP Requests: An API that allows applications to send arbitrary data across chains. These message requests are sent to the Axelar gateway (an online platform or digital system that utilizes blockchain technology to transfer digital currency from one address to another);
• Gateway: The first place where cross-chain messages initiated by users/applications pass through to route from the source chain to the destination chain. For EVM chains, these are smart contracts, while for Cosmos, these are application logic. The gateway is secured by Axelar validators using MPC, with shares weighted by AXL token delegation;
• Message Processing and Relayers: Relayers listen for events (gateway information) and submit them to the Axelar network for processing. While anyone can run a relayer, there are no incentives; relayers are operated by Axelar;
• Information Validation: Validators vote on the information received from the relayers. Each Axelar validator runs a full node for each source chain, thus able to validate the validity of messages. In contrast to typical Cosmos PoS blockchains, Axelar validators require more resources, as they rely on light clients and IBC to relay messages. In a sense, this model is less scalable than LayerZero but has a higher degree of decentralization. Axelar incentivizes validators by providing more monitoring rewards; the more chains they support, the more rewards they receive. In the long run, supported chains need to generate sufficient fees from cross-chain activities, as supporting validators running more than 50 full nodes will deplete token rewards. Supporting every chain may not be feasible; instead, they will cluster around major liquid chains;
• Submitting Information to the Destination: Relayers listen for authorization information issued by Axelar validators and push it to the target chain gateway. When the target chain receives the approved information, its payload is marked as approved by Axelar validators. Now anyone can execute that payload;
• Gas and Executor Services: The final step, Axelar deploys a contract called "Gas Receiver" on EVM chains to pay gas fees for the destination chain and execute cross-chain payloads (sending them to the desired application). Users can pay with source chain gas tokens, while Axelar extracts gas from the target chain.

Overall, besides supporting EVM on its own chain, its structure is similar to ZetaChain. In terms of security, Delphi Research believes it is more secure than LayerZero's 2/2 model, although there are still some shortcomings, but the likelihood of collusion between Google and LayerZero is extremely low (applications can run their own relayers).

Chainlink CCIP

Image source: Chainlink official

CCIP is not significantly different from other cross-chain information platforms, where users send information on one chain, which is forwarded to CCIP, and then CCIP forwards the information to the destination chain. The difference with CCIP lies in how it utilizes the oracle network and introduces another entity: the Risk Management Network.

CCIP is divided into on-chain and off-chain components.

On-Chain Components

• Router: Initiates cross-chain transactions. Routes transactions to the destination-specific OnRamp contract, receives information from the destination chain's OffRamp, and routes it to the end user/contract;
• Commit Store: Submits the Merkle root from the source chain to the target chain. The Merkle root must be "verified" by the Risk Management Network;
• OnRamp: A contract for each chain (from blockchain to blockchain). Validates information and tracks token transfers/information, manages billing, etc. Published under the monitoring of the Committing DON;
• OffRamp: Similar to OnRamp, a contract for each chain. Ensures the authenticity of information by validating the executing DON against the submitted and "verified" Merkle Root and transmits information to the router;
• Token Pool: Tokens can be "locked and minted" or "burned and minted," depending on the token. For local gas tokens, they must be locked and minted, as CCIP does not have minting rights; if integrated with CCTP, USDC can be "burned and minted";
• Risk Management Network Contract: Contains a list of risk management network nodes that can "verify" (approve) or "fail verification" (disapprove) transactions.

Off-Chain Components

• Submitting DON: As above, the submitting DON monitors events from the OnRamp contract, waits for results from the source chain, and creates a Merkle Root (signed by the legal submitting DON oracle nodes), which is ultimately written to the CommitStore contract on the target chain;
• Risk Management Network: A network of nodes that essentially double-checks the Merkle root submitted by the submitting DON. They monitor the OnRamp contract and the content published by the submitting DON in the commit storage area. If the RMN does not "verify" (i.e., validate/confirm) the Merkle Root, CCIP will freeze;
• Executing DON: Similar to committing but supervises information like the Risk Management Network. Once the RMN issues a "verification," the executing DON calls the OffRamp contract to complete the CCIP TX at the destination.

Conclusion

In reality, to break the island effect between chains, the issues of "multi-chain communication" and "cross-chain communication" are paramount to be resolved. Compared to other solutions, the core advantage of the ZetaChain project lies in its cross-chain interoperability capabilities, making interoperability between different blockchains possible and addressing the current fragmentation and lack of interoperability in blockchains. It aims to enable full-chain dApps to directly interact natively with different blockchains without the need to wrap or bridge any assets. However, there are security risks associated with external chains connected to ZetaChain, which may be susceptible to attacks, potentially leading to double spending, censorship, rollbacks, hard forks, chain splits, etc.

Currently, LayerZero and Axelar are leading in the application of cross-chain information. However, it is still early days, and no one can truly claim to be ahead. While looking forward to ZetaChain's new solutions, we also anticipate continuous iteration and innovation in technologies like LayerZero, Axelar, and Chainlink CCIP.

Reference Articles:

1. Future Opportunities for Full-Chain Applications https://members.delphidigital.io/reports/zetachain-part-2-the-opportunity-ahead-for-omnichain-applications#consumer-aggregation-apps--improving-the-on-chain-derivatives-experience-56d5

2. What is ZetaChain? https://www.datawallet.com/crypto/what-is-zetachain

3. Competitive Landscape of Blockchain Bridging https://members.delphidigital.io/reports/zetachain-part-1-a-competitive-landscape-of-blockchain-bridges#architecture-ed17

Extended Links:

(1) Zera Token Distribution https://www.zetachain.com/docs/about/token-utility/distribution/

(2) MUX Aggregator Whitepaper https://docs.mux.network/protocol/overview/leveraged-trading-aggregator

(3) LayerZero Supported Contracts https://layerzero.gitbook.io/docs/technical-reference/mainnet/supported-chain-ids