Source: Denglian Community

Introduction

Issuing a token used to be simple: you just deployed it on Ethereum, and all the activity was happening there - users, traders, capital and flows sex. Today, the situation is much more complex. Liquidity is dispersed across Bitcoin, Ethereum, L2, Solana, and other chains. So, where should you issue your tokens? There is no clear answer.

But what if you didn’t have to choose just one chain? Imagine a token that can be used everywhere, able to flow seamlessly throughout the crypto-economy.

Thanks to interoperability protocols (i.e. bridges), it is now possible to issue unified market tokens covering multiple chains. This creates global liquidity without borders, making things simpler for token issuers: more liquidity, greater adoption, and stronger network effects—without having to worry about fragmentation. Basically, it’s like having a bank account that’s available globally, integrated across all DeFi ecosystems.

In this article, we will compare the main token frameworks provided by different interoperability protocols. The goal is to evaluate their unique features, pros and cons to help teams choose the best solution for issuing native multi-chain tokens.

We will explore the following frameworks:

Axelar’s ​​Interchain Token Service (ITS)

Wormhole’s Native Token Transfer (NTT)

< p>LayerZero’s full-chain fungible token (OFT)

Hyperlane’s Warp Token

xERC20 (EIP 7281: Sovereign Bridge Token)

Let’s take a closer look.

How Token Framework Works

Token Framework works in two main ways, depending on whether you are converting an existing token to a multi-chain, or launching a native multi-chain token from the beginning. currency.

Spin Method: for native multi-chain tokens

When a token is issued natively on multiple chains from day one, its supply is distributed across those chains. As coins move between chains, they are burned on the source chain and minted on the destination chain, ensuring that the total supply remains the same.

Think of it as an accounting system (as many interop teams explain it). Here's an example: Consider Token B: 200 tokens

Chain C: 200 tokens

Chain D: 100 tokens

Chain E: 100 tokens

p>

If the user will 50 tokens transferred from chain EMoved to chain A, then these tokens will be destroyed 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< /p>

Chain D: 100 tokens

Chain E: 50 tokens

This process ensures that the total supply is still 1,000 tokens, achieving chain Slip-free transfer between.

Lock casting method: for existing tokens

For existing tokens that are initially deployed on a single chain, the process is slightly different. The entire supply exists on one chain, and when transferred to another chain, a portion of the supply is locked in the source chain’s smart contract, while an equal amount of tokens are minted on the target chain.

This approach is similar to how wrapped tokens work. Tokens locked on chain A can have a wrapped version minted on chain B. However, now these tokens can also be moved from chain B to chain C using pin minting without being locked on multiple chains. The original supply remains on chain A, ensuring that transfers between chains only involve verifying that burned tokens match minted tokens.

Why token frameworks are important

Here are the reasons why tokens are tradable in a unified market across multiple chains, which benefits teams:

Liquidity - Single Market Attract more traders and increase liquidity.

Brand Awareness – Tokens become accessible across various DeFi ecosystems, increasing demand and brand awareness.

Simplicity - Token management becomes easier and reduces complexity.

Redundancy - If one chain fails, tokens can still operate on other chains, providing security.

Market Expansion - Tokens can be deployed across chains faster, promoting adoption. Additionally, an interconnected ecosystem means there is more room for experimentation in the DeFi space.

Network effects – collaboration with other projects increases adoption and value.

Consider Circle’s Cross-Chain Transfer Protocol (CCTP). By launching CCTP, Circle enables USDC to be traded seamlessly on supported chains, solving key issues:

No fragmented liquidity – previously, you had different versions of USDC on each chain , leading to low efficiency. Now, USDC is the same on all chains.

Market expansion——inDeploying USDC on multiple chains allows them to reach more users and markets.

Capital Efficiency - Users can bridge large amounts of USDC without the need for liquidity pools or wrappers.

Minimum Fees - Transfer fees are limited to gas fees.

No Slippage – Transfers are direct, eliminating the risk of slippage.

