Exploring BTCFi’s rabbit hole from the perspective of Bitcoin programmability

Written by: HTX Ventures

summary

This article starts from the feasibility and evolution path of Bitcoin programming, and systematically explores the potential and challenges of Bitcoin in the field of decentralized finance (BTCFI). Bitcoin adopts the UTXO model in architecture and forms a contract system with verification as the core through its unique scripting language and opcode. Compared with Ethereum's smart contracts, the characteristics of Bitcoin contracts are "stateless" and "uncomputable", which makes them functionally limited, but also have higher security and decentralized characteristics.

With the implementation of the Taproot upgrade, Bitcoin contract capabilities have been significantly enhanced. The introduction of Taproot, especially the application of MAST and Schnorr signatures, allows 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 decentralization advantages.

On this basis, this article deeply analyzes how Bitcoin programming supports multiple BTCFI applications. Through the interpretation of mechanisms such as multi-signature, time lock, hash lock, and other mechanisms, as well as the application of tools such as DLC, PSBT, and MuSig2, the article shows the possibility of Bitcoin realizing decentralized clearing and complex financial contracts without trust. This decentralized financial system native to the Bitcoin network not only overcomes the centralized risks of the cross-chain bridge model in the WBTC era, but also provides Bitcoin holders with a more stable trust basis.

At the end of the article, the development of Bitcoin decentralized finance is not only a technological progress, but also a profound change in its ecological structure. With the emergence of new applications such as Babylon staking protocol and the launch of UTXO-native native scaling methods such as Fractal Bitcoin, BTCFI's market potential is gradually emerging. In the future, with the rise of Bitcoin prices, BTCFI will further attract the participation of mainstream users and form a new financial ecosystem with Bitcoin as the core. The formation of this ecosystem will further evolve Bitcoin from the "digital gold" narrative and become an indispensable decentralized financial infrastructure in the global economic system.

Preface

Since the launch of the Ordinals agreement in December 2022, dozens of asset issuance protocols such as BRC-20, Atomicals, Pipe, Runes, and hundreds of Bitcoin Layer 2 networks have emerged in the market. At the same time, the community is also actively exploring the feasibility of Bitcoin decentralized finance (BTCFI).

In the last crypto cycle, WBTC came into being to attract Bitcoin holders to participate in DeFi. WBTC locks and mints Bitcoin into WBTC through a centralized custody for use in Ethereum's DeFi protocol. WBTC’s target users are Bitcoin holders willing to take centralized cross-chain bridge risks to participate in Bitcoin DeFi. As a typical representative of bridging Bitcoin to the EVM ecosystem, WBTC implements a path to BTCFI. The EVM-based Bitcoin Layer 2 network and its ecosystem that appeared in this cycle also continues this model. Although this model has enabled WBTC to obtain a market value of more than US$9 billion in the Ethereum ecosystem, this ratio 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 cross-chain minting, while ensuring decentralized custody of funds, they will be able to attract more Bitcoin users and create a broader market. This requires Bitcoin programming under the UTXO structure. Just as mastering Solidity is the key to entering Ethereum DeFi, mastering Bitcoin programming is a necessary skill to enter the BTCFI market.

Unlike Ethereum contracts, Bitcoin contracts do not have computing power, and are more like verification programs connected by signatures. Although the initial application scenarios are limited, with the continuous upgrading of the Bitcoin network and the innovation of the OG community, the potential of Bitcoin programming is becoming increasingly apparent, and many research results have been transformed into the upcoming BTCFI products.

This article will explore the development path of BTCFI from the perspective of Bitcoin programmability, clarify the history and logic of Bitcoin programming, and help readers understand the actual implementation scenarios of BTCFI, and how these scenarios will affect Bitcoin holders and the entire Bitcoin ecosystem.

The basis of Bitcoin contract

Satoshi Nakamoto’s Thoughts: UTXO, scripting language and operation code

https://bitcointalk.org/index.php?topic=195.msg1611#msg16111

In 2010, satoshi, Satoshi, wrote on the bitcoin talk forum:

The core design of Bitcoin will be fixed after version 0.1 is released, so I hope it will support as many transaction types as possible, but these transaction types require special support code and data fields and can only cover one special case at a time, which will be too many special cases.

The solution to this problem is scripts. The transaction input and output party can use scripts to compile the transaction into an assertion (script language) that allows the node network to verify, and the node verifies the assertion (script language) of the transaction to evaluate whether the sender 's condition is satisfied.

" Script" is just a "predicate". In fact, it is just an equation where the result is either true or false. But predicate is a very long and rare word, so I called it "script".

The fund recipient will template the script. Currently, the recipient only accepts two templates: direct payment and Bitcoin address. More transaction type templates can be added in future versions, and nodes running that version or later will be able to receive them. All nodes in the network can verify and process any new transactions and put them into blocks, even if they may not know how to read them.

This design supports a variety of possible transaction types that I designed years ago. Including custody transactions, guarantee contracts, third-party arbitration, multi-party signatures, etc. If Bitcoin is so popular, these are areas we may want to explore in the future, but they must be designed from the beginning to ensure they can be achieved 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 "account", only "output", its full name is "transaction output" (TXO), which represents a batch of Bitcoin funds and is the basic unit of the state of the Bitcoin system.

When spending an output, it is to make this output an input to a transaction, which can also be said to provide funds for the transaction. This is why we say that the Bitcoin system is based on the "UTXO (Unspended Transaction Output)" model, because only "UTXO (Unspended Transaction Output)" is the metal block that we can use during the transaction process. The metal block enters a furnace, and after melting, some new metal blocks (new UTXO) will form, and the old metal block "Transaction Output (TXO)" will no longer exist.

Each fund has its own lock script (also called script public key) and face value. According to Bitcoin's consensus rules, the script public key can form a verification program, namely, the public key plus the command to perform a specific operation in the script - the opcode OP-Codes. In order to unlock it, a specific set of data must be provided, namely the unlock script, also called script signature (scriptSig). If the complete script (unlock script + lock script + OP-Codes) is valid, the corresponding output will be "unlocked" and can be spent.

