With the emergence of new applications such as the Babylon staking protocol and the launch of Fractal Bitcoin, which is based on the native scaling method of UTXO, the market potential of BTCFI is gradually becoming apparent.

Abstract

This article starts with the feasibility and evolutionary path of Bitcoin programming, systematically discussing the potential and challenges of Bitcoin in the field of decentralized finance (BTCFI). Bitcoin adopts the UTXO model in its architecture and forms a contract system centered on verification through its unique script language and opcodes. Compared with Ethereum's smart contracts, Bitcoin contracts are characterized by being "stateless" and "non-computable," which limits their functionality but also provides higher security and decentralization.

With the implementation of the Taproot upgrade, the contract capabilities of Bitcoin have been significantly enhanced. The introduction of Taproot, especially the application of MAST and Schnorr signatures, enables Bitcoin to support more complex contract logic and greatly improve privacy and transaction efficiency. These technological innovations pave the way for the further development of BTCFI, allowing Bitcoin to explore more financial application scenarios while maintaining its original decentralized advantages.

Based on this, the article provides an in-depth analysis of how Bitcoin programming supports various BTCFI applications. By interpreting mechanisms such as multi-signature, time locks, hash locks, and discussing the application of tools such as DLC, PSBT, and MuSig2, the article demonstrates the possibility of achieving decentralized clearing and complex financial contracts without the need for trust. This decentralized financial system native to the Bitcoin network not only overcomes the centralization risks of the WBTC era's cross-chain bridging model but also provides a more solid trust foundation for Bitcoin holders.

The article emphasizes that the development of decentralized finance in Bitcoin is not just a technological advancement, but a profound transformation of its ecosystem structure. With the emergence of new applications such as the Babylon staking protocol and the launch of Fractal Bitcoin, which is based on the native scaling method of UTXO, the market potential of BTCFI is gradually becoming apparent. In the future, as the price of Bitcoin rises, BTCFI will further attract mainstream users' participation, forming a new financial ecosystem centered around Bitcoin. The formation of this ecosystem will further evolve Bitcoin from the narrative of "digital gold" to an indispensable decentralized financial infrastructure in the global economic system.

Preface

Since the introduction of the Ordinals protocol in December 2022, the market has seen the emergence of dozens of asset issuance protocols such as BRC-20, Atomicals, Pipe, and Runes, as well as hundreds of Bitcoin Layer 2 networks. The community has also been actively discussing the feasibility of Bitcoin decentralized finance (BTCFI).

In the previous crypto cycle, WBTC was created to attract Bitcoin holders to participate in DeFi. WBTC locks Bitcoin through centralized custody institutions and mints WBTC for use in Ethereum's DeFi protocols. WBTC targets Bitcoin holders willing to take on the centralization risk of cross-chain bridging to participate in Bitcoin DeFi. As a typical representative of bridging Bitcoin to the EVM ecosystem, WBTC has achieved a path for BTCFI. The EVM-based Bitcoin Layer 2 networks and DeFi projects in this cycle continue this pattern. While this pattern has given WBTC a market value of over $9 billion within the Ethereum ecosystem, this proportion is less than 1% compared to the total market value of Bitcoin, reflecting the limitations of this model.

In contrast, if Bitcoin holders can directly participate in BTCFI with Bitcoin without the need for cross-chain minting, while ensuring decentralized custody of funds, it could attract more Bitcoin users and create a broader market. This requires the implementation of Bitcoin programming under the UTXO structure. Just as mastering Solidity is crucial for entering the Ethereum DeFi, mastering Bitcoin programming is a necessary skill for entering the BTCFI market.

Unlike Ethereum contracts, Bitcoin contracts do not have computational capabilities and are more like verification programs connected through individual signatures. Although the initial application scenarios were limited, with the continuous upgrades of the Bitcoin network and the innovation of the OG community, the potential of Bitcoin programming is increasingly evident, and many research results have been transformed into BTCFI products that are about to be launched.

This article will delve into the development path of BTCFI from the perspective of Bitcoin programmability, clarify the historical and logical context of Bitcoin programming, help readers understand the actual landing scenarios of BTCFI, and how these scenarios will impact Bitcoin holders and the entire Bitcoin ecosystem.

The Foundation of Bitcoin Contracts

Satoshi Nakamoto's Thoughts: UTXO, Script Language, and Opcodes

Image Link

In 2010, Satoshi Nakamoto wrote on the Bitcoin Talk forum:

• The core design of Bitcoin will be fixed after version 0.1 is released, so I hope it can support as many transaction types as possible, but these transaction types require special support codes and data fields, and each can only cover a special case, so there are too many special cases.

• The solution to this problem is scripting. Transaction input and output parties can compile transactions into assertions (script language) that the node network can verify, and nodes verify the assertions (script language) of transactions to evaluate whether the sender's conditions are met.

• "Script" is just a "predicate." In fact, it is just an equation with a result that is either true or false. But "predicate" is a long and rare word, so I call it "script."

• The recipient of the funds will match the script template. Currently, the recipient only accepts two templates: direct payment and Bitcoin address. Future versions can add more transaction type templates, and nodes running this version or higher will be able to accept them. All nodes in the network can verify and process any new transactions and include them in blocks, even if they may not know how to read these transactions.

• This design supports various possible transaction types I designed many years ago, including escrow transactions, guarantee contracts, third-party arbitration, multi-signature, etc. If Bitcoin becomes popular, these are areas we may want to explore in the future, but they must be designed from the beginning to ensure that they can be implemented in the future.

Satoshi Nakamoto's design fourteen years ago laid the foundation for Bitcoin programming. The Bitcoin network does not have the concept of "accounts," only "outputs," which are called "transaction outputs (TXO)" and represent units of Bitcoin funds, the basic unit of the Bitcoin system's state.

Spending an output means making it an input for a transaction, or providing funds for a transaction. This is why we say that the Bitcoin system is based on the "UTXO (Unspent Transaction Output)" model, because only "UTXO" is the metal block that we can use in the transaction process. The metal block enters a furnace, and after melting, it forms new metal blocks (new UTXO), and the old metal block "transaction output (TXO)" no longer exists.