The unique feature set that Circle provides USDC is because of their self-built bridge protocol CCTP, which is something that most projects do not have Luxury goods. This is where a token framework maintained by an interoperability protocol comes into play. These frameworks provide solutions similar to those provided by CCTP for USDC, but applicable to any coin. Issuing tokens through these frameworks allows projects to create a unified market across multiple supported chains, facilitating simple transfers using burn/lock and mint mechanisms.

Comparing Token Frameworks

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

Security

The following is an explanation of the key security aspects covered in the table:

1. Authentication mechanism

The verification mechanism is the core of cross-chain transfer verification. It refers to how messages are authenticated, and the type of setup of authentication mechanisms provided by each framework - whether a single option, a modular system of multiple options, or a flexible design compatible with any bridge - allowing tokens Issuers choose the most appropriate solution based on their security requirements.

Despite the benefits provided by custom authentication mechanisms, the default configuration is still the most widely used. Therefore, it is important to focus on the security of the default authentication scheme. It is recommended that teams use additional authentication schemes over the default settings to enhance their security setup.

Relying on multiple verification mechanisms has both advantages and disadvantages when it comes to liveness. On the one hand, fault tolerance is increased: if one service provider experiences an outage, other services can ensure continued operation, thus enhancing the reliability of the system. However, this also increases the complexity of the system. Each additional mechanism introduces a potential point of failure, increasing the risk of operational disruption.

2. Verification flexibility

Highlight how flexible each framework is in customizing its verification mechanisms—specifically, whether token issuers can choose from a variety of options Choose, or limit yourself to the default settings.

3. Remarkable pre-built verification mechanism

The pre-built mechanism is a ready-made verification mechanism that token issuers can use for message verification, simplifying the deployment process. A framework with a wider range of reliable pre-built options is usually a positive sign.

While some frameworks provide more verification mechanisms than others, it is critical when evaluating them based on their security scope, which can range from a single validator to a comprehensive set of validators.

For example, OFT offers a DVN option for a single validator, as well as more robust options like CCIP or Axelar, which use a full set of validators. Likewise, Warp Token offers ISMs like Multisig ISM, which includes validators managed by the Hyperlane community, as well as options like Aggregation ISM, which allows teams to combine security from multiple ISMs.

Additionally, many of these verification mechanisms may not yet be widely adopted or thoroughly tested in real-world scenarios. Therefore, teams should carefully evaluate the quality of available verification mechanisms and select one that is consistent with their desired level of security. We highly recommend taking advantage of the available options to build a secure and reliable token verification setup. In future research articles, we will delve into the security features of the different verification mechanisms provided by each token framework.

4. Default verification mechanism

Refers to whether the framework provides a default verification mechanism. This is important because most teams usually choose the default option due to convenience. If a token issuer intends to choose the default option, it is crucial to evaluate its security, while also considering taking advantage of the customizable features provided to enhance the security of the setup.

5. Application Involvement in Verification

Highlight whether the team has the opportunity to participate in the verification process, adding an additional layer of security, or enabling it to control its own security. This is important because it enables teams to enhance security by combining their own verification settings with existing mechanisms. This way, they can rely on their own safeguards to prevent potential problems if other verification methods fail.

For example, teams such as Stargate, Tapioca, BitGo, Cluster, and Abracadabra run their own DVNs on LayerZero, demonstrating how other teams can take advantage of the customization capabilities available.

Although it requires extra effort, more teams should take advantage of this extra layer of security. When implemented effectively, this feature can prevent major problems during critical outages.

6. Censorship Resistance

Define if and how messages may be censored, which could disable the application and cause liveness issues for the team. In most cases, even if applications are censored, they can still switch to a different verification mechanism or relay within the same framework. However, this requires additional effort and may not be a practical solution to short-term problems.

7. Open source

The open source code base enables developers to audit the security features and overall settings of the framework to ensure that the executed codecode transparency.

Fees

This table compares the fee structures of multiple token frameworks, focusing on how each framework handles the cost of protocol operations, messaging, and any additional fees. It is worth noting that all frameworks allow adding custom application-specific fees at the application layer. In addition, there are fees associated with the verification and transmission process in all frameworks, including fees paid to repeaters, transmission equipment or similar entities.

