CAT20 Specification

1. Deploy

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. The byte sequence cat (0x636174 in hex) signifies that this envelope is part of the CAT Protocol.

OP_FALSE
OP_IF
  OP_PUSH "cat"
  OP_PUSH 1	    // fungible token
  OP_PUSH <JSON>    // CBOR encoded
OP_ENDIF

The JSON file must contain the following fields:

{ 
  "name": "cat",
  "symbol": "CAT",
  "decimals": "2",
}

JSON is CBOR encoded. If it is longer than pushdata limit of 520 bytes, it is split into multiple chunks and is concatenated before decoding. More fields can be added for customized metadata.

The reveal transaction must follow the following rules to be valid:

• There is one and only one envelope in its inputs
• The first output is an OP_RETURN encoding state in recursive covenants
• There are one or more minter outputs of the same script after the first output, nothing else. Note that a change output is forbidden¹. After deployment, the token is uniquely identified by the commit output in the genesis transaction. tokenId consists of the genesis transaction txid and output index with the following formatting: txid_vout.

note

Token names/symbols are not unique and anyone can deploy a token with the same name/symbol with a previously deployed token, as in ERC20.

2. Mint

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 in the token reveal transaction. It can generate new minter UTXOs, which in turn can be spent to mint more tokens recursively. New tokens can only be issued by spending minter UTXOs. A mint transaction must follow the following rules to be valid:

• There is exactly one minter input
• There is exactly one token output
• The token output must be right after a minter output, if any. Note there can be zero and multiple minter outputs.

Compared to indexer-enforced token minting, minting CAT20 tokens can be flexibly customized by programming its minter contract, as long as it follows the rules above. The token issuer can define arbitrary minting rules without any change to the underlying protocol, unlike indexer-based protocols. Some use cases include:

• only mintable if certain amount of bitcoins are paid to a given address
• only mintable starting from a given time or block height
• only mintable if proof of work is demontrated, as in mining Bitcoin but with lower difficulty
• only mintable by holders of a certain different token
• only mintable if some bitcoins are time-locked: the more coins, the longer time locked, the more tokens can be minted

Open and closed mint

An open mint (also called permissionless mint) refers to a token issuance process where anyone can participate in minting new tokens. The creator of the token specifies parameters such as the total supply and mint limit per transaction, which the minter smart contract enforces. This is similar to BRC-20.

note

The mint limit can be dynamic and may change in the course of the whole minting process. For example, exponentially decay minting can be programmed by halving the limit after each mint: the first mint issues 100 tokens, second 50, third 25, ...

In a closed mint (also called permissioned minting), only authorized parties, such as the token issuer, can mint new tokens. The mint contract typically checks signatures from these parties. A minter UTXO can only be spent with their signatures, thus only they can mint new tokens. This is similar to ERC20.

Premine

Open and closed minting are not mutually exclusive. For example, the minter contract can require an issuer signature only for the first few mints, but not for subsequent mints. This allows preallocation of a certain number of tokens before the token minting is open to the public, i.e., a premine.

Limited supply

More tokens can be minted after the initial mint transaction, by consuming and creating minter UTXOs repeatedly. In cases where a fixed supply is desired, the last mint creates no new minter UTXOs. Relinquishing the minting ability creates a provably limited supply token.

Parallel mint

If there is only one minter UTXO for a token and there are multiple users trying to mint this token by spending it, only one of them will succeed and all others will fail. This contention is likely to occur in an open mint. To alleviate this, a mint transaction can create multiple (say N) minter UTXOs. We call the parameter N the concurrency of token minting. It allows an exponentially growing number of minter UTXOs as minting progrosses. By judiciously selecting UTXOs, contention can be drastically reduced as shown below where N = 2. All mint transactions form a tree rooted at the reveal transaction, instead of a chain where N = 1 and mints have to be sequential.

3. Transfer

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.

Different types of tokens can be transferred in the same transaction. Each token’s balance is preserved. The following example shows two different types of tokens transferred in a single transaction.

4. Burn

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”.

Footnotes

1. This prevents multiple types of tokens having the same tokenId, since they share the same genesis outpoint. ↩