Smart Contracts on BTC: Fractal Bitcoin and CAT20 Protocol

Recently, the Bitcoin ecosystem has welcomed an important development. After multiple rounds of testnets, Fractal BTC officially launched its mainnet in September. One of the highlights of Fractal is its smart contracts functionality, which was almost simultaneously launched with the new token protocol CAT20. So, what are the clever aspects of CAT20's technical design? What can we learn from it?

Fractal Bitcoin Introduction

Before delving into CAT20, we need to have a brief understanding of Fractal Bitcoin. The relationship between the two is similar to that of ERC20 and ETH, with the CAT20 protocol being deployed on top of Fractal Bitcoin.

Fractal Bitcoin, also known as 分形比特币, is a fully compatible "layer 2" network with BTC. Compared to BTC, it has a faster block confirmation time, taking only 1 minute. Its basic principle, as the name suggests, is to replicate the BTC network several times, with each chain able to process transactions, thereby increasing the overall processing speed. However, regarding specific details such as how different chains communicate, the official documentation has not yet been provided.

One of the highlights of Fractal is that it has enabled the opcode OP_CAT, which was abandoned a long time ago due to security issues. This greatly enhances the capabilities of Fractal Bitcoin, and there are views that OP_CAT can empower BTC with smart contracts, bringing more possibilities for future development.

Currently, developers have implemented a protocol similar to ERC20 on Fractal Bitcoin.

Overview of CAT Protocol

With the support of the underlying OP_CAT, relevant protocols quickly emerged, namely the CAT Protocol. The CAT20 protocol is currently in operation.

How does CAT20 achieve a similar token lifecycle compared to the mature ERC20 protocol?

deployment process

Before deployment, users need to specify the wallet address and basic token information. Compared to ERC20, CAT20 adds the functionality to set pre-mining and a limit on the amount that can be minted in a single operation.

The deployment is divided into two phases: "commit" and "reveal":.

1. "commit" stage: The transaction output script writes the basic information of the token, such as name, symbol, etc. The hashId of this transaction serves as the unique identifier for the token.

2. "reveal" stage: output an OP_RETURN to save the Hash of the initial state of the CAT20. At the same time, output a Minter to maintain state changes during the subsequent Mint process.

This two-step approach is a commonly used deployment method in blockchain projects, which reveals certain data about the project only during the "reveal" phase.

Mint process

Mint transactions have the following characteristics:

• The input is a minter, initially generated by deploy.
• Each mint has only one minter as input, but can have multiple minters as output.
• Each mint generates a token
• The output order requires minter before token

The setting of the number of minters will affect the Mint activity of the entire network. Setting it to 1 will cause congestion, while setting it to more than 1 will increase user costs. The V2 version defaults to generating two minters with similar states.

transaction construction

The Reveal process cleverly rewrites script logic to control UTXOs of different addresses using its own private key. The Minter phase may have utilized the smart contracts capability of OP_CAT, but specific implementation details have not been disclosed.

Transaction status (V2)

The status is stored in OP_RETURN and smart contracts. OP_RETURN stores the current output state hash, while the contract stores the remaining minting times. The mint quantity for new minters is half of the remaining mint quantity.

Unlike BRC20 or inscriptions, CAT20 does not exist on the UTXO of the user's address.

transfer and burn

During the transfer, the input and output quantities of the same token must remain consistent. To destroy, simply transfer the token to a regular address.

Summary

The design of CAT20 allows users to flexibly construct transactions, but it also requires strict verification of the contracts. This design facilitates the inquiry of token holdings and minting progress, but it may also pose the risk of oversight in the verification logic.