CW20 Tokens & Their Limitations

本页介绍 CW20 的基础知识，以及与 tokenfactory 和“原生” Cosmos 资产（也称为 Bank Module 资产）相比，使用 CW20 代币执行跨链操作时存在的限制。

​

API 请求中的 CW20 代币 Denom 格式

要在 Skip Go API 中使用 CW20 代币，请将 denom 指定为 "cw20:" + 代币合约地址。 Terra2 上 Astro 的 denom 示例：cw20:terra1nsuqsk6kh58ulczatwev87ttq2z6r3pusulg9r24mfj2fvtzd4uq3exn26

​

背景

​

什么是 CW20 代币？

CW20 是 CosmWasm（即 CW）虚拟机中的同质化代币规范。CosmWasm 是目前 CosmosSDK 区块链中最流行的智能合约虚拟机。从高层看，CW20 与 ERC20（流行的 EVM 同质化代币标准）非常相似。 符合该标准的合约会实现以下功能：

• 将代币从一个账户转移到另一个账户
• 将代币连同一条消息一起发送到某个合约（类似于 callContractWithToken）
• 跟踪余额
• 将余额支出权限委托给其他账户和合约

ASTRO（Astroport 的治理代币）就是 Terra2 上发行的一种 CW20 代币。

​

CW20 代币如何与 IBC 交互？

CW20-ICS20 转换器合约会让 CW20 代币兼容 ICS20 代币转移标准，因此它们可以通过普通的 ICS20 转账通道发送到其他链。当它们到达目标链后，就与 bank module 代币和 tokenfactory 代币没有区别。 这些转换器合约正是使用 CW20 执行跨链操作时诸多困难的来源：

• 不同的转换器合约实现了不同版本的 ICS20 标准（例如有些不支持 memo，而 post-transfer 合约调用和多跳转账都需要 memo）
• 转账失败时，转换器合约只会将资产退回给发送方。这意味着，如果我们的某个合约代表你发送代币但未成功，它将收到这些代币。我们无法以原子方式将其再发送给你。

​

CW20 代币与“原生”代币（即 bank module 代币）相比如何？

“原生”代币是指其铸造、销毁、余额和转账功能由 bank module 管理，而不是由合约管理的代币。与 CW20 不同，原生代币可直接兼容 ICS20 和 IBC 模块。用户只需使用一条 MsgTransfer 即可通过 transfer channel 将原生代币发送到另一条链，无需转换器合约或类似机制。 原生代币的缺点在于它们是有权限控制的，并且深度嵌入链的状态机。因此，发行新的原生代币需要链升级。相比之下，发行一个 CW20 只需要部署一个新合约（也就是一笔交易）。

​

CW20 代币与“tokenfactory”代币相比如何？

Tokenfactory 代币通过 tokenfactory 模块创建。它们旨在兼具 CW20 和原生代币两者的优势：

• 像 CW20 一样，它们是无许可的，用户只需提交交易即可创建新代币，无需修改链的状态机
• 像原生代币一样，它们开箱即用地直接兼容 IBC，并且由 bank module 管理其余额和转账功能。

这种特性的组合使得许多人认为，相比 CW20，tokenfactory 是一种严格意义上的改进，开发者在绝大多数场景下都应优先选择它。我们非常认同这一结论。 与 CW20s 不同，tokenfactory 代币在 Skip Go API 可提供的跨链功能方面没有这些限制。

​

CW20 代币在 Skip Go API 中有哪些限制？

从高层来看，几乎所有多链操作中，只要某个阶段涉及该代币位于其发行链上，就都需要多笔交易。 具体来说，这意味着你无法在 1 笔交易中完成以下操作：

• 购买 cw20 资产后再进行 IBC 转账

• 购买 cw20 资产后，在远端链上调用合约（例如，因为这在底层需要一次 IBC 转账）

• 从远端链通过 IBC 转账回到 CW20 的源链，然后在该链上执行兑换或任何其他路由后操作

