In-depth Research: A Comprehensive Comparison of Cross-chain Token Issuance Methods – Which One Takes the Lead?
TechFlow Selected TechFlow Selected
In-depth Research: A Comprehensive Comparison of Cross-chain Token Issuance Methods – Which One Takes the Lead?
This article will compare leading token frameworks provided by different interoperability protocols.
Navigating Web3 tides with focused insightsAuthor: Arjun Chand
Translation: TechFlow
Note: If you're already familiar with how token frameworks introduced by interoperability protocols work, feel free to skip directly to the comparative analysis section.
Introduction
Issuing tokens used to be simple: you just deployed them on Ethereum because that's where all the activity was—users, traders, capital, and liquidity. Today, it's far more complex. Liquidity is spread across Bitcoin, Ethereum, L2s, Solana, and other chains. So where should you issue your token? There’s no straightforward answer.
But what if you didn’t have to pick just one chain? Imagine a token that can be used anywhere, flowing seamlessly throughout the crypto economy.
Thanks to interoperability protocols (also known as bridges), it's now possible to issue tokens across multiple chains into a unified market. This creates borderless liquidity and simplifies operations for token issuers: more liquidity, broader adoption, and stronger network effects—without worrying about fragmentation issues. Essentially, it's like having a global bank account that works everywhere, integrated across all DeFi ecosystems.
In this article, we'll compare leading token frameworks offered by different interoperability protocols. Our goal is to evaluate their unique features, advantages, and trade-offs to help teams choose the best solution for issuing natively multi-chain tokens. We’ll 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 Tokens
-
xERC20 (EIP 7281: Sovereign Bridged Tokens)
Let’s begin.
How Token Frameworks Work
Token frameworks operate in two main ways, depending on whether you're making an existing token multi-chain or launching a natively multi-chain token from day one.
Burn-and-Mint: For Natively Multi-Chain Tokens
When a token is natively issued across multiple chains from day one, its supply is distributed across these chains. As tokens move between chains, they are burned on the source chain and minted on the destination chain, ensuring the total supply remains constant.
Think of it as an accounting system (as many interoperability teams describe it). 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, those tokens are burned on Chain E and minted on Chain A. The updated distribution becomes:
-
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 stays at 1,000 tokens, enabling seamless, zero-slippage transfers.
Lock-and-Mint: For Existing Tokens
For existing tokens originally deployed on a single chain, the process differs. The entire supply resides on one chain, and when transferred to another chain, part 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 resembles how wrapped tokens operate. Tokens locked on Chain A can be minted as wrapped versions on Chain B. However, these tokens can now also use burn-and-mint to transfer from Chain B to Chain C without requiring additional locking. The original supply remains on Chain A, ensuring inter-chain transfers only require verification that burned tokens match newly minted ones.
Why Token Frameworks Matter
Here are the benefits of having tokens tradable within a unified cross-chain market for teams:
-
Liquidity – Unified markets attract more traders, increasing liquidity.
-
Brand Recognition – Tokens become available across various DeFi ecosystems, boosting demand and visibility.
-
Simplicity – Token management becomes simpler, reducing complexity.
-
Redundancy – If one chain fails, tokens remain operational on others, providing a safety net.
-
Market Expansion – Faster deployment across multiple chains accelerates adoption. Additionally, interconnected ecosystems enable greater experimentation in DeFi.
-
Network Effects – Collaborations with other projects increase adoption and value.
Take Circle’s Cross-Chain Transfer Protocol (CCTP). By launching CCTP, Circle enabled USDC to trade seamlessly across supported chains, solving key problems:
-
No Fragmented Liquidity – Previously, different versions of USDC existed per chain, causing inefficiencies. Now, USDC is identical across all chains.
-
Market Expansion – Deploying USDC across multiple chains allows access to more users and markets.
-
Capital Efficiency – Users can bridge large amounts of USDC without relying on liquidity pools or wrappers.
-
Minimal Fees – Transfer costs are primarily gas fees.
-
Zero Slippage – Transfers are direct, eliminating slippage risk.
Circle’s unique feature set for USDC stems from their custom-built bridging protocol, CCTP—a luxury most projects don’t have. This is precisely where token frameworks maintained by interoperability protocols come into play. These frameworks offer 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, enabling simple transfers via 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 for teams issuing tokens.
Security
Token Framework Security
Below is an explanation of the key security aspects covered in the table:
1. Verification Mechanism
The verification mechanism is central to validating cross-chain transfers. It refers to how messages are verified and the type of setup each framework offers regarding verification—whether a single option, a modular system with multiple choices, or a flexible design compatible with any bridge—allowing token issuers to select the most suitable solution based on their security needs.
Although custom verification mechanisms offer many benefits, default configurations remain the most widely used. Therefore, it's crucial to focus on the security of default verification schemes. Teams are advised to layer additional verification mechanisms on top of default setups to enhance their security posture.
Regarding liveness, relying on multiple verification schemes has both pros and cons. The advantage is increased fault tolerance: if one provider goes down, others can maintain operations, improving reliability. However, this also increases system complexity. Each added scheme introduces a potential point of failure, raising the risk of operational disruption.
2. Flexibility in Verification Mechanisms
Highlights the flexibility each framework offers in customizing verification mechanisms—specifically, whether token issuers can choose from multiple options or are limited to default settings.
3. Notable Pre-Built Verification Schemes
Pre-built schemes are verification mechanisms that token issuers can directly use for message validation, streamlining deployment. A framework offering more reliable pre-built options is generally a positive signal.
While some frameworks provide more verification schemes than others, it’s essential to evaluate them based on security, ranging from single validators to full validator sets.
For instance, OFTs’ DVN (Decentralized Verification Network) options include single validators and more robust choices like CCIP or Axelar, which use complete validator sets. Similarly, Warp Tokens’ ISMs (Interchain Security Modules) include a multisig ISM run by the Hyperlane community, along with options like Aggregated ISM, allowing teams to combine security from multiple ISMs.
Moreover, many verification schemes may not yet be widely adopted or thoroughly battle-tested. Thus, teams should carefully assess the quality of available schemes and choose those matching their desired security level. We strongly recommend leveraging existing options to build secure and reliable token verification systems. In future research articles, we will dive deeper into the security properties of different verification schemes offered by each token framework.
4. Default Verification Scheme
Indicates whether the framework provides a default verification mechanism. This is important because most teams typically opt for defaults due to ease of use. If token issuers decide to use the default option, evaluating its security and considering the use of customizable features to enhance security becomes critical.
5. Application Participation in Verification
Highlights whether teams can participate in the verification process, adding an extra security layer or taking control of their own security. This is significant because it enables teams to strengthen security by combining their own verification systems with existing mechanisms. This way, they can rely on their safeguards to mitigate risks if other verification methods fail.
For example, teams like Stargate, Tapioca, BitGo, Cluster, and Abracadabra run their own DVNs on LayerZero, demonstrating how others can leverage available customization features. Although it requires extra effort, more teams should take advantage of this additional security layer. When effectively implemented, this feature can prevent major issues during critical failures.
6. Censorship Resistance
Defines whether and how messages could be censored, potentially disabling applications and disrupting team operations. In most cases, even if an application is censored, it can still switch to a different verification mechanism or relayer within the same framework. However, this requires additional effort and may not be practical for short-term issues.
7. Open Source
Open-source codebases allow developers to audit the framework’s security features and overall setup, ensuring transparency in execution. This transparency is crucial for guaranteeing software security and reliability.
Fee Comparison
This table compares the fee structures of several token frameworks, focusing on how each handles protocol operations, message passing, and other additional fees. Notably, all frameworks allow custom application-level fees to be added. Additionally, verification and transfer processes involve fees across all frameworks, including payments to relayers, transceivers, or similar entities.
Currently, most fees relate to message verification and relaying. As mentioned earlier, all token frameworks offer multiple mechanisms for message verification. While each additional verification scheme enhances system security, it also increases user fees and costs.
Fees Associated with Token Frameworks
-
Protocol-Level Fees
This refers to fees charged by each framework when executing transfers or other operations.
Due to a DAO-managed fee switch, token issuers might 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 dependency on DAO governance, as any changes to the fee switch directly impact tokens issued through these frameworks, making them subject to DAO decisions.
Smart Contracts
This table highlights key attributes of each framework’s smart contracts, emphasizing differences in flexibility, security, and customizability, particularly regarding deployment history, security audits, offered bounties, and notable customization options for finer control.
Notably, all frameworks allow applications to set rate limits and blacklists—critical security features that, when used effectively, can help prevent major financial losses. Additionally, each framework offers flexibility in deploying smart contracts as either immutable or upgradeable, based on the application’s specific needs.
Token Framework Smart Contracts
-
Deployment Time
This field shows when each framework’s smart contracts were deployed, reflecting the operational duration of the framework.
-
Audits
The number of audits is a key indicator of security. Audits ensure the integrity of framework smart contracts, identifying vulnerabilities and issues that could affect the system.
-
Bounties
Bounties are financial incentives offered by the framework to encourage external security researchers to discover and report vulnerabilities.
-
Notable Features for Fine-Grained Control
Smart contract frameworks allow applications to implement various customizable security features based on specific needs. This field highlights key security characteristics provided by some frameworks to ensure system safety.
Adoption and Outreach
Each framework has unique characteristics, and developer, protocol, and platform engagement varies based on technical focus, integration methods, and security assurances.
-
Core Contributors
This section emphasizes active participation by various teams in building and maintaining each framework. Beyond the original development team, participant diversity is a positive indicator of multiple factors: (1) broader demand for the framework, and (2) its accessibility and ease of use, whether permissionless or through general collaboration.
-
Adoption
Adoption reflects the usage level and appeal of each framework, measured by the number of deployed tokens and total value locked (TVL). It offers insights into widespread acceptance among developers and protocols, as well as reliability in securing assets.
-
Prominent Teams
This section highlights top-tier teams and protocols adopting each framework, reflecting industry trust and overall attractiveness.
-
VM Coverage
VM coverage refers to the range of virtual machines supported by each framework. Supporting more VMs provides greater flexibility and compatibility across different blockchain environments. This gives applications and token issuers more choices, enabling access to diverse communities.
-
Number of Deployed Chains
This field reflects the number of chains each framework is deployed on—that is, how many chains an application or token issuer could support by choosing a specific framework. This directly correlates with the number of markets and DeFi ecosystems an application can access. Higher chain deployment means broader liquidity access.
Additionally, while permissionlessly expanding frameworks to new chains holds great potential, it may pose challenges if developers must build and maintain critical infrastructure themselves. For some teams—such as those aiming to establish bridge support for a new chain—this effort may be worthwhile. But for token issuers simply looking to expand their token’s reach to another chain, this could seem overly complex and resource-intensive.
-
Unique Differentiators
Each framework brings unique differentiating features, often in the form of special functions, tools, or integrations, setting it apart from others. These distinctive features typically attract developers and protocols seeking specific capabilities, ease of use, or greater token distribution.
Developer Experience
Disclaimer: This section reflects insights gathered from @SlavaOnChain (Head of Developer Relations at LI.FI) and discussions with developers familiar with various frameworks. Developer experience may vary based on background and use case.
Developer Experience with Token Frameworks
-
Integration Simplicity
Refers to how easy it is to deploy a token using the framework for the first time without team support.
-
Documentation
Evaluates the effectiveness of the framework’s guides, examples, and reference materials in helping developers understand and use the platform.
-
Developer Tools
Considers a suite of tools—including libraries, SDKs, and utilities—that make building, testing, and deploying tokens with the framework easier.
Key Takeaways
A. Trends in Interoperability
-
Customizability and Verification Mechanisms – All frameworks offer customizable verification mechanisms, marking a new trend in interoperability protocols. The discussion around wstETH on Lido DAO’s governance forum was a pivotal moment, highlighting the demand for this feature.
-
Security Practices – 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 positive progress in interoperability security.
-
Adoption Challenges Beyond Defaults – While custom verification mechanisms are beneficial, adoption beyond default settings remains low, necessitating better education on security options. Ensuring high security in default verification schemes is crucial, as they are the most commonly used.
-
Verification Mechanisms – Axelar’s validator set and Wormhole’s Guardian Network are widely adopted verification mechanisms now offered across multiple frameworks.
B. Leading Token Frameworks
-
LayerZero’s OFT – Leads in number of token deployments and secured value, thanks to early market entry, broad support across most chains, and comprehensive developer resources.
-
Hyperlane’s Warp Token – The team focuses heavily on making the framework and developer tools more permissionless-friendly. This is evident in multiple VM implementations built and maintained by external teams, showcasing ease of use 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 no protocol-level fee switch. A popular choice for teams looking to extend tokens to Solana or bring Solana tokens into the EVM ecosystem.
-
Axelar’s ITS – With over $400 million TVL, Axelar ranks among the top 25 PoS chains. The ITS framework is a key growth driver, boosting both TVL and message volume sent through the Axelar network.
-
xERC20 Framework – The only framework fully independent of bridges, unlike other more product-like frameworks. Many interoperability protocols without their own frameworks encourage teams to use xERC20 for token issuance, and some even provide pre-built templates for integration.
-
Differences in Fee Structures – xERC20 and NTT are the two frameworks without protocol-level fee switches.
Conclusion
Token frameworks are on the rise and could transform how value moves across the multi-chain world. Currently, transferring assets cross-chain typically requires liquidity pools or solvers (solvers). But token frameworks eliminate the need for liquidity pools or solvers. Instead, assets can be directly minted on the destination chain via interoperability protocols.
In fact, token frameworks might signal the end of wrapped assets. Liquidity no longer needs to be fragmented across chains. You can mint fungible assets on any chain, trade them across chains, and only pay gas fees. We’re already seeing signs of this trend. Circle launched CCTP to bypass wrapped USDC issues, and many major teams and high-value tokens are now adopting token frameworks—indicating accelerating momentum.
However, legitimate concerns exist about third-party ripple effects—if an interoperability protocol fails, it could impact all projects built on it. Despite these risks, adoption of token frameworks continues to grow.
Another perspective: in a future with chain abstraction, token frameworks may become irrelevant, as solvers will handle native token swaps behind the scenes for users. While there’s merit to this—users won’t need to think about tokens—it overlooks a key factor: What about the solvers themselves? For solvers, token frameworks could be highly valuable. They solve the asset inventory and rebalancing challenge, as they don’t require liquidity to move across chains. That’s why frameworks like CCTP are favored by solvers moving USDC—it’s cheap, efficient, and ideal for cross-chain rebalancing.
How this will unfold remains uncertain. Perhaps we’ll only need token frameworks on a few edge chains, or they may become the standard for token deployment in crypto. What we know today is that adoption of interoperability frameworks is growing, and competition is intensifying. And here lies the problem with this growth: fragmentation. Competing frameworks will scatter assets and liquidity, and we won’t see a one-size-fits-all solution. That’s unsustainable under current incentive models.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@lifiprotocol
