Foreword

ZetaChain (ZETA) is a Layer 1 blockchain designed to bridge the gap between various blockchain networks. Utilizing the Cosmos SDK and Tendermint consensus mechanism, it enables developers to custom-build scalable interoperable applications. The platform allows decentralized applications (DApps) to leverage the capabilities of multiple blockchains to address current cross-chain protocol issues and achieve full-chain cross-chain functionality. The use of Omnichain smart contracts and the ZetaEVM engine fosters interoperability, making ZetaChain a central integration hub.

How ZetaChain Works

Image Source: ZetaChain Official Website

ZetaChain leverages the Cosmos SDK, with the Tendermint consensus engine and Proof of Stake (PoS) model as its foundation, showcasing a unique ability for full-chain interoperability. It uses its own token as Gas fees and has the advantage of extending full-chain EVM smart contracts. As explained by Jed Barker, ZetaChain operates as follows:

• 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, which is compatible with the Ethereum Virtual Machine, allowing for cross-blockchain data interaction;
• Seamless Asset Transfer: Simplifies asset transfer between blockchains without the need for complex bridging. This includes support for blockchains without native smart contract functionality, such as Bitcoin;
• Cross-Chain Messaging: For simpler data exchanges (such as NFT transfers), ZetaChain offers cross-chain messaging capabilities, facilitating lightweight data transfer between different networks;
• Managing External Assets: ZetaChain extends its functionality to managing assets on other blockchains, applying smart contract logic to chains that typically lack this feature.

ZetaChain Architecture

Like other architectures, Zeta can provide numerous cross-chain messaging functions, but its unique advantage lies in supporting full-chain EVM contracts, dubbed as the “THORChain with smart contracts” or “Axelar with EVM.” It is built using the Cosmos SDK and CometBFT consensus to create a PoS blockchain, similar to THORChain. Zeta utilizes the ZETA token as a routing token for cross-chain messaging.

Here is the explanation: ZetaCore is the client that generates blocks and runs the Layer1, similar to other PoS blockchains. ZetaClient is responsible for cross-chain operations, with other nodes running both ZetaCore and ZetaClient. Zeta nodes perform three key functions: validation, observation, and signing, each operated by different roles within each node. This architecture enables two key functionalities: Omnichain smart contracts and cross-chain messaging.

Image Source: Delphi Creative

· Validators: Standard CometBFT validators, like on other PoS chains, stake ZETA and vote on blocks;

· Observers: Observers need to run full nodes of external chains, divided into sorters and validators. Sorters oversee events on external chains and send them to validators, who vote on the events to reach a consensus. The role of sorters is solely to ensure validity; any node can sort transactions. This makes running a Zeta node more costly than running a standard chain, similar to THORChain, which is also one reason THORChain has not added Solana support;

· Signers: Nodes share ECDSA/EdDSA keys, with only a supermajority (2/3) able to sign transactions on external chains. Signers are Zeta’s method for custodying assets and signing information on external chains. On smart contract platforms like Ethereum, they can be used to interact with smart contracts and custody assets, as well as custody assets on non-smart contract chains like Bitcoin and Dogecoin. The following image from the whitepaper shows the signing chart.

Image Source: Delphi Creative

Cross-Chain Information Transfer

CCMP enables the routing of information between other chains through the use of ZetaChain as an intermediary. In the field of other protocols such as LayerZero, Axelar, IBC, Chainlink CCIP, and to some extent, THORChain, competition unfolds in this direction. However, for ZetaChain, their cross-chain messaging protocol is implemented using their native token ZETA, fundamentally differentiating them from their competitors. Except for THORChain, other competitors do not rely on their native tokens for value transfer. An example from the whitepaper — a 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 would be:

1. Exchange ETH for ZETA on a Polygon AMM;
2. Send ZETA to ZetaChain;
3. Route ZETA from ZetaChain to Ethereum;
4. Exchange ZETA for USDC on Ethereum;
5. The user receives Ethereum USDC.

