# The Potential of OP_CAT for BTC - Using CAT20 as an Example

By: **@cyberorange** (https://x.com/xcshuan)

[TOC]

## 1. Background

Over the past year, the BTC ecosystem has seen significant growth compared to earlier times, with the emergence of many asset protocols based on indexers or CSV (client-side validation), such as BRC20, Runes, Atomicals, RGB, RGB++, Taproot Assets, and others. These protocols have increased BTC’s on-chain activity but only use BTC as a DA or transaction ordering service (`double-spending prevention`), without BTC itself verifying their operational validity.

So, is it possible to use BTC to validate computations? Several designs have been proposed, such as BitVM and BitVM2, which aim to leverage BTC's scripting capabilities to validate arbitrary computations. However, these solutions face challenges in terms of complexity, usage costs, and various user experience issues.

On the other hand, some enthusiasts claim that simply re-enabling a long-sealed opcode—`OP_CAT`—on BTC could give us many highly desirable features, such as `transaction introspection`, `stateful UTXO`, `Covenants`, even `Recursive Covenants`, and the ability to verify arbitrary computations. Could this simple path truly promise us such vast possibilities?

This article will outline some methods for achieving this goal while comparing them to an Extended UTXO model—the [Cell model](https://medium.com/nervosnetwork/https-medium-com-nervosnetwork-cell-model-7323fca57571). The Cell model is an Extended UTXO model that supports transaction introspection, arbitrary Covenants, and can store arbitrary state in UTXOs. Understanding the Cell model will help clarify the goal of implementing these features on BTC.

Exploring whether the BTC UTXO model, with just `OP_CAT`, can achieve capabilities similar to an extended UTXO model, you will discover how a simple instruction can unlock so many possibilities, reminiscent of the concept of "one begets two, two begets three, and three begets all things."

## 2. UTXO and Extended UTXO (Cell)

### 2.1 UTXO vs. Cell

UTXO (Unspent Transaction Output) is the on-chain state representation model initially used by BTC. It has many advantages, such as:

- Parallel execution
- Off-chain determinism
- On-chain validation, off-chain computation
- Easy implementation of light nodes

In BTC’s UTXO model, there are essentially only two components:

1. **Value**: Represents the amount of BTC contained in the UTXO.
2. **ScriptPubkey**: Represents the unlocking conditions for the UTXO.

Thus, BTC's basic functionality is limited to storing and transferring BTC, with only limited programmability offered by its scripting language.

In contrast, the Extended UTXO model, such as the Cell model, includes the following elements:

pub struct CellOutput {
    pub capacity: u64,
    pub data: Vec<u8>,
    pub lock: Script,
    pub type_: Option<Script>,
}

Where:

- **Capacity**: Represents the amount of the native coin held in the Cell, while also limiting the size of on-chain state space the Cell occupies.
- **Data**: Stores arbitrary state, such as token balances, NFT data, contract state, and more.
- **Lock Script**: Similar to BTC's `ScriptPubkey`, representing the unlocking conditions of the Cell. The lock script is executed only when the Cell is consumed.
- **Type Script**: Optional. If absent, the Cell is simple. If present, the `type` script defines the meaning of the Cell, such as representing a token or a contract. The `type` script is executed both when the Cell is created and consumed.

The Cell model as an Extended UTXO model offers the following key extensions:

1. **Data Field**: A Cell can carry arbitrary on-chain state.
2. **Type Field**: The addition of the `type` script allows for Recursive Covenants. The `type` script checks both the validity of Cell consumption and the validity of Cell creation, so constraints can be enforced perpetually.
3. **Turing-complete:** The Cell model uses a RISC-V register-based model to execute scripts.
4. **Transaction Introspection**: Various syscalls are implemented for transaction introspection, such as `load_input(source, index)`, `load_output(source, index)`, `load_witness(source, index)`, and `load_cell_dep(source, index)`.
5. **Separation of Control and Meaning**: The Cell model separates ownership control from the Cell’s meaning, making it more flexible.

Thus, the Cell model, as an Extended UTXO model, can achieve `transaction introspection`, `Recursive Covenants`, `stateful UTXO`, and even `Turing completeness`.

Below are definitions of some key terms:

### 2.2 Transaction Introspection

For the UTXO model, transaction introspection refers to the ability to access the transaction’s own attributes during validation.

In BTC, the supported opcodes do not allow scripts to retrieve information such as the current transaction’s inputs and outputs. The only opcodes that provide limited introspection capabilities are `OP_CHECKSEQUENCEVERIFY`, `OP_CHECKLOCKTIMEVERIFY`, and `OP_CHECKSIG`. Therefore, BTC does not fully support transaction introspection at the scripting layer.

Transaction introspection allows a script to read some of the input and output values of the current transaction during execution, which can be used to decide whether to unlock the transaction.

The Cell model achieves transaction introspection through built-in syscalls, allowing scripts to introspect and access transaction data during execution.

### 2.3 Covenants and Recursive Covenants

In the BTC ecosystem, the term "`Covenants`" is not precisely defined, and different Covenant schemes provide varying functionalities. However, we can provide a simple definition:

- **Covenants**: A UTXO model supports `Covenants` if the unlocking script of a UTXO can impose restrictions on the transaction outputs, such as the amount of BTC sent and the output addresses.

For example, a UTXO could have two unlocking paths:
1. Path 1: Address A receives a maximum of 30%, Address B receives a maximum of 70%, and the remaining is sent to Address C.
2. Path 2: Address C receives the full amount.

Once transaction introspection is enabled, Covenants can be implemented easily.

**Recursive Covenants** offer an even stronger capability, which can be defined as:

- **Recursive Covenants**: A UTXO model supports `Recursive Covenants` if the unlocking script of a UTXO can impose restrictions on the outputs of the transaction, and these restrictions must be perpetuated in future transactions.

For example, a UTXO could have two unlocking paths:
1. Path 1: Address A receives a maximum of 30%, Address B receives a maximum of 70%, and the remaining is sent to a subsequent UTXO following the same Covenant rules.
2. Path 2: Address C receives the full amount.

After enabling transaction introspection, Recursive Covenants can also be easily implemented.

We can further define a new type of Covenant: **Retrospective Covenants**, which is even more restrictive than Recursive Covenants. Retrospective Covenants can be defined as:

- **Retrospective Covenants**: A UTXO model supports `Retrospective Covenants` if the unlocking script of a UTXO can impose restrictions on the outputs of the transaction, and these restrictions must be perpetuated while ensuring that the outputs themselves were generated according to the original constraints.

An example of `Retrospective Covenants` would be asset issuance on the BTC chain. According to issuance rules, if a UTXO is bound to 1,000 coins, a clear requirement is that all subsequent transactions consuming that UTXO should not transfer more than 1,000 coins. Similarly, if a UTXO is tied to a colored coin (e.g., Asset A), then any UTXO of Asset A should be traceable back to its legitimate issuance, with the entire process validated by a BTC script.

The Cell model uses the `type` script to enforce `Retrospective Covenants` by executing validation during both creation and consumption. Achieving this on BTC would require more complex mechanisms.

### 2.4 Stateful UTXO

A UTXO is considered stateful if, in addition to carrying BTC, it can carry arbitrary data as state. This state can be transferred across transactions through Covenant-like constraints.

Once validated state can be placed in a UTXO, many possibilities open up:

- For example, a state root can be placed in the UTXO, and the script can verify the correctness of state transitions, resulting in a Validium.
- Alternatively, a Merkle Mountain Range root of blockchain headers can be placed in the state, and the script can verify block header transitions, enabling a bidirectional SPV cross-chain bridge.

The Cell model directly stores arbitrary state data in the `data` field of each Cell.

## 3. OP_CAT and UTXO On-Chain Validation Paradigm

Earlier, we discussed some potential extensions of the UTXO model. Now, what exactly is `OP_CAT`, and how does it help achieve these extensions?

`OP_CAT` is a very simple opcode that takes two values from the stack, concatenates them, and pushes the result back onto the stack.

Can such a simple opcode allow the UTXO model to gain the benefits described earlier? To a certain extent, yes. Although more detailed work is required, it is theoretically possible.

Another point to clarify is that, unlike the account model, the UTXO model favors an `off-chain computation, on-chain validation paradigm`. Any opcode can be used in a positive or reverse manner. For example, `OP_CAT` can be used to concatenate two values, but it can also be used to prove that a value can be split into two separate values.

In a way, writing UTXO scripts is somewhat like designing zk (zero-knowledge) circuits. The important part is constraining the input-output transformation of the transaction to adhere to specific rules, and the script validates whether the rules are satisfied.

In contrast, account-based models, such as Ethereum's EVM, place more emphasis on on-chain computation, where inputs are processed by contract functions to produce outputs.

### 3.1 Transaction Introspection with OP_CAT

As we know, BTC’s supported opcodes do not allow scripts to access the current transaction’s inputs or outputs. The only opcodes that provide limited introspection capabilities are `OP_CHECKSEQUENCEVERIFY`, `OP_CHECKLOCKTIMEVERIFY`, and `OP_CHECKSIG`, so BTC scripts do not support full transaction introspection.

`OP_CHECKSIG` functions as follows: it reads two values from the stack (a signature and a public key), calculates a hash using the `sigHashType` and the transaction data, and then verifies the signature’s correctness using this hash, the public key, and the signature. For Taproot transactions, with `SIG_HASH_ALL` as an example, the `SIG_HASH` is computed as follows:

sig_msg = (
    sighash_epoch
    + sighash_type
    + version
    + locktime
    + sha_prevouts
    + sha_amounts
    + sha_scriptpubkeys
    + sha_sequences
    + sha_outputs
    + spend_type
    + index_of_this_input # Now includes the index of the input being signed
)

# Taproot uses tagged hashes for the sighash
tag_hash = sha256("TapSighash".encode())
sighash = sha256(tag_hash + tag_hash + sig_msg)

As we can see, `OP_CHECKSIG` accesses parts of the transaction through the computation of `sigHash`, indirectly binding it to the transaction's related properties. Can we take advantage of this to access the entire contents of the transaction?

To explore this, we first need to understand the signature algorithm used in BTC. Currently, `OP_CAT` is being proposed as an addition to `Tapscript`, so we will focus on the `Schnorr` signature algorithm.

The `Schnorr` signature algorithm works as follows:

> Assume the user's private key is $x$, and the public key is $P = x \cdot G$.
>
> **Signature generation process:**
>
> 1. Assume the message to be signed is $m$.
> 2. The user randomly selects a nonce $r$, and computes $R = r \cdot G$.
> 3. Compute $e = H(R | P | m)$, and $s = r + x \cdot e$.
> 4. The signature is $(R, s)$.
>
> **Signature verification process:**
>
> 1. Compute $e = H(R | P | m)$.
> 2. Compute $A = R + e \cdot P$ and $B = s \cdot G$.
> 3. Verify whether $A = B$.

In theory, if we can recompute the signature and verify it using `OP_CHECKSIG`, we can confirm the transaction’s correctness. A possible process is as follows:

1. Place the transaction `tx` on the stack.
2. Use `OP_SHA256` and other opcodes to calculate the `sigHash`.
3. Construct the signature in the script using the private key.
4. Place the public key on the stack.
5. Use `OP_CHECKSIG` to verify the generated signature.
6. If the signature is valid, it confirms that the `sigHash` generated by the transaction matches the one generated in the script, meaning the transaction on the stack is the current transaction, achieving transaction introspection.

This process heavily depends on `OP_CAT`. To use certain fields from the transaction (such as input amounts or outputs), those fields need to be split and placed on the stack. Then, `OP_CAT` concatenates them back together, after which the hash and signature are computed.

Another challenge is implementing `Schnorr` signatures in the script, as `Schnorr` signatures involve scalar and elliptic curve multiplications, and since BTC scripts lack a multiplication opcode (`OP_MUL`), performing these calculations is difficult.

However, since we only need to verify the hash consistency, not secure the assets themselves, the private key and nonce used for signing can be simplified. For instance, we could use trivial values like $x = 1$ and $r = 1$, which would give us the public key $P = 1 \cdot G = G$.

In this case, the signature calculation would be:

1. Let the transaction’s `sigHash` be $m$.
2. Choose a nonce $r = 1$, giving $R = 1 \cdot G = G$.
3. Compute $e = H(R | P | m) = H(G | G | m)$, and $s = 1 + H(G | G | m)$.

Thus, the final signature is $R = G, s = 1 + H(G | G | m)$, where the only operations involved are hashing, and both the public key and $R$ are $G$, which can be hardcoded in the script.

By using this method, we can place various parts of the transaction on the stack, concatenate them with `OP_CAT`, calculate the `SIG_HASH`, compute $e$, add 1, and finally use `OP_CHECKSIG` to verify the signature’s correctness.

The specific implementation would require some clever tricks since BTC scripts do not support 256-bit operations. However, it is possible to convert these operations into concatenation problems and then solve them using `OP_CAT`.

- First, through "transaction grinding" ensure that the last byte of $s$ is always `0x01`.
- Then, place the value of $s$ with the last byte removed on the stack.
- Using `OP_CAT`, concatenate `0x01` to obtain the valid $s$ for signing.
- Using `OP_CAT`, concatenate `0x00` to obtain $s - 1$, which can be used to compare the value of $e$.

Since there are only 256 possible values, this computation is not too difficult, and values like `timelock` can be adjusted to find the correct solution, similar to a `Proof of Work` (PoW).

After verifying the transaction on the stack, the transaction's values (such as input amounts, scripts, etc.) can be used during script execution, thereby achieving full transaction introspection.

For example:

- Using `sha_prevouts`, we can obtain the input's `Outpoint`.
- Using `sha_amounts`, we can retrieve the input’s BTC amount.
- Using `sha_scriptpubkeys`, we can retrieve the input’s `scriptPubkey`.
- Using `sha_outputs`, we can access the outputs.

With transaction introspection, simple `Covenants` can be implemented.

### 3.2 Covenants with OP_CAT

First, simple `Covenants` can easily be implemented after enabling transaction introspection. The script can use opcodes like `OP_IF` and `OP_CAT` to concatenate and create the expected `outputs`, which can then be compared with the `sha_outputs` obtained through introspection. This allows the script to enforce rules on the addresses and amounts in the outputs.

For `Recursive Covenants`, these can also be easily constructed. Since transaction introspection can retrieve the unlocking address, the script can enforce that the unlocking address matches the output address, ensuring that the constraints are maintained.

Now, how can **`Retrospective Covenants`** be implemented? Simple transaction introspection alone cannot guarantee this, because when the current script is unlocked, it cannot check how the output will be unlocked in the next transaction, nor can it know how the previous transaction was unlocked.


However, the introspection technique mentioned earlier can be applied again. By reading the `sha_prevouts` from the script, the corresponding `Outpoint` can be retrieved, which contains the `TxID` of the previous transaction. If the previous transaction is placed on the stack and its `TxID` is verified against the `Outpoint`, this confirms the correctness of `preTx`. Then, the script can verify whether the previous transaction was constrained by the same script, making **Retrospective Covenants** feasible. Similarly, it is possible to trace back further to `prePreTx`, which is the `preTx` of the previous transaction, allowing the script to verify the legitimacy of the UTXO’s origin and retrieve any data from previous transactions.

### 3.3 UTXO-Bound State

After solving the issue of `Recursive Covenants`, the next question is how to bind a state to a UTXO.

For pre-Taproot scripts, this is not particularly difficult if transaction introspection can be achieved.

Non-Taproot scripts reveal all the script data in the witness during unlocking, so state data can be stored directly in the script. The state data can be placed at the end of the script, as shown below:


Each time a transaction is completed, the script needs to check whether the state value in the output script has been updated correctly according to the computed value.

However, for Taproot-based scripts, this method cannot be easily applied, since Taproot scripts do not reveal the entire script in the witness. Instead, a `ControlBlock` is used to locate a specific script in the `Taptree`, as shown below. There are three possible unlocking paths: A, B, or C, and an internal private key can also be used to unlock the script directly. Since the entire script is not disclosed, storing state data within the script, as previously mentioned, is difficult to implement.


Another approach is to use the transaction’s `OP_RETURN` to store state data. `OP_RETURN` is a special type of output in BTC that allows up to 80 bytes of arbitrary data to be stored, although it cannot be spent again.


Each time the script unlocks, it can validate the state transition using the techniques discussed earlier, such as transaction introspection and **`Retrospective Covenants`**. By reading the current transaction’s `OP_RETURN` output and the previous transaction’s `OP_RETURN` output, these values can serve as the UTXO’s bound state, and the script can then validate the correctness of the state transition.

Various types of data, such as token balances, state tree roots, and more, can be stored in `OP_RETURN`.

## 4. Example of CAT20

CAT20 is a fungible token (FT) asset protocol that utilizes the features mentioned above based on `OP_CAT`. Compared to BRC20 and Runes, CAT20 does not require an indexer, is fully secured by BTC, and avoids issues such as token burning. The code can be found at: [CATProtocol/cat-token-box: A monorepo for packages implementing CAT protocol](https://github.com/CATProtocol/cat-token-box).

To better understand CAT20's design, let’s first define a few key terms:

- **curTx**: The transaction currently undergoing script validation.
- **parentTx**: The historical transaction from which the current transaction’s inputs are sourced.
- **grandparentTx**: The historical transaction from which the `parentTx` inputs are sourced.
- **CAT20State**: For token UTXOs, it includes the amount of tokens bound to the UTXO and the address that owns the UTXO. For Minter UTXOs, it should include the amount that the minter can mint, stored in the `OP_RETURN` output.
- **id**: The token ID bound to the UTXO, determined by the outpoint of the genesis transaction, i.e., `genesisTxid + vout`.
- **id embedding**: The Minter’s script should embed the token ID to distinguish between different Minters, and the Minter’s script should be embedded in the Token’s script to distinguish between different tokens.


Next, we will briefly describe the constraints in CAT20’s Deploy, Mint, and Transfer operations. Please note that the following discussion is simplified to explain the core principles, and the actual implementation may involve more complex constraints.

### 4.1 Deploy


A transaction is constructed where one output’s witness field contains the token metadata, such as the name, symbol, and decimals. This transaction is called the `genesisTx`.

To unlock the UTXO that is bound to the token metadata in `genesisTx`, another transaction is constructed:

- The first output is an `OP_RETURN` output that binds the minter state using the UTXO-bound state method described earlier.
- All non-`OP_RETURN` outputs are minter UTXOs, representing the minting rights for a certain amount of tokens.

The Deploy process involves only two transactions, so no `Retrospective Covenant` checks are triggered at this stage.

### 4.2 Mint


There are two possible scenarios when minting tokens:

- The current minter used to mint tokens was generated directly from the `genesisTx`.
- The current minter was generated by consuming another minter.

For minting tokens, the following constraints should be enforced:

- To maintain token balance, check: `curTx.Minter.Amount + curTx.Token.Amount == parentTx.Minter.Amount`.
- Check that the tokens are of the same ID: `curTx.Minter.id == parentTx.Minter.id`, and `curTx.Token.MinterScript == curTx.Minter.Script`.
- Verify the legitimacy of the token source by ensuring one of the following is true:
- `parentTx.Minter.Script == grandParentTx.Minter.Script`.
- `parentTx.Minter.id == tdid(grandParentTx) | vout`.

### 4.3 Transfer


The Transfer operation primarily involves checking two main points: balance consistency, owner authorization, and the legitimacy of the token source. The following constraints should be enforced for a Transfer:

- To ensure token balance, check: `curTx.Token.Amount == parentTx.Token.Amount`.
- To ensure that the owner provided authorization, check: `checkSig(curTx.Token.Owner, signature)`.
- To ensure the legitimacy of the token source, first check that `curTx.Token.Script == parentTx.Token.Script`, and then ensure that at least one of the following is true:
- `grandParentTx.Script == parentTx.Token.MinterScript` (i.e., the source is from a minter).
- `grandParentTx.Script == parentTx.Token.Script` (i.e., the source is from another token transfer).

### 4.4 Additional Tips

- **Separation of Unlocking and Meaning Constraints**: Store the unlocking conditions in `Token.State` to achieve a separation of UTXO ownership from UTXO meaning, similar to the Cell model.
- **Contract-Owned Tokens**: The `Token.State.Owner` field does not necessarily have to be bound to a user’s public key. It can also be bound to another unlocking script, which, during unlocking, checks whether the input’s unlocking script matches the owner’s. This allows contracts to hold tokens, enabling applications such as AMMs, lending protocols, and more.
- **High Validation Efficiency**: When verifying whether a UTXO represents a valid token, only two previous transactions need to be checked. There is no need for an indexer to scan the entire transaction history.
- **Alleviating State Contention**: Since minting requires consuming minter UTXOs, this can lead to state contention. To alleviate this while ensuring supply limits, multiple new minter UTXOs can be created when consuming a minter, allowing the number of minter UTXOs to grow while keeping the minting limit for each one constrained.
- **Transaction Size**: CAT20 transactions tend to be large due to the need to include back-referenced transactions in the witness. For example, [Transaction 2537706ed1000d5dd3a28d79a95ade8f674fd3e25c020cbcf97fd1b1e86ec8ef](https://mempool.fractalbitcoin.io/zh/tx/2537706ed1000d5dd3a28d79a95ade8f674fd3e25c020cbcf97fd1b1e86ec8ef) includes two token inputs and one token output, resulting in a transaction size of 14.82 kB and a virtual size of 3.93 kB.
- **`OP_CAT` Limitations**: Currently, `OP_CAT` has a constraint that the concatenated string cannot exceed 520 bytes. CAT20 needs to concatenate transactions in the stack and compute their hashes, so the transaction size must also be kept below 520 bytes. According to the documentation, CAT20 transactions are limited to a maximum of six inputs and six outputs.
- **TransferGuard and BurnGuard**: CAT20 uses `TransferGuard` and `BurnGuard` to impose constraints on the entire transaction. Since scripts are only executed in the input, each time a transfer or burn operation is initiated, a separate transaction must first construct a corresponding guard UTXO. This guard UTXO is then used as an input to construct the transfer or burn transaction, meaning two transactions are required for each transfer.

## 5. Towards General Computing

Earlier, we described how `OP_CAT` combined with BTC’s UTXO model can achieve features similar to those of an Extended UTXO model, with CAT20 as an example.

Now, is it possible to achieve more general computing on BTC scripts? For instance, can we use BTC scripts to verify zkRollup state transitions? Directly implementing such functionality in scripts would be challenging and difficult to interoperate with. However, one possible path is to use scripts to verify zkProofs.

- **Verifying Pairing-based zkProofs**: The Scrypt team has previously deployed Groth16 verification scripts on BSV. However, these scripts are very large, taking up 24MB, which is impractical given BTC’s current block size limits.
- **Alternative Approach with zkSTARK**: A more feasible strategy is to use zkSTARKs based on smaller domains, as these computations use fields small enough to be performed with native script opcodes, keeping the final verification script size within a reasonable range. Additionally, zkSTARK’s core operations are primarily hash-based and rely on Merkle proofs, which can benefit from `OP_CAT` to reduce script size by leveraging native `OP_CODE`.

If the final script size is still slightly larger than acceptable, it can be split into multiple sub-scripts and executed on BTC using a concatenation or challenge-response mechanism.

The repository [Bitcoin-Wildlife-Sanctuary/bitcoin-circle-stark](https://github.com/Bitcoin-Wildlife-Sanctuary/bitcoin-circle-stark) is currently working on implementing Circle-STARK verification scripts based on `OP_CAT`.

Once BTC supports transaction introspection, Recursive Covenants, Stateful UTXOs, and general computing, what can be accomplished?

- **Bidirectional SPV Cross-Chain Bridge**: The repository [Bitcoin-Wildlife-Sanctuary/scrypt-poc-bridge](https://github.com/Bitcoin-Wildlife-Sanctuary/scrypt-poc-bridge) is working on a BTC-to-Starknet cross-chain bridge PoC.
- Use `State` to maintain an accumulator root of another chain’s block headers.
- Use zkProofs to verify the correctness of block headers (e.g., verifying PoW hash computations).
- Use zkProofs and transaction introspection to verify the validity of deposit and withdrawal operations.
- Use contracts on the other chain to maintain the BTC SPV and verify cross-chain events.

- **zkRollup, Validium**:
- Use `State` to maintain the state root of a sidechain.
- Use zkProofs to validate state transitions.
- Use zkProofs and transaction introspection to verify deposit and withdrawal operations.

---

After reviewing this, you may begin to understand why many BTC OGs are so enthusiastic about `OP_CAT`. Its simplicity belies its immense power. It is foreseeable that the re-enablement of `OP_CAT` on BTC could mark the beginning of the next wave of innovation in the BTC ecosystem. The capabilities unlocked by `OP_CAT`—such as MEME tokens, stablecoins, DeFi, zk-based sidechains, permissionless cross-chain bridges, and an improved Lightning Network—could greatly stimulate innovation on BTC.

### Some Reference Links:

- [Cell Model. A generalized UTXO as state storage | by Jan Xie | Nervos Network | Medium](https://medium.com/nervosnetwork/https-medium-com-nervosnetwork-cell-model-7323fca57571)
- [Bitcoin OP_CAT Use Cases Series #1: Covenants | by sCrypt | Medium](https://scryptplatform.medium.com/trustless-ordinal-sales-using-op-cat-enabled-covenants-on-bitcoin-0318052f02b2)
- [Bitcoin OP_CAT Use Cases Series #4: Recursive Covenants | by sCrypt | Medium](https://scryptplatform.medium.com/bitcoin-op-cat-use-cases-series-4-recursive-covenants-6a3127a24af4)
- [Introduction | CAT Protocol](https://catprotocol.org/)
- [OP_CAT: A Big Step towards Bitcoin Contracts, From Vault to General Computing | Bitlayer Blog](https://blog.bitlayer.org/opcat_a_big_step_towards_Bitcoin_contracts/)
- [The Path to General Computation on Bitcoin | StarkWare](https://starkware.co/blog/general-computation-on-bitcoin/)
- [How to Verify ZK Proofs on Bitcoin? @Polyhedra](https://hackmd.io/@polyhedra/bitcoin)