Since the first quarter of 2024, the speculative enthusiasm of the BTC ecosystem has not been as high as in 2023, but as more and more developers join and become familiar with the BTC model, the BTC ecosystem has made rapid progress in terms of technology, especially in terms of programmable expansion solutions. Trustless labs has previously introduced BTC's L2 and UTXO binding and BTC re-staking. This article will continue to fill in the gaps and introduce the highly popular Fractal Bitcoin and the programmable solutions of BTC metadata protocols such as BRC20, CBRC, and ARC20.
Fractal
Fractal is a virtualized version of bitcoin core client software. By recursively creating a tree-like extensible framework, each layer of blockchain can improve the performance of the entire Fractal network. Because of the reuse of the main code, Fractal is instantly fully compatible with Bitcoin and its infrastructure, such as mining. The difference is that Fractal activates the op_cat operator, allowing more logic to be implemented.
Fractal was developed by the Unisat team, and Unisat mentioned the development progress of Fractal in a blog in January 2024. The project launched the Beta test network on June 1, 2024, completed a reset of the testing phase on July 29, and the main network is expected to be launched in September 2024.
The team has just released its token economics. The Fractal network will have its own tokens, 50% of which will be mined, 15% will be used for the ecosystem, 5% will be pre-sold to early investors, 20% will go to advisors and core contributors, and 10% will be used as community subsidies to build partnerships and liquidity.
Architecture Design
Fractal fully virtualizes the bitcoin core client and packages it into a deployable and runnable blockchain software package (Bitcoin Core Software Package, BCSP). Then it recursively anchors to the Bitcoin mainnet and runs one or more BCSP instances independently. Through modern virtualization technology, efficient hardware performance sharing is achieved, allowing multiple instances to run on the main system. In simple terms, it is similar to opening multiple virtual machine instances (BCSP instances built by Fractal) on a computer (BTC mainnet), and it can also be recursive.
When a large number of on-chain interaction needs arise, these needs can be selectively delegated to deeper levels. This system's dynamic balancing ability helps avoid excessive congestion at any particular level. For a better user experience, Fractal has also made some modifications to bitcoin core. The block confirmation time has been changed to 30 seconds or less, and the block size has been increased 20 times to 20 MB, which ensures sufficient performance and short enough latency.
Fractal activated the op_cat operator, making it possible to explore and test more expansion solutions on BTC.
At the asset cross-chain level, since different instances are running in the same physical environment, it can be understood as running multiple bitcoin core chains under the same BTC framework. Therefore, the instance chains can communicate with each other and achieve seamless asset transfer between different layers by constructing a universal asset transfer interface.
Bitcoin, as well as assets such as BRC-20 and Ordinals, can be bridged through a decentralized bridge. The underlying mechanism is a rotating MPC signature mechanism with dynamic replacement. At present, it seems to be a packaging layer. In subsequent iterations, BTC and other mainnet assets can also exist on Fractal Bitcoin as brc-20 packaging assets.
Compared to typical Ethereum Layer 2 solutions, this form of virtualization achieves computational scalability through an additional abstraction layer outside the main chain while maintaining consistency with the main chain and not introducing a new consensus mechanism. Therefore, current BTCASIC miners and mining pools can seamlessly join the Fractal network.
Fractal's security is guaranteed by its computing power. The design mainly enhances the security of Fractal's PoW mechanism through three aspects. Fractal introduces joint mining, where one out of every three blocks is generated through merged mining with BTC miners to help protect the network from potential 51% attacks; the remaining two blocks are produced by the Fractal network's own computing power. It can be seen that the impact on BTC miners is the key to Fractal's success, and its token economy will inevitably tilt towards miners.
At the same time, the newly created virtualized instance chain will experience an initial fragile period during the startup phase. When launching a new instance, the operator can set a specific block height to provide protection until the instance reaches a safe and healthy state. In the future, miners with large computing power can allocate their resources to different BCSP instances, thereby enhancing the robustness and resilience of the entire system.
The relationship between Fractal mainnet currency and sats
The mining output of Fractal mainnet coins is to ensure the operation of the chain. The fb chain is basically the same as BTC and does not have the ability to directly run smart contracts. Therefore, complex defi functions such as swaps require additional infrastructure. Unisat promises to use brc20 sats for swaps. This swap runs on Fractal and also requires its own nodes. The service fees charged by these nodes for self-profit and loss are sats.
Shopping Mall
AVM (Atomicals Virtual Machine) is the BTC smart contract implementation of Atomicals Protocol. AVM creates a virtual machine that simulates the BTC script and opens multiple BTC original opcodes in the virtual machine. Developers implement smart contracts through Bitcoin script combinations and define their own rules to manage the creation and transfer of assets.
Satoshi Nakamoto initially designed a fully expressive scripting language design for Bitcoin, which includes a rich set of original opcode instructions. These scripts have certain data storage capabilities and are Turing complete. Later, Bitcoin Core disabled some opcodes required for Turing completeness, such as basic string concatenation operations (OP_CAT) and arithmetic operators (such as multiplication OP_MUL and division OP_DIV).
The idea of AVM is to maximize the original opcode capabilities of BTC. The AVM virtual machine simulates the BTC script and achieves Turing completeness through a dual-stack PDA (Pushable Storage Automaton). This virtual machine runs in a sandbox, which contains an indexer, an instruction parser, and a global state, thereby realizing the processing of smart contracts and the synchronization and verification of states.
The instruction set of the AVM virtual machine includes complete BTC opcodes, so developers can use many BTC unlaunched functions for programming on the main network. This makes AVM look like a native pioneer network for BTC ecological expansion.
AVM is a set of architectures. Any BTC metadata protocol, such as BRC20, ARC20, Runes, and CBRC, can be customized and jointly managed by application developers, service providers, and users to form a spontaneous consensus. Therefore, it is applicable to almost any metadata protocol, and only requires fine-tuning of the indexer under the virtual machine.
AVM has released a beta version https://x.com/atomicalsxyz/status/1823901701033934975, and the relevant code is https://github.com/atomicals/avm-interpreter.
ON_NET
Official website: https://opnet.org/#
OP_NET was proposed in the third quarter of 2024. It is committed to introducing smart contract functions similar to Ethereum on the Bitcoin network, but more in line with the characteristics and architecture of Bitcoin. To conduct transactions on OP_NET, only native Bitcoin is needed, and no other tokens are needed to pay node incentives or transaction fees.
OP_NET provides a complete, compact and easy-to-use development library, mainly written in AssemblyScript (similar to TypeScript, which can be compiled to WebAssembly). Its design goal is to simplify the creation, reading and operation of Bitcoin-related technologies, especially in smart contracts and Bitcoin Smart Inscription (BSI).
OP_NET's core functions and features
OP_NET retains Bitcoin's block consensus and data availability, ensuring that all transactions are stored on the Bitcoin network and protected by its immutability. Through an execution virtual machine (OP_VM), OP_NET can perform complex calculations on Bitcoin blocks. All submitted OP_NET transactions are marked with a "BSI" string and executed in OP_VM to update the contract status.
The OP_NET node runs a WASM virtual machine, so it supports multiple programming languages such as AssemblyScript, Rust and Python. By leveraging Tapscript to enable advanced smart contract functions, developers can deploy and interact with smart contracts directly on the Bitcoin blockchain without permission.
The codes of these smart contracts are compressed and written into BTC transactions. This generates a UTXO address, which is regarded as the contract address. Users need to transfer money to this address when interacting with the contract.
When interacting with the OP_NET network, in addition to the BTC transaction fee, users also need to pay an additional fee of at least 330 satoshis to ensure that the transaction will not be identified as a "dust attack" by BTC mainnet miners. Users can add more gas fees, and the order in which transactions are packaged in the OP_NET network will be sorted according to the fee, not entirely dependent on the BTC block packaging order. If the OP_NET transaction fee paid by the user is greater than 250,000 sats, the excess will be rewarded to the OP_NET node network.
In order to expand the use of BTC in DeFi applications, OP_NET provides a Proof of Authority system that allows BTC to be packaged as WBTC. The mainnet BTC is bridged to the OP_NET protocol through a multi-signature method.
It is worth mentioning that OP_NET is compatible with SegWit and Taproot, and its token design is not bound to UTXO, avoiding the risk of sending tokens to miners by mistake, further improving the security and reliability of the system. Through these features, OP_NET injects stronger smart contract functions and decentralized application support into the Bitcoin ecosystem.
OP_NET Ecosystem Projects
OP_NET's predecessor is the cbrc-20 protocol, and most of its ecological projects are directly inherited. The ecology covers decentralized trading, lending, market making, liquidity provision, cross-chain bridges and other fields:
Motoswap: This is a decentralized trading protocol that runs on Bitcoin Layer 1.
Stash: This is a decentralized lending protocol that runs on Bitcoin Layer 1. Stash uses OP_NET's WBTC as collateral, allowing users to make permissionless loans, and loans are issued in the form of USDs stablecoins.
Ordinal Novus: This is the market making and liquidity provision platform in the OP_NET ecosystem.
Ichigai: This is a decentralized aggregator that integrates multiple DeFi platforms, allowing users to manage transactions, market tracking, and portfolios on a single interface.
SatBot: A trading bot integrated into Telegram that allows users to execute trades, track markets, and manage portfolios in real time through Telegram.
KittySwap: A decentralized exchange and perpetual contract platform running on OP_NET.
Redacted: Providing on-chain private and compliant DeFi private banking services.
SLOHM Finance: A decentralized reserve currency project launched on OP_NET.
BuyNet: A buying bot developed for the Bitcoin DeFi ecosystem.
SatsX: A project developing versatile features and tools on OP_NET, expanding the capabilities of the ecosystem.
Meme Coins like Satoshi Nakamoto Inu, Zyn, Unga, Pepe: These are Meme tokens based on the OP_20 protocol, all powered by OP_NET.
BRC100
Documentation: https://docs.brc100.org
BRC-100 is a decentralized computing protocol built on the Ordinals theory. It adds new operations such as "destruction" and "minting" to BRC20. By combining these new operations, the balance and status of tokens held by different addresses are recorded in the indexer, thereby realizing complex DeFi operations. Developers can also expand more operators based on the BRC-100 protocol to expand their business.
Operation of the BRC-100 protocol
BRC-100 provides some operations: mint2/mint3 and burn2/burn3, which allow tokens to be safely converted between the UTXO model and the state machine model:
mint2: used to generate new tokens and increase the circulation of the entire system. Usually requires permission from an application or address to operate.
mint3: Similar to mint2, but does not increase circulation. It is mainly used to convert balances in applications into UTXO (unspent transaction outputs), which can be used in other applications.
burn2: used to destroy tokens and update the status of the application. The destroyed tokens can be regenerated through mint2 if certain conditions are met.
burn3: Similar to burn2, but instead of reducing the circulation, the tokens are converted to the state of the application. The destroyed tokens can be regenerated through mint3.
Expansion and compatibility
Computing power and state transitions can be expanded through the BRC-100 extension protocol. All BRC-100 extension protocols are compatible with each other, that is, tokens that implement BRC-100 and its extension protocols can be used in all applications. At the same time, the BRC-100 protocol and its extension protocols can be updated and upgraded through improvement protocols.
The BRC-100 protocol and all its extensions and improved protocols are collectively referred to as the BRC-100 protocol stack. All BRC-100 extension protocols are compatible with each other, that is, tokens that implement BRC-100 and its extension protocols can be used in all applications and support cross-chain operations. There are BRC-101, BRC-102 and BRC-104:
BRC-101 is a decentralized on-chain governance protocol that defines how to govern applications based on the BRC-100 protocol or its extensions.
BRC-102 is an automated liquidity protocol for BRC-100 assets. It defines an automated market-making method based on the “constant product formula” (x*y=k) for a pair of tokens based on the BRC-100 protocol stack.
BRC-104 is a liquidity staking/re-staking pool protocol that defines how to wrap BRC-20 assets, Rune assets, and BTC into BRC-100 assets through staking, and how to distribute BRC-100 asset rewards to BRC-100 assets, BRC-20 assets, Rune assets, or BTC stakers. BRC-104 is the Asset Wrapping Protocol and Yield Farming Protocol of the BRC-100 protocol stack.
BRC-100 Ecological Project
The project is exploring a method to implement a minimal index for the BRC-100 protocol indexer. The demander can deploy their own minimal index to obtain the status of all assets in the BRC-100 protocol stack without having to implement the complex calculation logic of all extended protocols. Moreover, the minimal index does not need to be updated or upgraded frequently.
There are 3 projects in the BRC-100 ecosystem:
inBRC (Launched) - The first BRC-100 marketplace and indexer: https://inbrc.org/.
100Swap (Launched) - The first Bitcoin L1 AMM inscription decentralized exchange based on the BRC-102 protocol: https://100swap.io/.
100Layer (Developing) - A liquidity protocol for the Bitcoin ecosystem on Bitcoin L1, based on the BRC-104 and BRC-106 protocols, consisting of stablecoins backed by decentralized collateral, wrapped tokens, and liquidity mining: https://100layer.io/.
Programmable Runes (Protorunes)
Rune is essentially a data structure stored in the OP_RETURN field of Bitcoin. Compared with other JSON-based protocols such as BRC-20, Rune is more lightweight and does not rely on complex index systems, maintaining the simplicity and security of Bitcoin.
Programmable Runes is an extension layer of Runes that allows the creation of programmable assets with Runes. The introduction of these assets can exist in UTXO and support operations similar to AMM (Automated Market Maker) protocols. The core idea of Programmable Runes is to use data on the Bitcoin blockchain to realize the functions of smart contracts through virtual machines or similar technologies.
Proto-Runes Protocol
Among programmable runes, the most important project is Proto-Runes Protocol, which is led by the team of @judoflexchop, the founder of oyl wallet. It is now open source: https://github.com/kungfuflex/protorune
Proto-Runes Protocol is a standard and specification that provides a framework for programmable runes. By managing and transferring rune assets between sub-protocols (meta protocols), AMMs, lending protocols, or full-fledged smart contracts can be built.
For example, Proto-Runes Protocol implements a DEX (decentralized exchange) similar to Uniswap on the Bitcoin network, supporting atomic swaps of rune assets and the creation of liquidity pools. Through the combination of prototype destruction and prototype messages, users can conduct decentralized transactions and asset management without leaving the Bitcoin network.
Simply put, the Proto-Runes Protocol allows runes to be burned into programmable runes called Protorunes, giving runes additional functions and uses.
Protoburn和Protorunes
One of the key mechanisms of Proto-Runes is Protoburn, which allows users to destroy and convert runes into a representation that is only used by the sub-protocol. These rune assets are targeted through Runestone pointers or edicts on the Rune Protocol, thereby generating new asset forms in the sub-protocol, namely programmable rune Protorunes.
The prototype destruction ensures the unspendability of the rune by locking it on the OP_RETURN output. This mechanism ensures that the rune assets can be safely transferred from the main protocol to the sub-protocol, allowing further operations and transactions in the sub-protocol.
This process is usually one-way, that is, assets are transferred from the Rune Protocol to the sub-protocol, but cannot be directly transferred back. Protoburn messages are embedded in Protostone in the Protocol field of Runestone, and its protocol tag is 13 (Rune Protocol Tag). The message contains information such as the target sub-protocol ID and a pointer to the asset. This mechanism provides the basis for asset management and transfer between sub-protocols, and allows functions such as Atomic Swaps.
Protomessage
In the Proto-Runes protocol, Protomessage refers to the operation instructions performed in the sub-protocol. It is implemented by encoding in the Protostone structure and parsing by the indexer. Protomessage usually includes operation requests for assets, such as transfers, transactions, or other protocol-defined functions. When the indexer parses the message field in Protostone, the field contains a byte array, which is usually parsed by protobuf or other sub-protocol expected serializers, and then passed as a parameter to the runtime of the sub-protocol. The message may involve asset transfers, transaction logic, or other protocol functions.
The pointer is used to specify the target location of the Protostone, which can be a UTXO in the transaction output or another Protostone. If the sub-protocol decides not to execute an input, when the transaction fails, the protostones will be returned to the location pointed to by the refund pointer (refund_pointer), and the unused assets will be returned to the initiator of the original transaction.
The operating mechanism of the Proto-Runes protocol
The operating mechanism of the Proto-Runes protocol is: the Indexer first processes the Runestone features in the Rune Protocol, and then processes the protocol messages of the sub-protocols in order. All Protostones are processed in the order they appear in the Protocol field of the Runestone. In order to avoid complexity and potential security vulnerabilities, the Proto-Runes protocol prohibits recursive execution of prototype messages, that is, each prototype message can only be executed once, and any recursive instructions will cause the transaction to fail, and unused assets will be refunded.
In the Proto-Runes protocol, LEB128 (Little Endian Base 128) is a variable-length encoding method for representing large integers. LEB128 encoding is widely used to represent protocol fields and messages to save space and improve processing efficiency. Each subprotocol has a unique protocol tag to distinguish different subprotocols. These tags are represented by u128 values and appear as LEB128-encoded values in Protostone. Pointers are used to specify the target location of Protostone, which can be UTXO in the transaction output, another Protostone, or even a reference to a prototype message, so as to implement complex operation logic in the subprotocol.
Latest progress: Genesis Protorune
QUORUM•GENESIS•PROTORUNE is the first Protorrune, and its Protoburn has been successfully completed. We can see the correct operation of the ord indexer, where Protoburn occurs without cenotaph because OP_RETURN is used to output the balance of QUORUM•GENESIS•PROTORUNE, which can be seen through this link: https://mempool.space/tx/eb2fa5fad4a7f054c6c039ff934c7a6a8d18313ddb9b8c9ed1e0bc01d3dc9572.
This Genesis Protorune is intended only as a reference implementation and is not intended to be sold. It is intended to serve as a public forum for Protorune standards and can be integrated into the protocol to provide governance functions for project tokens.
@judoflexchop team is still developing indexer for this genesis protorune a WASM: https://github.com/kungfuflex/quorumgenesisprotorune
This is a functional model for implementing on-chain governance on Bitcoin L1. As an indexer, it allows users to generate voting tokens through protomessage. The same range of runes in each proposal can only generate voting tokens once. Proposals are automatically executed after reaching a quorum, and users can also withdraw their votes by transferring voting tokens to non-spendable addresses. The whole process ensures the transparency and effectiveness of governance.