Currently, most fees are related to message verification and relaying. As mentioned earlier, all token frameworks provide the option to verify messages using multiple mechanisms. Although each additional verification mechanism improves the security of the system, it also increases user fees and costs.

1. Agreement fee

This refers to the agreement fee charged by each framework for performing transfers or other operations level fees.

The existence of a fee switch for DAO governance means that token issuers may need to pay additional fees to the interoperability protocols behind the token framework (e.g. OFT’s LayerZero or Warp Token’s Hyperlane). This introduces a dependency on DAO governance, as any changes to the fee switch will directly affect tokens issued through these frameworks, making them subject to the DAO's decisions on fee structures.

Smart Contracts

This table highlights the key attributes of each framework's smart contracts, emphasizing their varying degrees of flexibility, security, and customizability, focusing on deployment history, security audits, bounties offered, and Significant customization for fine-grained control.

It is important to note that all frameworks allow applications to set rate limits and blacklists, which are critical security features that, when used effectively, can prevent significant financial losses. Additionally, each framework provides flexibility in smart contract deployment, which can be deployed as immutable or upgradable depending on the specific needs of the application.

1. Deployment time

This field displays the time of smart contract deployment for each framework. This provides insight into how long the framework has been operating.

2. Audit

The number of audits is an important measure of security. Audits verify the integrity of framework smart contracts and identify vulnerabilities or issues that could compromise the system.

3. Bounty

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

4. Salient features of fine-grained control

The smart contract framework allows applications to implement various customizable security features according to their specific needs. This field highlights several key security features provided by each framework to ensure security.

Adopt and extend

Every frameworkBrings unique features and has varying levels of involvement from developers, protocols and platforms depending on their technical focus, integrations and security assurances.

1. Core contributors

This section highlights active participation in the build and the various teams that maintain each framework. Diverse contributors, not just limited to the original development team, are positive indicators of several factors: (1) broader demand for the framework; (2) accessibility and ease of use of the framework, whether in a permissionless form or Through general cooperation.

2. Adoption

Adoption reflects the level of usage and traction of each framework, measured by the number of deployed tokens and total security value. It provides insights into the framework’s broad acceptance by developers and protocols, as well as its reliability in protecting assets.

3. Notable Teams

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

4. Virtual machine coverage

Virtual machine coverage refers to the range of virtual machines supported by each framework. More virtual machines provide more flexibility and compatibility in different blockchain environments. This gives application and token issuers a more accessible and diverse community.

5. Deployed Chains

This field reflects the number of chains deployed by each framework, i.e. each application or token issuer can support if they decide to use a specific framework The number of chains. This is directly related to the number of markets and DeFi ecosystems an application can reach. Higher chain deployment means wider liquidity access.

Also, while the ability to extend the framework permissionlessly between different chains has great potential, it can also be a challenge if developers need to build and maintain critical infrastructure themselves. For some teams, such as those looking to build bridging support for new chains, the effort may be worthwhile. But this may appear overly complex and resource-intensive for token issuers who simply want to bring other chains into their token coverage.

6. Unique Differentiators

Each framework has unique differentiators, usually in the form of special features, tools, or integrations, that make it different from other frameworks. These differentiators often attract developers and protocols looking for specific functionality or ease of use, or simply looking to provide wider distribution for their tokens.

Developer Experience

Disclaimer: This section reflects insights from @SlavaOnChain (Head of DevRel at LI.FI) and discussions with Discussions from developers familiar with various frameworks. developUser experience may vary depending on context and use case.

1. Ease of integration

Refers to the Experience for the first time how easy it is to deploy a token using this framework without team support.

2. Documentation

Evaluate the effectiveness of the framework’s guidance, examples, and reference materials in supporting developers’ understanding and use of the platform.

3. Developer Tools

Consider libraries, SDKs, and utility sets that make it easier to build, test, and deploy tokens using the framework.

Key Takeaways

A. Interoperability Trends

