Original article by: Arjun Chand
Original translation: TechFlow
Note: If you are already familiar with how the token framework introduced by the interoperability protocol works, you can skip directly to the comparative analysis section.
introduction
Issuing a token used to be simple: you just deployed it on Ethereum because that’s where all the activity is — users, traders, capital, and liquidity. Today it’s much more complicated. Liquidity is spread across Bitcoin, Ethereum, L2, Solana, and other chains. So where can you issue a token? There’s no simple answer.
But what if you didn’t have to choose just one chain? Imagine a token that could be used everywhere, flowing smoothly throughout the crypto economy.
Thanks to interoperability protocols (also known as bridges), it is now possible to issue tokens for a unified market on multiple chains. This creates borderless liquidity and simplifies operations for token issuers: more liquidity, greater acceptance, and stronger network effects - without having to worry about the problems that come with fragmentation. Basically, it's like having a global bank account that works everywhere, integrated into all DeFi ecosystems.
In this article, we will compare the leading token frameworks offered by different interoperability protocols. Our goal is to evaluate their unique features, advantages, and tradeoffs 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
xERC 20 (EIP 7281: Sovereign Bridge Tokens)
Let’s get started.
How the Token Framework Works
There are two main approaches to token frameworks, depending on whether you are turning an existing token into a multi-chain token or launching a native multi-chain token from the beginning.
Burning and minting: for native multi-chain tokens
When a token is natively issued on multiple chains from day one, its supply is distributed across those chains. When tokens are transferred between chains, they are destroyed on the source chain and minted on the destination chain, ensuring that the total supply remains constant.
Think of it as a ledger system (as explained by many interoperability teams). Here’s an example: Consider token X, with a total supply of 1,000 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, these tokens are destroyed on chain E and minted on chain A. The updated distribution is:
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 1,000 tokens, facilitating seamless transfers without slippage.
Locking and Minting: For Existing Tokens
For existing tokens that were initially deployed on only a single chain, the process is different: the entire supply is concentrated 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, while the same number of tokens are minted on the target chain.
This approach is similar to how wrapped tokens operate. Tokens locked on chain A can be minted as wrapped tokens on chain B. However, now these tokens can also be transferred from chain B to chain C using the burn-and-mint method, without having to be locked on multiple chains. The original supply still remains on chain A, ensuring that transfers between chains only require verifying that the tokens burned match the tokens minted.
Why Token Systems Are Important
Here are the benefits to teams of having tokens that can be traded in a unified cross-chain marketplace:
Liquidity – A unified market attracts more traders and increases liquidity.
Brand recognition – Tokens are available in various DeFi ecosystems, increasing demand and brand recognition.
Simplicity – Token management becomes simpler and reduces complexity.
Redundancy – If one chain fails, tokens can still operate on other chains, providing a safety net.
Market Expansion – Tokens can be deployed on multiple chains faster, facilitating adoption. Additionally, an interconnected ecosystem means there is room for more experimentation in the DeFi space.
Network effects – collaboration with other projects increases adoption and value.
Take a look at Circle’s Cross-Chain Transfer Protocol (CCTP). By launching CCTP, Circle enables USDC to be traded seamlessly on supported chains, solving key problems:
Fragment-free liquidity – Before, there were different versions of USDC on each chain, causing inefficiencies. Now, USDC is the same on all chains.
Market Expansion – Deploying USDC on multiple chains enables it to access more users and markets.
Capital efficiency – Users can bridge large amounts of USDC without the need for liquidity pools or wrappers.
Minimal fees – Transfer costs are mostly gas costs.
No Slippage – Transfers are direct, eliminating the risk of slippage.
The unique feature set that Circle provides for USDC is made possible by their custom built bridge protocol CCTP, a luxury that most projects do not have. This is where token frameworks maintained by interoperability protocols come into play. These frameworks provide similar functionality to what CCTP provides for USDC, but for any token. By issuing tokens through these frameworks, projects can establish unified markets across multiple supported chains, enable simple transfers, use 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 on the market for teams to issue tokens.
Security
Security of the Token Framework
Below is an explanation of the key safety aspects covered in the table:
1. Verification mechanism
The verification mechanism is the core of cross-chain transfer verification. It refers to how messages are verified, and the type of settings each framework provides in terms of verification mechanisms - whether it is a single option, a modular system with multiple options, or a flexible design compatible with any bridge - this allows token issuers to choose the most appropriate solution based on their security needs.
Although custom authentication mechanisms offer many benefits, the default configuration is still the most widely used. Therefore, it is important to pay attention to the security of the default authentication scheme. It is recommended that teams use additional authentication mechanisms on top of the default scheme to enhance its security settings.
Relying on multiple validation schemes has both advantages and disadvantages when it comes to liveness. The advantage is improved fault tolerance: if one provider goes down, the other providers can ensure continued operations, thus enhancing the reliability of the system. However, it also increases the complexity of the system. Each additional scheme introduces a potential point of failure, increasing the risk of operational disruption.
2. Flexibility of verification mechanism
Emphasize the flexibility of each framework in customizing authentication mechanisms—particularly, whether token issuers can choose from a variety of options or are restricted to using the default settings.
3. Outstanding pre-built verification solutions
Pre-built schemes are authentication mechanisms that token issuers can use directly for message authentication, thus simplifying the deployment process. A framework that provides more reliable pre-built options is usually a positive sign.
While some frameworks offer more verification schemes than others, it is critical to evaluate them based on their security, which can range from a single verifier to a comprehensive set of verifiers.
For example, OFTs offers DVN (Dynamic Verification Network) options that include a single validator and more powerful options like CCIP or Axelar that use a full set of validators. Similarly, Warp Token offers ISM (Smart Contract Management) that includes a multi-signature ISM run by the Hyperlane community, while also offering options like Aggregate ISM that allows teams to combine security from multiple ISMs.
Additionally, many authentication schemes may not yet be widely used or adequately tested in the real world. Therefore, teams should carefully evaluate the quality of available authentication schemes and choose the ones that match their required security level. We strongly recommend leveraging existing options to build a secure and reliable token authentication system. In future research articles, we will delve deeper into the security features of different authentication schemes provided by various token frameworks.
4. Default Authentication Scheme
Refers to whether the framework provides a default authentication mechanism. This is very important because most teams usually choose the default option for ease of use. If the token issuer decides to use the default option, it is particularly important to evaluate its security and consider taking advantage of customizable features to enhance security.
5. Application participation verification
Emphasize whether teams can participate in the verification process, which can add additional security, or let them take control of their own security. This is very important because it allows teams to improve security by combining their own verification systems with existing mechanisms. This way, if other verification methods fail, they can rely on their own protection measures to avoid potential risks.
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, this feature can prevent major issues in the event of a critical failure.
6. Censorship resistance
Define if and how messages may be censored, which can cause the application to fail and affect the normal operation of the team. In most cases, even if the application is censored, they can still switch to a different verification 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 that executes. This transparency is critical to ensuring the security and reliability of the software.
Cost Comparison
This table compares the fee structures of several token frameworks, focusing on how each framework handles protocol operations, messaging, and other additional fees. It is worth noting that all frameworks allow custom application fees to be added at the application layer. In addition, in all frameworks, the verification and transfer processes involve fees, including fees paid to relayers, transceivers, or similar entities.
Currently, most fees are associated with message verification and relaying. As mentioned earlier, all token frameworks provide multiple mechanisms to verify messages. While each additional verification scheme increases the security of the system, it also increases fees and costs for users.
Fees are related to the token framework
Protocol layer fees
This refers to the fee each framework charges when performing a transfer or other operation.
Since there is a fee switch managed by the 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 Tokens). 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.
Smart Contracts
This table demonstrates the key attributes of each framework's smart contracts, highlighting their differences in flexibility, security, and customizability, paying particular attention to deployment history, security audits, rewards offered, and significant customization options to enable more Meticulous control.
Notably, all frameworks allow applications to set rate limits and blacklists, key security features that can help prevent significant financial losses when used effectively. Additionally, each framework provides the flexibility to deploy smart contracts as immutable or upgradeable, depending on the specific needs of the application.
Token framework for smart contracts
Deployment time
This field shows the deployment time of each framework smart contract, reflecting the operational time of the framework.
audit
The number of audits is an important indicator of security. Audits ensure the integrity of the framework smart contracts and identify vulnerabilities and issues that may affect the system.
bonus
Bounties are financial incentives provided by the framework to encourage external security researchers to discover and report vulnerabilities.
Salient features for fine-grained control
Smart contract frameworks allow applications to implement a variety of customizable security features based on specific needs. This field highlights some of the key security features provided by the framework to ensure system security.
Adoption and promotion
Each framework has its own unique characteristics, and the level of involvement of developers, protocols, and platforms varies depending on the technical focus, integration approach, and security assurance.
Core Contributors
This section highlights the active involvement of various teams in building and maintaining each framework. The diversity of participants beyond the original development team is a positive indicator of multiple factors: (1) the broader demand for the framework, and (2) the accessibility and ease of use of the framework, both through permissionless means and general collaboration.
Adoption
Adoption reflects the level of usage and traction of each framework, measured by the number of tokens deployed and total locked value. It provides insight into the broad acceptance of the framework by developers and protocols, as well as its reliability in securing assets.
Well-known team
This section highlights the top teams and protocols adopting each framework, reflecting their trust and overall traction in the industry.
Virtual Machine Overlay
VM coverage refers to the range of VMs supported by each framework. Supporting more VMs provides greater flexibility and compatibility in different blockchain environments. This provides more choices for applications and token issuers, allowing them to reach a diverse community
Number of deployment 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 decentralized finance (DeFi) ecosystems that the application can access. Higher chain deployment means wider access to liquidity.
Additionally, while permissionless extension of the framework across different chains has great potential, it can also present challenges if developers need to build and maintain critical infrastructure themselves. For some teams, such as those looking to build bridge support for new chains, this work may be worthwhile. But for token issuers who simply want to expand the reach of their token to another chain, this may prove overly complex and resource-intensive.
Unique differentiation
Each framework brings a unique differentiator, usually in the form of special features, tools, or integrations, that sets it apart from the others. These differentiators often attract developers and protocols that are looking for specific functionality, ease of use, or want to get more distribution for their tokens.
Developer Experience
Disclaimer: This section reflects insights gained from @SlavaOnChain (Head of Developer Relations at LI.FI) and discussions with developers familiar with various frameworks. Developers’ experiences may vary depending on their background and use case.
Developer Experience with the Token Framework
Ease of integration
Refers to how easy it is to deploy a token using the framework for the first time without support from a team.
document
Evaluate the effectiveness of the framework's guidance, examples, and reference materials in helping developers understand and use the platform.
Developer Tools
Consider the full suite 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 Validation Mechanisms – All frameworks offer customizable validation mechanisms, marking a new trend in interoperable protocols. The discussion on wstETH in the Lido DAO governance forum was a key moment that highlighted the need for this feature.
Security Practices – Features such as rate limiting, whitelisting/blacklisting, and enabling token issuers to participate in message validation 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.
Adoption Challenges Beyond Defaults – While custom authentication mechanisms are beneficial, adoption rates beyond defaults remain low, which requires better education on security options. Ensuring that default authentication schemes are highly secure is critical, as they are the most commonly used.
Validation Mechanisms – Axelar’s validator set and Wormhole’s guard network are widely adopted validation mechanisms that are already available in various frameworks.
B. Leading Token Frameworks
LayerZero’s OFT – Leads in number of tokens deployed and value secured, thanks to its early market advantage, broad support for most chains, and comprehensive developer resources.
Hyperlane’s Warp Token - The team is very focused on making the framework and developer tooling more permissionless friendly. This is evident through multiple virtual machine implementations built and maintained by external teams, showing how easy it is to use the framework in a permissionless manner.
Wormhole’s NTT – has quickly gained widespread adoption, with high-value tokens deployed across chains, and offers multiple unique features in its design, such as no protocol-level fee switches. It is a popular choice for teams looking to scale their tokens to Solana or bring Solana tokens to the EVM ecosystem.
Axelar’s ITS – With over $400M in Total Value Locked (TVL), Axelar is ranked among the top 25 Proof of Stake (PoS) chains. The ITS framework is a key growth driver, driving both TVL growth and the volume of messages sent through the Axelar network.
xERC 20 Framework – The only framework that is completely independent of bridges, unlike other frameworks that are more like products. Many interoperable protocols that do not have their own frameworks encourage teams to use xERC 20 to issue tokens, and some protocols also provide pre-built templates for integration.
Differences in fee structures – xERC 20 and NTT are two frameworks that do not have protocol-level fee switches.
Summarize
Token frameworks are emerging, and they could change every aspect of how value flows in a multi-chain world. Currently, transferring assets across chains typically requires 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 interoperable protocols.
In fact, the Token Framework could be the end of wrapped assets. Liquidity no longer needs to be fragmented across chains. You can mint fungible assets on any chain, and they can be traded between chains for just the gas fee. We’re already seeing signs of this trend. Circle launched CCTP to circumvent issues with wrapped tokens for USDC, and many large teams and high-value tokens are now adopting the Token Framework. This suggests progress is accelerating.
However, there are legitimate concerns about third-party chain reaction risks—if interoperable protocols fail, it could affect all projects built on top of them. Despite these risks, adoption of token frameworks continues to grow.
Another view is this: in a chain-abstracted future, token frameworks won’t matter because solvers will swap native tokens for users behind the scenes. While this makes some sense — users won’t need to think about tokens — it misses a key factor. So, what about the solvers themselves? For solvers, token frameworks can be very useful. They solve the hard problem of asset inventory and rebalancing because they don’t require liquidity to be transferred between chains. This is why frameworks like CCTP are favored by solvers when moving USDC — it’s cheap, efficient, and a great fit for cross-chain rebalancing.
How this will all play out is uncertain. Perhaps we will only need token frameworks on a few edge chains, or perhaps they will become the standard for deploying tokens in the crypto space. What we know today is that adoption of interoperable frameworks is growing, and competition is increasing. What’s the problem with this growth? Fragmentation. Competing frameworks will fragment assets and liquidity, and we won’t see a one-size-fits-all solution. That’s not feasible given the incentive structure.
Original link
