Source: Jinse Community
Introduction
Issuing Tokens used to be simple: you just deployed it on Ethereum, where all the activity was happening - users, traders, capital, and liquidity. Today, the situation is much more complex. Liquidity is scattered across Bit, 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 across the entire crypto economy.
Thanks to interoperability protocols (i.e., bridges), it is now possible to issue a unified market Token that spans multiple chains. This creates borderless global liquidity, simplifying the operations of Token issuers: more liquidity, greater adoption, and stronger network effects - without the concern of fragmentation. Essentially, it's like having a bank account that can be used globally, integrated into all the DeFi ecosystems.
In this article, we will compare the main Token frameworks provided by different interoperability protocols. The goal is to assess 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 Cross-Chain Token Service (ITS)
Wormhole's Native Token Transfer (NTT)
LayerZero's Omni-Fungible Token (OFT)
Hyperlane's Warp Token
xERC20 (EIP 7281: Sovereign Bridged Tokens)
Let's dive in.
How Token Frameworks Work
Token frameworks primarily work in two ways, depending on whether you are converting an existing Token to be Multi-Chain, 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 those chains. As the Token moves between chains, it is burned on the source chain and minted on the destination chain, ensuring the total supply remains constant.
This can be thought of 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 the total supply remains 1000 Tokens, enabling seamless cross-chain transfers without slippage.
For Tokens that already exist, 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 a smart contract on the source chain, while an equivalent amount is minted on the destination chain.
This method is similar to how wrapped Tokens operate. The Tokens locked on Chain A can be minted as a wrapped version on Chain B. However, now these Tokens can also be moved from Chain B to Chain C using the burn-and-mint method, without needing to be locked on multiple chains. The original supply is still retained on Chain A, ensuring that cross-chain transfers only involve verifying that the burned Tokens match the minted Tokens.
Why Token Frameworks Matter
Here are the benefits of having a Token tradable in a unified market across multiple chains, which are advantageous for teams:
Liquidity - A single market attracts more traders, increasing liquidity.
Brand Visibility - The Token becomes accessible across various DeFi ecosystems, increasing demand and brand awareness.
Simplicity - Token management becomes easier, reducing complexity.
Redundancy - If one chain fails, the Token can still operate on other chains, providing a safety net.
Market Expansion - Tokens can be deployed across chains more quickly, facilitating adoption. Additionally, the interconnected ecosystems mean more experimentation space in DeFi.
Network Effects - Collaborations with other projects increase adoption and value.
Consider Circle's Cross-Chain Transfer Protocol (CCTP). By launching CCTP, Circle has enabled USDC to be seamlessly tradable on supported chains, solving key issues:
No Fragmented Liquidity - Previously, you had different versions of USDC on each chain, leading to inefficiencies. Now, USDC is the same across all chains.
Market Expansion - Deploying USDC on multiple chains allows them to reach more users and markets.
Capital Efficiency - Users can bridge large amounts of USDC without needing liquidity pools or wrapping.
Minimal Fees - Transfer fees are limited to gas costs only.
No Slippage - Transfers are direct, eliminating slippage risk.
The unique feature set Circle provides for USDC is due to their in-house bridging protocol CCTP, a luxury most projects don't have. This is where the Token frameworks maintained by interoperability protocols come into play. These frameworks provide solutions similar to what CCTP offers for USDC, but for any Token. By issuing Tokens through these frameworks, projects can create a unified market across multiple supported chains, enabling seamless 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 in the market for teams seeking to issue Tokens.
Security
Here's an explanation of the key security aspects covered in the table:
1. Verification Mechanism
The verification mechanism is the core of cross-chain transfer validation. It refers to how messages are verified, and the type of verification mechanism setup each framework provides - whether 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 requirements.
While custom verification mechanisms offer benefits, default configurations are still the most widely used. Therefore, focusing on the security of the default verification scheme is important. Teams are advised to use additional verification schemes on top of the default settings to enhance their security setup.
In terms of resilience, relying on multiple verification mechanisms has both pros and cons. On one hand, fault tolerance is increased: if one service provider experiences downtime, the other services can ensure continued operation, enhancing the system's reliability. However, this also increases the complexity of the system. Each additional mechanism introduces a potential point of failure, raising the risk of operational disruptions.
2. Verification Flexibility
Highlights the flexibility of each framework in customizing their verification mechanism - specifically, whether Token issuers can choose from various options, or are limited to the default setup.
3. Prominent Pre-Built Verification Mechanisms
Pre-built mechanisms are ready-to-use verification mechanisms that Token issuers can leverage for message validation, simplifying the deployment process. Frameworks with a wider range of reliable pre-built options are generally a positive signal.
While some frameworks provide more verification mechanisms than others, the critical evaluation when assessing them is based on their security scope, which can range from a single verifier to a comprehensive set of verifiers.
For example, OFT offers a DVN option with a single verifier, as well as more robust choices like CCIP or Axelar that utilize a full set of verifiers. Similarly, Warp Token provides ISM options such as Multisig ISM, which includes verifiers managed by the Hyperlane community, as well as options like Aggregation ISM that allow 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 choose the ones that align with their required security level. We strongly recommend leveraging the available options to build a secure and reliable token verification setup. In future research articles, we will dive deeper into the security features of the different verification mechanisms provided by each token framework.
4. Default Verification Mechanism
This refers to whether the framework provides a default verification mechanism. This is important because most teams often choose the default option for convenience. If token issuers plan to select the default option, evaluating its security is crucial, and they should also consider leveraging the customizable features provided to enhance the security of the setup.
5. Application Participation in Verification
This highlights whether teams have the opportunity to participate in the verification process, adding an extra layer of security or allowing them to control their own security. This is important because it enables teams to enhance security by combining their own verification setup with the 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 have run their own DVNs on LayerZero, demonstrating how other teams can leverage the available customization features.
While it requires additional effort, more teams should utilize this extra security layer. When effectively implemented, this feature can prevent significant issues during critical failures.
6. Censorship Resistance
This defines whether and how messages may be censored, which could disable applications and cause issues with team activity. 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 immediate problems.
7. Open-Source
Open-source code repositories allow developers to audit the security features and overall setup of the framework, ensuring transparency in the executed code.
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. It's worth noting that all frameworks allow for the addition of custom application-specific fees at the application layer. Additionally, there are fees associated with the verification and transmission processes in all frameworks, including payments to relayers, transmission devices, or similar entities.
Currently, most fees are related to message verification and relaying. As mentioned earlier, all token frameworks provide options to verify messages using various mechanisms. While each additional verification mechanism increases the system's security, it also increases the user's fees and costs.
1. Protocol Fees
These are the protocol-level fees charged by each framework for executing transfers or other operations.
The existence of fee switches governed by DAOs means that token issuers may need to pay additional fees to the interoperability protocols (e.g., LayerZero for OFT or Hyperlane for Warp Token) behind the token frameworks. This introduces a dependency on DAO governance, as any changes to the fee switches will directly impact the tokens issued through these frameworks, making them subject to the DAO's decisions on the fee structure.
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 provided, and notable customization features for fine-grained control.
It's important to note that all frameworks allow applications to set rate limits and blacklists, which are critical security features that can prevent significant financial losses when used effectively. Additionally, each framework provides flexibility in smart contract deployment, allowing them to be deployed as immutable or upgradable, depending on the specific needs of the application.
1. Deployment Time
This field shows the deployment time of each framework's smart contracts, providing insights into the longevity of the framework's operation.
2. Audits
The number of audits is an important security metric. 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. Notable Features for Fine-Grained Control
The smart contract frameworks allow applications to implement various customizable security features based on their specific needs. This field highlights a few key security features provided by each framework to ensure security.
Adoption and Scaling
Each framework brings unique features, and the level of engagement from developers, protocols, and platforms varies depending on their technical focus, integrations, and security assurances.
1. Core Contributors
This section highlights the various teams actively involved in building and maintaining each framework. Diverse contributors, not limited to the original development team, are a positive indicator of (1) broader demand for the framework and (2) the framework's accessibility and usability, whether in a permissionless form or through general collaboration.
2. Adoption Metrics
The adoption metrics reflect the usage and attractiveness levels of each framework, measured by the number of deployed tokens and the total value secured. This provides insights into the framework's widespread acceptance among developers and protocols, as well as its reliability in protecting assets.
3. Prominent Teams
This section highlights the top teams and protocols that have adopted each framework, reflecting their trust and overall appeal within the industry.
4. Virtual Machine Coverage
The virtual machine coverage refers to the range of virtual machines supported by each framework. More virtual machines provide greater flexibility and compatibility across different blockchain environments. This offers a more diverse community that applications and token issuers can reach.
5. Deployed Chains
This field reflects the number of chains each framework is deployed on, meaning the number of chains that an application or token issuer can support if they choose to use a specific framework. This directly relates to the market and DeFi ecosystem that the application can access. Higher chain deployment means broader liquidity access.
Additionally, while the ability to scale the framework across different chains without permission has tremendous potential, it may also be a challenge if developers need to build and maintain the critical infrastructure themselves. For some teams, such as those seeking to establish bridge support for new chains, this effort may be worthwhile. However, for token issuers who only wish to incorporate other chains into their token coverage, this may be too complex and resource-intensive.
6. Unique Differentiating Factors
Each framework has unique differentiating factors, often manifested in specialized features, tools, or integrations that set it apart from others. These differentiating factors typically attract developers and protocols seeking specific functionalities or usability, or simply those who want to provide a broader distribution for their tokens.
Developer Experience
Disclaimer: This section reflects insights from @SlavaOnChain (DevRel lead at LI.FI) and discussions with developers familiar with various frameworks. Developer experiences may vary depending on their background and use cases.
1. Simplicity of Integration
Refers to the ease of deploying Tokens using this framework without a team's support, based on the initial user experience.
2. Documentation
Evaluates the effectiveness of the framework's guides, examples, and reference materials in supporting developers' understanding and use of the platform.
3. Developer Tools
Considers the libraries, SDKs, and utility suites that make building, testing, and deploying Tokens using the framework easier.
Key Points
A. Interoperability Trends
1. Customizability and Verification Mechanisms — All frameworks provide customizability in verification mechanisms, marking a new trend in interoperability protocols. The discussion around Lido DAO's governance forum on wstETH was a crucial moment, highlighting the demand for this functionality.
2. Security Practices — Rate limiting, whitelists/blacklists, and allowing Token issuers to participate in message verification and security settings through custom strategies and roles have become standard practices in frameworks, indicating that security in the interoperability domain is progressing in a positive direction.
3. Adoption Challenges Beyond Default Settings — While customizable verification mechanisms are beneficial, adoption beyond default settings remains low, requiring better education on security options. Ensuring the default verification schemes are highly secure is crucial, as they are the most commonly used.
4. Verification Mechanisms — Axelar's validator set and Wormhole's Guardian network are widely adopted verification mechanisms provided to multiple frameworks.
B. Leading Token Frameworks
1. LayerZero's OFT — Leading in deployed Tokens and total secured value. They were the first to launch the OFT (V1) Token framework in 2022 and have continued to consolidate their position, with major assets like WBTC recently adopting the OFT framework. They also provide broad support for most chains and comprehensive developer resources.
2. Hyperlane's Warp Token — The team is strongly focused on making the framework and developer tools permissionless-friendly. This is reflected through multiple virtual machines built and maintained by external teams, showcasing the ease of collaborating with the framework in a permissionless manner.
3. Wormhole's NTT — Quickly gained adoption of high-value Tokens in cross-chain and offers some unique features in its design, such as the absence of a protocol-level fee switch. It is a popular choice for teams looking to extend Tokens to Solana or bring Solana Tokens to 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 the TVL and message volume transmitted through the Axelar network.
5. xERC20 Framework — The only fully bridge-agnostic framework, unlike the more product-like frameworks. Many interoperability protocols without their own frameworks encourage teams to use xERC20 to deploy Tokens, and some provide pre-built integration templates.
6. Fee Structure Differences — xERC20 and NTT are two frameworks without a protocol-level fee switch.
Concluding Thoughts
Token frameworks are on the rise, and they may change everything about how value flows in a multi-chain world. Currently, moving assets between chains often requires liquidity pools or solvers, but Token frameworks eliminate these needs. Instead, assets can be minted directly on the desired chain through interoperability protocols.
In fact, Token frameworks may be the end of wrapped assets. Liquidity no longer needs to be scattered across chains. You can mint fungible assets on any chain, and they can be traded between chains, paying only gas fees. We're already seeing signs of this transition. Circle launched CCTP to bypass the wrapped USDC problem, and many major teams and high-value Tokens are now adopting Token frameworks. This is a sign that things are accelerating.
However, reasonable concerns about third-party contagion risk are justified — if interoperability protocols fail, they may impact all the projects built on top of them. Despite these risks, adoption is still growing.
Another perspective: in a chain-agnostic future, Token frameworks may no longer matter, as solvers will swap user native Tokens in the background. While this has merit — users don't need to think about Tokens — it ignores a key angle. What about the solvers themselves? For them, Token frameworks may be very useful. They solve the hassle of inventory and rebalancing, as they don't need liquidity to move between chains. This is why solvers like using CCTP to move USDC — it's cheap, efficient, and very suitable for cross-chain rebalancing.
How this all plays out remains to be seen. Perhaps we'll only need Token frameworks for a few fringe chains, or they'll become the standard for deploying Tokens in crypto. What we know today is that the adoption of interoperability frameworks is growing, and the competition is intensifying. The growing pains? Fragmentation. Competing frameworks will scatter assets and liquidity, and we won't see a one-size-fits-all solution. The incentive structures just don't allow for that.
This leads us to another solution for addressing 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, regardless of whether the mechanism is pool-based, intent-based, or lock/burn and mint. The only thing that matters is getting the desired Token at the best price.