1. Customizability and Authentication Mechanisms - All frameworks provide customizability in authentication mechanisms, marking a step forward in interoperability protocols. New trends. Discussions on wstETH’s Lido DAO governance forum were an important moment that highlighted the need for this feature.

2. Security practices - Features such as rate limiting, whitelisting/blacklisting, and allowing token issuers to participate in message verification and security settings through custom policies and roles have become standard practices in the framework, It shows that security in the interoperability field is developing in a positive direction.

3. Adoption challenges beyond the default — Although custom authentication mechanisms are beneficial, adoption beyond the default is still low and better education about security options is needed. It is crucial to ensure that default authentication schemes are highly secure since they are the most commonly used.

4. Verification mechanism — Axelar’s ​​validator set and Wormhole’s Guardian network are widely adopted verification mechanisms provided to multiple frameworks.

B. Leading Token Framework

1. LayerZero’s OFT — Leading in deployed tokens and total security value. They were the first to launch the OFT (V1) token framework in 2022 and have continued to solidify their position, with major assets such as WBTC recently adopting the OFT framework. They also offer extensive support and comprehensive developer resources for most chains.

2. Hyperlane’s Warp Token — The team has a strong focus on making the framework and developer tools friendly for unauthorized operations. This is demonstrated through multiple virtual machine implementations built and maintained by external teams, demonstrating the ease of working with the framework in a permissionless manner.

3. Wormhole’s NTT — quickly gained adoption of high-value tokens across chains and offers some unique features in the design, such as no protocol-level fee switch. It is looking to expand the token to Solana or a popular choice for teams expanding Solana tokens into the EVM ecosystem.

4. Axelar’s ​​ITS — With over $400M in TVL, Axelar ranks among the top 25 PoS chains. The ITS framework is a key growth driver, contributing to TVL and the volume of messages sent across the Axelar network.

5. xERC20 Framework — The only fully bridge-agnostic framework, unlike other frameworks that are more product-like. Many interop protocols without their own frameworks encourage teams to deploy tokens using xERC20, and some offer pre-built integration templates.

6. Fee structure differences — xERC20 and NTT are two frameworks that do not have a protocol-level fee switch.

End Thoughts

Token frameworks are on the rise and they could change everything about the flow of value in a multi-chain world. Currently, moving assets between chains typically requires a liquidity pool or solver, but the Token Framework eliminates these needs. Instead, assets can be minted directly on the desired chain through interoperability protocols.

In fact, token frameworks may be the end of the world for wrapped assets. Liquidity no longer needs to be dispersed between chains. You can mint fungible assets on any chain and they can be traded between chains for just gas fees. We are already starting to see signs of this shift. Circle launched CCTP to bypass USDC’s wrapped token issues, and many large teams and high-value tokens are now adopting the token framework. This is a sign that things are accelerating.

However, there are valid concerns about the risk of third-party contagion—if interoperability protocols fail, they could impact all projects built on them. Despite these risks, adoption is growing.

Another perspective: In a future of chain abstraction, token frameworks may no longer matter as solvers exchange user-native tokens behind the scenes. And while this is true—the user doesn’t need to think about the token—it misses a key angle. What about the solvers themselves? For them, a token framework can be very useful. They solve the headache of inventory and rebalancing because they don’t require liquidity to move between chains. This is why solvers love using CCTP to move USDC — it’s cheap, efficient, and perfect for cross-chain rebalancing.

How all this plays out remains to be seen. Maybe we only need token frameworks for a few edge chains, or they will become the standard for deploying tokens in crypto. What we know today is that adoption of interop frameworks is growing and competition is intensifying. What are the growing pains? Fragmentation. A competitive framework will fragment assets and liquidity, and we won’t see a one-size-fits-all solution. The incentives just don't allow for that.

This brings us to another way to solve liquidity fragmentationSolution: Aggregation. This is where players like LI.FI come into play. By integrating multiple token frameworks and abstracting complexity for applications and users, our API enables seamless token exchange, whether the mechanism is pool-based, intent-based, or lock/destroy and mint. The only thing that matters is getting the coins you need at the best price.