Comparison of cross-chain token frameworks

Source: Denglian Community

Introduction

Issuing tokens used to be simple: you just deployed it on Ethereum, where all the activity was going on - users, traders, capital, and liquidity. Today, the situation is much more complicated. Liquidity is scattered across Bitcoin, Ethereum, L2, Solana, and other chains. So, where should you issue your token? 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 operations 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 works worldwide and is integrated into 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 to issue native multi-chain tokens.

We’ll explore the following frameworks:

• Axelar’s ​​Interchain Token Service (ITS)

• Wormhole’s Native Token Transfer (NTT)

• LayerZero’s Total Fungible Token (OFT)

• Hyperlane’s Warp Token

• xERC20 (EIP 7281: Sovereign Bridge Token)

Let’s take a deeper look.

How the Token Framework Works

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

Pinning: For Native Multichain Tokens

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

It can be thought of as a bookkeeping system (as explained by many interop teams). Here is an example: Consider token X, which has 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, then those 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

• Chain D: 100 tokens

• Chain E: 50 tokens

This process ensures that the total supply remains at 1000 tokens, enabling slippage-free transfers between chains.

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

This method 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 the pinning method without being locked up on multiple chains. The original supply remains on chain A, ensuring that transfers between chains only involve verifying that the tokens burned match the tokens minted.

Why Token Frameworks Matter

Here are the reasons why having tokens tradable in a unified marketplace across multiple chains is a benefit to teams:

• Liquidity – A single marketplace attracts more traders, increasing liquidity.

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

• Simplicity – Token management becomes easier, reducing 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 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 problems:

• No fragmented liquidity – Before, you had different versions of USDC on each chain, causing inefficiencies. Now, USDC is the same on all chains.

• Market expansion – Deploying USDC on multiple chains gives them access to 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 for USDC is due to their homegrown bridge protocol CCTP, a luxury that most projects don’t have. This is where token frameworks maintained by interoperability protocols come into play. These frameworks provide a solution similar to what CCTP provides for USDC, but for any token. By issuing tokens through these frameworks, projects can 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. Verification mechanism

The verification mechanism is the core of cross-chain transfer verification. It refers to how the message is verified, and the type of setting of the verification mechanism provided by each framework - whether it is a single option, a modular system with multiple options, or a flexible design compatible with any bridge - allows token issuers to choose the most appropriate solution according to their security requirements.

Despite the benefits provided by custom validation mechanisms, the default configuration is still the most widely used . Therefore, it is important to focus on the security of the default validation scheme. Teams are advised to use additional validation schemes on top of the default setup to enhance their security setup.

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

2. Flexibility of validation

Highlight the flexibility of each framework in customizing its validation mechanisms - specifically, whether token issuers can choose from a variety of options or are limited to the default settings.

3. Notable Pre-Built Validation Mechanisms

Pre-Built mechanisms are off-the-shelf validation mechanisms that token issuers can use for message validation, simplifying the deployment process. Frameworks with a wider range of reliable pre-built options are generally a positive sign.

While some frameworks offer more validation mechanisms than others, it is critical to evaluate them based on their range of security, which can range from a single validator to a comprehensive validator set.

For example, OFT offers DVN options for a single validator, as well as stronger options like CCIP or Axelar that use a full validator set. Similarly, Warp Token offers ISMs like Multisig ISM, which includes validators managed by the Hyperlane community, while also having options like Aggregation ISM that allow teams to combine security from multiple ISMs.

In addition, many of these validation 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 choose one that matches their desired level of security. We strongly recommend leveraging the available options to build a secure and reliable token verification setup. In future research articles, we will delve deeper 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 leveraging the customizable features provided to enhance the security of the setup.

5. Application Participation in Verification

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

For example, teams like 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 additional effort, more teams should take advantage of this additional layer of security. When implemented effectively, the feature can prevent major issues during critical outages.

6. Censorship Resistance

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

7. Open Source

The open source codebase enables developers to audit the security features and overall setup of the framework, ensuring transparency into the code executed.

Fees

This table compares the fee structures of multiple token frameworks, focusing on how each framework handles the costs of protocol operations, messaging, and any additional fees. Notably, all frameworks allow for custom application-specific fees to be added at the application layer. Additionally, there are fees associated with the verification and transmission processes in all frameworks, including fees paid to relayers, transmission devices, or similar entities.

Currently, the majority of fees are associated with message verification and relaying. As mentioned earlier, all token frameworks offer the option to verify messages using multiple mechanisms. While each additional verification mechanism improves the security of the system, it also increases fees and costs for users.

1. Protocol Fees

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

The existence of a fee switch for DAO governance means that token issuers may need to pay additional fees to the interoperability protocol 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 decision on the fee structure.

Smart Contracts

The table highlights the key attributes of each framework’s smart contracts, highlighting their varying degrees of flexibility, security, and customizability, with a focus 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 key security features that, when used effectively, can prevent significant financial losses . Additionally, each framework offers 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 shows the time when each framework’s smart contracts were deployed. This provides insights into how long the framework has been operational.

