Introduction to Chain Abstraction

One of the main differences between web3 and web2 applications is their ease of use. In web2, users are generally unaware of the complexities happening behind the scenes. For example, when sending an email through Gmail, the user simply types and clicks send. The system then handles server communications, data encryption, and spam filtering without any user intervention. Similarly, ordering food on UberEats involves integrating restaurant menus, payment gateways, and delivery tracking seamlessly. This is the same with payment systems, messaging services and others. All of this underlying complex technology is abstracted away from the user.

In fact, applications push it further by adding automated processes on top. Netflix doesn’t just abstract away the underlying tech, but deliberately starts the next episode without the viewer so much as pressing a button. These applications are in the business of extending the time spent as much as possible, and a clunky interface is as good as handing over their business to competitors.

A web3 application might not be more complicated than web2 ones that already handle billions of consumers. But they sure feel like they’re built only for the people with an IQ higher than Gary Kasparov. The amount of options and steps involved in using web3 is overwhelming for the average user. Users are confronted by a huge number of chains, bridges, and other pieces of connecting infrastructure. Managing multiple wallets and protecting seed phrases adds more complexity. All this needs to change if we want to build platforms that will power the next generation of consumer applications.

Chain Abstraction

Account abstraction has gained attention for good reasons. It is an important step forward in simplifying web3 UX. Features like passkeys, account recovery, and gas abstraction are valuable improvements. However, they address only a small part of the overall UX challenges.

The hurdle lies in the sheer number of rollup choices, L1s, bridges, and dApps to carry out actions beyond the account related problems. This fragmentation creates a complex and confusing landscape for users. Chain abstraction addresses these issues by extending the addressable UX problems to their maximum scope. The idea is to imagine an ideal state of user interaction, where, similar to the web2 experience, the user doesn’t need to understand what a blockchain or bridges are.

In an ideal world, using a web3 application should be as intuitive as sending an email or ordering food online. The user shouldn’t need to know which blockchain their transaction is on, how to choose the right bridge, or how to manage multiple wallets and seed phrases. Instead, all these complexities should be seamlessly handled in the background. This way, users can focus on their intended activities without being burdened by the underlying technical details.

Many efforts are underway to address this problem. The CAKE framework, Near protocol, Particle network — address these problems by dividing it into layers focused on each problem. Few projects are vertically integrating across the layers, while others focus on a single one. Broadly, there are account aggregation problems, routing problems, solving, bridge selection problems.

The Frontier group, with their CAKE framework has proposed a three-layered stack designed to tackle these problems systematically.

• Permission Layer: This layer handles accounts and permissions. It includes smart contract wallets and proxy services, which aim to abstract user interactions and maintain a balance between ease of use and user control.
• Solver Layer: The second layer focuses on solver markets and the competition among them. This layer addresses the routing problem by finding the optimal solution for users based on their preferences for speed, cost, and efficiency. Solver markets compete to provide the best routes for transactions, enhancing the overall user experience by automating the decision-making process and reducing the cognitive load on users.
• Settlement Layer: The final layer is responsible for settling interactions. It utilizes bridges, oracles, and other cross-chain solutions to ensure that transactions are completed efficiently and accurately. This layer abstracts the complexity of cross-chain interactions.

We’ll compare different solutions in these layers in detail later. ZetaChain is one of these solutions that addresses more than one problem.

On a high level, ZetaChain is a Cosmos SDK-based L1 using CometBFT. It is built to deploy omnichain smart contracts and provide a unified application experience. This is its core value proposition. Developers can deploy just a single contract and ZetaChain will take care of the cross-chain interactions. In the following sections, we will first explore how ZetaChain operates, and a high level understanding of its mechanics. Later, we will discuss the enhancements in version 2.0, highlighting the new features and improvements.

ZetaChain Architecture

ZetaChain components and their functions:

• Universal EVM: A modified Ethereum Virtual Machine (EVM) designed for building omni-chain apps.
• Communication Mechanism:
  • Omnichain: an interoperability layer that allows developers to build omnichain apps, which can be called from connected chains.
  • Connector API: point-to-point cross-chain messaging that supports arbitrary data and value transfer.
• ZRC-20: a standard for omnichain fungible tokens. Native gas and supported ERC-20 tokens can be sent from connected chains to omnichain apps as ZRC-20s. A ZRC-20 token can be withdrawn back to the connected chain.
• TSS Signers: Validators with additional responsibilities, including signing and monitoring outbound transactions.
• TSS Addresses: Specific addresses used for depositing tokens and initiating cross-chain interactions.

ZetaChain, like Near protocol and Lit uses Threshold signatures. A Threshold Signature Scheme (TSS) is a cryptographic method where a signature is generated collaboratively by a group of participants. It requires a minimum threshold number of participants (e.g., 3 out of 5) to produce a valid signature, with each participant holding a share of the private key. This enhances security by distributing the private key across multiple parties, protecting against single points of failure and ensuring fault tolerance.

On ZetaChain, observer-signer validators run two different pieces of software:

• ZetaChain Node: blockchain node that handles cross-chain transactions, management of ZRC-20 minting, omnichain app calls and more.
• ZetaClient: off-chain program run by observer-signers to observe transactions on connected blockchains and sign and broadcast transactions on connected chains on behalf of ZetaChain.

These TSS signers continuously monitor the deposit addresses across all supported chains, ensuring that they relay information upon successful transactions, triggering activities on ZetaChain. Additionally, they are responsible for signing outbound transactions, dispatched for processing on other chains.

