Introduction

Issuing a token used to be simple: you’d deploy it on Ethereum, where all the action was — users, traders, capital, and liquidity. Today, the landscape is much more complex. Liquidity is scattered across Bitcoin, Ethereum, L2s, Solana, and other chains. So, where should you issue your token? There’s no clear answer.

But what if you didn’t have to choose just one chain? Imagine a token that works everywhere, flowing seamlessly across the entire crypto economy.

Thanks to interoperability protocols (aka bridges), it’s now possible to issue tokens with a unified market that spans multiple chains. This creates global liquidity without borders, simplifying operations for token issuers: more liquidity, greater adoption, and stronger network effects — without the headaches of fragmentation. Essentially, it’s like having a global bank account that works everywhere, integrated across all DeFi ecosystems.

In this article, we’ll compare the leading token frameworks offered by different interoperability protocols. The goal is to assess their unique features, strengths, and trade-offs to help teams choose the best solution for issuing natively multi-chain tokens.

We’ll explore 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
• xERC20 (EIP 7281: Sovereign Bridged Tokens)

Let’s dive in.

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 the start.

Burn-and-Mint: For Natively Multi-Chain Tokens

When a token is natively issued on multiple chains from Day 1, its supply is distributed across those chains. When tokens are moved 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 interop teams have explained). Here’s an example: consider Token X with a total supply of 1000 tokens, distributed based on demand across five chains:

• 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 would 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 stays at 1000 tokens, facilitating seamless transfers between chains without slippage.

Lock-and-Mint: For Existing Tokens

For already existing tokens that were initially deployed on a single chain, the process is slightly different. The entire supply exists on one chain, and when transferring 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 is similar to how wrapped tokens operate. Tokens locked on Chain A can then have a wrapped version minted on Chain B. However, now these tokens can also move from Chain B to Chain C using the burn-mint method, without needing to be locked on multiple chains. The original supply remains on Chain A, ensuring that transfers between chains simply involve verifying that the tokens burned match those minted.

Why Token Frameworks Matter

Here’s why having a token that is tradable across a unified market spanning multiple chains benefits teams:

• Liquidity — A single market 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 others, providing a safety net.
• Market expansion — The token can be deployed across chains more quickly, boosting adoption. Moreover, interconnected ecosystems means more room for experimentation across DeFi.
• Network effects — Collaboration with other projects increases adoption and value.

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

• No fragmented liquidity — Before, you had different versions of USDC on each chain, leading to inefficiency. Now, USDC is the same across all chains.
• Market expansion — Deploying USDC across multiple chains gives them access to more users and markets.
• Capital efficiency — Users can bridge large amounts of USDC without needing liquidity pools or wrapping.
• Minimal fees — Transfers cost little beyond gas fees.
• No slippage — Transfers are direct and eliminate the risk of slippage.

Circle’s unique feature set for USDC is because of their custom-built bridge, CCTP, a luxury 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 offers for USDC, but for any token. By issuing a token through these frameworks, projects can create a unified market across multiple supported chains, allowing for easy 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 their tokens.

Security

Here’s an explanation of the critical security aspects covered in the table:

1.Verification Mechanism

The verification mechanism is at the core of how transfers are validated across chains. It refers to how messages are verified and the type of setup in terms of verification mechanisms each framework provides — whether it’s a single option, modular system with multiple options, or a flexible design compatible with any bridge — allowing token issuers to select the most appropriate solution based on their security requirements.

Although custom verification mechanisms offer benefits, it’s the default configurations that remain most widely used. Therefore, focusing on the security of default verification schemes is important. It’s recommended that teams use additional verification schemes on top of defaults to enhance their security setup.

When it comes to liveness, relying on multiple verification schemes has both benefits and drawbacks. On the plus side, there’s improved fault tolerance: if one provider experiences downtime, others can ensure continued operations, enhancing system reliability. However, this also increases system complexity. Each additional scheme introduces a potential point of failure, raising the risk of operational disruptions.

2.Flexibility on Verification

Highlights the flexibility of each framework in customizing its verification mechanism — specifically, whether token issuers can choose from various options or are limited to default settings.

3.Notable Pre-Built Verification Schemes

Pre-built schemes are ready-to-use verification mechanisms that token issuers can use for message verification, simplifying deployment. A framework with a wider selection of reliable, pre-built options is generally a positive sign.

While some frameworks offer more verification schemes than others, it’s essential to evaluate them based on their security spectrum, which can range from a single validator to comprehensive validator sets.

For instance, OFTs offer DVN options that are single validators alongside more robust choices like CCIP or Axelar, which use full validator sets. Similarly, Warp Token offers ISMs like the Multisig ISM which includes validators run by the Hyperlane community and at the same time, there are options like the Aggregation ISM which allows teams to combine security from multiple ISMs.