Image Source: Delphi Creative

Though logically viable, this solution requires significant capital, somewhat diminishing its competitiveness against intent protocols like Squid and UniswapX, as well as Circle’s CCTP, which occupies a substantial market share as a settlement track. Beyond capital efficiency, cross-chain messaging is a fiercely competitive arena.

Cross-Chain Smart Contracts

Deploying cross-chain smart contracts on Zeta provides numerous benefits for developers, going beyond simply using Zeta and zEVM for transaction facilitation. Firstly, it enables interactions with assets that inherently do not support smart contracts, such as BTC, DOGE, LTC. Secondly, by locating the application state on Zeta, it minimizes the vulnerability attack surface and does not rely on the liquidity of ZETA tokens for the transfer of value. Among its competitors, except for Axelar, which employs CosmWasm instead of EVM, no other protocols currently offer such a product, nor have they seen any adoption thus far.

ZetaChain’s cross-chain smart contracts are backed by the TSS protocol, with validators operating full nodes on external chains and sharing signatures, hence they can custody assets on behalf of ZetaChain and its users. The zEVM is then able to manipulate these assets as desired. It’s important to note that in this process, for example, BTC is not directly transferred from Bitcoin to Zeta, but to addresses custodied by Zeta validators and then represented on ZetaChain, similar to how THORChain adds smart contract capabilities to protocol-custodied BTC.

Image Source: Delphi Creative

Under this framework, Zeta has the capability to develop many unique protocols, for instance:

• A cross-chain CDP stablecoin backed by BTC;
• Money markets for BTC, DOGE, LTC, and other non-smart contract assets;
• A cross-chain Perp DEX;
• A cross-chain yield aggregator;
• BTC AMMs.

Fundamentally, the combination of ZetaChain’s zEVM and ZetaClient is distinctive for its custody and control over assets on chains that do not support smart contracts directly. While most cross-chain platforms are used as backend infrastructure, ZetaChain facilitates the creation of its own cryptocurrency economy on ZetaChain.

Utility of the ZETA Token

ZETA serves as the cornerstone of the ZetaChain ecosystem, playing a crucial role in programmability and governance. ZetaChain is distinguished by its interoperability and support for cross-chain dApps, with key network activities dependent on ZETA.

Key Functions of the ZETA Token Include:

• Network Incentives: ZETA tokens incentivize 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 for Gas fees, which are distributed to validators and network participants, helping prevent 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 target chain, eliminating the need for creating new wrapped assets;
• Core Liquidity Pools: ZetaChain’s liquidity pools, comprised of ZETA and other assets, facilitate user transactions and pay fees and rewards to liquidity providers;
• Governance Role: ZETA holders participate in network governance, influencing key decisions and policy changes to ensure the network evolves with the community at the forefront.

Overall, the multifaceted utility of ZETA supports the security, efficiency, and decentralized governance of ZetaChain, making it a vital component of the network’s functionality.

ZETA Token Economy and Issuance The initial total supply of ZETA tokens is set at 2.1 billion, with a planned inflation rate of approximately 2.5% per year after four years. The token distribution (see Reference Link 1) is strategically allocated across various segments of the ecosystem:

• User Growth Pool (10%): Aims to expand the user base through airdrops and community rewards;
• Ecosystem Growth Fund (12%): Supports ecosystem development, aiding partners and dApp developers;
• Validator Rewards (10%): For block rewards, transitioning to network security rewards based on inflation after the initial phase;
• Liquidity Incentives (5.5%): Encourages liquidity in core ZRC-20 pools, crucial for effective value transfer;
• Protocol Treasury (24%): Funds operations, development, and ecosystem strengthening;
• Core Contributors, Advisors, and Purchasers (22.5% and 16%): Rewards contributions to the development and growth of ZetaChain.

Cross-Chain DEX