This makes the contracts deployed on Universal EVM not just limited to ZetaChain. They can be called from connected chains.

Inbound Communication:

The user can interact with a dApp built on ZetaChain from any external chain. TSS observers monitor a special deposit address for native gas tokens and an ERC-20 custody contract for ERC-20 assets. A transaction to this deposit address or an ERC-20 custody contract is created with function call information embedded in it. The TSS observers verify and send this to the system contract, which calls the OnCrossChainCall function in the appropriate contract to execute it.

Outbound communication:

Contracts on ZetaChain can make calls to connected chains using the Connector API. A contract calls the Connector contract with details such as the chain ID, contract address, and message. ZetaChain then processes this call and forwards these details to the target chains, where the recipient contract’s “onZetaMessage” function is called.

These mechanisms ensure that ZetaChain contracts can both respond to and initiate requests with other chains effectively, with minimal effort from the dApp developer or user.

Inbound and Outbound communication between ZetaChain and external chains is triggered by users from their frontend. This means they can interact with a straightforward frontend, without needing to understand the underlying mechanics.

After understanding the foundational ZetaChain architecture, let’s turn our attention to the latest iteration — ZetaChain 2.0 and its expanded capabilities.

ZetaChain 2.0

ZetaChain 2.0 is the next iteration incorporating a number of new additions to make the previous experience more complete. It supports a wider range of compatible Bitcoin addresses, replaces the Connector API with extended omnichain capabilities, and omnichain accounts for easier user experience.

The new ability of calling contracts on connected chains directly from universal apps enables powerful omnichain applications. Applications can now handle complex multi-leg transactions involving various assets and interactions across multiple chains, all streamlined into a single user step. For example, a user on Bitcoin can trigger a ZetaChain contract that executes additional contracts on Ethereum, BNB, and other chains seamlessly.

Universal Applications

One of the biggest additions in ZetaChain 2.0 is Universal apps. ZetaChain 1.0 offered two separate capabilities: cross-chain messaging and omnichain applications. With cross-chain messaging using the Connector API, users could send arbitrary messages between connected chains using ZetaChain as a relayer. Omnichain functionality allowed universal apps to accept calls from and manage fungible tokens on connected chains.

In ZetaChain 2.0, the Connector API is being replaced with extended omnichain capabilities that let universal apps call contracts on connected chains. For example, a user can stake BTC, send the LST to BNB, swap the LST, and then lend it on Polygon, all in a single interaction. This turns the applications from Omnichain, to universal applications with multi-leg flows.

In terms of change in mechanism, the Gateway shifts the communication into a hub and spoke model with reduced costs and execution steps. The earlier connector API method was a more of a point to point communication and introduced more steps, costs etc. Gateway acts as the entry point for the user and simplifies the interactions.

Below are some details:

• Extending the Omnichain FunctionalityZetaChain 2.0 allows universal apps to withdraw ZRC-20 tokens while simultaneously making a call to a contract on a connected chains with withdrawAndCall function. Universal apps can also make contract calls on connected chains without withdrawing tokens.
• Sunsetting the Connector APIInstead of having separate APIs for omnichain and cross-chain messaging, ZetaChain 2.0 offers a consistent and unified set of APIs for building universal applications.
• Gateway ContractZetaChain 2.0 introduces Gateway contracts that act as a single entrypoint on connected chains for developers to interact with universal apps. Instead of sending native gas assets to TSS address and ERC-20 to a custody contract, developers will have a single Gateway contract to interact with.
• Enabling Staking ZETA Tokens from ContractsZetaChain 2.0 introduces the ability for smart contracts stake native ZETA tokens on chain. This makes it easier for developers to build universal apps that are capable of staking ZETA in a decentralized way without relying on off-chain programs.
• Modular Code StructureEarlier versions had bundled state transition and messaging logic, making the code complex. The new version has separated state transition and messaging logic, simplifying the codebase and improving its manageability and maintainance.

Omnichain Accounts

Omnichain accounts simplify how users manage assets across multiple blockchains. The introduction of the withdrawAndCall function in ZetaChain 2.0 allows users to perform asset withdrawals and smart contract calls in a single transaction across chains. This function first secures the necessary gas fees, then burns the specified tokens from the user’s account before executing further actions on the destination chain.

The withdrawAndCall function on ZetaChain simplifies transactions by combining multiple steps into one. It calculates and transfers necessary gas fees for both ZetaChain and the target chain. Then, it securely burns the specified amount of tokens from the user’s account. An event called WithdrawalAndCall is emitted, logging the withdrawal and providing the data needed for a smart contract call on the destination chain. Finally, the specified actions are executed on the target chain.

It reduces the need for multiple steps and network switches, making cross-chain operations much simpler. For example, a user using a yield aggregator on ZetaChain can withdraw tokens, send them to another chain, and execute investment commands on a smart contract on that chain—all in a single transaction.

Complete BTC experience

ZetaChain 1.0 supported only transactions using specific addresses, which limited interactions. In ZetaChain 2.0, they have expanded its compatibility to include a wider array of Bitcoin address types—P2PKH, P2SH, P2WSH, and P2TR. This makes it accessible and user-friendly for all transaction types. Additionally, with the inclusion of Taproot (P2TR) and continued support for SegWit-based addresses (P2WPKH and P2WSH), users now enjoy benefits such as improved privacy, reduced transaction fees, and increased transaction efficiency.

Transaction types in BTC