Each fund has its own locking script (also known as a script public key) and face value. According to Bitcoin's consensus rules, the script public key can form a verification program, which is the public key plus commands to execute specific operations in the script—OP-Codes. To unlock it, a specific set of data, known as the unlocking script or script signature, must be provided. If the complete script (unlocking script + locking script + OP-Codes) is valid, the corresponding output will be "unlocked" and can be spent.

Therefore, Bitcoin script programming involves programming funds to respond to specific input data. By designing script public keys, OP-Codes, and the interaction process between users, we can provide cryptographic guarantees for key state transitions in Bitcoin contracts, ensuring the contracts' proper execution.

Here is a simple diagram of a standard P2PKH (Pay to Public Key Hash) script in Bitcoin:

Image Link

For example, if I want to pay 1 BTC to Xiao Ming, I need to use a UTXO available in my wallet to form a UTXO with a face value of 100 million satoshis and place Xiao Ming's public key in the locking script of this UTXO (along with a signature verification operator). This way, only Xiao Ming's private key, as the unlocking script corresponding to Xiao Ming's public key, can unlock these funds.

In summary, Script, or script language, is a very basic programming language. It consists of two types of objects: data (such as public keys and signatures) and simple functions that operate on the data (the list of OP-Codes can be found here).

Arsenal of Bitcoin Programming

As mentioned earlier, Satoshi Nakamoto initially hoped that the Bitcoin network could support transaction types such as escrow transactions, guarantee contracts, third-party arbitration, and multi-signature. So, how are these tools implemented, and how are they used in BTCFI?

Multi-Signature (MULTISIG)

• Its locking script form is M PUB-1> PUB-2> … PUB-N> N OP_CHECKMULTISIG, meaning it records n public keys and requires m of these public keys' signatures to unlock the UTXO.
• For example, a script with the code 2 Alice> Bob> Chloe> 3 OP_CHECKMULTISIG means that any two of the three people (or public keys) Alice, Bob, and Chloe can sign to spend this script. OP_CHECKMULTISIG verifies if the signature matches the provided public keys.
• Use cases include:
  1. Personal and corporate fund management: Setting up a 2-of-3 multi-signature wallet means that only two of the three parties need to agree to use the funds, preventing malicious behavior by wallet manufacturers, as funds can only be accessed with the collusion of m manufacturers.
  2. Transaction arbitration:
     • For example, if Alice and Bob want to make a transaction, such as purchasing Ordinals NFT, but cannot conduct a direct exchange of money and goods, they can lock the funds in a multi-signature output. When Bob receives the Ordinals NFT from Alice, he can then fully pay Alice. To prevent the situation where Bob receives the goods but does not pay, a third party can be involved, forming a 2-of-3 multi-signature output. In case of a dispute, the third party can arbitrate. If the third party believes that Alice has delivered the goods, they can help Alice transfer the funds.
     • By publicly sharing their public key (e.g., if they are an oracle), the two parties can include the third party in a 2-of-3 multi-signature script without the third party's knowledge. However, there is a risk that the third-party oracle can decide the specific outcome of the contract. The cautious log contract (DLC) mentioned later has optimized this aspect, making it suitable for Bitcoin lending and other BTCFI scenarios.

Time Locks

Time locks control the validity of transactions and when an output can be spent, making them essential tools in Bitcoin script programming for scenarios such as staking, collateral, and borrowing in BTCFI. Developers need to choose between using relative time locks (nSequence) or absolute time locks (nLocktime):

• Absolute time locks (nLocktime): This type of lock ensures that a transaction is only considered valid after a specific time, allowing it to be included in a block. At the script level, an absolute time lock is represented by the OP_CLTV opcode, which verifies that the UTXO can only be spent after a certain time, such as after block height 400,000.
• Relative time locks (nSequence) indicate that a transaction is only valid after a certain period following the confirmation of the transaction that created the UTXO (i.e., the previous transaction). At the script level, a relative time lock is represented by OP_CSV, such as "this money can only be spent after 3 blocks have been confirmed."

Hash Locks (Hash Preimage Verification)

In addition, there are hash locks (hash preimage verification) combined with hash time locks, which are often used in Bitcoin staking and restaking:

• The locking script form of a hash lock is OP_HASH160 hash> OP_EQUAL, which verifies that the data in the unlocking script is the preimage of the hash in the locking script.
• Hash time lock contracts (HTLC): If the recipient cannot provide the preimage of a hash within a certain time, the funds can be reclaimed by the payer.

Flow Control (Parallel Unlock Conditions)

The OP_IF opcode can arrange multiple unlocking paths in the locking script, allowing the UTXO to be spent if any of the conditions are met. The hash time lock contract mentioned earlier also uses this type of flow control opcode.

After the taproot upgrade, the Merkelized Abstract Syntax Tree (MAST) feature allows different unlocking paths to be placed in different Merkel tree leaves. Babylon's BTC staking transactions also use MAST, improving transaction efficiency and privacy. This will be described later.

SIGHASH Attached Information Signatures

Bitcoin transactions allow the use of SIGHASH tags during signing, which specify additional conditions for the validity of the signature. These tags allow us to modify parts of the transaction without invalidating the signature, expressing the signer's expectations or delegation of the signature's purpose. For example:

• SIGHASH_SINGLE | ANYONECANPAY signs the input and the output using the same index number as the input. The rest of the inputs and outputs can be changed without invalidating the signature. This allows anyone willing to exchange a certain amount of tokens for 1 BTC to complete the transaction and have it included in the blockchain.

Other examples include Schnorr signatures after the taproot upgrade, which can be used in cautious log contracts (DLC).

Limitations of Bitcoin Programmability

The basic pattern of Bitcoin programming involves locking scripts indicating verification conditions, unlocking scripts providing data, and OP-Codes in the locking script specifying the data verification program (such as signature verification, hash preimage verification, etc.). Through the verification program, funds can be spent. The core limitations are:

1. The available verification programs are limited: Implementing zero-knowledge proofs or other verification programs requires a fork. Therefore, the BTCFI extension solution Fractal introduced by Unisat, while keeping BTC 100% consistent, has partially separated from the Bitcoin mainnet in terms of liquidity and security in order to implement "controversial" OP_CAT, ZK native verification OPCode, and other "controversial" opcode proposals.