Therefore, Bitcoin's script programming is to program funds and allow a specific amount of money to respond to the input specific data. By designing script public keys, opcodes OP-Codes, and interaction processes between users, we can provide cryptographic guarantees for the key state transitions of Bitcoin contracts to ensure the normal performance of the contract.

Here is a simple diagram of a standard P2PKH (pay to public key hash) script for Bitcoin

https://learnmeabitcoin.com/technical/script/

Suppose I want to pay 1 BTC to Xiao Ming, I need to use the UTXO that can be used in my wallet to form a UTXO with a denomination of 112 Cong, and put Xiao Ming's public key (and add the signature check operator) in the UTXO lock script. In this way, only Xiao Ming's private key is used as the signature of Xiao Ming's public key corresponding to Xiao Ming's public key to unlock the funds.

To sum up, Script, that is, scripting language is a very basic programming language. It consists of two types of objects: Data such as public key and signature + opcode - a simple function to operate data (the list of opcodes is as follows https://en.bitcoin.it/wiki/Script#Opcodes).

Bitcoin programming arsenal

As mentioned above, Satoshi Nakamoto initially hoped that the types of transactions that the Bitcoin network could support were custodial transactions, guarantee contracts, third-party arbitration, multi-party signatures, etc. So what are these weapons implemented, and how are they used for BTCFI?

Multi-party signature (MULTISIG)

• Its lock script form is M ... N OP_CHECKMULTISIG means that it records n public keys and needs to provide the signature of m public keys to unlock in order to unlock this UTXO.

• For example, the signature of two of Alice, Bob and Chloe (or three public keys) can cost this script, and its Script code is: 2 3 OP_CHECKMULTISIG, OP_CHECKMULTISIG is the opcode that verifies whether the signature matches the provided public key.

Uses include:

• Personal and corporate fund management: After setting up a 2-of-3 multi-signature wallet, funds can be used as long as two can be used. It can also prevent wallet manufacturers from committing evil. M manufacturers must conspire to withdraw funds.

• Transaction Arbitration:

• Suppose Alice and Bob want to make a transaction, such as purchasing ordinals NFTs, but cannot make one hand and deliver the goods in the same way. So they agreed to lock the money into a multi-signature output. When Bob receives the ordinals NFTs sent by Alice, he will pay the money completely to Alice. In order to prevent the situation of not giving money from receiving the goods, a third party can be introduced to form a 2-of-3 multi-signature output; when a dispute arises, a third party can be requested to uphold justice. If a third party believes that Alice has shipped the goods, it can join forces with Alice to transfer the funds.

• As long as the third party discloses its public key (for example, TA is an oracle), both parties to the transaction can use their public key in the 2-of-3 multi-signature script to join the arbitrator. Because the hash value of the script is recorded on the chain output, it can be done without the arbitrator's knowledge. However, the problem here is that the third-party oracle can determine the result of the specific contract, which has certain risks. The prudent log contract DLC mentioned later has been optimized in this regard to enable it to be truly used for BTCFI such as Bitcoin lending.

Time lock

Time locks are used to control the effectiveness of transactions and when an output can be spent. This is a Bitcoin script programming weapon used in BTCFI scenarios such as re-pled, pledged, mortgage loan, etc. Developers need to choose to use relative time locks (nSequence) or absolute time locks (nLocktime):

• Absolute time lock (nLocktime): This transaction will be regarded as a valid transaction and can only be packaged into a block after a certain time point. The absolute time lock at the script level is the OP_CLTV opcode. This UTXO can be unlocked after verification at a certain time point. For example, this money can only be spent after the block height is 400,000.

• The relative time lock (nSequence) means that after the transaction (i.e., pre-order transaction) is entered to create this UTXO for a period of time and the transaction is valid to be confirmed by blocks. The relative time lock at the script level is OP_CSV, such as this money can only be spent after 3 blocks confirmed by blocks.

Hash lock (hash original image verification)

In addition, there is a hash time lock that combines hash locks (hash original image verification), which is often used in Bitcoin staking and re-staking:

• The lock script of hash lock is OP_HASH160 OP_EQUAL , verify that the data in the unlock script is the original image of the hash value in the lock script

• Hash time lock contract (HTLC): If the party receiving the funds cannot provide a hash image within a certain period of time, the funds can be recovered by the payer.

Process control (parallel unlocking conditions)

The OP_IF opcode can arrange multiple unlocking paths in the lock script. As long as the conditions of any path are met, this UTXO can be unlocked. The hash time lock contract mentioned above also uses such a process to control the operation code.

After the taproot upgrade, the MAST (Merkelized Abstract Syntax Tree) feature allows us to place different unlocking paths into different Merkel tree leaves. Babylon's BTC staking transactions also use MAST, which improves the efficiency and privacy of the transaction, which we will describe later.

SIGHASH with information signature

Bitcoin transactions allow the use of SIGHASH tags when signing, which make additional specifications for the validity of the signature, allowing us to change parts of the transaction without invalidating the signature, expressing the signer's expectations or delegation of the purpose of the signature. for example:

• SIGHASH_SINGLE | ANYONECANPAY Signed the input and the output with the same index number as the input. The remaining inputs and outputs can be changed, and the signature will not be invalidated. Andy can sign inputs worth 1 BTC and outputs of 100 Runes tokens, so anyone willing to exchange 1 BTC for 100 Runes tokens can complete the transaction and put it on the chain.

Other examples are taproot upgraded Schnorr signatures, which can be used for discreet log contract DLC.

Limitations of Bitcoin Programmability

The basic mode of Bitcoin programming is that UTXO lock script indicates verification conditions, unlock script provides data, and the opcode in the lock script indicates the data verification program (signature verification, hash image verification, etc.). Through the verification program, funds can be spent. The core limit is:

1. There are only a few available verification programs: implementing zero-knowledge proof or other verification programs requires forking. Therefore, although Fractal, the BTCFI expansion solution launched by Unisat, is 100% consistent, in order to implement OP_CAT, ZK native verification OPCode and other "controversial" opcode proposals are also separated from the Bitcoin main network in terms of liquidity and security.

2. Bitcoin scripts do not have computing power: as long as funds can be unlocked, all funds can be used using any path. The way funds are spent cannot be limited after unlocking, which also means that it is difficult to use floating interest rates in BTCFI lending projects, and only fixed interest rates can be used. To solve this problem, the Bitcoin community is discussing the implementation of "covenants", which can unlock more BTCFI application scenarios through the limitations on the transaction. The BIP-420 mentioned by Taproot Wizard and OP_CAT, OP_CTV, APO, OP_VAULT, etc. are all related to this.

3. The unlocking conditions of UTXO are completely independent: a UTXO cannot decide whether it can unlock it based on whether another UTXO exists and its locking conditions. This problem is often seen in BTCFI's mortgage lending and pledge. Some of the signature Bitcoin transactions explained later are used to solve this problem.

Adjustment and evolution of Bitcoin contracts

Compared with Ethereum contracts based on computing, Bitcoin contracts are based on verification. This stateless contract has brought many difficulties to us in developing BTCFI products. In the more than ten years of Bitcoin contract development, the wonderful uses of cryptographic algorithms and signatures have greatly improved privacy, efficiency and decentralization, making product-based BTCFI possible.

Prudent Log Contract (DLC): Solve the Decentralized Clearing Problem in

BTCFI Scenarios

When lending, options, and futures agreements need to clear user positions based on oracle prices, it is inevitable to retain the right to operate the user's assets, which will undoubtedly cause the user's trust cost that the agreement will not do evil.

The discreet log contract (DLC) was introduced to solve this problem, using a cryptographic technique called adaptor signature, which allows Bitcoin scripts to program financial contracts that rely on external events and fully guarantee privacy.

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

Adapter signatures allow a signature to become a valid signature only after a private key is added. The Schnorr signature introduced in the taproot upgrade is an example of adapter signature.

In layman's terms, the standard form of Schnorr signature is (R, s), giving (R, s') . As long as you know x is the secret value (secret), you can let s = s' + x, and the result (R, s) is obtained.

