Since the first quarter of 2024, the speculative enthusiasm in the BTC ecosystem has not matched that of 2023. However, with more and more developers joining and becoming familiar with the BTC model, the technical progress of the BTC ecosystem has been rapid, especially in terms of programmability expansion solutions. Previously, Trustless Labs introduced BTC's L2 and UTXO binding, as well as BTC re-staking. This article will continue to fill in the gaps by introducing the highly anticipated Fractal Bitcoin and the programmable solutions of BTC metadata protocols such as BRC 20, CBRC, and ARC 20.

Fractal

Fractal is a scalable framework based on the bitcoin core client software virtualization, recursively creating a tree structure where each layer of the blockchain can enhance the overall performance of the Fractal network. By reusing the main code, Fractal is instantly fully compatible with Bitcoin and its infrastructure, such as being completely universal in mining. The difference is that Fractal activates the op_cat operator, allowing for the implementation of more logic.

Fractal is developed by the Unisat team, which mentioned the development progress of Fractal in its blog in January 2024. The project launched its Beta testnet on June 1, 2024, and completed a reset during the testing phase on July 29. The mainnet is expected to go live in September 2024.

The team has just released its tokenomics, with the Fractal network having its own token: 50% will come from mining, 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 community subsidies for establishing partnerships and liquidity.

Architecture Design

Fractal fully virtualizes the bitcoin core client, encapsulating it into a deployable and runnable blockchain software package (Bitcoin Core Software Package, BCSP). It then recursively anchors on the Bitcoin mainnet, independently running one or more BCSP instances. By utilizing modern virtualization technology, it achieves efficient hardware performance sharing, allowing multiple instances to run on the main system. In simple terms, it is similar to running multiple virtual machine instances (Fractal-built BCSP instances) on a single computer (BTC mainnet), and it can be recursively extended.

When a large number of on-chain interaction demands arise, these demands can be selectively delegated to deeper layers. This dynamic balancing capability of the system helps avoid excessive congestion at any specific level. To enhance user experience, Fractal has also made some modifications to the bitcoin core, changing the block confirmation time to 30 seconds or less and increasing the block size by 20 times to 20 MB, ensuring sufficient performance with short latency.

Fractal activates the op_cat operator, allowing for more exploration and testing of scalability solutions on BTC.

At the asset cross-chain level, since different instances run in a single physical environment, it can be understood as multiple bitcoin core chains running under the same BTC framework. Therefore, instance chains can communicate with each other, enabling seamless asset transfers between different layers by constructing a universal asset transfer interface.

Bitcoin and assets like BRC-20 and Ordinals can be bridged through decentralized means. The underlying mechanism is a dynamically replaceable rotating MPC signature mechanism. Currently, it seems to be a wrapping layer. In future iterations, BTC and other mainnet assets can also exist as wrapped assets on Fractal Bitcoin.

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, without introducing new consensus mechanisms. Therefore, current BTC ASIC miners and mining pools can seamlessly join the Fractal network.

The security assurance of Fractal lies in its hash power size. The design mainly enhances the security of Fractal's PoW mechanism through three aspects. Fractal introduces merged mining, where one block 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 hash power of the Fractal network itself. Thus, the impact on BTC miners is key to Fractal's success, and its tokenomics will inevitably tilt towards miners.

At the same time, newly created virtualized instance chains will experience an initial vulnerability period during the startup phase. When starting a new instance, operators can set specific block heights for protection until the instance reaches a safe and healthy state. In the future, miners with substantial hash power can allocate their resources across different BCSP instances, thereby enhancing the robustness and resilience of the entire system.

Relationship Between Fractal Mainnet Coin and Sats

The mining output of the Fractal mainnet coin is to ensure the chain's operation. The fb chain is essentially consistent with btc and does not have the capability to run smart contracts directly; therefore, complex DeFi functions like swaps require additional infrastructure. Unisat has promised that brc 20 sats will be used for swaps, which will run on Fractal and also require its own nodes. The service fees charged by these nodes for self-sufficiency will be in sats.

AVM

AVM (Atomicals Virtual Machine) is the BTC smart contract implementation of the Atomicals Protocol. AVM creates a virtual machine that simulates BTC script capabilities and opens multiple raw opcodes in the virtual machine, allowing developers to implement smart contracts by combining Bitcoin scripts and defining their own rules for managing asset creation and transfer.