This is made possible through updates in three areas:

1. Address Handling
   • Enhanced Decoding: ZetaChain 2.0 has decoding capabilities tailored to recognize and process different formats of Bitcoin addresses like P2PKH, P2SH, P2WSH, and P2TR. These decoding functions are important for identifying each address type, extracting key components like public key hashes or script hashes, and performing thorough validations to ensure accuracy and security.
   • Support for Taproot (P2TR): Taproot supports multisig, complex spending conditions, and enhanced privacy. This address type uses unique features like Schnorr signatures and advanced scripts, which are different from those ZetaChain was initially equipped to handle. To extend support for Taproot, ZetaChain created a new address type, AddressTaproot. This new type was designed to integrate with the existing infrastructure by following the same structure and standards, ensuring compatibility with existing systems.
2. Transaction Creation
   • ZetaChain 2.0 now includes specific scripts for each Bitcoin address type to ensure that transactions conform to the unique requirements of P2PKH, P2SH, P2WSH, and P2TR addresses. These scripts are essential for defining how transactions are processed, particularly addressing the special requirements for witness data in SegWit-based addresses like P2WSH and P2TR.
3. Transaction Parsing
   • The parsing logic has been improved to handle the unique characteristics of P2PKH, P2SH, P2WSH, and P2TR address types in a unified manner. This means that the system can correctly identify, extract, and validate the necessary components for each type.

Additional Chain support

ZetaChain is growing its network by adding new chains through a careful governance process and software updates. This ensures that each new chain is integrated smoothly. Currently, they are considering adding Polygon, Base, Solana, and IBC chains.

Adding new chains can be easier or harder depending on their signature schemes. EVM chains, like Ethereum, are easier to add because of wide support for its signature schemes. Other chains might be more challenging. For example, more recent chains such as Solana, NEAR, and TON, often use EdDSA (Ed25519 curve) rather than ECDSA (scep256k1 curve). This often poses challenges for the TSS module as ECDSA TSS in GG18 and GG20 were more mature and much more battle tested than EdDSA TSS. Fortunately those new chains often have smart contract capability and often support scep256k1 operations efficiently at smart contract level. This allows ZetaChain to use the relatively mature ECDSA TSS technology to connect to those chains.

Additionally, observer validators in the ZetaChain network need to run nodes for all the supported chains. This allows them to validate transactions across different chains.

ZetaChain currently uses its Cross-Chain Messaging Protocol and ZetaClient TSS to communicate with other chains. There is also a proposal to incorporate IBC modules to enhance these communications and extend the reach of omnichain contracts into the Cosmos ecosystem appchains.

Other Updates

RPC: ZetaChain is forking the current Ethermint module to extend it and address these issues. Ethermint is updated to the latest version to support the latest features and security. Other issues related to JSON RPC are also worked upon. Customizing the Ethermint EVM module and improving RPC compatibility ensures better handling of cross-chain transactions and zEVM contract interactions.

Throttle mechanism: To safeguard the network from unwanted or malicious activities, ZetaChain has implemented an adjustable throttle mechanism. This system dynamically adjusts the rate of transactions in response to current network conditions and predefined rules. By managing the transaction flow, this mechanism enhances network stability and security, protecting against potential threats such as spam transactions or flash loan attacks. This addition not only prevents network abuse but also ensures ongoing reliability and safety for all users.

General Applications on ZetaChain

In ZetaChain 2.0, the contracts can be called from external chains and can call contracts on external chains as well. Applications developed using it typically have similar general working under the hood. The first part of application is construction of a transaction with function call details sent to the omnichain contract. The dApp frontend does this. This is sent via TSS observers and relayed to the appropriate contract on ZetaChain. These are passed on to systemContract, which acts as a gatekeeper. This contract ensures that only authorized functions, such as OnCrossChainCall, can trigger the next steps in the process, adding an extra layer of security. The OnCrossChainCall function in the target contract processes the incoming message to identify and execute the required function.

After this is successfully executed, results are processed and sent to the destination chain. Users receive the final result directly in their wallets on the destination chain. From the user’s perspective, this interaction involves simply initiating a transaction on the source chain and receiving the outcome on the destination chain. ZetaChain handles all the intricate details of transaction construction, validation, and execution behind the scenes, making cross-chain interactions appear effortless. Users experience a smooth and straightforward process, seeing only the transaction they signed and the ultimate outcome, with all intermediary steps efficiently managed by ZetaChain’s infrastructure.

Specific Applications

Native Swaps

Using ZetaChain you can implement a cross-chain swap application as a universal contract. Users start by sending native gas or supported ERC-20 assets to a Gateway contract on a connected chain alongside a universal contract address and a message (containing the target token and recipient). The observer-signer validators observes and processes the transaction. The fungible module mints ZRC-20 tokens that represent tokens deposited into the Gateway contract and the system contract calls the universal contract’s onCrossChainCall function. The function accepts ZRC-20 tokens, context (containing the connected chain’s ID, and the caller address), and a message. The universal contract then uses one of the available liquidity pools (default Uniswap v2 pools or any other DEX contract) to swap incoming ZRC-20 tokens for the ZRC-20 of the target token and ZRC-20 of the gas token of the destination chain. Finally, the contract calls ZRC-20 withdraw method that burns ZRC-20 gas tokens (to cover the gas costs on the destination chain) and withdraws the target ZRC-20 to the destination chain as native assets.

Staking