Additionally, many of these verification schemes may not yet be widely adopted or thoroughly tested in real-world scenarios. Thus, teams should carefully assess the quality of available verification schemes and choose the one that aligns with their desired security level. We strongly recommend leveraging the available options to build a secure and resilient setup for token verification. In a future research article, 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 default options due to convenience. If a token issuer is going to opt for the default option, it’s crucial to assess its security as well as consider using the customizability features on offer to enhance the security of the setup.

5.App Participation in Verification

Highlights whether teams have the option to participate in the verification process, adding an extra layer of security or allow them to take control of their security. This is important because it allows teams to enhance security by incorporating their own verification setup alongside existing mechanisms. This way, if other verification methods fail, they can rely on their own safeguards to prevent potential issues.

For example, teams like Stargate, Tapioca, BitGo, Cluster, and Abracadabra run their own DVNs on LayerZero, showcasing how other teams can leverage the available customizations.

More teams should take advantage of this additional security layer, despite the extra effort required. When implemented effectively, this feature can be crucial in preventing major issues during critical failures.

6.Censorship Resistance

Defines whether and how messages can be censored, potentially disabling applications and causing liveness issues for teams. In most cases, even if apps are censored, they can switch to different verification mechanisms or relayers within the same framework. However, this requires additional effort and may not be a practical solution for short-term issues.

7.Open-Sourceness

Open-source codebases enable developers to audit a framework’s security features and overall setup, ensuring transparency about the code being executed.

Fees

This table compares the fee structures of several token frameworks, focusing on how each handles costs for protocol operations, messaging, and any additional fees. It’s important to note that all frameworks allow for custom, app-specific fees to be added at the application level. Moreover, there’s a cost associated with the verification and transfer process, including the fees paid to relayers, transceivers, or similar entities, in all frameworks.

Currently, most fees are associated with message verification and relaying. As mentioned earlier, all token frameworks provide the option to use multiple mechanisms for verifying messages. While each additional verification scheme enhances the system’s security, it also increases fees and costs for users.

1.Protocol Fees

This refers to the protocol-level fees each framework charges for executing transfers or other operations.

The presence of a DAO-governed fee switch means that token issuers may need to pay additional fees to the interoperability protocols behind the token frameworks (e.g., LayerZero for OFTs or Hyperlane for Warp Token). This introduces a dependency on DAO governance, as any changes to the fee switch directly affect the tokens issued through those frameworks, making them subject to DAO decisions on fee structures.

Smart Contracts

This table highlights key properties of the smart contracts of each framework, highlighting their varying degrees of flexibility, security, and customization with a focus on deployment history, security audits, bounties offered, and notable customizations for granular control.

It’s important to note that all frameworks allow apps to set rate limits and blacklists, crucial security features that, when used effectively, can prevent significant financial losses. Additionally, each framework offers the flexibility to deploy smart contracts as either immutable or upgradeable, depending on the app’s specific needs.

1.Deployed Since

This field shows when each framework’s smart contracts were deployed. It gives insight into how long the framework has been operational.

2.Audits

The number of audits is a crucial measure of security. Audits validate the integrity of a framework’s smart contracts, identifying vulnerabilities or issues that could compromise the system.

3.Bounties

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

4.Notable Feature for Granular Control

Smart contract frameworks allow applications to implement a variety of customizable security features, depending on their specific needs. This field highlights a few key security features that each framework offers to ensure security.

Adoption & Expansion

Each framework brings unique features and has seen varying levels of engagement from developers, protocols, and platforms, depending on their technical focus, integrations, and security guarantees.

1.Core Contributors

This section highlights the various teams 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 framework’s accessibility and ease of use, whether permissionlessly or through general collaboration.

2.Adoption

Adoption reflects the level of usage and traction of each framework, measured by the number of tokens deployed and the total value secured. It provides insight into how widely the framework has been embraced by developers and protocols, as well as its reliability in securing assets.

3.Notable Teams

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

4.VM Coverage

VM coverage refers to the range of virtual machines supported by each framework. A greater number of VMs provides more flexibility and compatibility across different blockchain environments. This gives apps and token issuers more variety in terms of diverse communities they can tap into.

5.Chains Deployed On

This field reflects the number of chains each framework is deployed on, i.e., the number of chains each app or token issuer could support if they decide to use a particular framework. This is directly related to the number of markets and DeFi ecosystems apps can tap into. Higher chain deployment means broader access to liquidity.

