HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

avatar
HTX Ventures
3 months ago
This article is approximately 9768 words,and reading the entire article takes about 13 minutes
The development of Bitcoin decentralized finance is not only a technological advancement, but also a profound change in its ecological structure.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

summary

Starting from the feasibility and evolution path of Bitcoin programming, this article systematically explores 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 with verification as the core through its unique scripting language and operation code. Compared with Ethereums smart contracts, Bitcoin contracts are characterized by statelessness and incomputability, which limits their functionality, 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, enables Bitcoin to support more complex contract logic and greatly improves 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.

On this basis, this article deeply analyzes how Bitcoin programming supports a variety of BTCFI applications. Through the interpretation of mechanisms such as multi-signature, time lock, hash lock, and the application of tools such as DLC, PSBT, and MuSig 2, the article shows the possibility of Bitcoin to achieve decentralized clearing and complex financial contracts without trust. This decentralized financial system native to the Bitcoin network not only overcomes the centralized risk of the cross-chain bridging model in the WBTC era, but also provides a more solid trust foundation for Bitcoin holders.

The article finally emphasizes that the development of Bitcoin decentralized finance is not only a technological advancement, but also a profound change in its ecological structure. With the emergence of new applications such as the Babylon pledge protocol and the launch of UTXO-based native scaling methods such as Fractal Bitcoin, the market potential of BTCFI is gradually emerging. In the future, as the price of Bitcoin rises, BTCFI will further attract the participation of mainstream users and form a new financial ecology with Bitcoin at its core. The formation of this ecology will enable Bitcoin to further evolve from the digital gold narrative and become an indispensable decentralized financial infrastructure in the global economic system.

Preface

Since the launch of the Ordinals protocol 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 was created to attract Bitcoin holders to participate in DeFi. WBTC locks Bitcoin through centralized custodians and mints it into WBTC for use in Ethereums DeFi protocol. WBTCs target users are Bitcoin holders who are willing to take the risk of centralized cross-chain bridges to participate in Bitcoin DeFi. As a typical representative of bridging Bitcoin to the EVM ecosystem, WBTC has realized a path for BTCFI. The EVM-based Bitcoin Layer 2 network and DeFi projects in its ecosystem that appeared in this cycle also continued this model. Although this model has enabled WBTC to gain a market value of more than US$9 billion in 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 use Bitcoin to participate in BTCFI without cross-chain casting, while ensuring decentralized custody of funds, it will be able to 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 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 were limited, with the continuous upgrade of the Bitcoin network and the innovation of the OG community, the potential of Bitcoin programming has become increasingly apparent, and many research results have been transformed into BTCFI products that will be launched soon.

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

The Basics of Bitcoin Contracts

Satoshi Nakamoto’s thoughts: UTXO, scripting language, and opcodes

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

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 all require special support code and data fields, and only one special case can be covered at a time, which means there are too many special cases.

The solution to this problem is scripts. The transaction input and output parties can use scripts to compile transactions into assertions (script language) that can be verified by the node network. The nodes verify the assertions (script language) of the transaction to evaluate whether the senders conditions are met.

A script is just a predicate. Its actually just a function that evaluates to either true or false. But predicate is a long and uncommon word, so Ill just call it a script.

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

The design supports a wide range of possible transaction types that I designed many years ago. These include escrow transactions, guarantee contracts, third-party arbitration, multi-party signatures, etc. These are areas we may want to explore in the future if Bitcoin becomes popular, but they must be designed in at the outset to ensure that they can be implemented in the future.

Satoshi Nakamotos design fourteen years ago laid the foundation for Bitcoin programming. The Bitcoin network does not have the concept of accounts, but only outputs, the full name of which is transaction output (TXO), which represents a sum of Bitcoin funds and is the basic unit of the Bitcoin system state.

When you spend an output, you make it an input for a transaction, or you can say it provides funding for the transaction. This is why we say that the Bitcoin system is based on the UTXO (unspent transaction output) model, because only UTXO (unspent transaction output) is the metal block we can use in the transaction process. The metal block enters a furnace, and after melting, new metal blocks (new UTXO) will be formed, and the old metal block transaction output (TXO) will no longer exist.

Each fund has its own locking script (also called script public key) and face value. According to Bitcoins consensus rules, the script public key can form a verification procedure, that is, the public key plus the command to perform specific operations in the script - the operation code OP-Codes. In order to unlock it, a specific set of data, namely the unlocking script, also called the script signature (scriptSig) , 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 is to program funds so that a specific amount of money can respond to specific input data . By designing script public keys, operation codes OP-Codes, and the interaction process 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 P2P KH (pay to public key hash) script in Bitcoin.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

Suppose I want to pay Xiao Ming 1 BTC, I need to use the available UTXO in my wallet to form a UTXO with a face value of 100 million satoshis, and put Xiao Mings public key in the locking script of the UTXO (and add an operator to check the signature). In this way, only Xiao Mings private key as the signature of Xiao Mings public key in the unlocking script can unlock the funds.

