Analisis mendalam: Penerbitan koin lintas rantai mana yang terbaik?

Original article by: Arjun Chand

Terjemahan asli: 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.

perkenalan

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, its 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 Token)

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 will be 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 pasar:

• Likuiditas – A unified market attracts more traders and increases liquidity.

• Brand recognition – The token is available in various DeFi ecosystems, increasing demand and brand recognition.

• Kesederhanaan – Token management becomes simpler and reduces complexity.

• Redundancy – If one chain fails, the token can still be operated on other chains, providing a safety net.

• Pasar expansion – Tokens can be deployed on multiple chains more quickly, facilitating adoption. Additionally, interconnected ecosystems mean 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 major problems:

• Non-fragmented 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 fees are primarily gas charges.

• 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 minting 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.

Keamanan

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 at the heart 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 that is 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 one that matches their required level of security. 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 protections 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 with DAO governance, as any changes to the fee switch will directly affect tokens issued through these frameworks, making them subject to DAO decisions.

Smart Contracts

This table presents the key properties of smart contracts for each framework, highlighting their differences in flexibility, security, and customizability, with a particular focus on deployment history, security audits, offered rewards, and notable customization options for more granular 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.

• Distinctive 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 by @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.

• dokumen

Evaluate the effectiveness of the frameworks 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.

Poin Penting

A. Trends in interoperability

• Customizability and Validation Mechanisms – All frameworks offer customizable validation mechanisms, which marks 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 entry advantage, broad support for most chains, and comprehensive developer resources.

• Warp Token by Hyperlane – The team is very focused on making the framework and developer tools more friendly to permissionless operations. This is reflected in multiple virtual machine implementations built and maintained by external teams, showing the convenience of using the framework in a permissionless way.

• Wormhole’s NTT – has quickly gained widespread adoption, has a high-value token deployed on various 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.

Meringkaskan

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 will no longer matter because solvers will swap native tokens for users behind the scenes. While this makes some sense – users wont 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 dont require liquidity to be transferred between chains. This is why frameworks like CCTP are favored by solvers when moving USDC – its cheap, efficient, and perfect 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.

Tautan asli

This article is sourced from the internet: In-depth analysis: Which cross-chain coin issuance is the best?

Related: XEX Market Observation Report: A review of recent major events in the cryptocurrency space

French President Emmanuel Macron denied rumors that the arrest of Telegram founder Pavel Durov was politically motivated, while cryptocurrency inflows rose for five consecutive weeks amid rumors of a September rate cut in the U.S. Meanwhile, Polygon, Avalanche, and ZKsync were all hit by Discord scam attacks within 48 hours. Macron says Durovs arrest is not politically motivated President Macron confirmed Durov’s arrest in a post on the X social media platform on August 26. In his post, Macron responded to false information circulating on social media claiming that Durovs arrest was politically motivated. Macron said it was in no way a political decision. On August 24, Durov was arrested at an airport outside Paris, sparking rumors of possible charges against him and law enforcement action against Telegram. On August…