# SRC20 on Fractal

## Fractal Bitcoin

[**Fractal Bitcoin**](https://www.fractalbitcoin.io/), the Bitcoin-native scaling solution designed to extend the power and potential of Bitcoin without compromising its core principles. By maintaining consistency with the Bitcoin mainnet and providing new tools for developers and miners, Fractal creates a robust environment for innovation that stays true to Bitcoin’s ethos of decentralization, security, and transparency.

The Fractal network has activated the `OP_CAT` opcode, unlocking significant potential for programmability across the entire network. The recently introduced [CAT20](https://catprotocol.org/cat20/) protocol takes full advantage of this feature, creatively developing a fungible token protocol validated by POW miners. This protocol not only serves as a practical smart contract use case within the Fractal ecosystem but also provides valuable insights for both Fractal and Bitcoin regarding the potential of `OP_CAT`.

## Extending SRC20 Protocol onto Fractal

Currently, the most prominent fungible token protocols on Bitcoin include BRC20, SRC20, ARC20, and RUNES. Notably, BRC20 was activated at block height 21,000 on the Fractal mainnet, and RUNES is set to activate at height 84,000. To further increase the impact of the SRC20 protocol and explore how `OP_CAT` can unlock new possibilities for its development, it is both logical and advantageous to extend the SRC20 protocol to the Fractal network.

## **SRC20 on Fractal**

The protocol specifications for SRC20 on Fractal are identical to those on Bitcoin, except for the ticker name length. For native SRC20 protocol details, please refer to: [SRC20 Specifications](https://github.com/stampchain-io/stamps_sdk/blob/main/docs/src20specs.md).

To prevent conflicts with existing assets on the Bitcoin mainnet, the SRC20 ticker naming rule on Fractal has been customized.

🔸 **SRC20 ticker names on Fractal must be between 6 and 12 characters. Tickers with fewer than 6 characters are not allowed, as they are already in use on Bitcoin's mainnet.**

**🔸 In addition to the rule mentioned above, SRC20 rules on Fractal are consistent with the** [**rules**](https://github.com/stampchain-io/stamps_sdk/blob/main/docs/src20specs.md) **on Bitcoin mainnet.**

## UTXO Model (under development)

Currently, SRC20 uses a pure account-based model. Compared to the UTXO model, the account model eliminates the risk of unintended asset transfers but does not benefit from the advantages offered by the UTXO model, such as a fully non-custodial P2P trade mode.

To retain the benefits of the account model while also taking advantage of the UTXO model’s convenience and exploring future possibilities on the Fractal network, we are researching how to extend the SRC20 protocol to the UTXO model on Fractal. The protocol will introduce the `attach` and `detach` operators, with the initial design described as follows:

1. **attach**
   * Bind a specified amount of tokens to a UTXO.
   * Example:

     ```json
     {
       "p": "src-20",
       "op": "attach",
       "tick": "STAMP",
       "amt": "100"
     }
     ```
2. **detach**
   * Unbind all assets from the transaction inputs and credit them to the account model.
   * Example:

     ```json
     {
       "p": "src-20",
       "op": "detach"
     }
     ```
3. **Account model transfer (same as the current SRC20 protocol on Bitcoin)**
   * Example:

     ```json
     {
       "p": "src-20",
       "op": "transfer",
       "tick": "STAMP",
       "amt": "100"
     }
     ```
4. **UTXO model transfer**
   * Transfer all bound assets from the transaction inputs to the first non-OP\_RETURN output UTXO.

**Pros and cons of the SRC20 protocol coexisting with both account and UTXO models:**

1. The SRC20 account model avoids unintended asset transfers.
2. The SRC20 UTXO model benefits from the network’s native validation and further potential with OP\_CAT activated networks.
3. Coexistence of account and UTXO models increases protocol complexity.
4. The UTXO model requires wallet support, or there is a risk of easily losing assets.

***


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.openstamp.io/introduction/src20-protocol/src20-on-fractal.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.