Bitroot: Exploring a smarter way of issuing coins on the BTC chain (with interactive tutorial)

From the earliest colored coins, OmniLayer, etc., to last year’s inscriptions, and this year’s runes and RGB++, the Bitcoin community has been constantly experimenting with asset issuance on the Bitcoin network, despite much controversy among Bitcoin maximalists who believe that Bitcoin should simply play the role of currency and are concerned that complexity may introduce potential risks.

The main reason is that the security and scale of the Bitcoin network itself are very attractive. As a natural high-quality infrastructure, it can bring a great narrative space for assets issued on it. And avoiding proposals for the Bitcoin network, only using existing on-chain space to explore asset issuance methods is open to the community. Currently, these explorations of asset issuance methods are blooming everywhere, but the final outcome is uncertain.

Today, Bitroot also proposes a new way to use the Bitcoin network for asset issuance and supports the embedding of smart contracts, while also being the L2 layer of Bitcoin.

Evolution of Asset Issuance Methods on the Bitcoin Network

Let’s start with the asset issuance method on Bitcoin.

The earliest colored coins used the UTXO of Bitcoin to achieve the ‘coloring’ effect by adding specific information to the Bitcoin UTXO, making it distinguishable from other UTXOs, and the ‘colored’ UTXO carries new assets. The metadata related to these assets is mainly stored in the OP_RETURN opcode of the Bitcoin transaction script. OP_RETURN was initially designed to terminate the script and return the value at the top of the stack, similar to a return function in programming languages. Later, it became the primary way to embed data in Bitcoin transactions. The most significant feature is that the data added to Bitcoin transactions using OP_RETURN is verifiable but unspendable for the Bitcoin network, allowing the maximum data input to increase from the early version’s 40 bytes to the current 80 bytes. Representative projects include Open Assets.

During the same period when Colored Coin was popular, there were many upgraded ways of asset issuance, such as OmniLayer (formerly known as Mastercoin), which is more like Layer2 mentioned nowadays. It puts the transaction logic off-chain and uses the Bitcoin chain as a log function, also using OP_RETURN to add OmniLayer transaction metadata. There is also Counterparty, which is a protocol layer above Bitcoin and aims to achieve decentralized asset exchange. Initially, Counterparty used the Bitcoin operation code OP_CHECKMULTISIG to include Counterparty-related data in the Bitcoin blockchain. However, because the use of OP_CHECKMULTISIG was considered a hacker attack, it later switched to using the OP_RETURN operation code to store data.

Other early storage methods include: using the issuance method of the nSequence field, nSequence is a reserved field in Bitcoin transactions with a 32-bit space, and the advantage of using nSequence is that it does not increase additional storage. The representative project is EPOBC (enhanced, padded, order-based coloring), which stores additional information about assets in the nSequence field of Bitcoin transactions. However, the disadvantage is that there is no asset numbering, so it is cumbersome to trace back to the original genesis transaction when conducting transactions.

It can be seen that using the OP_RETURN opcode to store data is almost the mainstream practice of asset issuance on early BTC.

After the SegWit and Taproot upgrades of Bitcoin, new storage space was brought to asset issuance. At this time, Ordinals, which uses the P2TR (a type of Bitcoin transaction output) introduced after the Taproot upgrade, was born. It engraves metadata in the witness data (witness field) of the transaction. The advantage is that the storage space is larger: the upper limit of a single piece of Taproot information is 520 bytes, and the amount of data that can be accommodated can be extended by combining multiple pieces of information. The storage cost of witness data is also relatively cheaper. Therefore, after the experimental launch of Ordinals, it caused market hype and redirected the community’s attention to the way Bitcoin chain assets are issued. Inspired by Ordinals, various improved asset issuance protocols have emerged, such as Atomicals, which borrows the logic of colored coins and corresponds the quantity of each ARC-20 token to the sat amount, so there is no need for off-chain indexers like BRC-20 because asset information is located in the UTXO.

However, the issuance of inscriptions has also been opposed by many OGs in the Bitcoin community, mainly out of concern that it will make the Bitcoin blockchain bloated. BRC-20 tokens are also susceptible to dusting attacks. In addition, the inscription is located in the witness data area, and some community members are concerned that this space may be removed after future upgrades.

The recent popular Runes protocol, returning to tradition, chooses to store asset metadata in OP_RETURN, and combines Atomicals’ UTXO-based mechanism, which can contain any number of Runes tokens in UTXO.

It can be seen that the asset issuance method has gone through rounds of iteration, but ultimately, more protocols still choose to use the OP_RETURN in Bitcoin to store asset data.

Bitroot’s New Asset Issuance Solution

Returning to Bitroot, Bitroot has introduced BRT20, a new on-chain asset issuance protocol for Bitcoin. Bitroot calls it the Root Protocol, and the chosen location for data storage is also OP_RETURN.