2. Bitcoin script lacks computational capabilities: Once funds are unlocked, any path can be used to access all funds, and the spending of funds cannot be restricted after unlocking. This also means that it is difficult to use floating interest rate schemes in BTCFI lending projects, and only fixed interest rates can be used. To address this issue, the Bitcoin community is discussing the implementation of "covenants," which can further restrict the spending of transactions and unlock more BTCFI applications. Taproot Wizard's BIP-420 and OP_CAT, OP_CTV, APO, OP_VAULT, and others are related to this.

3. The unlocking conditions of UTXOs are completely independent: One UTXO cannot determine its own unlocking based on the existence of another UTXO and its locking conditions. This issue frequently arises in BTCFI collateral lending and staking. Partially Signed Bitcoin Transaction (PSBT), described later, is used to address this issue.

Adjustments and Evolution of Bitcoin Contracts

Compared to Ethereum contracts based on computation, Bitcoin contracts are based on verification. This stateless contract has brought many difficulties to the development of BTCFI products. In the more than ten years of development of Bitcoin contracts, the clever use of cryptographic algorithms and signatures has greatly improved privacy, efficiency, and decentralization, making the productization of BTCFI applications possible.

Discreet Log Contracts (DLC): Solving the Decentralized Liquidation Issue in BTCFI Scenarios

When lending, options, and futures contracts need to be settled based on the price provided by an oracle, it is inevitable that the right to operate the user's assets needs to be retained, which undoubtedly creates a trust cost for users to trust that the protocol will not act maliciously.

Discreet Log Contracts (DLC) were introduced to solve this problem. It uses a cryptographic technique called adaptor signatures, allowing Bitcoin scripts to program financial contracts that depend on external events and fully ensure privacy.

It was proposed by Tadge Dryja (research scientist) and Gert-Jaap Glasbergen (software developer) at the Massachusetts Institute of Technology's (MIT) Digital Currency Initiative in 2017 and publicly demonstrated on March 19, 2018.

Adaptor signatures allow a signature to become valid only after adding a private key. The Schnorr signature introduced in the taproot upgrade is an example of an adaptor signature.

