Technical sharing: CAT20 -- Token protocol on Fractal BTC

Author: ZAN Team

This article is for technical sharing only and does not constitute any investment advice.

BTC will also have its own Smart Contract?

In the recent BTC ecosystem, Fractal BTC finally launched Mainnet in September after undergoing multiple Testnets. One of the major features of Fractal is its ability to support smart contracts, and almost simultaneously with the Mainnet launch, it introduced a new Tokenprotocol CAT20. What clever technical designs does CAT20 have? What can we learn from it?

Fractal Bitcoin

Before understanding CAT20, we need to briefly understand Fractal Bitcoin. Their relationship is similar to ERC20 and ETH. The CAT20 protocol is deployed on Fractal Bitcoin.

Fractal Bitcoin, also known as Fractal BTC, is a "second-layer" network that is fully compatible with BTC. Compared to BTC, its Block confirmation time is faster, only taking 1 minute. The basic principle is as simple as its name suggests, which is to replicate the BTC network several times, and each chain will process transactions. With more Nodes capable of processing transactions, the speed naturally increases. However, the specific details, such as how different chains communicate with each other, are currently not very clear, and there are no corresponding technical documents from the official source for reference.

If it's just a second-layer chain, faster transactions don't seem exciting. However, enabling the long-abandoned Operation Code OP_CAT in Fractal Bitcoin has taken its capabilities to a new level, some say it gives BTC the ability to have smart contracts, which opens up even more room for imagination.

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

About why OP_CAT was deprecated and then re-enabled on Fractal Bitcoin, we can discuss this further later. Here, let's follow CAT20.

CAT Protocol

The following content refers to the White Paper: Introduction | CAT Protocol (*)

And the github repository:

GitHub - CATProtocol/cat-token-box: A monorepo for packages implementing CAT protocol (*)

With the support of the underlying OP_CAT, the corresponding protocol, CAT Protocol, was quickly established. Currently, one of the protocols that is already running in practice is the CAT20 protocol, and the corresponding panel has also been added to Unisat: *

Upon seeing the name CAT20, most people should be able to infer that it is similar to ERC20. Compared to the mature ERC20 protocol, deploying a Token has become very convenient. How does CAT20 achieve a lifecycle similar to ERC20?

Deploy

Before deployment, users need to specify their WalletAddress and basic information of the Token. The basic information of the Token is similar to that of ERC20:

There will be some differences. CAT20 can set limits on pre-mining and the quantity minted each time. Of course, ERC20 can also achieve these capabilities through the contract's ability.

During the deployment phase, two transactions will be initiated, which can be considered as two stages: 'commit' and 'reveal'. Referring to the official diagram, the deployment phase is as follows:

In the 'commit' phase, the basic information of the Token, such as the name and symbol, will be written into the output script of the transaction. The hashId of the transaction initiated in the 'commit' phase will serve as the identifier for the Token, distinguishing it from other Tokens.

You can see that this transaction 'bc1pucq...ashx' corresponds to the commit, and the remaining two transactions pointing to 'bc1pszp...rehc4' are used for paying the gas fee for the 'reveal' stage below, and the other is for change.

During the 'reveal' phase, you can see that there are two UTXO inputs, corresponding to the first two outputs in the previous commit phase. This transaction will first output an OP_RETURN, which will store the initial state hash of CAT20 in the OP_RETURN. Then another Minter will be output, which will play an important role in the subsequent Mint process, to maintain the state changes of the Mint process.

Looking back at the whole process of Deployment, the "commit" and "reveal" follow the common on-chain steps of Block, which is a common way to deploy projects. Some data of the project will only be revealed in the "reveal" phase.

Mint

Let's take a look at how the transaction works when we mint a Token.

In the figure above, the Mint process has the following characteristics.

• The input of mint is a minter, which is initially generated during deployment.
• Each mint has one and only one minter as input, and any number of minters as output (a little problem).
• Each mint has one and only one token (there is a bit of a problem)
• The order of the output is required, and 'minter' must be followed by 'token'.

Knowing the process of Mint, in fact, we can find some special situations that make the whole process of Mint interesting.

For example, as the output of mint transactions, minter can be 1, multiple, or even 0. If it is set to 1 every time mint is performed, the total number of minters available in the entire network will remain unchanged (1), which will make minting congested and everyone will need to compete for this minter. To avoid this situation, it is necessary to set the quantity of minter output to be greater than 1 each time, so that after minting, the number of minters available for everyone will increase.

However, each additional output of a minter means that you need to pay an additional utxo. For economic reasons, more people would be willing to set the minter to 0, which inevitably makes the minter become deflationary. This requires some people to make contributions, voluntarily paying the extra minter.

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

Construction of Transactions

Some users may have noticed a problem, that is, why can the utxo of the minter be used to build transactions? To understand this issue, we need to analyze the source code of the "contract".

1、reveal utxo

First, let's analyze the transactions during the reveal process. We found that he used the output commit of the previous transaction as the input. Why can we use a utxo that is not our Address to construct the transaction input?

According to common sense, a Private Key corresponds to a Public Key, and the Public Key derives an Address. When verifying whether an input utxo is valid, it is generally determined by comparing whether the decrypted signature using the Public Key is consistent with the original transaction. This part of the logic is written in the BTC script. So we can cleverly rewrite the logic of the script, and write in the script that the Public-Private Key pair is our own Address, so that we can control the utxo of two different Addresses.

We can know what happened by looking at the source code:

There is another issue here, which is that one Private Key corresponds to one Public Key, so why does the generated commit Address differ from our Address? This can be seen from the source code here

In other words, our Private Key will be adjusted based on an ISSUE_PUBKEY to adjust the Public Key, which is also a feature of P2TR Address.

2, Minter UTXO

In the reveal process, we use different utxos as inputs, but actually the Secret Key of encryption is the same, that is the deployer's Private Key. But in the minter phase, how can everyone use these utxos as inputs?

I guess this part is the OP_CAT capability mentioned earlier, that is, the capability of Smart Contract, and each minter is a Smart Contract. However, at present, the source code of this part has not been disclosed, and I don't know what the specific implementation will be for the time being.

Trading status (V2)

In minter, the state is also preserved. This state exists in two places: one is in the transaction output OP_RETURN, and the other is stored in Smart Contracts, which refers to the above-mentioned Minter and Token.

The Hash stored in OP_RETURN is the hash of the current transaction output state, and the remaining Mint count of the Token will be stored in the contract. After each Mint, the mint quantity of the newly generated Minter will be equal to the remaining mintable quantity divided by two. Represented in a graph:

When the last one is finished, the remaining quantity of Minter is 0.

Back to the original picture, in addition to Minter being a Smart Contract, the generated Token is also a Smart Contract, which is CAT20. CAT20 has two basic states: quantity and the owner's Address of the Token. It can be seen that unlike the previous BRC20 or inscription, your CAT20 is not on the UTXO of your Address.

Transfer

When transferring, the quantities of tokens in the inputs and outputs of the transaction need to be consistent. Of course, there can be multiple different tokens in the same transaction, as long as the quantities of their inputs and outputs are consistent.

Burn

If you want to burn the TOKEN, just transfer the TOKEN to a regular Address.

Summary

It can be seen that all operations are built by the users themselves, with great flexibility, so there needs to be a lot of verification logic in the contract part. Some of the current vulnerabilities are also due to negligence in the verification logic.

There can be some benefits to such a design:

1. If you want to check the holding situation of all TOKENs, just check the utxo of the token, no need to continue to check up.
2. If you want to check the current status of mint, you can search for transactions with OP_RETURN data containing cat.