Original Author: Arjun Chand

Original Translation: Deep Tide TechFlow

Note: If you are already familiar with how the token frameworks introduced by interoperability protocols work, you can skip directly to the comparative analysis section.

Introduction

Issuing tokens used to be simple: you just needed to deploy it on Ethereum, as that was the core of all activities—users, traders, capital, and liquidity. Today, the situation is much more complex. Liquidity is distributed across Bitcoin, Ethereum, L2, Solana, and other chains. So, where can you issue tokens? There is no simple answer.

But what if you didn’t have to choose just one chain? Imagine a token that can be used anywhere, flowing smoothly throughout the crypto economy.

Thanks to interoperability protocols (also known as bridging), it is now possible to issue tokens for a unified market across multiple chains. This creates borderless liquidity and simplifies the operational processes for token issuers: more liquidity, greater acceptance, and stronger network effects—without worrying about the issues brought by fragmentation. Essentially, it’s like having a global bank account that can be used anywhere, integrated into all DeFi ecosystems.

In this article, we will compare the leading token frameworks provided by different interoperability protocols. Our goal is to assess their unique features, advantages, and trade-offs to help teams choose the best solution for issuing native multi-chain tokens. We will examine the following frameworks:

• Axelar's Interchain Token Service (ITS)

• Wormhole's Native Token Transfers (NTT)

• LayerZero's Omnichain Fungible Token (OFT)

• Hyperlane's Warp Token

• xERC20 (EIP 7281: Sovereign Bridged Token)

Let’s get started.

How Token Frameworks Work

Token frameworks primarily operate in two ways, depending on whether you are converting an existing token into a multi-chain token or launching a native multi-chain token from the start.

Burn and Mint: For Native Multi-Chain Tokens

When a token is natively issued across multiple chains from day one, its supply is distributed across these chains. When tokens are transferred between different chains, they are burned on the source chain and minted on the target chain, ensuring that the total supply remains constant.

Think of it as an accounting system (as many interoperability teams have explained). Here’s an example: consider Token X, with a total supply of 1000 tokens, distributed across five chains based on demand:

• Chain A: 400 tokens

• Chain B: 200 tokens

• Chain C: 200 tokens

• Chain D: 100 tokens

• Chain E: 100 tokens

If a user transfers 50 tokens from Chain E to Chain A, those tokens will be burned on Chain E and minted on Chain A. The updated distribution will be:

• Chain A: 450 tokens

• Chain B: 200 tokens

• Chain C: 200 tokens

• Chain D: 100 tokens

• Chain E: 50 tokens

This process ensures that the total supply remains at 1000 tokens, facilitating seamless transfers without slippage.

Lock and Mint: For Existing Tokens

For existing tokens that were initially deployed on a single chain, the process is different. The entire supply is concentrated on one chain, and when transferred to another chain, a portion of the supply is locked in a smart contract on the source chain while the same amount of tokens is minted on the target chain.

This method is similar to how wrapped tokens operate. Tokens locked on Chain A can be minted as wrapped tokens on Chain B. However, these tokens can now also be transferred from Chain B to Chain C using the burn-mint method without needing to lock on multiple chains. The original supply remains on Chain A, ensuring that transfers between chains only require verification that the burned tokens match the minted tokens.

Why Token Systems Matter

Here are the benefits of tokens that can be traded in a unified cross-chain market for teams:

• Liquidity – A unified market attracts more traders, increasing liquidity.

• Brand Recognition – Tokens available across various DeFi ecosystems increase demand and brand awareness.

• Simplicity – Token management becomes simpler, reducing complexity.

• Redundancy – If one chain fails, tokens can still operate on other chains, providing a safety net.

• Market Expansion – Tokens can be deployed more quickly across multiple chains, promoting adoption. Additionally, interconnected ecosystems mean more room for experimentation in DeFi.

• Network Effects – Collaborations with other projects increase adoption rates and value.

Take a look at Circle's Cross-Chain Transfer Protocol (CCTP). By launching CCTP, Circle enables USDC to be traded seamlessly across supported chains, addressing major issues:

• No Fragmented Liquidity – Previously, there were different versions of USDC on each chain, leading to inefficiencies. Now, USDC is the same across all chains.

• Market Expansion – Deploying USDC across multiple chains allows it to access more users and markets.