The ability of smart contracts to stake ZETA simplifies the development of liquid staking and re-staking applications on ZetaChain.

In the past staking applications required off-chain programs that monitored deposits of ZETA into a smart contract and staked ZETA on behalf of users. This off-chain mechanism was a source of centralization and made it harder to build resilient and decentralized staking protocols.

With the ability to stake ZETA a contract can natively accept ZETA tokens from users and other contracts, stake ZETA using the native staking mechanism of the chain (the Cosmos SDK staking module), as well as query the staking module and claim rewards.

Using this ability universal apps can accept tokens from connected chains, provision ZETA tokens and stake them on behalf of users and earn yield on the transferred tokens on connected chains.

NFT Applications

The ability to natively call smart contracts on connected chains from universal apps on ZetaChain makes it possible to create innovative NFT apps. Developers can create apps that accept tokens and messages from connected chains, mint NFTs, and allow users to transfer these NFT from ZetaChain to connected chains and back.

New Applications Enabled by ZetaChain

ZetaChain’s omnichain infrastructure enables DeFi applications to operate across multiple chains, rather than being confined to a single one. One of the key advantages of web3 is its composability, which allows smart contracts to interact and build on each other. Currently, this interaction is limited to contracts on the same chain. ZetaChain, however, extends this composability to all chains, including those without native smart contract support, such as Bitcoin and Dogecoin. This broadens the range of use cases that can benefit from omnichain abstraction for developers, setting the stage for innovation at the dApp level.

Omnichain Treasury Management

Treasury management across multiple blockchains is a complex task. When an organization’s assets are spread across different chains, each with its own native accounts, the management process is difficult and could lead to loss of assets if not handled properly. Without a unified solution, treasury managers must juggle multiple accounts, coordinate signatures from stakeholders on various chains, and manually track assets across diverse networks. This fragmented approach not only increases operational risks but also limits the treasury’s ability to efficiently manage and deploy assets.

By using ZetaChain’s infrastructure, organizations can have a central control of their treasury while maintaining the decentralized nature of blockchain assets. The key innovation lies in use of programmable TSS and smart contracts.

Treasury managers can write their management logic in a single smart contract deployed on ZetaChain. This contract serves as the central control point for all treasury operations across multiple chains. The initial setup requires stakeholders to provide their keys only once on ZetaChain, significantly simplifying the approval process.

Once set up, the ZetaChain smart contract can orchestrate complex treasury operations across different blockchains. This means that assets can be moved, allocated, or utilized across various chains with a single approval process on ZetaChain, rather than requiring multiple iterations of signatures from all stakeholders on each native chain.

This approach not just limited to sending funds. Treasury policies, spending limits, and approval thresholds can be programmed directly into the smart contract, so that there is consistent application across all chains. Additionally, it opens up possibilities for more sophisticated treasury management strategies, such as automated cross-chain rebalancing or yield optimization, which were previously impractical due to the complexity of managing multiple separate blockchain accounts.

Omnichain Portfolio Management

Managing a crypto portfolio across multiple chains is hard, with users struggling to balance assets and track performance across different networks. ZetaChain simplifies this with a unified platform for omnichain portfolio management.

An omnichain smart contract acts as a central control tower for all user crypto assets is the key to the solution. This contract uses TSS to interact directly with accounts on various chains. The users can encode investment strategy and rules in the ZetaChain smart contract. This contract then uses TSS to execute trades, move assets, and rebalance the portfolio across different blockchains.

The smart contract can monitor market conditions, automatically rebalance portfolio, and execute complex trades across chains without manual intervention. It does this by generating signatures through TSS, allowing it to control assets on multiple chains securely.

This approach not only automates cross-chain operations but also provides a consolidated view of entire portfolio’s performance. It opens up possibilities for sophisticated investment strategies like cross-chain arbitrage or multi-chain yield farming, which were previously impractical.

This is crucial for attracting and scaling new users who are interested in yield opportunities but may not be well-versed in the specific steps required for each chain. By abstracting the complexity of multi-chain operations, ZetaChain makes advanced crypto portfolio management accessible to a broader set of users.

Native Swapping

We have already discussed native asset swapping applications similar to ThorChain, where users can deposit and receive assets in their native form. From the user’s perspective, this process is as straightforward as depositing and receiving funds on a centralized exchange. Since the inputs & outputs are simple transfers on connected chains, this has significantly less cost compared to messaging-based approaches where the involved contract calls (message verification, etc.) can be very costly. Instead of logic execution piece-wise across involved chains, all logic is in one place in an omnichain contract.

Cross-Chain Lending

ZetaChain 2.0 enhances cross-chain lending by enabling direct function calls on external chains from ZetaChain. This allows a cross-chain lending protocol to be deployed on ZetaChain, accepting deposits from lenders on any chain without requiring additional effort from users. Deposits can include assets from liquidity pools, liquid staked assets, and more from any supported chain. On the borrower side, collateral can be provided across multiple chains and in various asset types, creating a flexible lending ecosystem. Taking a look at the BTC native lending market, not a lot of options are available. This opens up new opportunities and markets for builders to enable BTC yield and borrow against other assets. Compared to ThorChain, development on ZetaChain also provides more options to build different architectures with the same input and output tokens.

Restaking for Assets From Any Chain

Assets from supported chains can be used to provide restaked security for other chains, similar to the Eigenlayer approach. Restakers can use assets such as BTC, ETH, and others, which may be subject to slashing based on the specific conditions of the target chain or application. This pooled security model allows chains or applications to tap into a diverse portfolio of restaked assets, enhancing overall security and offering stronger protection for the entire ecosystem.