In simple terms, the standard form of a Schnorr signature is (R, s). Given (R, s'), as long as the secret value (x) is known, the signature can be made valid by setting s = s' + x, resulting in (R, s).

Here's a simple example to explain its application:

• Alice and Bob bet on opposite outcomes of a sports match (assuming no draw) and each bet 1 BTC. The winner will receive the entire 2 BTC bet. They lock the bet in a multi-signature wallet, which requires multi-party signatures to release the funds.
• They choose an oracle, which will announce the result of the match (usually this information is found off-chain, such as on exchanges and match websites).
• The oracle does not need to know any details about the bet, or even who is involved in the DLC. Its role is strictly limited to providing the result. Once the event occurs, the oracle will publish an encrypted proof called a commitment, indicating that it has determined the result of the event.
• To claim the funds locked in the multi-signature wallet, the winning party, Alice, uses the secret value provided by the oracle to create a valid private key, allowing her to sign the transaction to spend the funds.
• The transaction is added to the Bitcoin blockchain for settlement. At this point, because the signature is a regular signature, it is not apparent that this is a DLC. This is completely different from other common multi-signature patterns—where the contract's contents are fully disclosed, and the oracle participates in decision-making.

Image Link

Liquidation Mechanism of Lending Protocols

Suppose Alice uses $ORDI as collateral to borrow 0.15 BTC. The loan position will only change to a pending liquidation state if the oracle's price for $ORDI falls below 225,000 sats/ordi. DLC allows the liquidator to liquidate the position without permission while ensuring that they cannot operate the user's collateral assets until the price reaches the liquidation price. In this scenario, Alice essentially makes a bet with the lending protocol on the price of $ORDI:

• If the price is below 225,000 sats/ordi, the protocol can obtain all of Alice's collateral and assume the corresponding BTC debt.
• If the price is equal to or greater than 225,000 sats/ordi, nothing happens, and the asset ownership remains unchanged.

Therefore, we need the oracle to commit to signing s_c_1 for the result when the price is below 225,000 sats/ordi using a nonce R_c:

• Alice and the protocol only need to create a commitment transaction for this result, creating an adaptor signature (R, s') instead of a signature (R, s). This means that the signatures given to each other are not directly usable to unlock the contract and require the revelation of a secret value. This secret value is the preimage of s_c_1.G, which is the oracle's signature. Because the oracle's signature nonce value is already determined, s_c_1.G can be constructed.
• When the price is below 225,000 sats/ordi, the oracle will publish the signature (R_c, s_c_1), allowing the protocol to complete the opponent's adaptor signature, add its own signature, make the transaction valid, broadcast it to the network, and trigger the settlement effect.
• Conversely, if the price is not below 225,000 sats/ordi, the oracle will not publish s_c_1, and the commitment transaction will not become a valid transaction.

Fundamentally, DLC allows users and protocols to use the Bitcoin blockchain to make agreements, locking funds in multi-signature addresses to construct DLC scripts. These funds can only be used and redistributed according to certain rules when the oracle publishes specific information at a specified time.

In this way, lending protocols can use DLC to implement a decentralized liquidation mechanism without the need for user trust in any entity.

The role of Oracles

Oracles in DLC are used to provide fixed-frequency price feeding services and also participate as a third party in the secret value generation and public process in the DLC mechanism.

Currently, there are no standardized products for DLC oracles. The main development of DLC modules is in lending protocol research, while standardized oracles such as Chainlink perform off-chain data feeding functions. However, with the launch and continuous development of lending protocols based on DLC, many existing oracle projects are also exploring how to develop DLC oracles.

Partially Signed Bitcoin Transactions (PSBT): Implementing Trustless Multi-Party Transactions in BTCFI Protocols

PSBT comes from the Bitcoin standard BIP-174, which allows multiple parties to sign the same transaction in parallel, and then merge the corresponding PSBTs to form a complete signed transaction. These multiple parties can be protocols and users, buyers and sellers, pledgers and pledging protocols, so any BTCFI application involving multi-party fund exchange scenarios can use PSBT. The majority of existing BTCFI projects use this technology.

Alice, Bob, and Charlie have funds in a 2-of-3 multi-signature. They want to withdraw the funds and split them into 3 parts. All three of them must sign the same transaction to spend this UTXO. Assuming they do not trust each other, how can they ensure the security of the funds?

Image Link

• First, Alice, as the creator, initiates a PSBT transaction with the multi-signature UTXO as input and outputs to the wallets of the three individuals. Since PSBT ensures that no transaction other than the one being signed can call any one person's signature, Alice can sign it and send it to Bob.
• Similarly, after Bob checks the PSBT and finds no issues, he signs it and sends it to Charlie for signing and transaction broadcasting. Charlie performs the same operation.

Therefore, the meaning of partially signed is that each person only needs to check the part of the transaction related to them, ensuring that as long as the part of the transaction related to them is correct, there will be no issues once the transaction is confirmed on the blockchain.

On March 7, 2023, Yuga Labs' Ordinals NFT auction adopted an extremely centralized custody auction model. During the auction, all bidding funds were required to be deposited into Yuga's address for custody, posing a serious threat to the security of the funds.

Image Link

Users in the Ethereum ecosystem pointed out that Yuga's auction event precisely illustrates the importance of ETH smart contracts. However, the developers of Ordinals also responded: trustless quote transactions based on PSBT are very useful and can facilitate fund trustless transactions between NFT buyers and Yuga Labs.

Suppose there are now two Bitcoin NFT traders, and the public key of the NFT seller is known to both parties. When initiating an NFT transaction, the buyer first writes their UTXO input and an output for receiving the NFT in the transaction. After constructing and signing the transaction, the buyer converts it to a PSBT and sends it to the seller. Upon receiving the message, the seller signs through the protocol, and the Bitcoin NFT transaction is completed.

The entire process is completely trustless for both the buyer and the seller. For the buyer, the bid, receiving address, and other information are already built into the transaction. Any changes will invalidate the signature. For the seller, the NFT will only be sold after their signature, and the price is determined by them.

Taproot Upgrade: Opening the Pandora's Box for the Bitcoin Ecosystem and BTCFI Explosion

The Taproot upgrade was activated in November 2021, aiming to enhance Bitcoin's privacy, improve transaction efficiency, and expand Bitcoin's programmability. Through the implementation of Taproot, Bitcoin can host large-scale smart contracts with tens of thousands of signers, while concealing all participants and retaining the scale of a single signature transaction, making more complex on-chain BTCFI operations possible. Almost all BTCFI projects have adopted the script language of the Taproot upgrade.

1. BIP340 (BIP-Schnorr): Supports multi-party signing of single transactions, as well as the previously mentioned requirement for specific conditions to execute a transaction in Discreet Log Contracts (DLC) applications. The data committed to Bitcoin is the same as the standard single signature transaction data.

Image Link

2. BIP341 (BIP-Taproot): Taproot introduces the Merkle Abstract Syntax Tree (MAST), committing less contract transaction data to the chain, allowing Bitcoin to create more complex contracts. Unlike existing Pay to Script Hash (P2SH) transactions, MAST allows users to selectively disclose parts of the script as needed, enhancing privacy and efficiency. MAST has also been effectively used in Babylon's BTC staking transactions, combining multiple locking scripts into a transaction containing multiple scripts, including:

• TimeLockScript: Time lock, implementing the lock-up function of staking.
• UnboundingPathScript: Unstaking, implementing the early termination of staking.
• SlashingPathScript: Penalty, implementing punishment for system misconduct.

All are leaf nodes, starting from the leaf nodes and gradually constructing a binary tree as shown below.

Image Link

3. BIP342 (BIP-Tapscript): Provides an upgraded transaction programming language for Bitcoin, leveraging Schnorr and Taproot technology. Tapscript also allows developers to more efficiently implement future Bitcoin upgrades.
4. Laying the Foundation for the Ordinals Protocol:

• The Taproot upgrade also introduced Taproot (P2TR) addresses, starting with bc1p, allowing metadata to be written into the spent script stored in the Taproot script path, but it never appears in the UTXO set.
• Since maintaining/modifying the UTXO set requires more resources, this approach can save a significant amount of resources and increase block storage data volume — meaning there is now space to store images, videos, and even games — inadvertently making the deployment of Ordinals possible. The commonly used inscription address is the Taproot (P2TR) address.
• Because the spending of Taproot scripts can only occur from existing Taproot outputs, Ordinals adopts a two-stage commitment/reveal process for minting. First, in the commitment transaction, a Taproot output is created that commits to the script containing the inscription content. Then, in the reveal transaction, the transaction is initiated by using the UTXO corresponding to that inscription as input. At this point, the corresponding inscription content is publicly revealed to the entire network.
• Ordinals BRC-20, ARC-20, Runes, and other new assets have also maintained a transfer adoption rate of around 70% for Taproot.

Ordinals and Brc20: Creating a Batch of Blue-Chip Assets for BTCFI and Opening the Door to Indexer-Based Programming

Ordinals has fulfilled the desire of Bitcoin OG to buy, buy, buy on the Bitcoin mainnet, and its popularity and market value have already surpassed Ethereum NFT.

• Ordinals was proposed in January 2023 by Bitcoin core contributor Casey Rodarmor. Its core is ordinal theory, aiming to give the smallest unit of Bitcoin — sats — a unique identifier and attributes, transforming it into a unique non-fungible token (NFT). By inscribing diverse data (images, text, videos, etc.) into sats, the Ordinals protocol enables the creation and trading of Bitcoin NFTs.
• This process not only increases the utility of Bitcoin but also allows users to directly create and trade digital assets on the Bitcoin blockchain. The permanent value lies in the fact that since Ordinals is created based on Bitcoin sats, its underlying value is linked to Bitcoin itself and theoretically will not go to zero.

BRC-20 is a token system that records on-chain and processes off-chain, deploying token contracts, minting, and transferring tokens using ordinal inscription of JSON data.

• It treats the inscription as an on-chain ledger to record the deployment, minting, and transfer of BRC-20 tokens.
• In settlement, off-chain queries are required, relying on third-party indexing tools to retrieve Bitcoin blocks, recording all deployments, minting, and transfer operations of BRC-20 tokens to ultimately query the final balance of BRC-20 tokens for each user. This may lead to different platforms having different results for the balance of a specific account.

Ordinals and Brc20 not only provide the demand for trading and blue-chip assets for BTCFI but also offer a new approach for many BTCFI projects based on indexer-based programming, allowing for the enhancement of Bitcoin contract capabilities. The combination of the "op" field in JSON can further evolve into inscription-based DeFi, and even socialfi and gamefi, including AVM, tap protocol, brc100, unisat's swap function, and many projects proposing to create a smart contract platform on the Bitcoin layer are using indexer-based programming solutions.

MuSig2: Decentralized Mode for Bitcoin Restaking and LST

Multi-signature schemes allow a group of signers to produce a joint signature on a message. MuSig allows multiple signers to create an aggregate public key from their respective private keys and then jointly create a valid signature for that public key. It is an application of Schnorr signatures, as mentioned earlier, the standard form of Schnorr signatures is (R, s), given (R, s'), as long as the secret value (x) is known, it is possible to make s = s' + x, obtaining (R, s). The private key plus a random nonce value is also used to generate the aggregate public key and valid signature.

The MuSig2 scheme only requires two rounds to complete a multi-signature, and the aggregate public key created in this way cannot be distinguished from other public keys, enhancing privacy and significantly reducing transaction fees. The Taproot upgrade is compatible with the Musig2 multi-signature scheme, and its BIP proposal was published in Bitcoin BIP-327: MuSig2 for BIP340-compatible Multi-Signatures in 2022.

• Liquidity staking on Ethereum can be achieved through smart contracts, but Bitcoin lacks the contract capabilities needed for liquidity staking. As mentioned earlier, Bitcoin whales generally dislike centralized custodians and need MuSig2 to achieve decentralized Bitcoin liquidity staking. Here, we use the example of Shell Finance's solution:

1. Users and Shell Finance calculate an aggregate public key and the corresponding MulSig2 multi-sign address P based on private key data and two nonce random numbers generated by the wallet.
2. Shell Finance constructs a PSBT transaction, and the user and Shell Finance stake assets from the MuSig2-supported multi-sign address P into Babylon, with the wallet providing nonce random number support again, passed into the aggregate public key corresponding to the multi-sign address.
3. When the Babylon staking period ends, Shell Finance constructs a PSBT unlock transaction, and the user and Shell Finance jointly sign to unlock the staked assets.

A third-party wallet that generates the nonce random number, the staking user, and the LST project jointly create the aggregate public key and signature. In this process, both the user and the project can only hold one private key, and without the nonce value, they cannot generate the aggregate public key and signature to retrieve the funds. The wallet cannot access the funds without the private key. If the nonce value is generated by the project itself, there is a risk of misconduct, which users need to be aware of.

Unpublished technical document: No public source

Current Landing Applications of BTCFI

Bitcoin programming is not complicated; it is even much simpler than languages like Rust. The focus is on creating verifiable, trusted commitments and providing superior technical security compared to Ethereum, which sets the boundaries for BTCFI development. The most challenging part is what kind of BTCFI products can be developed within these boundaries that align with PMF (project market fit). Just like when Ethereum's Solidity contract was first introduced, developers did not know they could use it to develop the x*y=k AMM algorithm, but instead chose to explore directions such as ICOs, order books, and peer-to-peer lending.

Liquidity Booster: Babylon — The Catfish in BTCFI

Babylon has built a completely trustless staking protocol without intermediaries, allowing direct staking of Bitcoin on the first layer and earning interest, while also extracting Bitcoin security and sharing it with POS chains as a universal shared security layer, providing POS security guarantees for cosmos and other Bitcoin layer 2 solutions, sharing Bitcoin economic security.

• Absolute Security: Compared to other forms of staking, BTC staking has a significant advantage in that when the protected POS chain is attacked and collapses, the impact will not affect the staked Bitcoin. Specifically, if a POS chain is attacked, resulting in the token value going to zero, users holding tokens of that POS chain will face losses. However, in the case of BTC staking, even if the protected POS chain is attacked and fails, the user's staked Bitcoin principal remains safe and intact.
• Forfeiture Mechanism: If a user engages in malicious behavior such as double-signing on a PoS chain secured by Babylon, the assets can be unlocked using EOTS (extractable one-time signatures) and a portion of the assets will be forcibly sent to a burn address by the network's execution role.

Image Link

The Babylon mainnet is already live and has completed the first phase of 1,000 BTC staking, with the second phase set to launch soon.

​​

Image Link

Currently, the first phase of BTC staking is dominated by large holders, with gas fees accounting for 5%. There may be more retail investors joining in the second and third phases.

Attracting a Large Amount of BTC for the First Time in BTCFI Staking:

• Although Babylon cannot provide the underlying ETH-based returns of POS itself like Ethereum, for some who prioritize security over high expected returns and are unwilling to accept cross-chain wrap solutions, as well as for passive Bitcoin whales, and European and Asian funds bullish on the Bitcoin ecosystem, an APY of 3-5% is still attractive. With a total deposit of 100,000 BTC, only over $100 million in equivalent token income is needed to meet the demand.
• The Cosmos ecosystem actively cooperating with Babylon includes well-known projects such as Cosmos Hub, Osmosis, Injectiv, which may become AVS in the future and provide their tokens as rewards for Bitcoin restakers, further expanding Babylon's BTC deposit limit.

Babylon Injects a Large Amount of Liquidity into BTCFI Ecosystem, Educates Users, and Sparks Ecosystem Vitality

• The Ethereum ecosystem has previously seen successful narratives similar to DeFi and Layer2 with Restaking. Babylon is the first to enable staking and earning interest on the Bitcoin mainnet, allowing most Bitcoin holders to experience BTCFI for the first time. In addition, they may also experience LST and other gameplay options.
• In the Babylon ecosystem, the LST track alone has seen the emergence of dozens of projects such as StakeStone, Uniport, Chakra, Lorenzo, Bedrock, pSTAKE Finance, pumpbtc, Lombard, Solvbtc, and many other DeFi projects. For Bitcoin ecosystem projects struggling to obtain initial TVL, they can leverage the power of Babylon's BTC Staking to attract a batch of BTC, and their LST assets can be used in their own ecosystem business.
• Since the income generated by Babylon is in the form of tokens rather than priced in BTC/ETH, it limits the attraction for giants. The overall landscape will not be as centralized as ETH staking, and early-stage startups have the opportunity to seize the market due to the uncertain profits that their tokens can generate.

The Bitcoin Mainnet is Expected to Produce Multiple Blue-Chip LST Assets, Driving BTCFI Demand

Babylon has opened up a new track for native BTC staking and interest earning, allowing the previously dormant mainnet BTC, with a scale of hundreds of billions, to have a large-scale application scenario for the first time. A large amount of staked BTC has generated a large number of liquidity staking tokens, which can serve as natural blue-chip collateral for scenarios such as collateralized lending, stablecoins, and swap, thereby providing conditions for the development of BTCFi based on native Bitcoin assets.

• The core reason why BTCFi has been difficult to develop is the lack of high-quality assets on the Bitcoin mainnet, directly leading to a lack of collateral for lending, a lack of demand for swap, and shallow liquidity pools. Currently, the blue-chip assets in the Bitcoin ecosystem are only sats and ordi in brc20, as well as node monkey in ordinals NFT.
• However, if a portion of the staking volume in Babylon can generate liquidity staking tokens, similar to the issuance of steth by Lido on Ethereum, it can serve as collateral for lending platforms such as Aave and Compound, and create high trading depth on Uniswap, providing development conditions for BTCFi.
• Imagine that many stakers may want to borrow BTC through liquidity staking tokens, or use them for nested staking, or for risk hedging.

Innovative Asset Issuance: Unisat and Magic Eden, Two Major DEXs, Set to Launch

Image Link

Image Link

• The brc20 swap on Unisat will go live in September, and by mapping Runes to brc20 to support Renes, it will be possible to issue and trade tokens by adding liquidity pool methods, without the need to mint tokens by raising gas fees or trading tokens inscription by inscription, enabling batch trading.
• Magic Eden's runes dex will also go live in Q4 this year.

Fully BTC-native Point-to-Pool Lending Stablecoin Protocol Set to Launch

Liquidium is a lending platform completely built on the Bitcoin mainnet, implementing lending through partial signature Bitcoin transactions (PSBT) mentioned earlier and cautious log contract DLC. Specifically:

• Lenders fill out offers, including LTV (debt amount/collateral ratio), interest, floor price, and deposit Bitcoin.
• Borrowers select lenders based on offers on the platform and deposit NFT or Runes assets.

It went live in October 2023 and achieved a trading volume of 2227 BTC in less than a year, indicating the existence of demand for BTCFI lending on the Bitcoin mainnet assets.

Image Link

The core issues are:

1. Low Capital Utilization Efficiency: If there are no borrowers actively accepting offers, the lender's Bitcoin remains idle. Each time an order is canceled or placed, it incurs fees. In other words, it does not have order matching functionality and involves a discovery process.
2. Peer-to-Peer Settlement: The only parties involved in settlement are the borrower and lender, with no involvement of others.

• Once NFT or RUNES falls below the borrowing value at LTV, if the borrower does not repay, the offer provider can only receive NFT or RUNES, effectively bearing the risk of the decline.
• From another perspective, as long as the borrower's NFT or RUNES falls, they either repay immediately or lose the NFT or RUNES, which is also unfair to the borrower.
• To prevent borrowers from not repaying, the loan term can only be limited to a little over ten days, with a very high APY.

Image Link

Perhaps this is why AAVE's predecessor, Ethlend, struggled to sustain development. Peer-to-peer lending is simply too difficult to achieve continuous scalability.

Shell Finance maximizes liquidity in lending and settlement scenarios using the synthetic stablecoin $bitUSD, achieving point-to-pool lending for Bitcoin and creating a positive feedback loop for borrowing and repayment with $bitUSD, potentially leading to strong economies of scale in the future.

In the process of settlement and trading, DLC and PSBT are also used for collateral and fund management without custody and decentralized settlement. Specifically:

• Borrowers can pledge Ordinals NFT, BRC-20, and Runes assets on the platform (future support for other assets on the Bitcoin layer such as assets issued by Arch network and assets mapped by RGB++), and borrow the synthetic asset $bitUSD.
• Build a BTC/BitUSD trading pair liquidity pool in unisat and magic eden's swap, allowing borrowers to exchange the synthetic asset $bitUSD for BTC. LPs can earn transaction fee income from the borrower's exchange.
• When repaying, borrowers need to return BitUSD to the protocol, creating a demand to exchange BTC for BitUSD.

Image Link

During settlement, the focus is on clearing BitUSD, and anyone can participate in the settlement of pending positions. When a vault is liquidated, the liquidator needs to pay off the debt and retrieve the corresponding collateral assets, with the difference between the collateral assets and the market net value being the liquidator's profit. Taking a loan of 600 $BitUSD with a collateral of 30 $ORDI as an example, the liquidation process mainly follows the following steps:

1. When the price drops below 28.5 USD, the LTV falls below 80%. Therefore, the position reaches the liquidation line and enters a liquidation state.
2. For the current collateral asset value of 855 USD, a Dutch auction for the position will be initiated for a period of 48 hours. Bidders need to provide $BitUSD to acquire the pending liquidated asset, with a starting price of 855 BitUSD and a final price of 600 BitUSD, with the auction price linearly decreasing over time.
3. When the liquidator participates in the liquidation through the Dutch auction, they input 700 BitUSD priced by the auction. After deducting the 600 BitUSD debt to be repaid, Shell Finance will include the remaining 100 BitUSD in the insurance fund.
4. After checking the liquidator's transaction information, Shell Finance adds the collateral assets to the PSBT, and the liquidator can obtain the collateral of 30 Ordi from the vault.
5. Shell Finance triggers the oracle to reveal the "Secret" value, which can complete the signatures of the participants (borrower and protocol), thereby executing the operation to transfer the collateral from the vault to the liquidator's address. The price oracle will automatically close the corresponding DLC process.

Image Link

It is also evident that Shell Finance can facilitate batch borrowing with an APY of only 10%, supporting longer-term borrowing.

As mentioned earlier, Shell Finance is also using MuSig2 to create Bitcoin LST, using LST assets as a new form of collateral, further expanding the application wheel of BitUSD and increasing the project's limit.

A Batch of BTCFI Expansion Solutions Based on UTXO Goes Live

The Bitcoin community generally believes that EVM-based BTC Layer2 innovations are innovative but have low limits. However, to explore more complex BTCFI, stronger Bitcoin contracts are needed. Many Bitcoin developers have introduced native, UTXO-based expansion solutions, categorizing them based on whether they settle on the Bitcoin mainnet:

• If they settle on the Bitcoin mainnet, they can reuse the mainnet's liquidity and directly support assets such as Runes without the need for cross-chain compatibility.
• If they do not settle on the Bitcoin mainnet, they require cross-chain asset deposits.

BTCFI Expansion Solutions Settling on the Bitcoin Mainnet

Arch Network: Core Expansion of Computing Power, Off-Chain ZKVM to Build Smart Contract Network

Arch utilizes a decentralized network of validator nodes and an off-chain, Turing-complete zero-knowledge virtual machine (zkVM) outside the Bitcoin mainnet, which can integrate with the Bitcoin mainnet, allowing it to share liquidity with the Bitcoin mainnet and integrate protocols for assets such as Runes:

• ZKVM: After each smart contract execution, Arch's zkVM generates ZK proofs, which are used to verify the correctness and state changes of the contract.
• Decentralized Network: The generated ZK proofs are subsequently verified by Arch's decentralized validator node network. This network plays a crucial role in maintaining the integrity and security of the platform. By relying on a decentralized architecture, Arch is committed to ensuring that the verification process is not only secure but also resistant to censorship and central point failures.
• Integration with Bitcoin Layer 1: Once the ZK proofs are verified, the validator network can sign unsigned transactions. These transactions, including state updates and asset transfers determined by application logic, ultimately return to Bitcoin. This final step completes the execution process, and all transactions and state updates are directly confirmed on the Bitcoin blockchain.
• UTXO Model: Arch's state and assets are encapsulated in UTXOs, with state transitions achieved through the concept of single-use. The state data of smart contracts is recorded as state UTXOs, while the original asset data is recorded as Asset UTXOs. Arch ensures that each UTXO can only be spent once, providing secure state management.

DeFi applications that hope to be compatible with Bitcoin mainnet assets (such as lending and decentralized exchanges) can be built on Arch.

Image Link

AVM: Implementing BTCFI Representation through Indexer-Oriented Programming

AVM provides Atomicals with an advanced execution environment for handling smart contracts and dApps, equipped with a custom instruction set to enhance performance, reduce gas fees, optimize state transitions, increase parallel processing capabilities, and improve throughput and scalability. AVM also achieves interoperability and cross-chain communication.

• Sandbox execution environment, where the entire simulator operates in a controlled isolation environment, ensuring that execution within the sandbox does not interfere with external execution.
• State hash, allowing participants to verify the correctness and synchronization of their indexer's state, preventing potential attacks due to inconsistent states.

AVM enables the Atomicals protocol to perform various BTCFI tasks, not limited to the previous simple token issuance mechanism.

BTCFI Expansion Solutions Based on UTXO Binding but Not Settling on the Bitcoin Mainnet

Fractal Bitcoin: Parallel Expansion of BTCFI System Using Existing Bitcoin Architecture

Image Link

Fractal Bitcoin is a self-replicating expansion method that encapsulates the entire Bitcoin Core into a deployable and runnable blockchain software package called Bitcoin Core Software Package (BCSP). It can independently run one or multiple instances of BCSP and associate with the Bitcoin mainnet through recursive anchoring.

Fractal produces a block every 30 seconds, making it approximately 20 times faster than the Bitcoin mainnet, supporting and compatible with all protocols on the main chain (such as Ordinals and brc-20) at the same physical settlement rate as the main chain. Miners on the mainnet can mine a Fractal block every 90 seconds. Meanwhile, Fractal retains the optional ability to settle and anchor on the mainnet through encryption.

• Fractal is relatively consistent with the main chain consensus, making it easy to interoperate at the protocol level.
• It breaks free from the physical constraints and historical baggage of the main chain, removing some code that was once meaningful but no longer relevant in history. While retaining complete consensus, the system's implementation has been streamlined, resulting in a more concise and lightweight implementation.
• It will implement OP_CAT and other opcode proposals faster than the BTC mainnet, aligning with the basic path of Bitcoin upgrades but at a faster pace, potentially implementing encrypted BTCFI contracts through scripts in the future.

Image Link

Mining Incentive Model

50% of Fractal's tokens are produced through mining, with 15% allocated to ecosystem projects, 5% to investors, and 20% to advisors and core contributors. The remaining 10% is used to establish partnerships and liquidity, showing its close relationship with miners.

Fractal innovatively adopts a mining method called "rhythm mining," where 2/3 of the blocks are freely mined, and 1/3 are mined through joint mining. ASIC miners and mining pools can mine both the Bitcoin mainnet and Fractal using existing mining machines, incentivizing miners with Fractal Bitcoin rewards and utilizing their computing power to protect the network from potential 51% attacks.

Ecosystem Progress

Fractal Bitcoin's mainnet will launch on September 9th, and the ecosystem already includes multiple NFT projects such as Fractal Punks, honzomomo, Nodino, FractalStone, Fractal Puppets, MEBS, asset issuance platform satspump.fun, AMM pizzaswap, blockchain game infrastructure UniWorlds, and NFT generation platform InfinityAI.

Fractal Bitcoin will directly activate OP_CAT upon mainnet launch. The combination of OP_CAT and Fractal's high capacity will enable the implementation of complex Bitcoin applications.

In terms of asset migration, BTC and other mainnet assets can exist as brc-20 wrapped assets on Fractal Bitcoin.

Image Link

In summary, while the Bitcoin mainnet focuses on high-value assets, Fractal Bitcoin serves as a storage ground for less significant assets, providing a fertile ground for asset and application innovation. However, whether Fractal Bitcoin can produce blue-chip assets and high-quality applications remains to be seen.

RGB++: Developing Unique BTCFI Based on UTXO Model

RGB++ utilizes a Turing-complete UTXO chain (such as CKB or other chains) as a shadow chain to handle off-chain data and smart contracts, further enhancing the programmability of Bitcoin.

The UTXO of the shadow chain is isomorphically bound to the UTXO of Bitcoin, ensuring consistency of state and assets between the two chains, thus ensuring security. Therefore, RGB++ can support assets such as Runes on the Bitcoin mainnet, and RGB++ assets can also be directly mapped to the Bitcoin mainnet and extended to all Turing-complete UTXO chains.

Image Link

RGB++ fully leverages the advantages of the UTXO model and can achieve many unique BTCFI functions:

• Cross-chain Leap without bridges through UTXO isomorphic binding: Assets on RGB++ can freely transfer between the Bitcoin mainnet and L2 or L2, without relying on the traditional cross-chain bridge Lock-Mint paradigm. This approach can mitigate many risks associated with traditional cross-chain bridges and has significant advantages in cross-chain response speed and liquidity aggregation, providing great convenience for the DeFi ecosystem.
• UTXO transaction model is well-suited for intent-driven transaction scenarios: Simply sign and submit the desired input and output information in a transaction to complete the verification on the chain. For example, UTXO inputs and an output for asset purchase can be used to bid for asset transactions, without needing to worry about the intermediate transaction details.
• UTXOSwap is already live on the mainnet: The user experience is almost identical to Uniswap. UTXOSwap divides each transaction into two steps: users submit their intent to the chain in the first step, and in the second step, the Aggregator aggregates everyone's intent, initiates a transaction, and interacts with the liquidity pool.
• UTXO has a mechanism for nesting contract scripts, allowing for the generation of a series of consecutive transactions with a single operation, simplifying the user's transaction process: The output of the previous transaction can be directly used as the input parameter for the next transaction, enabling the rapid generation of a batch of interconnected transaction instructions.

In summary, BTC has entered the mainstream market, and its future price surge will ultimately drive the development of BTCFI.

Although we may currently feel pessimistic about BTCFI due to the current downturn in the encrypted market and Bitcoin, it is important to remember that unlike other ecosystems, it is undeniable that Bitcoin will continue to rise and attract new retail investors. Bitcoin has become a high-frequency word in this year's U.S. election, and the U.S. is likely to adopt Bitcoin as a federal reserve. Russia has legalized mining, and mainstream society is actively embracing Bitcoin. Mothers with children and every Uber driver at the Bitcoin conference in Nashville are already or preparing to become Bitcoin holders, using it as a hedge asset.

When Bitcoin breaks new highs, various Bitcoin-denominated assets in the Bitcoin ecosystem will also rise, naturally sparking market demand for BTCFI, such as using collateralized assets to borrow funds to purchase more new assets, or attempting to stake for income.

There is also an easily overlooked fact:

In the last two cycles, Ethereum assets such as ICOs and NFTs were dominant in the culture. New entrants to the crypto space may have seen celebrities entering the NFT space and chose to use Ethereum wallets like Metamask, and are accustomed to buying Ethereum for airdrops, memes, and interactions, using idle Ethereum to participate in DeFi.

In this cycle, Bitcoin has become the dominant culture. Users may have entered the space due to Bitcoin elements in the U.S. election, and may continue to enter the space as Bitcoin continues to break new highs. They may first choose to use Bitcoin wallets like Unisat and are likely to buy Bitcoin. Their idle BTC may also be used to participate in BTCFI.

Some people may think that Bitcoin should return to the narrative of digital gold, but after the Taproot upgrade and the introduction of the Ordinals protocol, new retail investors and Bitcoin OGs interested in new use cases for Bitcoin have become a powerful new force. They will be at the forefront of BTCFI innovation, continuously attracting new Bitcoin holders, and educating other major Bitcoin holders and miners.

About HTX Ventures

This article was written by the research team under HTX Ventures. HTX Ventures is the global investment arm of Huobi HTX, integrating investment, incubation, and research to identify the world's best and brightest teams. As an industry pioneer, HTX Ventures has over 11 years of experience in blockchain construction, excelling in identifying cutting-edge technologies and emerging business models in the field. To drive growth in the blockchain ecosystem, we provide comprehensive support to projects, including financing, resources, and strategic advice.

HTX Ventures currently supports over 300 projects covering multiple blockchain domains, with some high-quality projects already trading on Huobi HTX. Additionally, as one of the most active FOF funds, HTX Ventures invests in 30 top global funds and collaborates with leading global blockchain funds such as Polychain, Dragonfly, Bankless, Gitcoin, Figment, Nomad, Animoca, and Hack VC to jointly build the blockchain ecosystem. Visit us.

For investment and collaboration inquiries, please feel free to contact VC@htx-inc.com.

Disclaimer

1. HTX Ventures has no affiliations that could affect the objectivity, independence, and fairness of the projects or other third parties mentioned in this report.

2. The data and information quoted in this report are from compliant channels, and HTX Ventures considers the sources of the data and information to be reliable, and has conducted necessary verification of their authenticity, accuracy, and completeness, but does not guarantee their authenticity, accuracy, or completeness.

3. The content of the report is for reference only, and the conclusions and opinions in the report do not constitute any investment advice for relevant digital assets. HTX Ventures does not assume any responsibility for losses resulting from the use of the content of this report, unless otherwise provided by laws and regulations. Readers should not make investment decisions solely based on this report, nor should they lose their ability to make independent judgments based on this report.

4. The information, opinions, and speculations in this report only reflect the judgment of the researchers on the day the report was finalized. In the future, based on industry changes and updated data information, there is a possibility of updating viewpoints and judgments.

5. The copyright of this report belongs solely to HTX Ventures. If you need to quote the content of this report, please indicate the source. If you need to quote extensively, please inform us in advance and use within the permitted scope. Under no circumstances should the report be cited, abridged, or modified in any way that contradicts the original intent.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。