Skip to main content

CAT20

CAT20 standard is a part of the Covenant Attested Token (CAT) protocol which supports fungible tokens. As you all know, CAT is a UTXO-based token protocol that is validated by miners directly and uses smart contracts, specifically covenants, to manage token mints and transfers. It is solely enforced by Bitcoin Script at Layer 1 and has several benefits compared with all the existing token protocols on Bitcoin.

Deploy​

Feature API​

To deploy a new CAT20 token, you can easily call the corresponding feature in the SDK.

Design​

To deploy a token, we employ a commit and reveal scheme utilizing Taproot (P2TR). We call the first transaction the token genesis transaction, and the second the reveal transaction. In the witness script of an input of the reveal transaction, we include a CAT envelope to embed token meta information.

Dive into details​

For genesis transaction, the commit output is a Taproot output carrying extra CAT-enveloped token metadata. You may notice the envelope OP_0 OP_IF ... OP_ENDIF when building the commit locking script.

When spending this commit output in the next reveal transaction, we not only pass the user signature in the witness but also add 5 output state hashes at the beginning. The signature is used for key verification, and these 5 state hashes are intended to reveal the state hashes of each output in this transaction. As you may noticed, the commit output is unlocked with the script spend method, commitLockingScript including token raw metadata is revealed in witness, but actually, it only verifies the user's signature.

The following witness data is an example of unlocking commit output in a reveal transaction.

Mint​

Feature API​

To mint CAT20 tokens, you can easily call the corresponding feature in the SDK.

Design​

Any rules governing the minting process of a token are enforced in its minter smart contract using covenants. New tokens can be minted by spending a minter UTXO first generated in the token reveal transaction. It can generate new minter UTXOs, which in turn can be spent to mint more tokens recursively. The minter UTXOs are consumed and generated again and again along with the mint processing, and new tokens can only be issued by spending minter UTXOs.

Dive into details​

Let's take OpenMinterV2 as an example to dive into the smart contract details.

Creating a minter output requires passing the token metadata as well as genesisOutpoint which is the commit outpoint in the genesis transaction.

For the minter states, it consists of three parts.

  1. The locking script of the token Taproot output.

  1. A flag to indicate if it needs to premine tokens. If isPremined equals false and premine flag in token metadata is true, then premine tokens, otherwise, skip the premine process. isPremined is true when the first minter UTXO that was created in the reveal transaction, and set to true after this first minter UTXO is spent.

  1. remainingSupplyCount indicates the token remaining supply amout in this minter UTXO.

Spend a minter UTXO is more clear to understand.

  1. Do routines check, including context validation, pre-states validation, and back-to-genesis validation.

  1. Handle the premine process, as well as calculate the next states of minter UTXO after this time of token mint.

  1. Split out new minter UTXOs, build new token UTXO, then confine the transaction outputs.

Send​

Feature API​

To send CAT20 tokens, you can easily call the corresponding feature in the SDK.

In SDK, we also provide an API to make token airdrop easier. This feature will automatically handle the repeated work for you when sending tokens to multiple receivers.

Design​

A fungible token (FT) UTXO can be split into small amounts. Multiple token UTXOs can be merged into a single UTXO, if only they descend from the same genesis transaction. In general, there can be multiple token inputs and token outputs in a token transfer transaction, and they can appear anywhere in the transaction.

The preservation of token balance is enforced by miners: the quantity of tokens in the inputs must equal that in the outputs. There is a guard input /xferGuard in the transfer transaction. Transfer Guard is a contract, it can only be unlocked when the token amount doesn't change between the transaction inputs and outputs. Note that guard contracts can vary in different situations, and you may design your guard contract as well to implement different token amount limitations. This is the reason why we separate token amount check logic into a dependent contract rather than hard code it directly in the token protocol.

Dive into details​

Create token outputs require two parameters.

  1. The Minter locking script, contains the unique genesis outpoint which will be used when doing the back-to-genesis validation.
  2. The Guard locking script, used for checking token amounts.

There are two ways to unlock the CAT20 token contract.

  1. User spend: The token is controlled and owned by a user, it can be unlocked when the owner provides the correct signature. The user transfer token belongs to this kind of unlock.
  2. Contract spend: The token is controlled and owned by a smart contract, it can be unlocked when the transaction has one input of this kind of contract. We will introduce this unlock method in CAT20 buy and sell contracts.

Burn​

Feature API​

To burn CAT20 tokens, you can easily call the corresponding feature in the SDK.

Design​

Tokens can be burned and their lineage from the genesis is terminated. The satoshis stored in their UTXOs are melted to a regular non-covenant address, effectively “uncolored”.

Compared to user transfer tokens, burn token has no big difference, it seems like another kind of transfer, except using a /burnGuard instead of /xferGuard which requires no token outputs in the transaction.