The application could be similar to Exocore, where smart contracts on ZetaChain orchestrate key functions. These contracts function as modules that could manage different aspects, such as AVS registration, tracking of stake delegations, processing deposits, handling withdrawals, and enforcing slashing.

When users interact with the system—either by depositing tokens for staking or delegating their assets to others — these transactions are recorded by the respective smart contracts. This ensures all user activities are logged and managed within the ZetaChain ecosystem.

The TSS signers actively monitor validators to ensure they are faithful. If a validator is malicious or a user initiates a withdrawal, slashing modules respond by slashing the stake on native chain.

Multi-Chain Liquidations

Suppose a user wants to use assets on different chains for lending, it is difficult for the user and the application to monitor and manage the liquidation of those assets. It needs continuous monitoring and quick execution across chains to minimise the loss to the protocol as much as possible. Using ZetaChain, the assets can be locked in a TSS address and liquidated using AMM/ DEX on the source chain where there’d be large liquidity compared to wrapped versions on other chains. This would minimise the time spent in liquidations, bridging and would take advantage of better rates due to higher native liquidity. The TSS observers would continuously monitor these positions and universal app on ZetaChain would keep a track of it. Once the prices of the assets reach a point that they’d need liquidations, smart contract would trigger it, get relayed by the TSS signers and liquidated on the native chain.

BTC Applications

Applications like Ordinals marketplaces, swaps for BTC assets such as BRC20, lending are enabled using ZetaChain. These applications are composable not only with other applications on ZetaChain but also with those on other supported chains. All the applications supported by a normal smart contract chain are supported along with omnichain capabilities for Bitcoin by ZetaChain.

Lending & Borrowing between assets like BTC and ETH would use TSS addresses. The application could be deployed as an Universal App on ZetaChain with its underlying logic. If a user wants to borrow ETH against its BTC, he/ she simply deposits the BTC on native chain, signing with their wallet. The BTC gets locked in the TSS address, waiting for it to be withdrawn or liquidated. TSS observers record this, mint ZRC-20 version of ETH on ZetaChain, send and swap it on Ethereum for ETH into the user account directly. The user simply deposits using their wallet and receives ETH on their ETH wallet. Simple as a centralized exchange. Other applications like Ordinals marketplaces, swaps would be similar in their simplicity.

Cross-Chain Orchestration

Chain abstraction is solving a broad spectrum of problems in areas such as account aggregation, solving, orchestration, settlement, and clearing. We will explore a few approaches to solve orchestration and compare them with ZetaChain.

Agoric

Agoric is a JavaScript-based smart contract platform built using the Cosmos SDK and CometBFT. It uses IBC and Axelar to communicate with other Cosmos chains. Agoric’s goal is to onboard millions of JavaScript developers to web3. The Agoric Orchestration API abstracts the complexities of orchestrating contracts across different chains, simplifying the development process.

One of Agoric’s standout features is its unique async/await model. This model allows smart contracts deployed on Agoric to interact with other chains, wait for responses, and execute workflows that span multiple blocks. When Agoric sends messages to other chains, these messages contain instructions—such as account creation or function calls—along with the necessary parameters. Once the destination chain processes these instructions and returns the results, the Agoric smart contract continues with the next steps defined in its logic.

Everclear (Formerly Connext)

Formerly known as Connext, Everclear has a bridge that facilitates cross-chain workflows and re-staking from multiple L2s. By integrating the Connext SDK, xApps can send special messages called xcall, across chains. These messages are managed by Connext contracts on both the source and destination chains, in addition to an adapter contract, to enable cross-chain function calls.

With the Connext SDK, an xApp can compile and send xcall messages loaded with all required execution details, such as function calls, funding, gas information, and additional data. These messages are initially processed on the origin chain by a Connext contract, which then forwards them to its counterpart on the destination chain. Here, adapter contracts play an important role by receiving these messages, converting assets if needed, and executing the designated functions with the correct parameters. Connext’s system supports nested xCalls, mimicking callbacks between chains to verify state changes and perform asynchronous follow-up actions.

This enables Connext to act effectively as a bridge, executing contract functions across various chains and supporting intricate cross-chain workflows. This is slightly similar to ZetaChain, where function calls are relayed to the destination chain and executed.

Comparison Between xERC-20 and ZRC-20 Tokens

Both ZetaChain and Connext have developed token standards — ZRC–20 and xERC-20, respectively—to facilitate cross-chain applications.

ZRC-20 tokens are an adaptation of the ERC-20 standard on Ethereum, designed specifically for ZetaChain’s cross-chain functionalities. ZRC-20 tokens are minted on ZetaChain only after the corresponding ERC-20 tokens are deposited into TSS addresses under ZetaChain’s control. Each ERC-20 token from different chains is represented uniquely on ZetaChain; for example, USDT from Ethereum appears as ZRC-20 USDT from Ethereum, and from Binance Smart Chain as ZRC-20 USDT from BSC. Although these represent the same ERC-20 token, on ZetaChain, they are treated as distinct assets but can still be exchanged.

In contrast, xERC-20 tokens maintain fungibility across different chains. All xERC-20 USDT tokens are treated as identical, regardless of the chain they originate from, facilitating consolidated liquidity and avoiding the dilution seen with ZRC-20 tokens. This fungibility allows for better asset management across chains, with xERC-20 tokens being used with xcall messages for sending tokens along with function calls and other transaction details.