Satoshi Nakamoto initially designed a fully expressive scripting language for Bitcoin, which includes a rich set of raw 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 (OPCAT) and arithmetic operators (like multiplication OPMUL and division OP_DIV).

The idea behind AVM is to maximize the capabilities of BTC raw opcodes. The AVM virtual machine simulates BTC scripts and achieves Turing completeness through a dual-stack PDA (Pushdown Automaton). This virtual machine runs in a sandbox that includes an indexer, instruction parser, and global state, allowing for the processing of smart contracts and the synchronization and verification of states.

The instruction set of the AVM virtual machine contains the complete BTC opcodes, enabling developers to program using many BTC features that have not yet been activated on the mainnet. This makes AVM appear to be a native precursor for expanding the BTC ecosystem.

AVM is a framework that any BTC metadata protocol, such as BRC 20, ARC 20, Runes, and CBRC, can customize, managed collaboratively by application developers, service providers, and users, forming a spontaneous consensus. Therefore, it is applicable to almost any metadata protocol, requiring only minor adjustments to the indexer under the virtual machine.

AVM has already released a test version https://x.com/atomicalsxyz/status/1823901701033934975, with related code available at https://github.com/atomicals/avm-interpreter.

OP_NET

Official website: https://opnet.org/#

OPNET was proposed in the third quarter of 2024 and aims to introduce Ethereum-like smart contract functionality to the Bitcoin network, but in a way that aligns more closely with Bitcoin's characteristics and architecture. Transactions on OPNET only require the use of native Bitcoin, without the need for other tokens to pay node incentives or transaction fees.

OP_NET provides a complete, compact, and easy-to-use development library, primarily written in AssemblyScript (similar to TypeScript, which can be compiled to WebAssembly). Its design goal is to simplify the creation, reading, and manipulation of Bitcoin-related technologies, especially in smart contracts and Bitcoin Smart Inscription (BSI).

Core Functions and Features of OP_NET

OPNET 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 (OPVM), OPNET can perform complex computations on Bitcoin blocks, with all submitted OPNET transactions marked as "BSI" strings and executed in OP_VM to update contract states.

OP_NET nodes run a WASM virtual machine, thus supporting multiple programming languages such as AssemblyScript, Rust, and Python. By utilizing Tapscript to enable advanced smart contract features, developers can deploy and interact with smart contracts directly on the Bitcoin blockchain without permission.

The code for these smart contracts is compressed and written into BTC transactions. This produces a UTXO address, which is treated as the contract address, and users need to transfer funds to this address to interact with the contract.

When interacting with the OPNET network, in addition to the BTC transaction fees, users also need to pay an additional fee of at least 330 satoshis to ensure that the transaction is not recognized by BTC mainnet miners as a "dust attack." Users can add more gas fees, and the packing order of transactions in the OPNET network will be sorted based on fees, not solely relying on the BTC block packing order. If the OPNET transaction fee paid by the user exceeds 250,000 sat, the excess will reward the OPNET node network.

To expand the use of BTC in DeFi applications, OPNET provides a Proof of Authority system that allows BTC to be wrapped as WBTC, with mainnet BTC bridged into the OPNET protocol through multi-signature methods.

It is worth mentioning that OPNET is compatible with SegWit and Taproot, and its token design is not bound to UTXO, avoiding the risk of mistakenly sending tokens to miners, further enhancing the security and reliability of the system. Through these features, OPNET injects stronger smart contract functionality and decentralized application support into the Bitcoin ecosystem.

OP_NET Ecosystem Projects

The predecessor of OP_NET is the cbrc-20 protocol, and most ecosystem projects continue directly from it. The ecosystem covers various fields, including decentralized trading, lending, market making, liquidity provision, and cross-chain bridges:

1. Motoswap: A decentralized trading protocol running on Bitcoin Layer 1.

2. Stash: A decentralized lending protocol running on Bitcoin Layer 1. Stash uses OP_NET's WBTC as collateral, allowing users to borrow without permission, with loans issued in USDs stablecoin.

3. Ordinal Novus: A market-making and liquidity provision platform within the OP_NET ecosystem.

4. Ichigai: A decentralized aggregator that integrates multiple DeFi platforms, allowing users to manage trading, market tracking, and portfolios from a single interface.