Unlike the current state of cross-chain deployments, ZetaChain, as the foundational layer of the protocol, can enable liquidity interoperability among all different deployments. For instance, users on ZetaChain could deposit their margin into a central contract and hold positions on GMX. This forms the core premise of Zeta cross-chain applications (with the position management layer located on Zeta), suggesting that users wanting to utilize the full liquidity of GMX would need to use ZetaChain.

Beyond ensuring execution quality, there are two key advantages:

• Similar to the MUX aggregator (see Reference Link 2), it allows for splitting asset orders across various liquidity sources;
• Enables access to more trading pairs without the need to manually connect all relevant chains.

Smart contracts on ZetaChain can directly deposit the required margin amount to the relevant chain, along with instructions on how to use these assets. Although this process technically does not necessitate ZetaChain, it can enhance the user experience by:

• Facilitating inter-chain interactions;
• Allowing comprehensive management rather than isolated management.

The market leader in the DEX space, UniSwap, might shift its operational hub from Ethereum to any other chain. However, theoretically, by deploying on ZetaChain and using the ZRC-20 standard, users could swap in and out of any asset (across any chain) and custody the said assets on any chain of their choice.

ZetaChain’s Competitors

LayerZero

Image Source: LayerZero Official Website

In the cross-chain transfer market, LayerZero stands as ZetaChain’s biggest competitor. Although they do not engage in the competition within the full-chain smart contracts realm, their market position in cross-chain transfers is very solid. Their main advantage comes from Stargate, followed by their promotion of the OFT standard (providing a new solution for cross-chain token transfers, making it simpler and more efficient to transfer tokens between different chains).

LayerZero Architecture

To briefly introduce, LayerZero is a protocol that allows “user applications” to send information across blockchains. The architecture consists of 4 main parts:

• User Applications: Contracts that interact with LayerZero endpoints and send/receive information (e.g., Stargate);
• 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 4 modules: Communicator, Verifier, Network, and Libraries. The first three modules are standardized across all chains, while Libraries are customized according to different chain logics, enabling LayerZero to rapidly add more chains;
• Oracles: Responsible for reading block headers from one chain and sending them to another. Currently, this role is defaultly undertaken by Chainlink, but a new partnership with Google Cloud has replaced Chainlink as the default since September 2023;
• Relayers: Similar to relayers, but they acquire proofs instead of block headers. Although applications themselves can act as relayers, it is practically handled by LayerZero.

This design essentially boils down to a 2/2 multisig, where the primary trust assumption is that Google Cloud and LayerZero will not collude. Relying on these off-chain components (like oracles and relayers) benefits from a lightweight, cheap, and scalable architecture but has the downside of depending on two centralized entities, potentially exposing it to censorship risks.

Axelar

Image Source: Axelar Official Website

Compared to LayerZero, Axelar’s structure is more similar to Zeta but with notable differences. Like ZetaChain, Axelar is also developed using the Cosmos SDK. However, it does not directly host EVM, thus not supporting the same type of full-chain smart contracts as Zeta. Therefore, Axelar’s target market is cross-chain messaging, similar to LayerZero.

Axelar Architecture

Axelar is a PoS chain with its validator set and staking token AXL, consisting of and processing information as follows:

• Cross-Chain GMP Requests: An API allowing applications to send arbitrary data across chains. These message requests are sent to Axelar Gateways (online platforms or digital systems using blockchain technology for transferring digital currency from one address to another);
• Gateways: The first stop for cross-chain messages initiated by users/applications for routing from the source to the destination chain. For EVM chains, these are smart contracts, while for Cosmos, these are application logic. Gateways are secured by Axelar validators using MPC, whose shares are weighted by AXL token delegations;
• Message Handling & 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 incentive mechanisms, and relayers are operated by Axelar;
• Information Verification: Validators vote on information received from relayers. Each Axelar validator runs a full node for each source chain, thus able to verify the message’s validity. In contrast to typical Cosmos PoS blockchains, where validators rely on light clients and IBC for message passing, Axelar validators require more resources. In a sense, this model’s scalability is not as extensive as LayerZero’s, but it offers a higher degree of decentralization. Axelar incentivizes its validators with additional surveillance rewards; the more chains they support, the more rewards they receive. Over the long term, the chains supported need to generate enough fees from cross-chain activities, as the token rewards for supporting validators running over 50 full nodes will be depleted. Supporting every chain may not be feasible; instead, they will likely concentrate around the main liquidity chains;
• Submitting Information to the Destination: Relayers listen for authorized information from Axelar validators and push it to the destination chain’s gateway. Once the destination chain receives approved information, its payload is marked as approved by Axelar validators. Now, anyone can execute that payload;
• Gas and Executor Services: In the final step, Axelar deploys a contract called “Gas Receiver” on EVM chains to pay the Gas fees on the destination chain and execute the cross-chain payload (sending it to the required application). Users can pay using the source chain’s Gas token, while Axelar takes a cut of the destination chain’s Gas.

Overall, besides supporting EVM on its chain,its structure is similar to ZetaChain, except for supporting EVM on its own chain. In terms of security, Delphi Research considers it safer than LayerZero’s 2/2 model, although it still has some shortcomings. The likelihood of collusion between Google and LayerZero is significantly low since applications can run their own relayers.

Chainlink CCIP

Image Source: Chainlink Official

The Cross-Chain Interoperability Protocol (CCIP) does not differ significantly from other cross-chain information platforms, where a user sends information on one chain, it gets forwarded to CCIP, and then CCIP forwards the information to the destination chain. What sets CCIP apart is how it utilizes Oracle Networks, and the addition of 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 the transaction to the destination-specific OnRamp contract, receives information from the destination chain’s OffRamp, and routes it to the final user/contract;
• Commit Store: Commits DON stores the source chain’s Merkle root on the target chain. The Merkle root must be “validated” by the Risk Management Network;
• OnRamp: One contract per chain (blockchain to blockchain). Validates information and tracks token transfers/information, manages billing, etc. Monitored by Committing DON;
• OffRamp: Similar to OnRamp, one contract per chain. Validates execution DON with the submitted and “validated” Merkle Root, ensuring the authenticity of information, and conveys information to the router;
• Token Pool: Tokens can be “lock and mint” or “burn and mint,” depending on the token. For example, native Gas tokens must be locked and minted since CCIP does not have minting rights. If integrated with CCTP, USDC can be “burn and mint”;
• Risk Management Network Contract: Contains a list of Risk Management Network nodes that can “validate” (approve) or “invalidate” (disapprove) transactions.

Off-Chain Components:

• Committing DON: As mentioned, Committing DON monitors OnRamp contract events, waits for the source chain results, and creates a Merkle Root (signed by statutory Committing DON oracle nodes), eventually written into the target chain’s Commit Store contract;
• Risk Management Network: A network of nodes essentially performing a double-check on the Merkle root submitted by DON. They monitor the OnRamp contract and the content posted by Committing DON in the commit store. If the RMN does not “validate” (i.e., verify/confirm) the Merkle Root, CCIP will freeze;
• Executing DON: Similar to committing, but oversees information like the Risk Management Network. Once the RMN issues a “validation,” Executing DON calls the OffRamp contract to complete the destination’s CCIP transaction.

Summary

In reality, to break the isolation effect between chains, addressing the issues of “multi-chain communication” and “cross-chain communication” is of paramount importance. 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 issues of blockchain fragmentation and lack of interoperability. 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 lead to double spending, censorship, reorgs, hard forks, chain splits, etc.

Currently, LayerZero and Axelar are leading in the application of cross-chain information. However, it is still too early to declare a definitive leader. While looking forward to the new solutions from ZetaChain, there is also anticipation for continuous iteration and innovation from LayerZero, Axelar, Chainlink CCIP, and others.

Disclaimer：

1. This article is reprinted from [Medium], All copyrights belong to the original author [YBB ]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.