Particle Network

Particle Network started by focusing on wallet and account abstraction infrastructure, and has been successfully meeting user demands. They’ve expanded their stack to include chain abstraction, adding key components such as a decentralized bundler, paymaster, and keystore on Particle L1 to manage cross-chain accounts. This keystore approach is inspired by Vitalik Buterin’s concepts for solving multichain account issues.

Particle’s abstraction stack spans three areas:

• Universal Accounts These accounts upgrade traditional smart contract accounts by integrating a new user operation structure, a master keystore, and Merkle trees for signature verification. Particle L1 serves as a centralized repository for smart accounts, handling settings and key-related data while storing commitments to user private keys in Merkle trees. Users validate key ownership through a Merkle proof of membership when initiating transactions. Similar approach is suggested by Scroll, Keybase & Stackr. We’ll address keystore in detail in the Unified account management section.
• Universal Liquidity: A network of Bundler nodes executes operations necessary for user transactions on any chain, such as token swaps and interactions with Liquidity Providers. This allows users to utilize their token balances across multiple chains, enabling easy interaction with new chains without directly holding tokens on them. Users create operations that can interact with multiple chains using a single signature, with Universal Accounts and Bundlers managing transaction construction, signing, and routing.
• Universal Gas: When users initiate transactions, the interface prompts them to select a preferred gas token. This token is then managed through Particle’s Paymaster contract, with gas payments settled on the source and destination chains. A portion of the fee is converted into Particle’s native $PARTI token on Particle L1.

These 3 solutions together provide a powerful abstraction experience for the end developers and users. The users are able to create cross-chain transactions that don’t require management of accounts or gas on destination. These are all handled for a seamless end user experience.

NEAR

NEAR’s goal is to provide a bridgeless cross-chain experience, different from other protocols that rely on bridges. It achieves this through Chain signatures, Multi-chain Relayers, and Multi-chain Gas Stations, along with decentralized frontends.

Account Aggregation simplifies the user experience by allowing users to sign transactions on any blockchain using a single account. NEAR has developed an MPC protocol called  Chain Signatures, using NEAR and Eigenlayer validators. This protocol generates and manages accounts on external chains without needing additional keys or addresses. These addresses are derived from existing NEAR accounts. We’ll have a more deeper look at how this works in the Unified account management section.

Similar to Particle Network, Multi-chain Gas Station and Multi-chain Relayer simplify the user experience by abstracting gas on external chains. So the users only interact with the dApp frontend, while the orchestration, signing, gas payment, relaying happens in the background.

The key feature of NEAR’s approach is the ability to transfer asset ownership across different chains without actually moving the assets. This process begins with the creation of accounts on other chains using the MPC network, linked to users’ NEAR accounts. Instead of wrapping or transferring the assets, the ownership keys of these accounts are turned into NFTs on NEAR. Users can then trade these NFTs on NEAR, effectively transferring the ownership of the assets without moving them.

This method allows for the exchange of native assets using NEAR’s high throughput, since only the control keys are swapped, not the assets themselves.

Neutron

Neutron, built using CosmosSDK, focuses on seamless cross-chain transactions using a few key components. Interchain Accounts (ICA) manage accounts on remote Cosmos chains, allowing them to hold assets and execute transactions. Packet Forward Middleware (PFM) forwards IBC packets between chains, making cross-chain communication easier. IBC Hooks let smart contracts execute custom logic when IBC packets are received.

If a user wants to create a cross-chain transaction using Neutron, Interchain Transactions (ICTX) module acts as the central orchestrator. Smart contract on Neutron sends a request to the ICTX module, specifying the target chain, interchain account, and the actions to perform. ICTX then creates an IBC packet with the transaction details and sends it via a relayer to the target chain. The remote chain processes the transaction and sends back an acknowledgment. This approach of sending the function call via bridge is similar to Connext and ZetaChain.

Comparisons with ZetaChain

In most approaches, cross-chain orchestration involves a bridge that transfers assets along with the corresponding function calls and parameters. These assets and instructions are unwrapped on the destination chains, executed by the contract. ZetaChain 2.0 also uses this method, with TSS signers and observers relaying the data to ensure secure and accurate transactions.

ZetaChain allows dApp developers to create smart contracts that can control assets across multiple blockchains using TSS. This makes the TSS programmable through the dApp’s logic. Developers can define complex rules for cross-chain asset management and automate multi-chain transactions. This approach opens up new applications and protocols.

ZetaChain also improves cross-chain applications by allowing developers to build with unified state and logic on a single chain. This approach is fundamentally different from traditional bridging solutions that fragment operations across multiple chains.

Using ZetaChain, applications maintain their entire state and logic in one place, enabling synchronous and atomic execution. This is a significant improvement over point-to-point communication systems in bridges, which rely on asynchronous, event-driven processes across fragmented states.

The benefits of this unified approach are huge. It reduces the complexity of cross-chain applications. For example, implementing an AMM like Curve becomes significantly simpler. Instead of coordinating complex operations across multiple chains, developers can write a single smart contract that handles all logic in one place. Another key advantage is reliability. In fragmented systems, each step in a cross-chain transaction introduces a new point of potential failure. This can lead to partially completed transactions and funds stuck in limbo. ZetaChain eliminates these risks. Transactions either complete fully or fail entirely, with funds returning to their original state.