5. SatBot: A trading bot integrated into Telegram, enabling users to execute trades, track markets, and manage portfolios in real-time through Telegram.

6. KittySwap: A decentralized exchange and perpetual contract platform running on OP_NET.

7. Redacted: Provides on-chain private compliant DeFi private banking services.

8. SLOHM Finance: A decentralized reserve currency project launched on OP_NET.

9. BuyNet: A buy bot developed for the Bitcoin DeFi ecosystem.

10. SatsX: A project developing multifunctional features and tools on OP_NET to expand the ecosystem's capabilities.

11. Meme Coins such as Satoshi Nakamoto Inu, Zyn, Unga, Pepe: These are meme tokens based on the OP20 protocol, all supported by OPNET.

BRC 100

Documentation: https://docs.brc100.org

BRC-100 is a decentralized computing protocol built on the Ordinals theory, which adds new operations like "burn" and "mint" to brc 20. By combining these new operations, it records the token balances and states held by different addresses in the indexer, enabling complex DeFi operations. Developers can also expand more operators based on the BRC-100 protocol to extend functionalities.

Operations of the BRC-100 Protocol

BRC-100 provides several operations: mint2/mint3 and burn2/burn3, allowing tokens to be safely converted between the UTXO model and state machine model:

• mint2: Used to generate new tokens, increasing the overall circulation of the system. Typically requires permission from a specific application or address to operate.
• mint3: Similar to mint2, but does not increase circulation. It is mainly used to convert balances in applications to UTXOs (Unspent Transaction Outputs), which can be used in other applications.
• burn2: Used to destroy tokens while updating the application's state. The destroyed tokens can be regenerated through mint2 under specific conditions.
• burn3: Similar to burn2, but does not reduce circulation; instead, it converts tokens into the application's state. The destroyed tokens can be regenerated through mint3.

Expansion and Compatibility

Computational capabilities and state transitions can be expanded through the BRC-100 extension protocol. All BRC-100 extension protocols are mutually compatible, meaning that tokens implementing BRC-100 and its extension protocols can be used across all applications. Additionally, the BRC-100 protocol and its extension protocols can be updated and upgraded through improved protocols.

The BRC-100 protocol and all its extensions and improvements are collectively referred to as the BRC-100 protocol stack. All BRC-100 extension protocols are mutually compatible, meaning that tokens implementing BRC-100 and its extension protocols can be used across 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 extension protocols.

• BRC-102 is an automated liquidity protocol for BRC-100 assets, defining 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 stake BRC-20 assets, rune assets, and BTC wrapped as BRC-100 assets, as well as how to distribute rewards for 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 Ecosystem Projects

The project team is exploring a method to implement minimal indexing for the BRC-100 protocol indexer. Demand-side participants can deploy their own minimal index to obtain the state of all assets in the BRC-100 protocol stack without implementing the complex computational logic of all extension protocols. Moreover, the minimal index does not require frequent updates or upgrades.

There are three projects in the BRC-100 ecosystem:

• inBRC (Launched) - The first BRC-100 market and indexer: https://inbrc.org/.

• 100Swap (Launched) - The first decentralized exchange based on the BRC-102 protocol for Bitcoin L1 AMM inscriptions: https://100swap.io/.

• 100Layer (Developing) - A liquidity protocol for the Bitcoin ecosystem on Bitcoin L1, based on the BRC-104 protocol and BRC-106 protocol, consisting of stablecoins, wrapped tokens, and liquidity mining supported by decentralized collateral: https://100layer.io/.

Programmable RUNES (Protorunes)

Runes are essentially a data structure stored in the OP_RETURN field of Bitcoin. Compared to other JSON-based protocols (like BRC-20), runes are more lightweight, do not rely on complex indexing systems, and maintain the simplicity and security of Bitcoin.

Programmable runes are an extension layer of runes that allow the creation of programmable assets with runes. These assets can exist in UTXOs and support operations similar to AMM (Automated Market Maker) protocols. The core idea of programmable runes is to leverage data on the Bitcoin blockchain to achieve smart contract functionality through virtual machines or similar technologies.

Proto-Runes Protocol

The main project within programmable runes is the Proto-Runes Protocol, led by the team of @judoflexchop, the founder of the oyl wallet. It is currently open-sourced: https://github.com/kungfuflex/protorune

