The BTC ecosystem welcomes new developments in smart contracts

Recently, a new smart contracts platform called Fractal Bitcoin has emerged in the Bitcoin ecosystem, officially launching its mainnet in September. One of Fractal's main features is its capability for smart contracts, and it introduced a new token protocol, CAT20, at the same time as the mainnet launch. What are the clever aspects of CAT20's technical design? What can we learn from it?

Fractal Bitcoin Introduction

Before understanding CAT20, we need to briefly understand Fractal Bitcoin; the relationship between the two is similar to that of ERC20 and ETH. The CAT20 protocol is deployed on Fractal Bitcoin.

Fractal Bitcoin, also known as 分形比特币, is a fully compatible second-layer network with BTC. Compared to BTC, it has a faster block confirmation time, taking only 1 minute. Its basic principle is to replicate the BTC network several times, allowing each chain to process transactions. With more nodes processing transactions, the speed naturally increases. However, the specific technical details, such as how different chains communicate with each other, are still not very clear, and the official has not provided relevant technical documentation.

One important feature of Fractal is that it has enabled the OP_CAT opcode, which was abandoned long ago for security reasons in BTC, elevating the capabilities of Fractal Bitcoin to a new level. Some believe that OP_CAT can give BTC the ability to implement smart contracts, thus providing more possibilities for future development.

Currently, someone has implemented a protocol similar to ERC20 on Fractal Bitcoin.

CAT Protocol

With the underlying support of OP_CAT, the corresponding CAT Protocol has quickly emerged. Currently, the CAT20 protocol is in actual operation, and a corresponding functional panel has also been added on a certain block explorer.

The name CAT20 is reminiscent of ERC20, and the two are indeed quite similar. How does CAT20 achieve a similar lifecycle compared to the mature ERC20 protocol?

Deploy

Before deployment, users need to specify the wallet address and the basic information of the token, which is similar to ERC20. The difference is that CAT20 allows for setting pre-mining and limits on the quantity for each Mint.

The deployment is divided into two phases: "commit" and "reveal". In the commit phase, the basic information of the token, such as name, symbol, etc., will be written into the output script of the transaction. The transaction hash ID initiated in the commit phase will serve as the identifier for that token, used to differentiate it from other tokens.

During the reveal phase, the transaction will output an OP_RETURN, saving the initial state hash of the CAT20. It will then output a Minter, used to maintain the state changes during the subsequent Mint process.

The entire Deploy process follows the two common steps of submission and disclosure on the blockchain, which is a relatively common method of project deployment.

Mint

The Mint process has the following characteristics:

• The input of mint is a minter, initially generated during deployment.
• Each mint has only one minter as input, and any number of minters as output.
• Each mint only has one token
• The output order is required, minter must be before token.

The change in the number of minters during the minting process affects the entire network's minting activities. If only one minter is output each time, the number of available minters in the network remains unchanged, which can lead to congestion. To avoid this situation, the number of minters output each time needs to be set to greater than 1. However, outputting an additional minter requires paying an extra utxo, and for economic reasons, more people are likely to set the minter to 0, which will lead to minter deflation, requiring some individuals to voluntarily pay for the additional minters to maintain stability.

In version V2, two Minter are generated by default, and the states of the two Minters will be as close as possible.

The status of the transaction (V2)

The minter retains the state, stored in two places: one is in the transaction output's OP_RETURN, and the other is stored in smart contracts, namely the aforementioned Minter and Token.

The Hash storing the current transaction output status in OP_RETURN, and the remaining Mint counts of the Token stored in the contract. After each Mint, the number of mints generated by the new Minter equals the remaining mintable quantity divided by two. Finally, the remaining quantity of all Minters is 0.

Apart from Minter, the generated tokens are also smart contracts, namely CAT20. CAT20 has two basic states: quantity and the address of the token owner. Unlike BRC20 or inscriptions, CAT20 does not exist on the UTXO of the address.

Transfer

When transferring, the input and output token amounts for constructing the transaction must remain consistent. A single transaction can involve multiple different tokens, as long as the input and output amounts for each token are consistent.

Burn

To burn tokens, simply transfer the tokens to a regular address.

Summary

All operations of CAT20 are constructed by the users themselves, providing great flexibility. Therefore, the contract part requires a lot of validation logic. Some vulnerabilities that have emerged are also due to negligence in the validation logic.

This design has the following advantages:

1. To find all Token holdings, you only need to check the token's utxo, no need to continue querying upwards.
2. To check the current mint status, you can search for transactions in OP_RETURN that contain the word cat.