This is because if a transaction needs to be reverted, it can usually be done quickly and easily within main chain because most of the state and logic are contained in a single place. In case the external calls are complex and fail, applications are provided with ways to rollback asynchronously. This is particularly important for operations with specific conditions, like swaps with slippage tolerance. In ZetaChain, if the slippage tolerance isn’t met, the entire transaction rolls back if a callback function to rollback is provided. This protects users from unexpected losses due to changing market conditions during execution.

Unified Account Management

Blockspace used to be scarce, but now there is an abundance due to alternate L1s, rollups on Ethereum, and appchains. Applications are now spread across these layers, giving users many options. There are account management solutions like Magicspend, Keystore rollups which address these issues directly. A deep-dive into those warrants a report of its own. So we will focus on how unified solutions like Near, Particle and ZetaChain address these and differ.

Particle Network

Particle Network has developed BTC Connect to extend benefits of account abstraction to Bitcoin users. While direct account abstraction isn’t implemented on Bitcoin L1, it is achieved through L2s. These Bitcoin L2s incorporate Particle’s AA infrastructure components such as bundlers and paymasters, allowing users to enjoy benefits like gasless transactions, account recovery, and passkeys.

BTC Connect has been integrated with different Bitcoin wallet providers, including UniSat, OKX and Bitget. When a user interacts with an application, they can connect to BTC Connect through their wallet. This connection automatically creates a Smart Account on the Bitcoin L2 for the user. The user can then choose to interact with the dApp via Bitcoin L1 or bridge their BTC to the L2 to make use of the benefits of AA wallets. This entire process is seamlessly abstracted by BTC Connect, providing a smooth and user-friendly experience.

Near

NEAR enables transaction signing across any blockchain with a single account. NEAR’s account model has integrated account abstraction. Users also benefit from human-readable accounts with different keys for each application, each with specific access levels. NEAR has extended this model to support multichain interactions through Chain Signatures, a protocol that allows NEAR accounts to create and manage remote accounts on other chains without users needing to manage them separately.

This process uses a TSS protocol run by NEAR validators. This innovative TSS protocol allows validators to join and leave the network without changing the public key or key shares, making the TSS a stable and reliable signer without frequent adjustments.

Users can create new accounts on each chain, with the TSS network acting as the signer, eliminating the need for users to maintain private keys for these accounts. The TSS network can derive multiple accounts for the same chain using different paths through NearID, further enhancing security and ease of use. The end experience for the user is a single NEAR account for all connected chains, leveraging TSS for signing and all the benefits of account abstraction.

One key difference in account management is the approach taken by NEAR compared to ZetaChain. NEAR relies heavily on its own network for interactions. When users want to create accounts or sign transactions for other chains, their NEAR account serves as the starting point for all interactions. Accounts on other chains are derived from the Near account and managed by the MPC network. In contrast, ZetaChain allows users to maintain their existing accounts on other chains and retain full custody. Users can initiate interactions from any source chain without requiring a ZetaChain account to use omnichain applications developed and deployed on ZetaChain. This approach minimises the need for users to create new accounts, as they can simply use their existing accounts on other chains. Importantly, users maintain full custody by holding their own private keys.

Both approaches make different tradeoffs. NEAR’s method locks in the user and serves as an entry point for interactions across all chains, simplifying account management to some degree. ZetaChain, on the other hand, provides users with more control and flexibility, allowing interactions from any chain. In the end, it might come down to what users prefer: the all-in-one package of NEAR, or the flexible, bring-your-own-account approach of ZetaChain.

Bitcoin Restaking

Bitcoin is the largest and most secure digital asset, primarily due to its PoW mechanism. However, its limited programmability restricts its use to basic transactions. Previously, we discussed how ZetaChain’s infrastructure supports restaking and omnichain staking, including for Bitcoin. Additionally, ZetaChain enables other omnichain applications for Bitcoin assets, such as lending, native swaps, and Ordinal marketplaces. Any kind of application using smart contracts is possible for Bitcoin using ZetaChain.

Restaking presents an opportunity to use BTC’s security for other applications and PoS chains. Let’s explore and compare a few other approaches to extending BTC’s security to enhance its utility across various applications. We’ll also compare ZetaChain as a platform compared to Bitcoin L2s.

Babylon Chain

Babylon is a Cosmos-based CometBFT chain that boosts the security of PoS chains by staking BTC. To stake BTC, it must be locked and controlled based on validator behavior. While Ethereum supports this directly, BTC does not. Typically, BTC is locked in multi-sig or Threshold Signature Scheme (TSS) accounts for staking. Babylon, however, uses a trustless method. It uses Bitcoin scripts to lock BTC for a set time, during which users can unbond and unstake their BTC. Slashing is done using Extractable One-Time Signatures (EOTS).

Components

• Extractable One-Time Signatures (EOTS)
• Covenants
• Timestamping

Covenants:

Covenants lock BTC in a vault until specific conditions are met, using Bitcoin scripting opcodes like OP_CHECKTEMPLATEVERIFY (OP_CTV). Bitcoin’s PoW security ensures the BTC remains secure until these conditions are fulfilled.

EOTS:

Validators use EOTS to sign blocks for PoS chains. These signatures are used only once. If a validator signs two conflicting blocks at the same height, EOTS reveals the validator’s private key, allowing the protocol to slash the BTC. This penalizes dishonest behavior and encourages honest validation.

Timestamping:

Timestamping creates an unchangeable record of data or transactions, preventing long-range attacks on PoS chains. This process synchronizes Bitcoin and PoS chains, ensuring data integrity and speeding up the unbonding of staked BTC. Timestamping reduces the unbonding period, allowing users to retrieve their assets quickly while protecting against long-range attacks.

Using these components, Babylon provides a trustless restaking alternative.

Stroom Network

The Stroom network lets users stake their BTC and earn native BTC yield without locking up their funds. Users also get liquid staked tokens that can be used in DeFi protocols on Ethereum to increase their yields. The key idea is to use BTC to provide liquidity in the Lightning Network, generating fees shared among users, the DAO, and node operators.

1. Stroom Bridge: This bridge connects Bitcoin with EVM-based blockchains. Users deposit BTC into the Stroom DAO treasury and receive stBTC or bstBTC on Ethereum. These wrapped tokens can be used in Ethereum’s DeFi protocols, allowing users to earn extra yields.
2. Stroom-Enabled Lightning Network Nodes: These nodes manage Lightning Network channels using users’ BTC deposits. The nodes can’t directly access the BTC; any changes to channel states need approval from validating nodes. Channel management is secured by a federation-controlled multisig setup and Schnorr signatures. Validating nodes also act as watchtowers, overseeing Lightning node activities.
3. Stroom Validating Nodes: These nodes approve operations and keep the protocol secure using the FROST algorithm for Schnorr threshold signatures. They independently validate events, ensuring decentralization and security. They store channel states and revocation keys, updating LN state signatures as needed. As DAO-managed watchtowers, they monitor Lightning Network channels through integrated Bitcoin full nodes.

tBTC

tBTC is a decentralized bridge that allows BTC to be used on Ethereum. It lets users mint tBTC, an ERC-20 token, by locking BTC in a Threshold Network-controlled account. This token can then be used in Ethereum’s DeFi ecosystem, providing more utility for Bitcoin holders.

The bridge randomly selects its operators for each epoch to ensure security. To secure Bitcoin deposits, tBTC requires agreement from a majority of operators, typically 51 out of 100 threshold-ECDSA-backed wallets. This replaces centralized intermediaries with a decentralized, cryptographic system.

To deposit BTC, users send it to one of these wallets using pay-to-script-hash (P2SH) or pay-to-witness-script-hash (P2WSH). The transaction includes the user’s Ethereum address. Operators validate the transaction and mint tBTC on Ethereum, converting Bitcoin into an Ethereum-compatible token.

To redeem tBTC for BTC, users provide a Bitcoin address. The system reduces their tBTC balance and releases the equivalent amount of Bitcoin to the provided address.

Products built on top of the tBTC bridge include:

• Mezo: Mezo creates an economic layer using tBTC. It is a PoS network secured by staking Mezo and tBTC, allowing access to BTC DeFi and other utilities.
• Acre: Acre offers a simple BTC-in, BTC-out staking process. Users deposit BTC and receive stBTC, representing fractional ownership of BTC in Acre vaults. This allows users to earn yield on their BTC while keeping liquidity with stBTC. Acre stakes BTC in various L2s for economic security, and validators earn rewards in L2 tokens or BTC. Users can redeem their stBTC on Acre to withdraw rewards or convert back to BTC.

While these approaches allow restaking, they’re exclusive for that purpose. ZetaChain allows restaking to be composed with other applications like lending, swapping etc for capital efficiency and inside a single synchronous environment. Applications also get access to user base of other applications in the ecosystem.

Comparison with Bitcoin L2s

Bitcoin L2s enhance the utility of BTC using their MPC-based bridges and wrapped assets. ZetaChain, however, uses TSS-controlled addresses on the Bitcoin network to represent ZRC-20 tokens on its chain. TSS can be more decentralized compared to the MPC-based approaches of Bitcoin sidechains, as a larger and more distributed TSS set provides greater Byzantine Fault Tolerance.

Additionally, ZetaChain’s TSS supports omnichain applications, allowing them to compose with contracts on other chains. This means BTC applications on ZetaChain can seamlessly interact with multiple contracts across different chains. In contrast, BTC L2s offer composability only within their own platforms.

While BitVM and CatVM-based bridges could offer trustless or trust-minimized alternatives, they are not yet feasible yet.

Outlook on the Future of UX and Zetachain’s Role

The future of UX on blockchains is set to see significant improvements driven by infrastructure like ZetaChain. Here’s a look at what to expect and the role ZetaChain can play:

• Seamless Interactions: The trend is moving towards seamless and intuitive user interactions where the underlying technology becomes invisible to the end-user. ZetaChain’s approach to chain abstraction is an important step in this direction, making blockchain interactions as simple as using any web2 application.
• Unified User Interfaces: With the ability to handle cross-chain interactions natively, applications can offer unified interfaces where users can manage assets, execute transactions, and interact with multiple chains from a single platform. This will greatly enhance the overall user experience.
• Enhanced Application Ecosystems: As ZetaChain enables more sophisticated cross-chain functionalities, we can see the development of richer and more complex ecosystems of applications. These ecosystems will offer services that are more integrated and interoperable, providing users with a comprehensive suite of tools and functionalities.
• Mainstream Adoption: Simplifying the user experience is key to driving mainstream adoption of blockchain technologies. By removing the barriers related to complexity and usability, ZetaChain can play an important role in bringing blockchain to a wider range of non-technical users.
• Innovative Use Cases: The ability to perform complex operations across multiple blockchains will lead to the emergence of new and innovative use cases. Developers will have the tools to create applications that were previously not possible, driving further innovation in the space.