• Capital Efficiency – Users can bridge large amounts of USDC without needing liquidity pools or wrapping.

• Minimal Fees – Transfer fees are primarily gas fees.

• No Slippage – Transfers are direct, eliminating slippage risk.

The unique feature set that Circle provides for USDC benefits from their custom-built bridging protocol CCTP, which is a luxury that most projects do not have. This is where the token frameworks maintained by interoperability protocols come into play. These frameworks offer functionalities similar to what CCTP provides for USDC, but applicable to any token. By issuing tokens through these frameworks, projects can establish a unified market across multiple supported chains, enabling simple transfers using burn/lock and mint mechanisms.

Comparing Token Frameworks

Now that we understand how token frameworks work and their advantages, let’s compare the various solutions available in the market for teams to issue tokens.

Security

Security of Token Frameworks

Here are explanations of the key security aspects covered in the table:

1. Verification Mechanism

The verification mechanism is at the core of cross-chain transfer validation. It refers to how messages are verified and the types of setups each framework offers in terms of verification mechanisms—whether it’s a single option, a modular system with multiple options, or a flexible design compatible with any bridge—allowing token issuers to choose the most suitable solution based on their security needs.

While custom verification mechanisms offer many benefits, the default configurations remain the most widely used. Therefore, it is crucial to focus on the security of the default verification solutions. Teams are advised to use additional verification mechanisms on top of the default solutions to enhance their security settings.

In terms of activity, relying on multiple verification solutions has both advantages and disadvantages. The advantage is improved fault tolerance: if one provider goes down, others can ensure continued operation, enhancing the system's reliability. However, this also increases the complexity of the system. Each additional solution introduces a potential failure point, increasing the risk of operational disruptions.

2. Flexibility of Verification Mechanisms

Emphasizing the flexibility of each framework in customizing verification mechanisms—specifically, whether token issuers can choose from multiple options or are limited to default settings.

3. Prominent Pre-Built Verification Solutions

Pre-built solutions are verification mechanisms that token issuers can use directly for message validation, simplifying the deployment process. A framework that offers more reliable pre-built options is usually a positive sign.

While some frameworks provide more verification solutions than others, it is crucial to assess them based on their security, which can range from a single validator to a comprehensive set of validators.

For example, the DVN (Dynamic Verification Network) options provided by OFTs include single validators and more robust options like CCIP or Axelar, which use a complete set of validators. Similarly, the Warp Token offers ISM (Interchain Security Management) that includes a multi-signature ISM operated by the Hyperlane community, while also providing options like aggregated ISM that allow teams to combine security from multiple ISMs.

Additionally, many verification solutions may not yet be widely used or thoroughly tested in practice. Therefore, teams should carefully assess the quality of available verification solutions and choose options that match their required security levels. We strongly recommend leveraging existing options to build a secure and reliable token verification system. In future research articles, we will delve into the security features of the different verification solutions offered by various token frameworks.

4. Default Verification Solutions

This refers to whether the framework provides a default verification mechanism. This is crucial because most teams typically opt for the default option for ease of use. If a token issuer decides to use the default option, it becomes particularly important to assess its security and consider utilizing customizable features to enhance security.

5. Application Participation in Verification

This emphasizes whether teams can participate in the verification process, which can add an extra layer of security or allow them to take control of their own security. This is significant because it enables teams to enhance security by combining their own verification systems with existing mechanisms. Thus, if other verification methods encounter issues, they can rely on their own safeguards to mitigate potential risks.

For instance, teams like Stargate, Tapioca, BitGo, Cluster, and Abracadabra run their own DVN on LayerZero, demonstrating how other teams can leverage available customization features. Although it requires extra effort, more teams should fully utilize this additional layer of security. When effectively implemented, this feature can effectively prevent major issues during critical failures.

6. Resistance to Censorship

This defines whether and how messages may be censored, which could lead to application failures and affect the normal operation of teams. In most cases, even if applications are censored, they can still switch to different verification mechanisms or relayers within the same framework. However, this requires additional effort and may not be a practical solution for short-term issues.

7. Open Source

Open-source codebases allow developers to audit the security features and overall setup of the framework, ensuring transparency in the execution of the code. This transparency is crucial for ensuring the security and reliability of the software.