The 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), it enables the construction of AMM, lending protocols, or mature smart contracts.

For example, the 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 proto-burn and proto-messages, users can conduct decentralized trading and asset management without leaving the Bitcoin network.

In simple terms, the Proto-Runes Protocol allows runes to be burned into programmable rune Protorunes, thereby granting runes additional functionalities and uses.

Protoburn and Protorunes

One of the key mechanisms of Proto-Runes is Protoburn, which allows users to destroy runes and convert them into representations used solely by sub-protocols. These rune assets are targeted through pointers in Runestone or edicts (decrees) on the rune protocol, generating new asset forms within the sub-protocols, namely programmable runes Protorunes.

Proto-burn ensures the unspendability of runes by locking them in OP_RETURN outputs. This mechanism ensures that rune assets can be safely transferred from the main protocol to sub-protocols, allowing for further operations and transactions within the sub-protocols.

This process is typically one-way, meaning assets are transferred from the rune protocol to sub-protocols but cannot be directly returned. Protoburn messages are embedded in the Protostone within the Protocol field of Runestone, with a protocol label of 13 (rune protocol label). The message contains information such as the target sub-protocol ID and pointers to the assets. This mechanism provides a foundation for asset management and transfer between sub-protocols and allows for functionalities like Atomic Swaps.

Protomessage

In the Proto-Runes protocol, Protomessage refers to the operation instructions executed within sub-protocols. It is achieved by encoding in the Protostone structure and parsed by the indexer. Protomessages typically include requests for asset operations, such as transfers, trades, or other functions defined by the protocol. When the indexer parses the message field in Protostone, it contains a byte array, which is usually parsed through protobuf or other expected serializers of the sub-protocol, and then passed as parameters to the runtime of the sub-protocol. This message may involve asset transfers, trading logic, or other protocol functionalities.

Pointers are used to specify the target location of Protostone, which can be a UTXO in a transaction output or another Protostone. If the sub-protocol decides not to execute a particular input, in the event of a transaction failure, protorunes will be refunded to the location pointed to by the refund pointer, returning unused assets to the originator of the original transaction.

Operational Mechanism of the Proto-Runes Protocol

The operational mechanism of the Proto-Runes protocol is as follows: the indexer first processes the Runestone features in the rune protocol, then sequentially processes the protocol messages of the sub-protocols. All Protostones are processed in the order they appear in the Protocol field of Runestone. To avoid complexity and potential security vulnerabilities, the Proto-Runes protocol prohibits recursive execution of proto-messages, meaning each proto-message can only be executed once, and any recursive instructions will result in transaction failure, with unused assets being refunded.

In the Proto-Runes protocol, LEB 128 (Little Endian Base 128) is a variable-length encoding method used to represent large integers. LEB 128 encoding is widely used to represent protocol fields and messages to save space and improve processing efficiency. Each sub-protocol has a unique protocol label to distinguish different sub-protocols. These labels are represented as u 128 values and appear in Protostone as LEB 128 encoded values. Pointers are used to specify the target location of Protostone, which can be a UTXO in a transaction output, another Protostone, or even reference proto-messages to implement complex operational logic within sub-protocols.

Latest Progress: Genesis Protorune

QUORUM•GENESIS•PROTORUNE is the first Protorrune, and its Protoburn has been successfully completed, demonstrating the correct operation of the ord indexer, where the Protoburn occurred without a cenotaph, using the balance of OP_RETURN output QUORUM•GENESIS•PROTORUNE, which can be viewed through this link: https://mempool.space/tx/eb2fa5fad4a7f054c6c039ff934c7a6a8d18313ddb9b8c9ed1e0bc01d3dc9572.

This genesis Protorune is intended only as a reference implementation and is not intended for sale. It aims to serve as a public forum for the Protorune standard and can be integrated into protocols to provide governance functionality for project tokens.

The @judoflexchop team is still developing a WASM indexer for this genesis protorune: https://github.com/kungfuflex/quorumgenesisprotorune

This is a functional model for implementing on-chain governance on Bitcoin L1, serving as an indexer that allows users to generate voting tokens through protomessages. Each rune in the same range of a proposal can only generate one voting token. Proposals are automatically executed once a quorum is reached, and users can withdraw their votes by transferring voting tokens to an unspendable address. The entire process ensures transparency and effectiveness in governance.