☄️SRC20 on Fractal

SRC20 protocol on Fractal

Fractal Bitcoin

Fractal Bitcoin, 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 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.

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 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:

     {
       "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:

     {
       "p": "src-20",
       "op": "detach"
     }

3. Account model transfer (same as the current SRC20 protocol on Bitcoin)

   • Example:

     {
       "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.

5. Hybrid transfer

   • Deduct assets from the transaction inputs first, if the assets are insufficient, deduct the remaining amount from the account model. If there is any remaining UTXO asset, it will be bound to the first non-OP_RETURN 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.

---