New Developments in Bitcoin Smart Contracts: Analyzing Fractal BTC and CAT20 Protocol

Recently, the Bitcoin ecosystem has welcomed an important development. After multiple rounds of testnet, Fractal BTC officially launched its mainnet in September. One of the highlights of Fractal is its capability of smart contracts, and at the time of its mainnet launch, it introduced a new token protocol CAT20. What ingenious features does CAT20 have in its technical design? What can we learn from it?

Fractal Bitcoin Introduction

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

Fractal Bitcoin, also known as 分形比特币, is a "second layer" network that is fully compatible with BTC. Compared to BTC, it has a shorter block confirmation time, taking only 1 minute. Its basic principle, as the name suggests, is to replicate the BTC network multiple times, with each chain capable of processing transactions, thereby increasing the overall processing speed. However, the communication details between the different chains are currently unclear, and the official has not provided relevant technical documentation.

One of the highlights of Fractal is the activation of the OP_CAT opcode, which was abandoned in the early days of BTC for security reasons. This significantly enhances the functionality of Fractal Bitcoin. There are views that OP_CAT can grant BTC smart contracts capabilities, opening up more possibilities for future development.

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

CAT Protocol Overview

With the support of the underlying OP_CAT, the corresponding protocol was soon introduced. The CAT20 protocol is currently in operation.

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

deployment process

Before deployment, users need to specify the wallet address and the basic information of the token, which is similar to ERC20. The feature of CAT20 is that it allows for setting pre-mining and limits on the number of tokens minted each time.

The deployment process is divided into two stages: "commit" and "reveal". In the commit stage, the transaction output script will write the basic information of the token. The transaction hash generated in this stage will serve as the unique identifier for the token.

In the reveal stage, the transaction will first output an OP_RETURN to save the hash value of the initial state of CAT20. It will then output a Minter for state maintenance in the subsequent minting process.

The entire deployment process follows the common submit-reveal two-step on the blockchain, which is a prevalent method for project deployment.

minting mechanism

The minting process has the following characteristics:

• The input is a minter, initially generated during the deployment phase.
• Each minting has only one minter as input, but there can be any number of minters as output.
• Each minting generates only one token.
• The output order is fixed, the minter must be before the token.

This design makes the minting process flexible and interesting. For example, the minter as output can be 0, 1, or multiple. If only 1 is output each time, the number of available minters in the network will remain unchanged, which may lead to congestion. To avoid this situation, the output is usually set to be greater than 1.

However, each additional minter output means paying an extra utxo fee. For economic reasons, more people may tend to set the minter to 0, which could lead to minter deflation, requiring some users to actively pay more minter to balance.

In version V2, two closely related Minters are generated by default.

Technical details of transaction construction

The reveal process uses the output commit of the previous transaction as input. This is achieved by cleverly rewriting the script logic, allowing the same private key to control the utxo of two different addresses.

In the minter stage, everyone can use these UTXOs as inputs, which may utilize the smart contract capabilities of OP_CAT, and each minter is essentially a smart contract.

transaction status management

The state in the minter is stored in two places: the OP_RETURN of the transaction output and the smart contract (, namely Minter and Token ).

OP_RETURN stores the hash value of the current transaction output status, and the contract stores the remaining minting times of the Token. After each minting, the newly generated Minter's minting amount is half of the remaining mintable amount.

In the end, the remaining quantity of all Minters is reduced to zero.

It is worth noting that the CAT20 Token is also a smart contract, containing two basic states: quantity and owner address. This differs from BRC20 or inscriptions, as CAT20 does not directly exist on the user's UTXO.

transfer and destroy

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

To destroy a Token, simply transfer it to a regular address.

Summary

The design of CAT20 gives users a great deal of operational flexibility, but it also places higher demands on the verification logic of the contracts. This design brings some advantages:

1. To check the Token holding status, simply check the token's utxo without needing to trace back.
2. You can check the current status of minting by searching for transactions containing cat data in OP_RETURN.

This innovation brings new possibilities to the Bitcoin ecosystem, and it is worth our continued attention to its development.