Here is a simple example to explain how it is applied:

• Alice and Bob bet on the opposite end of a sports match (assuming no draw) each bet 1 $BTC, and whoever predicts success will win all $2 $BTC, and they will lock the bet in a multi-signature wallet that requires multiple signatures to release funds.

• Select an oracle and it will announce the results of the match (usually this information source is found off-chain, such as exchanges and match websites, etc.)

• The oracle does not need to know any details about the bet, or even who is involved in the DLC. Its work is strictly limited to providing results, and once an event occurs, the oracle publishes an encrypted proof called promise, indicating that it has determined the outcome of the event.

• To claim funds locked in the multi-signature wallet, the winner Alice uses the secret value provided by the oracle to create a valid private key, allowing them to sign transactions that spend funds in the wallet.

• The transaction was added to the Bitcoin blockchain to settle. At this time, since its signature is an ordinary signature, it is not obvious that this is a DLC. This is completely different from other common multi-party signature models—the content of the contract is completely open and the oracle participates in decision-making.

https://shellfinance.gitbook.io/shell

Liquidation mechanism of lending agreement

Assuming Alice takes $ORDI as collateral asset with a loan value of $0.15 $BTC, the lending position will be changed to the pending liquidation state if and only if the oracle quotes less than 225,000 sats/ordi for $ORDI. DLC allows the liquidator to liquidate the position without permission while being liquidated, and at the same time ensures that it cannot operate the user's mortgaged assets when the price has not reached the liquidation price. In the above scenario, Alice is equivalent to making a bet with the lending agreement for the price of $ORDI:

• If the price is less than 225,000 sats/ordi, the agreement can obtain all collateral from Alice and assume the corresponding BTC debt.

• If the price is greater than or equal to 225,000 sats/ordi, nothing happens and the asset ownership remains unchanged

Then, we need the oracle to promise to publish the signature of the result with a nonce R_c when the price is below 225,000 sats/ordi:

• Alice and the agreement only need to create a promise transaction for the result, creating an adapter signature (R, s'), rather than a signature (R, s). This means that the signatures handed over by both parties to the other party cannot be used directly to unlock the contract, but must reveal a secret value. This secret value is the original image of s_c_1.G, that is, the signature of the oracle. Because the oracle's signature nonce value has been determined, s_c_1.G can be constructed.

• When the price is below 225,000 sats/ordi, the oracle will issue a signature (R_c, s_c_1). The protocol can complete the opponent's adapter signature and add its own signature to make the above transaction an effective transaction and broadcast it to the network to trigger the settlement effect.

• On the contrary, if the price is not lower than 225,000 sats/ordi, the oracle will not publish s_c_1, and this promised transaction cannot be a valid transaction.

Essentially, DLC allows users to make agreements with the protocol as participants using the Bitcoin blockchain, both parties build DLC scripts by locking funds in a multi-signature address. These funds can only be used and redistributed according to a certain rule when the oracle publishes specified information at a specified time.

In this way, the lending agreement can use DLC to realize a clearing mechanism involving external price oracles without the user trusting any entity.

The lending agreements liquidium and shell finance we will mention later are both license-free decentralized clearings achieved using this technology.

The role of oracle

The oracle in DLC is used to provide a fixed frequency price feeding service, and will also participate as a third party in the process of generating and publishing secret values ​​in the DLC mechanism.

At present, there is no standardized product for DLC oracle. It mainly develops DLC modules for lending protocols. Standardized oracle such as chainlink assumes the function of off-chain data feeding. However, with the launch and continuous development of DLC-based lending protocols, many existing oracle projects are continuing to explore how to develop DLC oracle.

Partially signed Bitcoin transactions (PSBT): realizes that funds under

multi-party transactions are not required.

PSBT comes from the Bitcoin standard BIP-174. This standard allows multiple parties to sign the same transaction in parallel, and then merge the corresponding PSBTs to form a fully signed transaction. The multiple parties here can be agreements and users, buyers and sellers, pledgers and pledge agreements, etc. Therefore, as long as BTCFI applications involving multi- party fund swap scenarios, they can use PSBT. Most existing BTCFI projects use this technology.

Alice, Bob and Charlie have a 2/3 multi-signment amount. They want to withdraw the money and divide it into 3 copies. The three of them have to sign the same transaction to spend this UTXO. Assuming they don’t trust each other, what do they need to do to ensure the security of their funds?

https://river.com/learn/what-are-partially-signed-bitcoin-transactions- psbts/

• First, Alice initiates a PSBT transaction as the creator, with multiple signing UTXO as input and output is the wallet address of the three people. Since PSBT ensures that no transaction except the transaction cannot call any person's signature, Alice can send it to Bob after signing it.

• Similarly, after Bob checks the PSBT, he will sign it if he feels there is no problem; after signing, he will give it to Charlie for signature and transaction release. Charlie does the same.

Therefore, partly signed means that everyone only needs to check the transactions related to themselves. As long as there is no problem with the transactions related to themselves, it can ensure that there will be no problems after the transactions are on the chain.

On March 7, 2023, Yuga Labs' Ordinals NFT auction adopted an extremely centralized hosting auction model. During the auction process, all auction funds were required to be uniformly deposited into Yuga's address for custody, which seriously threatened the security of the funds.

https://x.com/veryordinally

Ethereum ecosystem users pointed out that Yuga's auction incident just illustrates the importance of ETH smart contracts, but Ordinals' developers also responded: Trustless quotation transactions based on PSBT are very useful, and can enable funds between NFT buyers and Yuga Labs without custody transactions.

Suppose there is now a pair of Bitcoin NFT traders and the public key of the NFT seller is information that can be known to both parties. When launching an NFT transaction, the buyer first writes his own UTXO input and an output that undertakes the NFT in the transaction. After the buyer constructs the transaction and signs it, he converts it into PSBT and sends it to the seller. After the seller receives the message through the agreement, the Bitcoin NFT transaction is completed.

The above whole process is completely trustworthy for both buyers and sellers. For the buyer, information such as bidding, acceptance address, etc. has been constructed in the transaction in advance. Once the change occurs, the signature will be invalid. For the seller, only if he completes the signature himself can the NFT be sold, and the price is measured by himself.

Taproot Upgrade: Open the Pandora's Box with Bitcoin Economy and BTCFI

The Taproot upgrade was activated in November 2021 to improve Bitcoin privacy, increase transaction efficiency, and expand Bitcoin programmability. Through Taproot implementation, Bitcoin can host large-scale smart contracts with tens of thousands of signers while masking all participants and retaining the size of a single signed transaction, making more complex BTCFI on-chain operations possible. Almost all BTCFI projects use the Taproot upgraded scripting language.

1.BIP340 (BIP-Schnorr): supports multiple parties to sign a single transaction, as well as the aforementioned use in the application of the Prudent Log Contract DLC, and the predetermined conditions must be met before a transaction can be executed. The amount of data they commit to Bitcoin is the same as the standard single-sign transaction data.

https://cointelegraph.com/learn/a-beginners-guide-to-the-bitcoin-taproot- upgrade

2.BIP341 (BIP-Taproot): Taproot introduced the Merkle abstract syntax tree (MAST), committing less contract transaction data to the chain, which allows Bitcoin to create more complex contracts. Unlike existing payment-to-script hash (P2SH) transactions, MAST allows users to selectively disclose partial scripts on demand, improving privacy and efficiency. MAST is also well used in Babylon's BTC staking transactions, building multiple lock scripts into a transaction containing multiple scripts, with three lock scripts:

• TimeLockScript time lock, implements the staking lock function;

• UnboundingPathScript unstaking: implements the early end of the pledge function;

• SlashingPathScript Confiscation: Implement the punishment function of the system when doing evil

All are leaf nodes. Starting from leaf nodes, gradually build the binary tree as follows

https://blog.csdn.net/dokyer/article/details/137135135

3.BIP342 (BIP-Tapscript): Provides Bitcoin with an upgraded transaction programming language that utilizes Schnorr and Taproot technologies. Tapscript also allows developers to implement future Bitcoin upgrades more efficiently.

4. Lay the foundation of the Ordinals protocol:

• The Taproot upgrade also introduces the Taproot (P2TR) address, which starts with bc1p, allowing metadata to be written into spend scripts stored in the Taproot script path, but never appears in UTXO sets.

• Since maintaining/modifying UTXO sets requires more resources, this practice can save a lot of resources and add a block to store data—which means there is now room to store images, videos, and even games—inadvertently making the deployment of Ordinals possible. The inscription address we commonly use is the Taproot (P2TR) address.

• Since consumption of Taproot scripts can only be performed from the existing Taproot output, the inscription uses a two-stage commit/reveal process for casting. First, in the submission transaction, a Taproot output is created for a script that promises the content of the inscription. Then, in the reveal transaction, the transaction is initiated by taking the UTXO corresponding to the inscription as input. At this time, the corresponding inscription content is disclosed to the entire network.

• The emergence of new assets such as Ordinals BRC-20, ARC-20, Runes has also kept Taproot's transfer adoption rate basically at around 70%.

Ordinals and Brc20: Create a batch of blue chip assets for BTCFI, opening

the door to indexer-based programming

Ordinals has realized the desire of Bitcoin OG to buy and buy on the Bitcoin main website, and its popularity market value has exceeded that of Ethereum NFT.

• Ordinals was proposed by Bitcoin core contributor Casey Rodarmor in January 2023. Its core is ordinal theory, aiming to give Bitcoin’s smallest unit, Sats, with unique identification and attributes, and convert it into a unique non-fungible token (NFT). By inscribed diverse data (pictures, text, videos, etc.) in Cong. The Ordinals protocol realizes the creation and transaction of Bitcoin NFTs.

• This process not only increases the use of Bitcoin, but also allows users to create and trade digital assets directly on the Bitcoin blockchain. The permanent value lies in that Ordinals is created based on Bitcoin’s Sora, whose basic value is connected to Bitcoin itself and will not theoretically return to zero.

BRC-20 is a token system that records on-chain, off-chain processing, using ordinal inscriptions of JSON data to deploy token contracts, mints and transfer tokens.

• It treats the inscription as an on-chain ledger to record the deployment, minting and transfer of BRC-20 tokens.

• In settlement, it is necessary to search for Bitcoin blocks through off-chain query, rely on third-party indexing tools to record the deployment, minting and transfer operations of all BRC-20 tokens to query the final balance of BRC-20 tokens for each user. This may cause different platforms to have different results for a certain account balance query.

Ordinals and Brc20 not only provide transaction requirements and blue-chip assets for BTCFI, but also provide new ideas for indexer-based programming to improve Bitcoin contract capabilities for many BTCFI projects. Json's "op" field combination can further evolve inscription-based defi and even socialfi and gamefi, including AVM, tap protocol, brc100, unisat's swap functions, and many projects that propose to build a smart contract platform in the first layer of Bitcoin use indexer-based programming solutions.

MuSig2: Decentralized mode to play Bitcoin Restaking and LST

The multi-signature scheme enables a group of signers to generate a joint signature on the message. MuSig allows multiple signers to create an aggregate public key from their respective private keys, and then jointly create a valid signature for the public key. It is an application of Schnorr signature. As we mentioned earlier, the standard form of Schnorr signature is (R, s), giving (R, s') . As long as you know x, that is, the secret value (secret), you can let s = s' + x, and get (R, s) . The private key and the valid signature are also used to generate the aggregate public key and the valid signature.

The MuSig2 solution only requires two rounds to complete multi-signatures. The aggregated public keys created in this way are indistinguishable from other public keys, which improves privacy and significantly reduces transaction fees. Taproot is upgraded to be compatible with the Musig2 multi-signature solution, and its BIP proposal was released in 2022 Bitcoin BIP-327: MuSig2 for BIP340-compatible Multi-Signatures.

Liquid staking on Ethereum can be implemented through smart contracts. Bitcoin lacks the contract capability required to implement liquid staking. As mentioned above, Bitcoin giant whales generally hate centralized custodians and need MuSig2 to implement decentralized Bitcoin liquid staking. Let’s take Shell Finance’s solution as an example:

• The user and Shell Finance calculate the address P of an aggregated public key and the corresponding MulSig2 multi-signature address P based on both parties' private key data and two nonce random numbers generated by the wallet.

• PSBT transactions are constructed by Shell Finance. The user and Shell Finance assets are pledged from the multi-signature address P supported by MuSig2 to Babylon. The wallet again provides nonce random number support and pass in the aggregate public key corresponding to the multi-signature address.

• When the Babylon pledge time ends, the PSBT is constructed by Shell Finance to unlock the transaction, and the user and Shell Finance jointly sign the pledged assets to unlock.

The third-party wallet that generates the random number of nonce, the pledge user and the LST project party jointly create the aggregate public key and signature. In this process, both the user and the project party can only keep a private key. Without the nonce value, the aggregate public key and signature cannot be generated to retrieve funds; and the wallet cannot use funds without the private key. If the nonce value is generated by the project party itself, the project party is at risk of doing evil and users need to pay attention.

Unpublished technical documentation: No public source

Current BTCFI application scenarios

Bitcoin programming is not complicated. It is even much simpler than Rust. Its focus is on creating verified and trustworthy promises and providing superior technical security than Ethereum. This sets the boundary for the development of BTCFI. The most difficult thing is what kind of BTCFI products that comply with PMF (project market fit) can be developed within the boundary. Just like when the Ethereum solidity contract was first launched, developers did not know that they could use it to develop the x*y=k amm algorithm, but chose to explore from the directions of ICO, order thin, peer-to-peer lending, etc.

Fluid cardiogenic: Babylon - Catfish in BTCFI

Babylon has built a staking protocol that has no middlemen without trust. It can directly pledge a layer of Bitcoin and obtain interest-generating income. At the same time, it can withdraw Bitcoin security and share it with the POS chain. As a general shared security layer, it provides POS security guarantees for cosmos and other Bitcoin layer2, etc., and share Bitcoin economic security.

• Absolute security: BTC staking has a significant advantage over other staking forms, that is, when a protected POS chain is attacked and crashed, its impact will not affect the staked Bitcoin. Specifically, if a POS chain is attacked and its token value returns to zero, users holding the POS chain token will face losses; however, in the case of BTC stake, the user's Bitcoin principal remains safe and lossless even if the protected POS chain is attacked and failed.

• Confiscation mechanism: If a user commits evil behavior such as double signing on a PoS chain that is rented by Babylon, then through EOTS (extractable one-time signatures, you can extract signatures at one time), this part of the assets can be unlocked, and the execution role in the network forces a part of the assets to the burning address.

https://docs.babylonchain.io/papers/btc_staking_litepaper(EN).pdf

At present, the Babylon main network has been launched and has completed the first phase of 1,000 BTC pledges, and will be launched in the second phase soon.

https://btcstaking.babylonlabs.io/

Currently, the first phase of the BTC pledged is mainly large investors, with gas paid accounting for 5%. There may be more retail investors joining in the second and third phases.

Attracting huge amounts of BTC for the first time and joining BTCFI staking:

• 尽管Babylon 并不能像以太坊一样提供POS 本身的ETH 本位的收益作为基础，但是对于一些收益预期不高，以安全为优先级，不愿接受跨链wrap 等方案，惰性的比特币大户矿工乃至看好比特币生态的欧美和亚洲基金，3-5% 的APY 也具备一定吸引力，那么总存款量10 万BTC 时，只需要1 亿美元以上的等值代币收益即可满足。

• Babylon 目前积极合作的Cosmos 生态就有Cosmos Hub, Osmosis, Injective 等知名项目，让他们未来成为AVS 并提供自己的代币作为比特币再质押者奖励，这能进一步打开Babylon 的BTC 存款上限。

Babylon 为BTCFI 生态发展注入大量流动性，教育用户并激发生态活力

• ETH 生态生态还曾经出现Defi，Layer2 等与Restaking 相当的成功叙事，Babylon 则是第一次让比特币主网上能够进行质押生息玩法，绝大多数比特币持有者是不愿意冒着风险进行托管和跨链的，这相当于让他们第一次体验了BTCFI，除此之外或许他们也可能进一步体验LST 等玩法。

• Babylon 生态仅LST 赛道就出现了StakeStone、Uniport，Chakra、Lorenzo、Bedrock、pSTAKE Finance，pumpbtc, Lombard, Solvbtc 等数十几个项目，其余还有各种Defi 项目，对于难以获取初始TVL 的比特币生态项目方，可以借助Babylon 的BTC Staking 的力量，用LST 吸引一批BTC，其LST 资产还能用在自己生态业务中。

• 由于Babylon 产生的收益又是以代币形式而不是BTC/ETH 计价，这对巨头吸引有限，整体格局并不会像ETH 质押一样中心化，反而因为其代币能够产生的利润也不确定，能够另辟蹊径的早期创业项目存在跑马圈地的机会。

比特币主网有望诞生多个蓝筹LST 资产，催生BTCFI 需求

Babylon 开创了原生BTC 质押生息的新赛道，让千亿规模沉睡的主网BTC 第一次有了大规模应用场景，大量被质押的BTC 衍生出大量的liquidity staking token，这些BTC 衍生出的质押凭证能够成为抵押借贷等场景天然的蓝筹抵押物，从而让基于比特币原生资产的借贷，稳定币和Swap 即BTCFi 有条件发展。

• BTCFi 难以发展的核心原因是比特币主网长期以来缺乏优质资产，这直接导致了借贷缺乏抵押物，swap 缺乏交易兑换需求，池子没有深度。目前比特币主网的蓝筹资产只有brc20 中的sats 和ordi 以及ordinals NFT 的node monkey 等。

• 但如果Babylon 中的一部分质押量能够衍生liquidity staking token，就像以太坊上lido 发行的steth 一样，能够成为aave，compound 等借贷的抵押物，并在uniswap 形成极高的交易深度，BTCFi 就有了发展条件。

• 试想，或许不少质押者希望能够通过liquidity staking token 借出BTC，或用于套娃投入质押，或用于对冲风险。

资产发行端创新：unisat 和magic eden 两大DEX 即将上线

https://docs.unisat.io/knowledge-base/brc20-swap-introduction

https://magiceden.io/runes/DOG%E2%80%A2GO%E2%80%A2TO%E2%80%A2THE%E2%80%A2MOON

• Unisat 的brc20 swap 将在9 月上线，也通过将Runes 映射成brc20 支持Renes，后续可以通过添加流动性池方法发行和交易代币，不需要再通过拉高gas mint 代币，或像交易NFT 一样一张张交易代币铭文，能够实现批量交易。

• Magic eden 的runes dex 也将在今年Q4 上线。

完全BTC 原生的点对池借贷稳定币协议将上线

Liquidium 是一个完全构建在比特币主网上，通过前文提到的部分签名比特币交易（PSBT）和谨慎日志合约DLC 实现的借贷，具体来说：

• 放贷人填写offer，包括LTV 即债务数量/ 抵押品的比率、利息、地板价等指标，并存入比特币。

• 借款人根据平台上的offer 选择放贷人并存入NFT 或Runes 资产。

它于2023 年10 月上线，上线不到一年获得了2227 个BTC 的交易量，说明比特币主网资产的BTCFI 借贷需求存在。

https://dune.com/shudufhadzo/liquidium

核心的问题在于：

• 资金利用效率低：如果一直没有借款人主动接offer，放贷人的比特币就闲置了，每次撤单挂单也需要费用，换言之，它不具备订单匹配功能，存在发现的过程。

• 点对点式清算：这里的清算人有且只有借贷双方，不能让其他人参与。

• 一旦NFT 或者RUNES 下跌至LTV 下的借款值以下，贷款人不会还款了，那么提供offer 的人只能够拿到nft 或者符文，他们相当于承受了下跌的风险。

• 从另一个角度来说，只要借款人的NFT 或者RUNES 下跌，TA 要么马上还款，要么失去了这个NFT 或者RUNES，这对借款人也是很不公平的。

• 为了防止借款人不还款，借贷日（Term）只能限制在十多天，APY 非常高。

https://liquidium.fi/

或许这就是为什么AAVE 的前身Ethlend 难以持续发展，点对点的借贷实在是太难实现持续规模化了。

Shell Finance 利用合成稳定币$bitUSD 最大程度在借贷和清算场景汇聚了流动性，实现了比特币版本的点对池借贷，通过$bitUSD 借款还款的正向飞轮，有望在未来实现较强的规模效应。

在清算和构建交易的过程中同样使用了谨慎合约DLC 和部分签名PSBT，实现借贷抵押物和资金的无需托管与去中心化清算，具体来说：

• 借款人可以在平台内质押Ordinals NFT、BRC-20 和Runes 资产等（未来还会支持其他比特币一层上的资产如Arch network 发的资产和RGB++ 映射的资产），借入合成资产$bitUSD。

• 在unisat 和magic eden 的swap 中构建BTC/BitUSD 交易对流动性池，借款人可以将合成资产$bitUSD 兑换成BTC，LP 在借款人的兑换中可以获取手续费收益。

• 在还款时，借款人需要把BitUSD 还给协议，此时又有了将BTC 兑换给BitUSD 的需求。

https://shellfinance.gitbook.io/shell

• 在清算时，同样是针对BitUSD 进行清算，任何人都可以参与待清算仓位的清算。当一个金库被清算时，清算人需要支付债务并取回对应的抵押资产，抵押资产与市场净值之间的价差就是清算人的收益。以一笔抵押品为30 枚$ORDI ，借出资产为600 $BitUSD 的借贷为例，其仓位清算主要依循过程如下：

• 当价格下降到28.5 USD 以下，LTV 低于80%。因此，仓位达到清算线，仓位开启清算状态；

• 对于当前抵押资产价值855 USD，将开启周期为48 小时的荷兰拍式仓位拍卖。竞拍者需要提供$BitUSD 用于获取该待清算资产，起拍价格为855 BitUSD，终止价格为600 BitUSD，拍卖价格随时间线性递减。

• 清算人通过荷兰拍进行清算时，清算人输入通过拍卖定价的700 BitUSD，Shell Finance 扣除需要偿还的600 BitUSD 债务后剩余的100 BitUSD 将会纳入保险基金。

• Shell Finance 检查完清算人的交易信息后，将抵押物资产添加进PSBT 中，清算人可以获得金库中的30 Ordi 的抵押物

• Shell Finance 出发预言机揭晓「Secert 秘密值」，该秘密值可以将参与者（贷款人与协议人）的签名补全，从而执行将抵押物从金库中转移至清算人地址的操作，价格预言机将自动关闭对应的DLC 进程

https://shellfinance.gitbook.io/shell

同时我们可以发现，Shell finance 能够进行批量的借款，其APY 也只有10%，能够支持更为长期的借款。

在前文我们提到了，Shell finance 还在通过MuSig2 做比特币的LST，将LST 资产作为一种新的抵押物，再将BitUSD 给质押者，这就又扩大了BitUSD 的应用飞轮，提高了项目上限。

一批基于UTXO 的BTCFI 拓展方案上线

比特币社区普遍认为EVM 系的BTC Layer2 创新性和上限很低，但是想要探索更复杂的BTCFI，就需要更强的比特币合约，不少比特币开发者推出了原生、基于UTXO 而拓展方案，根据UTXO 模型创新BTCFI 模式，我们根据这些拓展方案是否在比特币主网结算分类，

• 如果在比特币主网结算，就可以复用主网的流动性，无需跨链就可以直接兼容Runes 等资产。

• 如果不在比特币主网结算就需要跨链充值资产。

比特币主网结算的BTCFI 拓展方案

Arch Network：以扩充计算能力为核心，链外ZKVM 构建智能合约网络

Arch 利用了去中心化的验证者节点网络和一个比特币主网外的，专门构建图灵完备的零知识虚拟机（zkVM），能与比特币主网集成，这使其能与比特币主网共享流动性，兼容索引器就可以集成Runes 等资产协议：

• ZKVM：每次智能合约执行后，Arch zkVM 会生成ZK 证明，这些证明用于验证合约的正确性和状态变化

• 去中心化网络：生成的ZK 证明随后由Arch 的去中心化验证者节点网络进行验证。该网络在维护平台的完整性和安全性方面起着至关重要的作用。通过依赖去中心化架构，Arch 致力于确保验证过程不仅安全，而且能够抗审查和中心点故障。

• 与比特币Layer 1 集成：一旦ZK 证明得到验证，验证者网络就可以对未签名交易进行签名。这些交易，包括由应用程序逻辑决定的状态更新和资产转移，最终都会传回比特币。最后这一步完成执行过程，所有交易和状态更新都直接在比特币区块链上最终确定。

• UTXO 模型：Arch 的状态和资产被封装在UTXO 中，通过单次使用的概念进行状态转换。智能合约的状态数据被记录为state UTXOs，而原数据资产被记录为Asset UTXOs。Arch 确保每个UTXO 只能被花费一次，从而提供安全的状态管理

• 希望与比特币主网资产兼容的DeFi 应用程序（如借贷和去中心化交易所）可以在Arch 上构建的。

https://arch-network.gitbook.io/arch-documentation/fundamentals/getting- started

AVM：面向索引器编程实现BTCFI 代表

AVM 通过引入一个自带索引器、沙盒解析器（指令集），全球Database（数据库）的沙盒环境，为Atomicals 提供了一个能够处理智能合约和dApp 的高级执行环境，配备用于增强性能的自定义指令集，同时可以降低Gas 费，优化状态转换功能以增加并行处理能力，从而提高吞吐量和可扩展性。同时，AVM 实现了互操作性和跨链通信。

• 沙盒运行环境，整个模拟机处于一个受控的隔离环境中，使得沙盒中的执行和之外的执行互不干扰；

• 状态哈希，可以让参与者验证其索引器的状态是否正确同步，防止了状态不一致潜在的攻击性。

AVM 让Atomicals 协议能够执行各种BTCFI 任务，不仅仅是之前简单的代币发行机制。

基于UTXO 绑定但不在比特币主网结算的BTCFI 拓展方案

Fractal Bitcoin：利用现有比特币架构，平行拓展BTCFI 系统

https://fractal-bitcoin.notion.site/Fractal-Bitcoin- Public-b71cbe607b8443ff86701d41cccc2958

Fractal Bitcoin 是一种自我复制的拓展方法，通过将整个Bitcoin Core 封装到一个名为比特币核心软件包（BCSP）的可部署和可运行的区块链软件包中，可以独立运行一个或多个BCSP 实例，并通过递归锚定方式与比特币主网关联。

Fractal Fractal 30 秒出一个块，从这个角度说可以比10 分钟出一个块的比特币主网快20 倍，无差别地支持和兼容主链上的所有协议（如Ordinals 和brc-20），和主链以不同的物理结算速率同步运行，主网矿工每90 秒可以挖一个Fractal 区块。与此同时，fractal 保留有可选的在主网上通过铭文结算和锚定的能力。

• Fractal 一方面与主链共识相对一致，容易在协议层面互通。

• 另一方面得以摆脱主链物理约束和历史包袱，移除了一些历史上曾经存在但已经不再有现实意义的代码，在保留完整共识的前提下，精简了系统的实现，得到了一个更加简洁轻量的实现。

• 会比BTC 主网更快实施OP_CAT 等操作码提案，与比特币升级的基本路径一致，但升级速度更快，未来可以通过脚本实现铭文的BTCFI 合约。

https://fractal-bitcoin.notion.site/Fractal-Bitcoin- Public-b71cbe607b8443ff86701d41cccc2958

挖矿激励模型

Fractal 的代币50% 由挖矿产出，15% 分配给生态项目，5% 分配给投资者，20% 分配给顾问与核心贡献者， 10% 用于建立合作关系和流动性，可见其经济模型与矿工紧密相关。

Fractal 创新性的采用了一种名为「节奏挖矿」的挖矿方式，具体来说2/3 的区块由自由挖矿产出，而1/3 的区块由联合挖矿挖出，ASIC 矿工和矿池可以用已有的矿机挖比特币主网的同时挖Fractal，即通过Fractal Bitcoin 收益来激励矿工，同时利用其算力贡献保护网络免受潜在的51% 攻击。

生态进展

Fractal Bitcoin 主网会在9 月9 日上线，生态中已经有多个NFT 项目如Fractal Punks、honzomomo、Nodino、FractalStone、Fractal Puppets、MEBS，资产发行平台satspump.fun，AMM pizzaswap，链游基础设施UniWorlds，NFT 生成平台InfinityAI 等项目。

Fractal Bitcoin 会在主网上线时直接激活OP_CAT。OP_CAT 与Fractal 的高容量相结合，将使复杂的比特币应用得以实现。

资产迁移方面，BTC 和其他主网资产也可以作为brc-20 封装资产存在于Fractal Bitcoin 上。

https://unisat-wallet.medium.com/2024-07-unisat-swap-product-important- update-e974084074a1

总的来说，相对于比特币主网着重于高价值的资产，Fractal Bitcoin 着重于次重要资产的储存地，为资产创新和应用创新提供土壤，但Fractal Bitcoin 是否能够出现蓝筹资产和优质应用尚待观察。

RGB++：发展UTXO 模型独有BTCFI

RGB++ 利用图灵完备的UTXO 链（例如CKB 或其他链）作为影子链来处理链下数据和智能合约，进一步提升了比特币的可编程性。

影子链的UTXO 和比特币的UTXO 同构绑定，确保状态和资产在两条链之间的一致性，保证安全性。因此RGB++ 可以支持Runes 等比特币主网的资产，RGB++ 的资产也可以直接映射到比特币主网上，并扩展到所有图灵完备的UTXO 链。

https://github.com/ckb-cell/RGBPlusPlus-design/blob/main/docs/light-paper- en.md

RGB++ 充分发挥了UTXO 模型的优势，能够实现很多独特的BTCFI 功能：

• 通过UTXO 同构绑定实现无桥跨链Leap：RGB++ 上的资产可以在比特币主网到L2 或L2 之间来回跳转，这种方式可以不需要依赖于传统跨链桥的Lock-Mint 范式，可以规避传统跨链桥的很多风险，在跨链响应速度以及流动性聚合上也有很大优势，可以为Defi 生态带来很大便利。

• UTXO 交易模型非常适合Intent 驱动的交易场景：只要把一笔交易中想要的输入和输出信息签名提交上链验证即可完成，如UTXO 输入以及一个承接资产购买的输出，来为资产交易出价，中间的交易细节都不用管。

• UTXOSwap 已经上线主网：实际体验跟Uniswap 几乎没有任何区别。UTXOSwap 把每一笔交易分成了两步，第一步是用户把其意图提交上链，第二步由Aggregator 去聚合所有人的意图，合并后发起一笔交易和流动性池做交互。

• UTXO 有合约脚本嵌套的机制，只需要操作一次，就可以连续生成一系列交易，简化用户的交户流程：上一笔交易的输出结果，可以直接作为下一笔交易的输入参数，因此可以快速生成一批首尾彼此衔接的交易指令。

总结：BTC 已进入主流市场，未来价格狂飙上升终将拉动BTCFI 的发展

尽管当前我们可能会因为当前铭文市场的萧条和比特币的下跌对BTCFI 感到悲观，但是需要记住：与其他生态区别最大的是，比特币未来将持续上涨并将持续吸引新的散户是毋庸置疑的，比特币成为今年美国大选中的高频词，美国未来会将比特币作为联邦储备、俄罗斯挖矿合法化，当前主流社会正在积极拥抱比特币，纳什维尔的比特币大会中带着娃的妈妈和每一个Uber 司机都已经或准备成为比特币持有者，将其作为避险资产。

当比特币突破新高，比特币生态的各种以比特币计价的资产也会水涨船高，自然也会激发BTCFI 的市场使用需求，比如抵押资产借出资金，从而购买更多新资产；比如试图拿去staking 生息。

另外还有一个容易被忽视的事实：

• 在上两个周期中，以太坊资产如ICO 和NFT 是强势文化，新入场的加密用户可能是看到明星发NFT 入圈的，往往会选择使用metamask 等以太坊钱包，也习惯购买以太坊用于空投，meme 等交互，闲置的以太坊用于参与Defi。

• 在这个周期，比特币成为了强势文化，用户可能是因为看到美国大选中的比特币元素入圈的，后续也可能是比特币持续突破新高下入圈的，往往会先选择使用Unisat 等比特币钱包，并习惯购买比特币，他们闲置的BTC 也可能拿去参与BTCFI。

总有人觉得比特币应该回到数字黄金的叙事，但是在Taproot 升级和ordinals 协议问世后，新入场的散户和对比特币新用例感兴趣的比特币OG 成为了一股强大的新力量，他们将站在BTCFI 创新的前沿，不断吸引新的比特币持有者，教育其他比特币的大户和矿工。