Additionally, while the ability to permissionlessly expand a framework across different chains holds great potential, it can also be challenging if developers are required to build and maintain critical infrastructure themselves. For some, like teams seeking to establish bridge support for a new chain, this effort may be worthwhile. But for token issuers simply looking to add another chain to their token’s reach, it can feel unnecessarily complex and resource-intensive.

6.Unique Differentiators

Each framework brings unique differentiators, often in the form of special features, tooling, or integrations that set it apart from others. These differentiators typically appeal to developers and protocols looking for specific functionalities or ease of use or simply more distribution for their token.

Developer Experience

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

1.Ease of Integration

Refers to how straightforward it was to deploy tokens using the framework based on first-time experience without team support.

2.Documentation

Evaluates how well the framework’s guides, examples, and references support developers in understanding and using the platform.

3.Developer Tools

Considers the set of libraries, SDKs, and utilities that make it easier to build, test, and deploy tokens using the framework.

Key Takeaways

A. Trends in Interop

1. Customizability and verification mechanisms — All frameworks offer customizability in verification mechanisms, marking a new trend across interop protocols. The discussion on Lido DAO’s governance forum regarding wstETH was a pivotal moment that highlighted the demand for this feature.
2. Security Practices — Features like rate limits, allowlists/blacklists, and enabling token issuers to participate in message verification and security setup through custom policies and roles have become standard practices across frameworks, indicating a positive direction for security in the interop space.
3. Challenges in adoption beyond defaults — While custom verification mechanisms are beneficial, adoption beyond default settings remains low, necessitating better education on security options. A focus on ensuring the default verification schemes are highly secure is critical since they are the most commonly used.
4. Verification mechanisms — Axelar’s validator set and Wormhole’s Guardian network are widely adopted verification mechanisms, offered across frameworks.

B. Leading Token Frameworks

1. OFT by LayerZero — leads in adoption, both for tokens deployed and total value secured. They were first to roll out token frameworks with OFT (V1) in 2022, and and they’ve continued to strengthen their position, with major assets like WBTC recently adopting the OFT framework. They also offer extensive support for most chains and comprehensive developer resources.
2. Warp Token by Hyperlane — The team is strongly focused on making the framework and developer tools user-friendly for permissionless operations. This is demonstrated by the multiple VM implementations built and maintained by external teams, showcasing the ease of working with the framework in a permissionless manner.
3. NTT by Wormhole — Has rapidly gained adoption with high-value tokens deployed across chains and offers several unique properties in its design such as no protocol-level fee switch. It’s a popular option for teams looking to expand their tokens to Solana or Solana tokens to the EVM ecosystem.
4. ITS by Axelar — With a TVL exceeding $400M, Axelar ranks among the top 25 PoS chains. ITS framework is a key growth driver, contributing to both the TVL and the volume of messages sent via the Axelar network.
5. xERC20 Framework — The only fully bridge-agnostic framework, unlike others that are more like products. Many interop protocols that don’t have their own frameworks encourage teams to use xERC20 to deploy tokens, with some offering pre-built templates for integration.
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 might end up changing everything about how value moves in a multi-chain world. Currently, transferring 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 could be the death knell for wrapped assets. Liquidity wouldn’t need to be fragmented across chains anymore. You could mint fungible assets on any chain, and they’d be tradable across chains for just the cost of gas. We’re already seeing signs of this shift. Circle launched CCTP to bypass the wrapped token problem for USDC and many big teams and high value tokens are now adopting token frameworks. That’s a sign things are accelerating.

However, there are valid concerns regarding third-party contagion risk — if interoperability protocols fail, they could impact all projects built on them. Despite these risks, adoption continues to grow.

Another point of view: in a chain-abstracted future, token frameworks won’t matter anymore because solvers will swap native tokens for users behind the scenes. And while there’s some truth to that — users won’t need to think about tokens — it misses a critical angle. What about the solvers themselves? For them, token frameworks could be really useful. They solve inventory and rebalancing headaches because they don’t require liquidity to move across chains. That’s why solvers like using frameworks like CCTP to move USDC — it’s cheap, efficient, and perfect for cross-chain rebalancing.

How this all shapes up is still anyone’s guess. Maybe we’ll only need token frameworks for a small group of fringe chains or maybe they will become the standard for deploying tokens in crypto. What we do know today is that adoption of interop frameworks is growing, and so is the competition. The problem with this growth? Fragmentation. Competing frameworks are going to split up assets and liquidity, and we won’t see a one-size-fits-all solution. Incentives just won’t allow it.

Disclaimer：

1. This article is reprinted from [LI.FI]. All copyrights belong to the original author [Arjun Chand]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. Translations of the article into other languages are done by the Gate Learn team. Unless mentioned, copying, distributing, or plagiarizing the translated articles is prohibited.