Fee Comparison

This table compares the fee structures of several token frameworks, focusing on how each framework handles protocol operations, messaging, and other additional costs. Notably, all frameworks allow for the addition of custom application fees at the application layer. Additionally, across all frameworks, the verification and transfer processes involve fees, including payments to relayers, senders, or similar entities.

Currently, most fees are related to message verification and relaying. As mentioned earlier, all token frameworks provide various mechanisms for verifying messages. While adding each verification solution enhances the security of the system, it also increases user fees and costs.

Fees Related to Token Frameworks

Protocol Layer Fees

This refers to the fees charged by each framework when executing transfers or other operations.

Due to the existence of a fee switch managed by a DAO, token issuers may need to pay additional fees to the interoperability protocol behind the token framework (e.g., LayerZero for OFTs or Hyperlane for Warp Token). This introduces a dependency on DAO governance, as any changes to the fee switch will directly impact the tokens issued through these frameworks, making them subject to DAO decisions.

Smart Contracts

This table showcases the key attributes of the smart contracts of each framework, highlighting their differences in flexibility, security, and customizability, with a particular focus on deployment history, security audits, rewards offered, and significant customization options for finer control.

Notably, all frameworks allow applications to set rate limits and blacklists, which are key security features that can help prevent significant financial losses when effectively utilized. Additionally, each framework provides flexibility to deploy smart contracts as immutable or upgradeable based on the specific needs of the application.

Token Frameworks of Smart Contracts

• Deployment Time

This field shows the deployment time of each framework's smart contracts, reflecting the operational duration of the framework.

• Audit

The number of audits is an important metric for measuring security. Audits ensure the integrity of the framework's smart contracts and identify vulnerabilities and issues that may affect the system.

• Bounties

Bounties are financial incentives offered by the framework to encourage external security researchers to discover and report vulnerabilities.

• Significant Features for Fine-Grained Control

Smart contract frameworks allow applications to implement various customizable security features based on specific needs. This field highlights some key security features offered by certain frameworks to ensure system security.

Adoption and Promotion

Each framework has its unique characteristics, and the level of participation from developers, protocols, and platforms varies based on technical focus, integration methods, and security assurances.

• Core Contributors

This section highlights the active participation of various teams in building and maintaining each framework. The diversity of participants, in addition to the original development team, is a positive indicator of multiple factors: (1) broader demand for the framework, and (2) the accessibility and usability of the framework, whether through permissionless means or general collaboration.

• Adoption Rate

The adoption rate reflects the level of use and appeal of each framework, specifically measured by the number of deployed tokens and total locked value. It provides insights into the broad acceptance of the framework by developers and protocols, as well as its reliability in securing assets.

• Notable Teams

This section highlights the top teams and protocols adopting each framework, reflecting their trustworthiness and overall appeal in the industry.

• Virtual Machine Coverage

Virtual machine coverage refers to the range of virtual machines supported by each framework. Supporting more virtual machines provides greater flexibility and compatibility across different blockchain environments. This offers applications and token issuers more choices, allowing them to reach diverse communities.

• Number of Deployed Chains

This field reflects the number of chains each framework has deployed, indicating how many chains each application or token issuer can support if they decide to use a specific framework. This is directly related to the number of markets and decentralized finance (DeFi) ecosystems that applications can access. A higher number of deployed chains means broader access to liquidity.

Furthermore, while the potential for permissionless expansion of frameworks across different chains is significant, it may also pose challenges if developers need to build and maintain critical infrastructure themselves. For some teams, such as those looking to establish bridging support for new chains, this work may be worthwhile. However, for token issuers who merely wish to extend the reach of their tokens to another chain, this may seem overly complex and resource-intensive.

• Unique Differentiation

Each framework brings unique differentiating characteristics, often manifested in special features, tools, or integrations that set it apart from other frameworks. These differentiating characteristics typically attract developers and protocols seeking specific functionalities, ease of use, or wanting to achieve greater distribution for their tokens.

Developer Experience

Disclaimer: This section reflects insights gained from discussions with @SlavaOnChain (Head of Developer Relations at LI.FI) and developers familiar with various frameworks. Developer experiences may vary based on their backgrounds and use cases.

Developer Experience of Token Frameworks

• Ease of Integration