2. Audits

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

3. Bounties

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

Smart contract frameworks allow applications to implement a variety of customizable security features based on their specific needs. This field highlights several key security features provided by each framework to ensure security.

Adoption and Expansion

Each framework brings unique features and varying levels of involvement from developers, protocols, and platforms, depending on their technical focus, integrations, and security assurances.

1. Core Contributors

This section highlights the various teams that are actively involved in building and maintaining each framework. A diverse set of contributors, beyond the original development team, is a positive indicator of several factors: (1) broader demand for the framework; and (2) the accessibility and ease of use of the framework, both in a permissionless form and through general collaboration.

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 how widely accepted the framework is by developers and protocols, and how reliable it is in protecting assets.

3. Notable Teams

This section highlights the top teams and protocols that have adopted each framework, reflecting their trust and overall traction in the industry.

4. VM Coverage

VM coverage refers to the range of VMs supported by each framework. More VMs provide more flexibility and compatibility across different blockchain environments. This provides applications and token issuers with a more diverse community to reach.

5. Deployed Chains

This field reflects the number of chains deployed by each framework, i.e., the number of chains that 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 DeFi ecosystems that the application can reach. Higher chain deployment means wider access to liquidity.

In addition, while the ability to permissionlessly extend a framework between different chains has great potential, it can also be challenging if developers need to build and maintain critical infrastructure themselves. For some teams, such as those seeking to build bridge support for new chains, the effort may be worthwhile. But for token issuers who simply want to include other chains in their token coverage, this may prove overly complex and resource-intensive.

6. Unique Differentiators

Each framework has unique differentiators, often in the form of special features, tools, or integrations that set it apart from the rest. These differentiators often attract developers and protocols that are looking for specific features or ease of use, or simply want wider distribution for their tokens.

Developer Experience

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

1. Ease of integration

Refers to how easy it is to deploy tokens using this framework without team support based on first-time experience.

2. Documentation

Evaluate the effectiveness of the framework's guides, examples, and reference materials in supporting developers to understand and use the platform.

3. Developer Tools

Consider libraries, SDKs, and utility toolsets 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 offer customizability in authentication mechanisms, marking a new trend in interoperable protocols. The discussion on the Lido DAO governance forum on wstETH was 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 validation and security settings through custom policies and roles have become standard practices in frameworks, indicating that security in the interoperability space is moving in a positive direction.

3. Adoption Challenges Beyond Defaults — While custom validation mechanisms are beneficial, adoption of moving beyond defaults is still low and better education about security options is needed. It is critical to ensure that default validation schemes are highly secure as they are the most commonly used.

4. Validation Mechanisms — Axelar’s ​​Validator Sets and Wormhole’s Guardian Network are widely adopted validation mechanisms that are provided to multiple frameworks.

B. Leading Token Frameworks

1. OFT by LayerZero — Leading in terms of 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 provide broad support for most chains and comprehensive developer resources.

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

3. NTT by Wormhole — Rapidly gaining adoption for high-value tokens across chains and offering some unique features in its design, like no protocol-level fee switches. It’s a popular choice for teams looking to scale their tokens to Solana or scale Solana tokens to the EVM ecosystem.

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

5. xERC20 Framework — The only fully bridge-agnostic framework, unlike others that are more product-like. Many interop protocols that don’t have their own frameworks encourage teams to use xERC20 to deploy tokens, 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.

Closing Thoughts

Token frameworks are on the rise, and they could change everything about how value flows in a multi-chain world. Currently, transferring assets between chains typically requires a liquidity pool or a solver, but token frameworks eliminate these needs. Instead, assets can be minted directly on the desired chain through an interoperable protocol.

In fact, token frameworks could be the endgame for wrapped assets. Liquidity no longer needs to be split between chains. You can mint fungible assets on any chain, and they can be traded between chains for just the gas fee. We’re already starting to see signs of this shift. Circle launched CCTP to get around the wrapped token problem with USDC, and many big teams and high-value tokens are now adopting token frameworks. It’s a sign that things are accelerating.

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

Another view: In a chain-abstracted future, token frameworks may no longer matter, as solvers swap users’ native tokens in the background. And while there’s truth to this — users don’t need to think about tokens — it misses a key angle. What about the solvers themselves? For them, token frameworks can be extremely useful. They solve the annoyance 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 great for cross-chain rebalancing.

How this all pans out remains to be seen. Maybe we’ll only need token frameworks for a handful of edge chains, or they’ll become the standard for deploying tokens in crypto. What we know today is that adoption of interoperable frameworks is growing, and so is competition. What are the growing pains? Fragmentation. Competing frameworks 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 solution to liquidity fragmentation: aggregation. This is where players like LI.FI come into play. By integrating multiple token frameworks and abstracting the complexity for applications and users, our API enables seamless token swaps, whether the mechanism is pool-based, intent-based, or lock/burn and mint. The only thing that matters is getting the token you want at the best price.