原则上，你可以使用 Skip Go API 通过多笔交易来构建上述任意一类操作序列，但这对你和你的终端用户来说都会更具挑战性。

---

This page covers the basics of CW20s and the limitations around performing cross-chain actions with CW20 tokens — compared to tokenfactory and “native” Cosmos assets (aka Bank Module assets).

​

CW20 Token Denom Formatting In API Requests

To use CW20 tokens in the Skip Go API, specify the denom as “cw20:” + the token contract address. Example denom for Astro on Terra2: cw20:terra1nsuqsk6kh58ulczatwev87ttq2z6r3pusulg9r24mfj2fvtzd4uq3exn26

​

Background

​

What is a CW20 token?

CW20 is the fungible token spec for the CosmWasm (i.e. CW) VM. CosmWasm is the most popular smart contract VM among CosmosSDK blockchains today. At a high-level, CW20 is very similar to ERC20 (the popular EVM fungible token standard). Contracts that comply with the standard implement the following functionalities:

• Transferring tokens from one account to another
• Sending tokens to a contract along with a message (similar to callContractWithToken)
• Tracking balances
• Delegating balance spending to other accounts and contracts

ASTRO (Astroport’s governance token) is one CW20 token issued on Terra2.

​

How do CW20 tokens interact with IBC?

CW20-ICS20 converter contracts make a CW20 token compatible with the ICS20 token transfer standard, so they can be sent to other chains over normal ICS20 transfer channels. When they arrive on the destination chain, they’re indistinguishable from bank module and tokenfactory tokens. These converter contracts are the source of much difficulty when attempting to perform cross-chain actions with CW20s:

• Different converter contracts implement different versions of the ICS20 standard (e.g. Some don’t support memos, which are required for post-transfer contract calls and multi-hop transfers)
• On transfer failure, converter contracts just return assets to sender. That means if one of our contracts attempts to send tokens on your behalf unsuccessfully, it will receive the tokens. We can’t atomically send them to you.

​

How do CW20 tokens compare to “native” (aka bank module) tokens?

“Native” tokens are tokens where minting, burning, balances, and transfer functionality are managed by the bank module, instead of by contracts. Unlike CW20s, native tokens are directly compatible with ICS20 and IBC modules. One can send a native token to another chain over a transfer channel just using a MsgTransfer — no conversion contracts or anything of the sort required. The downside of native tokens is that they’re permissioned and deeply ingrained into the chain’s state machine. As a result, issuing a new native token requires a chain upgrade. Issuing a CW20 on the other hand, only requires deploying a new contract (just a transaction).

​

How do CW20 tokens compare to “tokenfactory” tokens?

Tokenfactory tokens are created with the tokenfactory module. They’re designed to have the best of both worlds of CW20 and native tokens:

• Like CW20s, they’re permissionless and users can create new ones just by submitting transactions — no need to modify the chain’s state machine
• Like native tokens, they’re directly compatible with IBC out-of-the-box, and the bank module manages their balances + transferring functionality.

This combination of traits leads many to see tokenfactory as a strict improvement on CW20 that devs should prefer in the vast majority of cases. We strongly agree with this conclusion. Unlike CW20s , tokenfactory tokens have no limitations in the cross-chain functionality Skip Go API can offer for them.

​

What limitations do CW20 tokens have within the Skip Go API?

At a high-level, basically any multi-chain action—in which the token is on the chain where it was issued for one stage of the action—requires multiple transactions. In particular, this means you cannot perform the following actions in 1 transaction:

• IBC transfer after purchasing a cw20 asset

• Call a contract on a remote chain after purchasing a cw20 asset (e.g. since this requires an IBC transfer under the hood)

• IBC transfer from a remote chain to the CW20’s origin chain then perform a swap or any other post-route action on that chain

In principle, you can use the Skip Go API to construct any of these action sequences across multiple transactions, but it will be more challenging for you and your end users.