This refers to how simple the process is to deploy tokens using the framework for the first time without team support.

• Documentation

The effectiveness of the framework's guides, examples, and references in helping developers understand and use the platform.

• Developer Tools

Considering a comprehensive set of tools, including libraries, software development kits (SDKs), and utilities that make it easier to build, test, and deploy tokens using the framework.

Key Takeaways

A. Trends in Interoperability

• Customizability and Verification Mechanisms – All frameworks offer customizable verification mechanisms, marking a new trend in interoperability protocols. The discussions about wstETH on the Lido DAO governance forum were a key moment that highlighted the demand for this feature.

• Security Practices – Features such as rate limiting, whitelisting/blacklisting, and enabling token issuers to participate in message verification and security settings through custom policies and roles have become standard practices across frameworks, indicating that security in the interoperability space is moving in a positive direction.

• Challenges in Adoption Beyond Default Settings – While customizable verification mechanisms are beneficial, the adoption rate beyond default settings remains low, necessitating better education on security options. Ensuring that default verification solutions are highly secure is crucial, as they are the most commonly used.

• Verification Mechanisms – The validator set of Axelar and the guardian network of Wormhole are widely adopted verification mechanisms that have been provided across frameworks.

B. Leading Token Frameworks

• LayerZero's OFT – Leading in the number of token deployments and secured value, thanks to its early market entry advantage, extensive support for most chains, and comprehensive developer resources.

• Hyperlane's Warp Token – The team is highly focused on making the framework and developer tools more user-friendly for permissionless operations. This is reflected through multiple virtual machines built and maintained by external teams, showcasing the convenience of using the framework in a permissionless manner.

• Wormhole's NTT – Rapidly gained widespread adoption, deploying high-value tokens across chains and offering several unique features in its design, such as the absence of a protocol-level fee switch. This is a popular choice for teams looking to extend tokens to Solana or bring Solana tokens into the EVM ecosystem.

• Axelar's ITS – Axelar's total locked value (TVL) exceeds 400 million dollars, ranking among the top 25 proof-of-stake (PoS) chains. The ITS framework is a key growth driver, both boosting TVL and facilitating the volume of messages sent through the Axelar network.

• xERC20 Framework – The only framework that is completely independent of bridging, unlike other more product-like frameworks. Many interoperability protocols without their own frameworks encourage teams to use xERC20 to issue tokens, and some protocols even provide pre-built templates for integration.

• Differences in Fee Structures – xERC20 and NTT are two frameworks without a protocol-level fee switch.

Summary

Token frameworks are on the rise, potentially transforming various aspects of value flow in a multi-chain world. Currently, cross-chain asset transfers often require liquidity pools or solvers, but token frameworks eliminate the need for liquidity pools or solvers. Instead, assets can be minted directly on the target chain through interoperability protocols.

In fact, token frameworks may signal the end of wrapped assets. Liquidity no longer needs to be dispersed across chains. You can mint fungible assets on any chain, which can be traded across chains with just gas fees. We have already seen signs of this trend. Circle launched CCTP to bypass issues related to wrapped tokens for USDC, and many large teams and high-value tokens are now adopting token frameworks. This indicates that relevant progress is accelerating.

However, there are reasonable concerns about the risk of third-party chain reactions—if interoperability protocols fail, it could impact all projects built on these protocols. Despite these risks, the adoption of token frameworks continues to grow.

Another perspective is that in a future of chain abstraction, token frameworks may become irrelevant as solvers will exchange native tokens for users behind the scenes. While this makes some sense—users will not need to consider tokens—it overlooks a key factor. What about the solvers themselves? Token frameworks may be very useful for solvers. They address the challenges of asset inventory and rebalancing, as they do not require liquidity to move between chains. This is why frameworks like CCTP are favored by solvers when moving USDC—it is cheap, efficient, and well-suited for cross-chain rebalancing.

How all this will evolve remains uncertain. Perhaps we will only need to use token frameworks on a few fringe chains, or they may become the standard for deploying tokens in the cryptocurrency space. What we know today is that the adoption of interoperability frameworks is growing, and competition is intensifying. What is the problem with this growth? Fragmentation. Competing frameworks will disperse assets and liquidity, and we will not see a one-size-fits-all solution. This is not feasible under incentive mechanisms.

Original link

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。