Specifically, Bitcoin transactions containing OP _ RETURN output can be created through the bitcoinlib library, a popular library that handles Bitcoin-related operations. Similar to other Bitcoin asset issuance and trading methods, Bitroot can also issue and trade assets by creating Bitcoin transactions in a specific format. When a user needs to issue a new asset, the user needs to construct a Bitcoin transaction that contains special metadata that defines the asset name, total amount, and other attributes. Once such transactions are confirmed by the Bitcoin network and added to the blockchain, nodes of the Bitroot protocol parse the data and record the corresponding asset creation and distribution in its internal database.

It is worth mentioning that Bitroot stores not only asset issuance and transaction data in OP_RETURN, but also smart contracts.

However, the smart contracts here are different from the typical EVM smart contracts, because Bitroot’s smart contracts are built on top of the Bitcoin blockchain and utilize Bitcoin’s script language (a basic language for Bitcoin transactions). For security reasons, Bitcoin’s script language is designed to be non-Turing complete and only includes some basic opcodes, such as OP_ADD, OP_EQUAL, OP_CHECKSIG, OP_CHECKMULTISIG, etc., which are designed for single payment purposes. There are no loop statements, avoiding the risk of infinite loops, but this also means that it cannot perform complex computational tasks. Its main application scenario is transaction signature verification to ensure the authenticity of transactions. Therefore, smart contracts on Bitcoin are more limited compared to EVM smart contracts.

Bitroot also recognizes this feature of the Bitcoin script language, and the solution is to expand the functionality of the Bitcoin script language by adding additional operation codes and functions to support more complex smart contracts. Here are the basic features of Bitroot’s implementation of smart contracts:

1. Script language based on Bitcoin

Bitroot extends the functionality by adding additional opcodes and features on top of the Bitcoin Script language.

2. Embedding Data in Transactions

Bitroot’s smart contract data is embedded in the OP_RETURN output of Bitcoin transactions, and Bitroot nodes can parse and execute the data. Therefore, the logic and state changes of the smart contract can be encoded and stored in this data.

3. Analysis and Execution of Smart Contracts

When the Bitcoin network confirms transactions containing OP_RETURN data, Bitroot nodes parse the data in these transactions and execute corresponding operations based on embedded smart contract code. This includes asset transfers, contract execution, etc. Each Bitroot node independently verifies and executes these operations to maintain network consistency.

4. Limitations and Features

While Bitroot enhances the functionality of smart contracts in this way, its functionality is limited by Bitcoin Script’s non-Turing completeness, so Bitroot’s smart contracts are better suited for applications that don’t require complex logic, such as simple financial agreements and asset management.

5. Future Expansion

Bitroot community has been exploring more ways to expand the functionality of smart contracts, including possible protocol upgrades and integration with other blockchain technologies to provide wider application support.

Based on these characteristics, Bitroot can achieve the issuance of new assets and embed smart contract logic into transactions, enabling more complex financial use cases than traditional issuance/trading without modifying the core protocol of Bitcoin.

Bitroot runs on two code repositories: Bitcoin Core and Bitroot’s own software, so Bitroot transactions must be confirmed by the Bitcoin network. At the same time, Bitroot also inherits the security and decentralization of the Bitcoin network.

In addition, Bitroot provides a series of tools and wallet applications to the developer community, allowing developers and users to conveniently use the Bitroot protocol for asset management, transactions, and smart contract interactions. Bitroot also supports automated and integrated APIs, maximizing convenience for user utilization.

Bitroot embeds smart contract functionality into the Bitcoin network and defines a resolution system to make contract logic more open and transparent. While inheriting the security of the Bitcoin network, it brings more diverse ways to play with assets on the Bitcoin network. In addition to asset issuance and trading, Defi services such as lending, Dex, derivatives, launch platforms, as well as on-chain transactions of in-game items, virtual characters, artworks, and other assets are also available.

Bitroot Test Experience

Currently, Bitroot is open for testing, testnet address: 01928374656574839201.

BRT test coin acquisition:;

BTC Test Coin Faucet:;

BTC test coin purchase: .

After entering, create a wallet first, and then you can test asset issuance after receiving the test tokens.

Currently, there are three types of assets that can be created, namely creating assets with letter names, sub-assets of existing created assets, and creating free digital name assets.

Creating assets with letter names is relatively simple. Enter Token Name, Deion (description information, which can be modified at any time), quantity (issuance quantity, default is expandable), and click create token to create.

To create a sub-asset of an asset, you need to create the parent asset first. You can select the asset you just created and enter the Token Name and quantity to create it.

When creating a free digital name asset, a string starting with ‘A’ will be randomly assigned as the token name (the numbers after ‘A’ can be customized). Simply enter the description information and quantity to create.

Simply click on the arrow on the asset to achieve functions such as asset transfer, information viewing, asset increase, and locking assets from further increase.

The left side of the functional area is the asset trading interface. The interface will display the currently popular trading pairs and the trading pairs with Maker on the current market. Simply search for the corresponding trading pair to complete the buy and sell orders, simple and convenient.

Summary

BRT20 launched by Bitroot delves into the available functions of the Bitcoin chain and provides an intelligent way for on-chain issuance of native assets on the Bitcoin chain. However, this protocol is still in its early stages and it will take time to be widely recognized by the community in the future.