To summarize, Script is a very basic programming language. It consists of two types of objects: data such as public keys and signatures + opcodes - simple functions that operate on data (the list of opcodes is as follows https://en.bitcoin.it/wiki/Script#Opcodes).

Bitcoin Programming Arsenal

It was mentioned above that Satoshi Nakamoto initially hoped that the types of transactions that the Bitcoin network could support include escrow transactions, guarantee contracts, third-party arbitration, multi-party signatures, etc. So what are the weapons to achieve these, and how are they used in BTCFI?

Multi-party signature (MULTISIG)

● Its locking script is in the form of M <PUB-1> <PUB-2> ... <PUB-N> N OP_CHECKMULTISIG, which means that it records n public keys, and the signatures of m of them are required to unlock this UTXO.

● For example, the signatures of two of Alice, Bob and Chloe (or three public keys) can spend this script, and its script code is: 2 <Alice> <Bob> <Chloe> 3 OP_CHECKMULTISIG, OP_CHECKMULTISIG is the operation code to verify whether the signature matches the provided public key.

Applications include:

1. Personal and corporate fund management : After setting up a 2-of-3 multi-signature wallet, as long as two people can use the funds, it can also prevent the wallet manufacturer from doing evil. It must have m manufacturers colluding to withdraw funds.

2. Transaction Arbitration:

- Assume that Alice and Bob want to make a transaction, such as buying ordinals NFT, but they cannot exchange money and goods at the same time, so they agree to lock the money into a multi-signature output. When Bob receives the ordinals NFT sent by Alice, he will pay the full amount to Alice. In order to prevent the situation where the goods are received but not paid, a third party can be introduced to form a 2-of-3 multi-signature output; when a dispute occurs in the transaction, the third party can be requested to preside over the dispute. If the third party believes that Alice has already shipped the goods, it can work with Alice to transfer the funds.

- As long as the third party discloses its public key (for example, TA is an oracle), the two parties to the transaction can use their public keys in the 2-of-3 multi-signature script to join the arbitrator. Because the on-chain output records the hash value of the script, this can be done without the knowledge of the arbitrator. However, the problem here is that the third-party oracle can determine the outcome of a specific contract, which poses a certain risk. The prudent log contract DLC mentioned later has made optimizations in this regard, allowing it to be truly used for BTCFI such as Bitcoin lending.

Time Lock

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

● Absolute time lock (nLocktime): Only after a certain point in time will the transaction be considered a valid transaction and packaged into the block. The absolute time lock at the script level is the OP_CLTV operation code, which verifies that the UTXO can be unlocked only after a certain point in time. For example, the money can only be spent after the block height of 400,000.

● Relative time lock (nSequence) means that the transaction is valid and can unlock the UTXO only after a period of time has passed since the transaction that created the UTXO (i.e. the previous transaction) was confirmed by the block. The relative time lock at the script level is OP_CSV, such as This money can only be spent after 3 blocks of block confirmation.

Hash lock (hash preimage verification)

In addition, there is a hash time lock combined with a hash lock (hash preimage verification), which is also often used in Bitcoin staking and re-staking:

● The locking script format of the hash lock is OP_HASH 160 <hash> OP_EQUAL, which verifies whether the data in the unlocking script is the original image of the hash value in the locking script.

● Hash Time Lock Contract (HTLC): If the party receiving the funds cannot provide a hash value original 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 locking script. As long as the conditions of any path are met, the UTXO can be unlocked. The hash time lock contract mentioned above also uses such a process control opcode.

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

SIGHASH Signature of attached message

Bitcoin transactions allow the use of SIGHASH tags when signing. These tags provide additional specifications for the validity of the signature, allowing us to modify parts of the transaction without invalidating the signature, and expressing the signers expectations or entrustment of the purpose of the signature. For example:

● SIGHASH_SINGLE | ANYONECANPAY Signs an input and an output with the same index number as the input. The rest of the inputs and outputs can be changed without invalidating the signature. Andy can sign an input worth 1 BTC and an output of 100 Runes tokens, then anyone willing to exchange 100 Runes tokens for 1 BTC can complete the transaction and put it on the chain.

Other examples include taproot-upgraded Schnorr signatures, which can be used in the Discreet Log Contract DLC.

The Limits of Bitcoin’s Programmability

The basic pattern of Bitcoin programming is that the UTXO locking script indicates the verification conditions, the unlocking script provides data, and the opcode in the locking script specifies the data verification procedure (signature verification, hash preimage verification, etc.). After the verification procedure, the funds can be spent. The core restriction points are:

1. There are only a limited number of available verification procedures: Implementing zero-knowledge proof or other verification procedures requires a fork. Therefore, although the BTCFI expansion plan Fractal launched by Unisat is 100% consistent with BTC, in order to implement controversial operation code proposals such as OP_CAT and ZK native verification OPCode, it is also partially separated from the Bitcoin main network in terms of liquidity and security.

2. Bitcoin scripts have no computing power: As long as the funds can be unlocked, all funds can be used by any path, and the way the funds are spent 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. In order to solve this problem, the Bitcoin community is discussing the implementation of covenants, which can unlock more BTCFI application scenarios by limiting the further spending of transactions. BIP-420, OP_CAT, OP_CTV, APO, OP_VAULT, etc. mentioned by Taproot Wizard are all related to this.

3. The unlocking conditions of UTXO are completely independent: a UTXO cannot decide whether it can be unlocked based on the existence of another UTXO and its locking conditions. This problem often occurs in BTCFIs mortgage lending and staking. The partially signed Bitcoin transaction PSBT described later is used to solve this problem.

Adjustment and evolution of Bitcoin contracts

Compared with the calculation-based Ethereum contract, the Bitcoin contract is based on verification. This stateless contract has brought many difficulties to our 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 product application of BTCFI possible.

Discreet Log Contract (DLC): Solving the decentralized liquidation problem in BTCFI scenarios

When lending, options, and futures protocols need to liquidate user positions based on oracle prices, it is inevitable to retain the right to operate user assets, which will undoubtedly cause users to trust that the protocol will not do evil.

The Discreet Log Contract (DLC) was introduced to solve this problem. It uses a cryptographic technique called adapter signature to allow Bitcoin scripts to program financial contracts that depend on external events while fully ensuring privacy.

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

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

In laymans terms, the standard form of Schnorr signature is (R, s). Given (R, s), as long as we know x, which is the secret value (secret), we can set s = s + x to get (R, s).

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

● Alice and Bob bet on opposite outcomes of a sports match (assuming there is no tie), each betting 1 $BTC. Whoever predicts successfully wins the entire 2 $BTC bet. They will lock the bet in a multi-signature wallet that requires multiple signatures to release the funds.

● Select an oracle that will announce the results of the competition (usually this information source is found off-chain, such as exchanges and competition websites)

● The oracle does not need to know any details about the bet, or even who participated in the DLC. Its job is strictly limited to providing an outcome, and once an event occurs, the oracle publishes a cryptographic proof called a commitment that indicates that it has determined the outcome 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, enabling them to sign a transaction that spends the funds in the wallet.

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

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

https://shellfinance.gitbook.io/shell

Liquidation mechanism of lending agreement

Assume that Alice uses $ORDI as collateral and the loan value is 0.15 $BTC. If and only if the oracle quotes $ORDI below 225,000 sats/ordi, the loan position will be changed to pending liquidation. DLC allows the liquidator to liquidate the position without permission in the pending liquidation state, while ensuring that it cannot operate the users collateral assets when the price does not reach the liquidation price. In the above scenario, Alice is equivalent to making a bet with the lending agreement on the price of $ORDI:

● If the price is lower than 225,000 sats/ordi, the protocol can obtain all of Alice’s collateral and assume the corresponding BTC debt

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

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

● Alice and the protocol only need to create a commitment transaction for the result, creating an adapter signature (R, s) instead of a signature (R, s), which means that the signatures given to each other by both parties cannot be used directly to unlock the contract, but a secret value must be revealed. This secret value is the original image of s_c_ 1.G, that is, the signature of the oracle. Because the signature nonce value of the oracle has been determined, s_c_ 1.G can be constructed.

● When the price is lower than 225,000 sats/ordi, the oracle will issue a signature (R_c, s_c_ 1), then the protocol can complete the opponent’s adapter signature and add its own signature, making the above transaction a valid transaction, and broadcast it to the network, triggering the settlement effect.

● On the contrary, if the price is not less than 225,000 sats/ordi, the oracle will not publish s_c_ 1, and the commitment transaction will not become a valid transaction.

Essentially, DLC allows users and protocols to use the Bitcoin blockchain as participants to agree that both parties lock funds in a multi-signature address to construct a DLC script. These funds can only be used and redistributed according to a certain rule when the oracle publishes the specified information at the specified time.

In this way, the lending agreement can use DLC to implement a liquidation mechanism involving external price oracles without the need for users to trust any entity.

The lending protocols liquidium and shell finance that we will mention later both use this technology to achieve permissionless decentralized liquidation.

The role of oracles

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 disclosing secret values in the DLC mechanism.

Currently, there is no standardized product for DLC oracles. Lending protocols mainly develop DLC modules, and standardized oracles such as chainlink take on the function of feeding off-chain data prices. However, with the launch and continuous development of DLC-based lending protocols, many existing oracle projects are continuing to explore how to develop DLC oracles.

Partially Signed Bitcoin Transactions (PSBT): Implementing the BTCFI protocol to enable multi-party transactions without the need for custody

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. The multiple parties here can be protocols and users, buyers and sellers, pledgers and pledge agreements, etc. Therefore, as long as BTCFI applications involve multi-party fund swap scenarios, PSBT can be used. Most existing BTCFI projects use this technology.

Alice, Bob, and Charlie have a sum of money in a 2/3 multi-signature. They want to withdraw the money and divide it into 3 equal parts. The three of them must sign the same transaction to spend the UTXO. Assuming they dont trust each other, what do they need to do to ensure the safety of their funds?

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

●First, Alice, as the creator, initiates a PSBT transaction, with the multi-signed UTXO as input and the output being the wallet addresses of the three people. Since PSBT ensures that no transaction other than this transaction can call the signature of any one person, Alice can sign and send it to Bob.

● Similarly, after Bob checks the PSBT, if he thinks it is OK, he also signs it. After signing, he gives it to Charlie to sign and publish the transaction. Charlie also performs the same operation.

Therefore, the meaning of partially signed is that everyone only needs to check the part of the transaction related to themselves. As long as the transactions related to themselves are fine, it can be guaranteed that there will be no problems after the transactions are uploaded to the chain.

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

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

https://x.com/veryordinally

Users of the Ethereum ecosystem pointed out that Yuga’s auction event just illustrates the importance of ETH smart contracts, but the developers of Ordinals also responded: The trustless quotation transaction based on PSBT is very easy to use and can realize the transaction of funds between NFT buyers and Yuga Labs without custody.

Suppose there is a pair of 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 his own UTXO input and an output that receives the NFT in the transaction. After the buyer constructs the transaction and signs it, it converts it into PSBT and sends it to the seller. The seller receives the message through the protocol and signs it, and the Bitcoin NFT transaction is completed.

The entire process is completely trustless for both buyers and sellers. For buyers, information such as bids and receiving addresses have been built into the transaction in advance. Once changed, the signature will become invalid. For sellers, NFTs will only be sold after they complete the signature, and the price is determined by themselves.

Taproot Upgrade: Opening the Pandora’s Box of Bitcoin Ecosystem and BTCFI Explosion

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

1. BIP 340 (BIP-Schnorr): Supports multiple parties signing a single transaction, as well as the aforementioned DLC application of the cautious log contract, which requires predetermined conditions to be met before a transaction can be executed. The amount of data they commit to Bitcoin is the same as the amount of data for a standard single-signature transaction.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

2. BIP341 (BIP-Taproot): Taproot introduces the Merkle Abstract Syntax Tree (MAST), which commits less contract transaction data to the chain, allowing Bitcoin to create more complex contracts. Unlike existing payment to script hash (P 2 SH) transactions, MAST allows users to selectively disclose part of the script on demand, improving privacy and efficiency. MAST is also well used in Babylons BTC pledge transaction, building its multiple locking scripts into a transaction containing multiple scripts, three locking scripts:

● TimeLockScript time lock, realizing the lock function of pledge;

● UnboundingPathScript: Unstaking: realizes the function of terminating the pledge in advance;

● SlashingPathScript confiscation: Implement the system’s penalty function when committing evil

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

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

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

4. Laying the foundation for the Ordinals protocol:

● The Taproot upgrade also introduced Taproot (P 2 TR) addresses, starting with bc 1 p, which allow metadata to be written to spent scripts stored in the Taproot script path, but never appear in the UTXO set.

● Since maintaining/modifying the UTXO set requires more resources, this approach can save a lot of resources and increase the amount of data stored in a block - which means there is now space to store images, videos, and even games - inadvertently making the deployment of Ordinals possible. The inscription address we commonly use is the Taproot (P 2 TR) address.

● Since Taproot scripts can only be consumed from existing Taproot outputs, inscriptions are minted using a two-phase commit/reveal process. First, in the commit transaction, a Taproot output is created that commits to a script containing the inscription content. Then, in the reveal transaction, a transaction is initiated by using the UTXO corresponding to that inscription as input. At this point, the corresponding inscription content is made public to the entire network.

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

Ordinals and Brc 20: Creating a group of blue-chip assets for BTCFI and opening the door to indexer-based programming

Ordinals has fulfilled the Bitcoin OG’s wish to buy a lot on the Bitcoin mainnet, and its popularity and market value have already exceeded that of Ethereum NFT.

● Ordinals was proposed by Bitcoin Core contributor Casey Rodarmor in January 2023. Its core is the ordinal theory, which aims to give the smallest unit of Bitcoin, sats, a unique identifier and attributes, and convert it into a unique non-fungible token (NFT). By engraving a variety of data (pictures, text, videos, etc.) in sats, the Ordinals protocol realizes the creation and trading of Bitcoin NFTs.

● This process not only increases the utility of Bitcoin, but also allows users to create and trade digital assets directly on the Bitcoin blockchain. The permanent value lies in that since Ordinals are created based on Bitcoin’s Satoshi, their underlying value is linked to Bitcoin itself and will not return to zero in theory.

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

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

● In terms of settlement, it is necessary to query off-chain, rely on third-party indexing tools to retrieve Bitcoin blocks, record the deployment, minting and transfer operations of all BRC-20 tokens, and query the final balance of each users BRC-20 tokens. This may result in different results for queries on a certain account balance on different platforms.

Ordinals and Brc 20 not only provide BTCFI with trading needs and blue-chip assets, but also provide many BTCFI projects with new ideas based on indexer programming to enhance the capabilities of Bitcoin contracts. The combination of Jsons op field can further evolve into inscription-based defi and even socialfi and gamefi, including AVM, tap protocol, brc 100, unisats swap function, and even many projects that propose to build smart contract platforms on the Bitcoin layer all use solutions based on indexer programming.

MuSig 2: Decentralized Mode for Bitcoin Restaking and LST

Multi-signature schemes enable 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 the public key. It is an application of Schnorr signature. As we said earlier, the standard form of Schnorr signature is (R, s). Given (R, s), as long as you know x, which is the secret value (secret), you can let s = s + x to get (R, s). The private key plus a random number nonce value is used to generate the aggregate public key and the valid signature.

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

● Liquidity pledge on Ethereum can be achieved through smart contracts. Bitcoin lacks the contractual capabilities required to achieve liquidity pledge. As mentioned earlier, Bitcoin whales generally dislike centralized custodians and need MuSig 2 to achieve decentralized Bitcoin liquidity pledge. Here we take Shell Finances solution as an example:

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

2. Shell Finance constructs a PSBT transaction. The user and Shell Finance assets are pledged to Babylon from the multi-signature address P supported by MuSig 2. The wallet again provides nonce random number support and passes in the aggregated public key corresponding to the multi-signature address.

3. When the Babylon pledge time ends, Shell Finance constructs a PSBT unlocking transaction, and the user and Shell Finance jointly sign to unlock the pledged assets.

The third-party wallet that generates the random number of nonce, the staking user and the LST project jointly create the aggregated public key and signature. During this process, the user and the project can only keep one private key. Without the nonce value, the aggregated public key and signature cannot be generated, and the funds cannot be retrieved; and the wallet cannot use the funds without the private key. If the nonce value is generated by the project party itself, there is a risk of malicious behavior on the part of the project party, and users need to be aware of this.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

Unpublished technical documentation: No public source

Current BTCFI application scenarios

Bitcoin programming is not complicated. It is even much simpler than languages like Rust. Its focus is on creating verifiable and credible commitments and being able to provide better technical security than Ethereum. This sets boundaries for the development of BTCFI. The most difficult thing is what kind of BTCFI products that meet PMF (project market fit) can be developed within the boundaries. Just like when the Ethereum solidity contract was first released, developers did not know that they could use it to develop the x*y=k amm algorithm, but instead chose to start exploring from ICO, order books, peer-to-peer lending and other directions.

Liquidity booster: Babylon - the catfish in BTCFI

Babylon has built a completely trustless staking protocol without any middlemen. It can directly stake a layer of Bitcoin and obtain interest-bearing income. At the same time, it can extract Bitcoin security and share it with the POS chain . As a universal shared security layer, it provides POS security guarantees for Cosmos and other Bitcoin layer 2, and shares Bitcoin economic security.

Absolute security: BTC staking has a significant advantage over other forms of staking, that is, when the protected POS chain is attacked and collapses, the impact will not spread to the staked Bitcoin. Specifically, if a POS chain is attacked and the value of its tokens is zero, users holding the POS chain tokens will face losses; however, in the case of BTC staking, even if the protected POS chain is attacked and fails, the users Bitcoin principal is still safe and intact.

Penalty mechanism: If a user has double signatures or other malicious behaviors on a PoS chain that is rented by Babylon, then through EOTS (extractable one-time signatures), this part of the assets can be unlocked, and the executive role in the network will forcibly send part of the assets to the burning address.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

Currently, the Babylon mainnet has been launched and completed the first phase of 1,000 BTC staking. The second phase will be launched soon.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

https://btcstaking.babylonlabs.io/

Currently, the BTC pledged in the first phase are mainly from large investors, who pay 5% of the gas. More retail investors may join in the second and third phases.

For the first time, a huge amount of BTC was attracted to join BTCFI staking:

● Although Babylon cannot provide ETH-based returns like Ethereum, for some large Bitcoin miners who have low expectations for returns, prioritize security, are unwilling to accept cross-chain wrap solutions, and are lazy, and even European, American and Asian funds that are optimistic about the Bitcoin ecosystem, an APY of 3-5% is also attractive. Therefore, when the total deposit amount is 100,000 BTC, only an equivalent token income of more than 100 million US dollars is needed to meet the demand.

● Babylon is currently actively cooperating with well-known projects in the Cosmos ecosystem, such as Cosmos Hub , Osmosis , and Injection . Allowing them to become AVS in the future and provide their own tokens as rewards for Bitcoin re-stakers can further open up Babylons BTC deposit limit.

Babylon injects a lot of liquidity into the development of BTCFI ecosystem, educates users and stimulates ecological vitality

● The ETH ecosystem has also seen successful narratives such as Defi and Layer 2 that are comparable to Restaking. Babylon is the first time that staking and interest-earning gameplay can be performed on the Bitcoin mainnet. The vast majority of Bitcoin holders are unwilling to take the risk of custody and cross-chain transactions. This is equivalent to letting them experience BTCFI for the first time. In addition, they may also be able to further experience gameplay such as LST.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

● In the Babylon ecosystem, there are dozens of projects in the LST track alone, including StakeStone, Uniport, Chakra, Lorenzo, Bedrock, pSTAKE Finance, pumpbtc, Lombard, Solvbtc, etc., and there are various Defi projects in the rest. For Bitcoin ecosystem project parties that find it difficult to obtain initial TVL, they can use the power of Babylons BTC Staking to attract a batch of BTC with LST, and their LST assets can also be used in their own ecological business.

● Since the revenue generated by Babylon is in the form of tokens rather than BTC/ETH, it has limited appeal to giants, and the overall structure will not be as centralized as ETH staking. On the contrary, because the profits that its tokens can generate are uncertain, early-stage entrepreneurial projects that can find alternative ways have the opportunity to grab market share.

The Bitcoin mainnet is expected to give birth to multiple blue-chip LST assets, giving rise to BTCFI demand

Babylon has created a new track for native BTC staking and interest-earning, allowing the dormant mainnet BTC with a scale of hundreds of billions to have a large-scale application scenario for the first time. A large number of pledged BTC have derived a large number of liquidity staking tokens. These BTC-derived pledge certificates can become natural blue-chip collateral for scenarios such as mortgage lending, thereby enabling the development of lending, stablecoins and swaps based on Bitcoin native assets, namely BTCFi.

● The core reason why BTCFi is difficult to develop is that the Bitcoin mainnet has long lacked high-quality assets, which directly leads to a lack of collateral for lending, a lack of trading demand for swaps, and a lack of depth in the pool. Currently, the blue-chip assets on the Bitcoin mainnet are only sats and ordi in BRC 20 and node monkey in ordinals NFT.

● But if part of the staked amount in Babylon can be derived into liquidity staking token, just like the steth issued by lido on Ethereum, which can become the collateral for loans such as aave and compound, and form a very high trading depth in uniswap, BTCFi will have the conditions for development.

● Imagine that perhaps many stakers hope to be able to borrow BTC through liquidity staking tokens, or use it for staking, or to hedge risks.

Innovation on asset issuance: two major DEXs, unisat and magic eden, are about to be launched

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

●Unisat’s brc 20 swap will be launched in September, and will also support Renes by mapping Runes to brc 20. Subsequently, tokens can be issued and traded by adding liquidity pools. There is no need to increase gas mint tokens, or trade token inscriptions one by one like trading NFTs, and batch transactions can be achieved.

● Magic eden’s runes dex will also be launched in Q4 this year.

A completely BTC-native peer-to-pool lending stablecoin protocol will be launched

Liquidium is a lending service built entirely on the Bitcoin mainnet, using the aforementioned partially signed Bitcoin transactions (PSBT) and the cautious log contract DLC. Specifically:

● The lender fills out the offer, including indicators such as LTV (debt amount/collateral ratio), interest, floor price, etc., and deposits Bitcoin.

● Borrowers choose lenders based on offers on the platform and deposit NFT or Runes assets.

It was launched in October 2023, and achieved a trading volume of 2,227 BTC in less than a year, indicating that there is a demand for BTCFI lending of Bitcoin mainnet assets.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

https://dune.com/shudufhadzo/liquidium

The core problem is:

1. Low efficiency of fund utilization: If no borrower actively accepts the offer, the lenders Bitcoin will be idle, and each order cancellation and placement also requires fees. In other words, it does not have an order matching function and there is a discovery process.

2. Peer-to-peer clearing: The clearing agents here are only the borrower and the lender, and no one else can participate.

● Once NFT or RUNES falls below the borrowed value under LTV, the lender will not repay the loan, and the person who provided the offer can only get NFT or RUNES, which means they are bearing the risk of decline.

● From another perspective, as long as the borrower’s NFT or RUNES drops, he or she must either repay the loan immediately or lose the NFT or RUNES, which is also very unfair to the borrower.

● In order to prevent borrowers from not repaying the loan, the loan period (Term) can only be limited to more than ten days, and the APY is very high.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

https://liquidium.fi/

Perhaps this is why AAVE’s predecessor, Ethlend, had difficulty sustaining its development. Peer-to-peer lending is simply too difficult to achieve sustained scale.

Shell Finance uses the synthetic stablecoin $bitUSD to maximize liquidity in lending and liquidation scenarios, realizing the Bitcoin version of peer-to-pool lending. Through the positive flywheel of $bitUSD borrowing and repayment, it is expected to achieve a strong scale effect in the future.

In the process of clearing and constructing transactions, the cautious contract DLC and partial signature PSBT are also used to achieve the non-custodial and decentralized clearing of loan collateral and funds. Specifically:

● Borrowers can pledge Ordinals NFT, BRC-20 and Runes assets on the platform (in the future, other Bitcoin layer assets such as assets issued by the Arch network and assets mapped by RGB++ will also be supported) and borrow synthetic assets $bitUSD.

● Build a BTC/BitUSD trading pair liquidity pool in the unisat and magic eden swap. Borrowers can exchange synthetic assets $bitUSD for BTC, and LP can obtain transaction fee income from the borrowers exchange.

● When repaying the loan, the borrower needs to return BitUSD to the protocol, and at this time there is a need to exchange BTC for BitUSD.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

https://shellfinance.gitbook.io/shell

●When liquidating, BitUSD is also liquidated, and anyone can participate in the liquidation of the position to be liquidated. When a vault is liquidated, the liquidator needs to pay the debt and take back the corresponding collateral assets. The price difference between the collateral assets and the market net value is the liquidators income. Take a loan with 30 $ORDI as collateral and 600 $BitUSD as an example. The position liquidation mainly follows the following process:

1. When the price drops below 28.5 USD, the LTV is lower than 80%. Therefore, the position reaches the liquidation line and the position enters the liquidation state;

2. For the current collateral asset value of 855 USD, a 48-hour Dutch auction will be launched. Bidders need to provide $BitUSD to obtain the asset to be liquidated. The starting price is 855 BitUSD and the ending price is 600 BitUSD. The auction price decreases linearly over time.

3. When the liquidator conducts liquidation through the Dutch auction, the liquidator enters 700 BitUSD priced through the auction. After Shell Finance deducts the 600 BitUSD debt that needs to be repaid, the remaining 100 BitUSD will be included in the insurance fund.

4. After Shell Finance checks the liquidators transaction information, it adds the collateral assets to the PSBT, and the liquidator can obtain the 30 Ordi collateral in the vault

5. Shell Finance starts the oracle to reveal the Secert secret value, which can complete the signatures of the participants (lenders and negotiators), thereby executing the operation of transferring the collateral from the vault to the liquidators address, and the price oracle will automatically close the corresponding DLC process

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

https://shellfinance.gitbook.io/shell

At the same time, we can find that Shell Finance is able to provide batch loans, and its APY is only 10%, which can support longer-term loans.

As we mentioned in the previous article, Shell Finance is still using MuSig 2 to develop Bitcoins LST, using LST assets as a new collateral and then giving BitUSD to pledgers. This further expands the application flywheel of BitUSD and increases the projects ceiling.

A batch of UTXO-based BTCFI expansion solutions are launched

The Bitcoin community generally believes that the EVM-based BTC Layer 2 has low innovation and upper limits. However, if you want to explore more complex BTCFI, you need a stronger Bitcoin contract. Many Bitcoin developers have launched native, UTXO-based expansion solutions to innovate the BTCFI model based on the UTXO model.

We classify these expansion plans based on whether they are settled on the Bitcoin mainnet.

● If the settlement is done on the Bitcoin mainnet, the liquidity of the mainnet can be reused, and assets such as Runes can be directly compatible without the need for cross-chain.

● If the settlement is not on the Bitcoin mainnet, cross-chain asset recharge is required.

BTCFI expansion plan for Bitcoin mainnet settlement

Arch Network: Focusing on expanding computing power, off-chain ZKVM builds a smart contract network

Arch leverages a decentralized network of validator nodes and a specially built Turing-complete zero-knowledge virtual machine (zkVM) outside of the Bitcoin mainnet that can be integrated with the Bitcoin mainnet, which enables it to share liquidity with the Bitcoin mainnet and integrate asset protocols such as Runes with compatible indexers:

ZKVM: After each smart contract is executed, Arch zkVM will generate ZK proofs, which are used to verify the correctness and state changes of the contract.

Decentralized Network: The generated ZK proofs are then verified by Arch’s decentralized network of validator nodes. This network plays a critical 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 proof is verified, the validator network can sign unsigned transactions. These transactions, including state updates and asset transfers determined by the application logic, are ultimately transmitted back to Bitcoin. This last step completes the execution process, and all transactions and state updates are finalized directly on the Bitcoin blockchain.

UTXO model: Archs state and assets are encapsulated in UTXO, and state transitions are performed through the concept of single use. The state data of the smart contract is recorded as state UTXOs, and the original data assets are recorded as asset UTXOs. Arch ensures that each UTXO can only be spent once, thereby 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.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

AVM: BTCFI representative for indexer programming

AVM provides an advanced execution environment for Atomicals that can handle smart contracts and dApps by introducing a sandbox environment with its own indexer, sandbox parser (instruction set), and global database, equipped with a custom instruction set for enhanced performance, while reducing gas fees, optimizing state transition functions to increase parallel processing capabilities, thereby improving throughput and scalability. At the same time, AVM achieves interoperability and cross-chain communication.

● Sandbox operating environment, the entire simulator is in a controlled isolated environment, so that execution in the sandbox and execution outside the sandbox do not interfere with each other;

● State hashing allows participants to verify that the state of their indexer is correctly synchronized, preventing potential attacks due to inconsistent state.

AVM enables the Atomicals protocol to perform a variety of BTCFI tasks, not just the simple token issuance mechanism it was previously.

BTCFI expansion solution based on UTXO binding but not settled on the Bitcoin mainnet

Fractal Bitcoin: Using the existing Bitcoin architecture to expand the BTCFI system in parallel

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

Fractal Bitcoin is a self-replicating extension method that encapsulates the entire Bitcoin Core into a deployable and runnable blockchain software package called the Bitcoin Core Package (BCSP). One or more BCSP instances can be run independently and associated with the Bitcoin mainnet through recursive anchoring.

Fractal Fractal produces one block every 30 seconds, which is 20 times faster than the Bitcoin mainnet, which produces one block every 10 minutes. It supports and is compatible with all protocols on the main chain (such as Ordinals and BRC-20) without distinction, and runs synchronously with the main chain at different physical settlement rates. Mainnet miners can mine one Fractal block every 90 seconds. At the same time, Fractal retains the optional ability to settle and anchor on the mainnet through inscriptions.

● On the one hand, Fractal is relatively consistent with the main chain consensus and can easily communicate at the protocol level.

● On the other hand, it is able to get rid of the physical constraints and historical baggage of the main chain, remove some codes that have existed in history but are no longer of practical significance, and streamline the implementation of the system while retaining complete consensus, resulting in a more concise and lightweight implementation.

● It will implement opcode proposals such as OP_CAT faster than the BTC mainnet, which is consistent with the basic path of Bitcoin upgrades, but the upgrade speed is faster. In the future, the BTCFI contract with inscriptions can be implemented through scripts.

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

Mining Incentive Model

50% of Fractals tokens are produced by mining, 15% are allocated to ecological projects, 5% are allocated to investors, 20% are allocated to consultants and core contributors, and 10% are used to establish partnerships and liquidity. It can be seen that its economic model is closely related to miners.

Fractal innovatively adopts a mining method called rhythm mining. Specifically, 2/3 of the blocks are produced by free mining, and 1/3 of the blocks are mined by joint mining. ASIC miners and mining pools can use existing mining machines to mine Fractal while mining the Bitcoin mainnet. That is, miners are incentivized through Fractal Bitcoin revenue, while using their computing power contribution to protect the network from potential 51% attacks.

Ecological Progress

The Fractal Bitcoin mainnet will be launched on September 9. There are already multiple NFT projects in the ecosystem such as Fractal Punks, honzomomo, Nodino, FractalStone, Fractal Puppets, MEBS, asset issuance platform satspump.fun, AMM pizzaswap, blockchain gaming infrastructure UniWorlds, NFT generation platform InfinityAI and other projects.

Fractal Bitcoin will activate OP_CAT directly when the mainnet is launched. OP_CAT combined with Fractal’s high capacity will enable complex Bitcoin applications.

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

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

In general, compared to the Bitcoin mainnet which focuses on high-value assets, Fractal Bitcoin focuses on the storage of less important assets, providing a fertile ground for asset innovation and application innovation. However, whether Fractal Bitcoin can produce blue-chip assets and high-quality applications remains to be seen.

RGB++: Developing the UTXO model unique to BTCFI

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

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

HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective

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

RGB++ gives full play to the advantages of the UTXO model and can realize many unique BTCFI functions:

Bridgeless cross-chain Leap is achieved through UTXO isomorphic binding: Assets on RGB++ can jump back and forth from the Bitcoin mainnet to L2 or between L2. This method does not need to rely on the Lock-Mint paradigm of traditional cross-chain bridges, can avoid many risks of traditional cross-chain bridges, and has great advantages in cross-chain response speed and liquidity aggregation, which can bring great convenience to the Defi ecosystem.

The UTXO transaction model is very suitable for intent-driven transaction scenarios: just submit the signatures of the desired input and output information in a transaction for chain verification, such as UTXO input and an output to undertake asset purchases, to bid for asset transactions, without having to worry about the transaction details in the middle.

UTXOSwap has been launched on the mainnet: the actual experience is almost the same as Uniswap. UTXOSwap divides each transaction into two steps. The first step is for the user to submit his intention to the chain, and the second step is for the Aggregator to aggregate everyones intentions, and then initiate a transaction to interact with the liquidity pool.

UTXO has a contract script nesting mechanism. It only needs to be operated once to continuously generate a series of transactions, simplifying the users account transfer process: the output result of the previous transaction can be directly used as the input parameter of the next transaction, so a batch of transaction instructions that are connected to each other can be quickly generated.

Summary: BTC has entered the mainstream market, and the future price surge will eventually drive the development of BTCFI

Although we may feel pessimistic about BTCFI due to the current depression of the inscription market and the decline of Bitcoin, we need to remember: the biggest difference from other ecosystems is that Bitcoin will continue to rise in the future and will continue to attract new retail investors. There is no doubt that Bitcoin has become a high-frequency word in this years US election. The United States will use Bitcoin as a federal reserve in the future, and Russia will legalize mining. The current mainstream society is actively embracing Bitcoin. At the Bitcoin Conference in Nashville, mothers with babies and every Uber driver have become or are preparing to become Bitcoin holders and use it as a safe-haven asset.

When Bitcoin breaks through new highs, various Bitcoin-denominated assets in the Bitcoin ecosystem will also rise in value, which will naturally stimulate the market demand for BTCFI, such as pledging assets to borrow funds to purchase more new assets; for example, trying to earn interest by staking.

There is another fact that is often overlooked:

In the last two cycles, Ethereum assets such as ICO and NFT were a strong culture. New crypto users may have seen celebrities release NFTs to enter the circle, and often choose to use Ethereum wallets such as metamask. They are also accustomed to buying Ethereum for airdrops, memes and other interactions, and using idle Ethereum to participate in Defi.

In this cycle, Bitcoin has become a strong culture. Users may have entered the circle because of the Bitcoin elements in the US election, or they may have entered the circle later because Bitcoin continued to break new highs. They often choose to use Bitcoin wallets such as Unisat first and get used to buying Bitcoin. They may also use their idle BTC to participate in BTCFI.

Some people always think that Bitcoin should return to the narrative of digital gold, but after the Taproot upgrade and the advent 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 stand at the forefront of BTCFI innovation, constantly attracting new Bitcoin holders and educating other large Bitcoin holders and miners.

About HTX Ventures

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

HTX Ventures currently supports more than 300 projects covering multiple blockchain fields, and some high-quality projects have been traded on Huobi HTX. In addition, as one of the most active FOF funds, HTX Ventures has invested in 30 top funds in the world and cooperated with top global blockchain funds such as Polychain, Dragonfly, Bankless, Gitcoin, Figment, Nomad, Animoca and Hack VC to jointly build a blockchain ecosystem. Visit us .

If you need investment and cooperation, please feel free to contact VC@htx-inc.com

Disclaimer

1. HTX Ventures does not have any relationship with the projects or other third parties involved in this report that may affect the objectivity, independence and impartiality of the report.

2. The information and data cited in this report are all from compliant channels. The sources of the information and data are considered reliable by HTX Ventures, and necessary verification has been carried out on their authenticity, accuracy and completeness. However, HTX Ventures does not make any guarantee on their authenticity, accuracy or completeness.

3. The contents of this report are for reference only. The conclusions and opinions in this report do not constitute any investment advice for the relevant digital assets. HTX Ventures shall not be liable for any losses caused by the use of the contents of this report, unless otherwise expressly provided by laws and regulations. Readers should not make investment decisions based solely on this report, nor should they lose their ability to make independent judgments based on this report.

4. The information, opinions and speculations contained in this report only reflect the judgment of the researchers on the day when this report was finalized. There is a possibility that opinions and judgments will be updated in the future based on industry changes and updated data information.

5. The copyright of this report is owned by HTX Ventures only. If you need to quote the content of this report, please indicate the source. If you need to quote a large amount of content, please inform us in advance and use it within the permitted scope. Under no circumstances shall this report be quoted, deleted or modified in any way contrary to the original intention.

References

https://www.btcstudy.org/2023/04/18/interesting-bitcoin-scripts-and-its-use-cases-part-1-introduction/#note6

https://www.btcstudy.org/2023/04/19/interesting-bitcoin-scripts-and-its-use-cases-part-2-multisig/#%E5%A4%9A%E7%AD%BE%E5%90%8D%E8%84%9A%E6%9C%AC%E7%A4%BA%E4%BE%8B

https://www.btcstudy.org/2023/04/21/interesting-bitcoin-scripts-and-its-use-cases-part-3-time-locks/

https://www.btcstudy.org/2022/09/07/on-the-programmability-of-bitcoin-protocol/#%EF%BC%88%E4%B8%89%EF%BC%89%E6%AF%94%E7%89%B9%E5%B8%81%E5%8E%9F%E7%94%9F%E7%9A%84%E5 %90%88%E7%BA%A6%E5%BC%8F%E5%8D%8F%E8%AE%AE%E7%9A%84%E7%89%B9%E7%82%B9

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

https://dergigi.com/2022/06/27/the-words-we-use-in-bitcoin/

https://medium.com/summa-technology/bitcoins-time-locks-27e0c362d 7 a 1

https://mp.weixin.qq.com/s/SyZgWBBq1 dPkQx 8 HOAh 60 w

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

https://learnblockchain.cn/article/8692

https://shellfinance.gitbook.io/shell

https://www.btcstudy.org/2022/08/15/what-are-partially-signed-bitcoin-transactions-psbts/

https://learnblockchain.cn/article/8754

https://multicoin.capital/2024/05/09/the-dawn-of-bitcoin-programmability/

https://www.theblockbeats.info/news/35385

https://foresightnews.pro/article/detail/61617

https://learnblockchain.cn/article/8094

https://www.panewslab.com/zh/articledetails/n3 6 m 8 a 636 d 3 w.html

https://blog.csdn.net/mutourend/article/details/135589245

https://liquidium.fi/

https://foresightnews.pro/article/detail/39035

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

https://fractal-bitcoin.notion.site/2024-03-Fractal-Bitcoin-FAQ-CN-2faefea58cd04885a376920fce92e632?pvs= 25

https://www.panewslab.com/zh/articledetails/iv4 jgb 5 c.html

Original article, author:HTX Ventures。Reprint/Content Collaboration/For Reporting, Please Contact report@odaily.email;Illegal reprinting must be punished by law.

ODAILY reminds readers to establish correct monetary and investment concepts, rationally view blockchain, and effectively improve risk awareness; We can actively report and report any illegal or criminal clues discovered to relevant departments.

Recommended Reading
Editor’s Picks