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
summary
Starting from the feasibility and evolution path of Bitcoin programming, this paper systematically discusses 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 to Ethereum's smart contracts, Bitcoin contracts are characterized by being "stateless" and "non-computable", making them limited in functionality, but at the same time possessing higher security and decentralization.
With the implementation of the Taproot upgrade, the Bitcoin contract capability has been significantly enhanced. The introduction of Taproot, especially the use of MAST and Schnorr signatures, has enabled Bitcoin to support more complex contract logic and greatly improve privacy and transaction efficiency. These technological innovations have paved 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 provides an in-depth analysis of how Bitcoin programming supports a variety of BTCFI applications. Through the interpretation of mechanisms such as multi-signature, time-locking, and hash-locking, as well as the application of DLC, PSBT, MuSig2 and other tools, the article demonstrates the possibility of decentralized clearing and complex financial contracts in Bitcoin without trust. This decentralized financial system, which is native to the Bitcoin network, not only overcomes the centralization risk of the cross-chain bridging model in the WBTC era, but also provides a more solid foundation of trust for Bitcoin holders.
Finally, the article emphasizes that 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 the Babylon staking protocol and the launch of native scaling methods based on UTXOs such as Fractal Bitcoin, the market potential of BTCFI 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 ecology with Bitcoin as the 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, and Runes have emerged in the market, as well as hundreds of Bitcoin Layer 2 networks, while 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 DeFi. WBTC locks and mints Bitcoin into WBTC through a centralized custodian for use in Ethereum's DeFi protocol. WBTC is targeted at Bitcoin holders who are willing to take on the risk of centralized cross-chain bridges in order to participate in Bitcoin DeFi. As a typical example of bridging Bitcoin to the EVM ecosystem, WBTC implements a path to BTCFI. The EVM is a Bitcoin Layer 2 network that emerged in this cycle and the DeFi projects in its ecosystem have also continued this model. Although this model has enabled WBTC to gain more than $9 billion in market capitalization in the Ethereum ecosystem, this proportion is less than 1% compared to the total market capitalization of Bitcoin, reflecting the limitations of this model.
In contrast, if Bitcoin holders can directly hold Bitcoin to participate in BTCFI without the need for cross-chain minting, while ensuring decentralized custody of funds, it will be able to attract more Bitcoin users and create a broader market. This requires Bitcoin programming to be implemented under the UTXO structure. Just as mastering Solidity is the key to entering Ethereum DeFi, mastering Bitcoin programming is a must-have skill to enter the BTCFI market.
Unlike Ethereum contracts, Bitcoin contracts don't have computing power, but are more like a verifier connected by signatures. Although the initial application scenarios were limited, with the continuous upgrading 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 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 the Bitcoin contract
Satoshi Nakamoto's Thoughts: UTXOs, Scripting Languages, and Opcodes
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
In 2010, Satoshi Nakamoto wrote on the Bitcoin Talk forum:
Bitcoin's core design will be fixed after version 0.1 is released, so I expect it to support as many transaction types as possible, but these transaction types all require special support codes and data fields, and can only cover one special case at a time, so there are too many special cases.
The solution to this problem is scripting. The input and output of a transaction can use a script to compile the transaction into an assertion that can be verified by the node network (scripting language), and the node validates the assertion of the transaction (scripting language) to assess whether the sender's conditions are met.
A "script" is just a "predicate". It's really just an equation where the result is either true or false. But predicate is a very long and rare word, so I'll call it "scripting".
The recipient of the funds will match the script to the template. Currently, there are only two templates accepted by the recipient: direct debit and bitcoin address. More transaction type templates can be added in future releases, and nodes running that version or higher will be able to receive them. All nodes in the network can validate 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 trade types that I designed many years ago. This includes escrow transactions, guarantee contracts, third-party arbitration, multi-party signatures, and more. These are areas that we may want to explore in the future if Bitcoin is a big hit, but they have to be designed in the beginning to ensure that they can be implemented in the future.
Satoshi Nakamoto's design fourteen years ago laid the foundation for Bitcoin programming. The Bitcoin network does not have the concept of an "account", only an "output", 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's state.
When an output is spent, it is to make that output an input to a transaction, or to fund the transaction. That's why we say that Bitcoin is based on the "UTXO" model, because only the "UTXO" is the piece of metal that we can use in the transaction process, and the piece of metal goes into a furnace and after it is melted to form some new pieces of metal (the new UTXO), and the old "transaction output (TXO)" is gone.
Each fund has its own lock script (also called script public key) and face value, according to the consensus rules of Bitcoin, the script public key can form a kind of verification program, that is, the public key plus the command to perform a specific operation in the script - 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 " is unlocked" and can be spent.
Therefore, Bitcoin scripting is to program the funds, so that a specific amount of money can respond to the input of specific data, through the design of the script public key, opcode OP-Codes, and the interaction process between users, we can provide cryptographic assurance for the key state transition of the Bitcoin contract 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
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
https://learnmeabitcoin.com/technical/script/
For example, if I want to pay 1 BTC to Tom, I need to use the UTXO available in my wallet to form a UTXO with a denomination of 100 million satosher tokens, and put Tom's public key (and add an operator to check the signature) in the lock script of the UTXO, so that only Tom's private key can be used as the signature of Tom's public key corresponding to the unlocking script to unlock the funds.
To sum up, Script, or 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 for manipulating data (the list of opcodes is https://en.bitcoin.it/wiki/Script#Opcodes below).
The arsenal of Bitcoin programming
As mentioned above, Satoshi Nakamoto initially hoped that the types of transactions that the Bitcoin network could support were escrow transactions, guarantee contracts, third-party arbitration, multi-party signatures, etc., so what are these weapons, and how are they used in BTCFI?
MULTISIG
Its lock script is in the form of M
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
Uses include:
Personal and business money management: After setting up a 2-of-3 multi-signature wallet, you can use funds as long as two are available, and it can also prevent wallet manufacturers from doing evil, and M manufacturers must collude to withdraw funds.
Transaction Arbitration:
Suppose Alice and Bob want to make a transaction, such as buying an ordinals NFT, but they can't pay the money in one hand and deliver it in the other, so they agree to lock the money into a multi-signature output, and when Bob receives the ordinals NFT issued by Alice, he will pay the money to Alice in full, and in order to prevent the situation of not giving money after receiving the goods, a third party can be introduced to form a 2-of-3 multi-signature output; When a transaction is disputed, a third party can be requested to administer justice. If the third party believes that Alice has already shipped the goods, they can work with Alice to transfer the funds away.
As long as the third party exposes its public key (for example, TA is an oracle), the two parties to the transaction can use their public key in the 2-of-3 multi-signature script, so as to join the arbiter, because the on-chain output is recorded as the hash value of the script, so it can be done without the knowledge of the arbitrator, but the problem here is that the third-party oracle can determine the outcome of the specific contract, and there is a certain risk. so that it can actually be used for BTCFI such as Bitcoin lending.
Timelocks
Timelock is used to control the validity of transactions and when an output can be spent, which is a Bitcoin Script programming weapon that will be used in BTCFI scenarios such as re-staking, staking, mortgage lending, etc., developers need to choose whether to use relative timelock (nSequence) or absolute timelock (nLocktime):
Absolute timelock (nLocktime): Only after a certain point in time, the transaction will be considered a valid transaction and can be packaged into the block, the absolute timelock at the script level is the OP_CLTV opcode, which is verified after a certain point in time, and the UTXO can only be unlocked", such as the money can only be spent after the block height is 400000.
Relative timelock (nSequence) means that the transaction that created the UTXO (i.e., the pre-order transaction) is valid after a period of time after the transaction that created the UTXO (i.e., the pre-order transaction) is confirmed by the block, and the UTXO can only be unlocked, and the relative timelock at the script level is OP_CSV, such as "This money can only be spent after 3 blocks of block confirmation."
Hash lock (preimage verification)
In addition, there are hash timelocks that combine hash locks (hash preimage verification), which are also commonly used in Bitcoin staking and restaking:
The lock script for a hash lock is in the form of OP_HASH160
Hash Timelock Contract (HTLC): If the party receiving the funds fails to provide a preimage of the hash value within a certain period of time, the funds can be recovered by the paying party
Process control (parallel unlock conditions)
OP_IF opcodes can be arranged in the lock script to unlock multiple paths, as long as the conditions of either path are met, the UTXO can be unlocked. The hash timelock contract mentioned above also uses this process to control the opcode.
After the taproot upgrade, the MAST (Merkelized Abstract Syntax Tree) feature allows us to put different unlock paths into different Merkle tree leaves, and Babylon's BTC staking transactions also use MAST to improve the efficiency and privacy of transactions, which we will describe later.
SIGHASH COMES WITH A MESSAGE SIGNATURE
Bitcoin transactions are signed with SIGHASH tags, which provide additional specifiers for the validity of the signature, allow us to alter parts of the transaction without invalidating the signature, and express the signer's expectation or delegation of the purpose of the signature. Like what:
SIGHASH_SINGLE | ANYONECANPAY signs the input and the output that uses the same index number as that input, and the rest of the input and output can be changed without the signature being invalidated. Andy can sign an input worth 1 BTC and an output of 100 Runes tokens, so anyone willing to exchange 100 Runes tokens for 1 BTC can make up the transaction and put it on-chain.
Other examples include the taproot's upgraded Schnorr signature, which can be used for the Prudential Log Contract DLC.
Limitations of Bitcoin programmability
The basic pattern of Bitcoin programming is that the UTXO lock script indicates the verification conditions, the unlock script provides the data, and the opcode in the lock script indicates the verification procedure for the data (signature verification, hash image verification, etc.), through which the funds can be spent, and the core limitation points are:
1. There are only a limited number of validators available: the implementation of zero-knowledge proofs or other validators requires a fork, so although the BTCFI extension scheme Fractal launched by unisat is 100% consistent with BTC, in order to be able to implement OP_CAT, ZK native verification OPCode and other "controversial" opcode proposals are also partially separated from the Bitcoin mainnet in terms of liquidity and security.
2. Bitcoin Script has no computing power: as long as the funds can be unlocked, all the funds can be used using any path, and the way the funds are spent cannot be limited after unlocking, which also means that it is difficult to use the floating interest rate scheme in the BTCFI lending project, and can only use a fixed interest rate. To address this issue, the Bitcoin community is debating the implementation of "covenants", which could unlock more BTCFI use cases by limiting the amount of further transactions that can be spent. BIP-420 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 be unlocked based on the existence of another UTXO and its locking conditions, which often occurs in BTCFI's mortgage lending and staking, and the partially signed Bitcoin transaction PSBT described below is used to solve this problem.
The adaptation and evolution of the Bitcoin contract
Compared with the computation-based Ethereum contract, the Bitcoin contract is based on verification, and this stateless contract has brought a lot of difficulties to our development of BTCFI products, and in the more than ten years of the development of Bitcoin contracts, the magic of cryptography algorithms and signatures has greatly improved privacy, efficiency and decentralization, making it possible to use BTCFI in products.
Cautionary Log Contract (DLC): Solves the problem of decentralized liquidation in BTCFI scenarios
When lending, options, and futures agreements need to liquidate users' positions according to the oracle price, it is inevitable that they need to retain the right to operate users' assets, which will undoubtedly cause users to trust the trust cost that the protocol will not do evil.
The Cautionary Log Contract (DLC) was introduced to solve this problem, using a cryptographic technique called adaptor signature, which allows Bitcoin Script to program financial contracts that rely on external events with full privacy.
It was proposed in 2017 by Tadge Dryja (research scientist) and Gert-Jaap Glasbergen (software developer) of the Digital Currency Initiative at the Massachusetts Institute of Technology (MIT) and 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 an adapter signature.
通俗的说，Schnorr 签名的标准形式是 (R, s)，给出(R, s') ，只要知道 x 即秘密值（secret）， 就可以令 s = s' + x，得到的 (R, s) 。
Here's a simple example to explain how it works:
Alice and Bob bet on the opposite outcome of a sports match (assuming no draw), each bet 1 $BTC, and whoever predicts success wins all 2 $BTC of their bet, and they lock their bet in a multisig wallet that requires multiple signatures to release funds.
Choose an oracle that will announce the results of the contest (usually such sources of information are found off-chain, such as exchanges and contest websites, etc.)
The oracle doesn't need to know any details about the stakes, or even who is involved in the DLC. Its work is strictly limited to providing a result, and once an event has occurred, the oracle issues a cryptographic proof called a promise, indicating that it has determined the outcome of the event.
To claim the funds locked in the multisig wallet, the winner, Alice, uses the secret value provided by the oracle to create a valid private key that allows them to sign transactions that cost the funds in the wallet.
The transaction is added to the Bitcoin blockchain for settlement, and since its signature is a normal signature, it is not clear that it is a DLC. This is quite different from other common multi-signature patterns, where the contents of the contract are completely public and the oracle is involved in decision-making.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
https://shellfinance.gitbook.io/shell
The liquidation mechanism of the lending agreement
Assuming that Alice has $ORDI as collateral and lends a value of 0.15 $BTC, the borrowing position will change to pending liquidation if and only if the oracle quotes less than 225,000 sats/ordi for $ORDI. The DLC allows liquidators to liquidate their positions without permission, while ensuring that they cannot operate the user's collateral if the price does not reach the liquidation price. In the above scenario, Alice is equivalent to making a bet with the loan agreement for the price of $ORDI:
If the price falls below 225,000 sats/ordi, the protocol can take all of Alice's collateral and assume the corresponding BTC debt
If the price is greater than or equal to 225,000 SATS/ORi, nothing happens and the asset vesting remains the same
So, we need the oracle to commit to publishing a signed s_c_1 of the result with a nonce R_c when the price drops 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 to unlock the contract directly, but must reveal a secret value. This secret value is the preface of s_c_1.G, which is the oracle's signature. Since the oracle's signature nonce value has been determined, s_c_1.G can be constructed.
When the price falls below 225,000 Sats/ORD, the oracle issues a signature (R_c, s_c_1), which can then complete the counterparty's adapter signature and add its own signature to make the transaction a valid transaction and broadcast to the network to trigger the settlement effect.
Conversely, if the price does not fall below 225,000 Sats/ordi, the oracle will not issue a s_c_1, and the commitment deal will not be a valid transaction.
Essentially, DLC allows users to make agreements with the protocol as participants using the Bitcoin blockchain, where both parties build a DLC script by locking funds in a multisig address. These funds can only be used when the oracle publishes a specified message at a specified time and is redistributed according to a certain rule.
In this way, the lending protocol can use the DLC to implement a settlement mechanism with the participation of an external price oracle without the user trusting any entity.
Both the lending protocols Liquidium and Shell Finance, which we'll mention later, leverage this technology to enable permissionless decentralized liquidation.
The role of oracles
The oracles in the DLC are used to provide a fixed frequency price feed, and are involved as a third party in the process of generating and disclosing secrets in the DLC mechanism.
At present, there is no standardized product for DLC oracles, mainly DLC modules developed by lending protocols, and standardized oracles such as chainlink are responsible for off-chain data feeding, but with the launch and continuous development of DLC-based lending protocols, many existing oracle projects continue to explore how to develop DLC oracles.
Partially Signed Bitcoin Transaction (PSBT): Enables the non-custody of funds under multi-party transactions in the BTCFI protocol
PSBT comes from the Bitcoin standard BIP-174, which allows multiple parties to sign the same transaction in parallel, and then merge the corresponding PSBT to form a fully signed transaction, where the multiple parties can be protocols and users, buyers and sellers, stakers and staking protocols, etc., so as long as the BTCFI applications involving multi-party fund swap scenarios can use PSBT, most of the existing BTCFI projects use this technology.
Alice, Bob, and Charlie have a 2/3 multisig in which they want to take out the money and divide it into 3 equal parts, and all three of them have to sign the same transaction to spend the UTXO. Assuming they don't trust each other, what do they need to do to keep their funds safe?
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
First, Alice initiates a PSBT transaction as the creator, with a multisig UTXO as the input, and the output as the wallet address of each of the three people. Since PSBT guarantees that no transaction other than that transaction can invoke any person's signature, Alice can sign it and send it to Bob.
Similarly, Bob checks the PSBT and signs it if he thinks it's okay; After signing, Charlie will be signed and the transaction will be published. Charlie does the same.
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 transaction related to themselves is okay, it can ensure that there will be no problem after the transaction is on the chain.
On March 7, 2023, Yuga Labs' Ordinals NFT auction adopted a bidding model with extremely centralized custody. During the auction process, all the bidding funds are required to be deposited into Yuga's address escrow, which seriously threatens the security of the funds.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
https://x.com/veryordinally
Ethereum ecosystem users pointed out that Yuga's auction event just illustrates the importance of ETH smart contracts, but the developers of Ordinals also responded: PSBT-based trustless quote transactions are very easy to use, allowing funds between NFT buyers and Yuga Labs to be traded without escrow.
Let's say there is a couple of Bitcoin NFT traders, and the NFT seller's public key is information that is knowable to both parties. When initiating an NFT transaction, the buyer first writes their UTXO input and an output to undertake the NFT in the transaction. After the buyer constructs the transaction and signs it, it is converted into PSBT and sent to the seller, and the seller receives the message through the agreement and signs, and the Bitcoin NFT transaction is closed.
The whole process is completely trustless for both the buyer and the seller. For the buyer, information such as the bid and acceptance address has been built into the transaction in advance, and if it is changed, the signature will become invalid. For the seller, the NFT will only be sold if the signature is completed by the seller, and the price is measured by themselves.
Taproot Upgrade: Open the Pandora's box of Bitcoin ecology and BTCFI outbreak
The Taproot upgrade was activated in November 2021 and aims to improve Bitcoin privacy, improve 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 signed transaction, which makes more complex BTCFI on-chain operations possible. Almost all BTCFI projects use Taproot's upgraded scripting language.
BIP340 (BIP-Schnorr): Allows multiple parties to sign a single transaction, as well as the one mentioned above in the Cautionary Log contract DLC application, where a predetermined condition must be met before a transaction can be executed. The amount of data they commit to Bitcoin is the same as the amount of data they can commit to Bitcoin as a standard single-signature transaction.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
BIP341 (BIP-Taproot): Taproot introduces the Merkle Abstract Syntax Tree (MAST) to commit less contract transaction data on-chain, which enables Bitcoin to create more complex contracts, and unlike existing payment-to-script hash (P2SH) transactions, MAST allows users to selectively expose parts of the script on demand, improving privacy and efficiency. MAST is also well used in Babylon's BTC staking transactions, building its multiple locking scripts into a single transaction with multiple locking scripts, three locking scripts:
TimeLockScript to realize the locking function of staking;
UnboundingPathScript 解质押：实现提前结束质押功能；
SlashingPathScript slashing: implements the punishment function of the system when committing evil
All of them are leaf nodes, starting from the leaf nodes and gradually building a binary tree as follows
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
BIP342 (BIP-Tapscript): Provides an upgraded transactional programming language for Bitcoin that leverages Schnorr and Taproot technologies. Tapscript also allows developers to implement future Bitcoin upgrades more efficiently.
Laying the foundation for the Ordinals protocol:
The Taproot upgrade also introduces a Taproot (P2TR) address, starting with bc1p, which allows metadata to be written to a spent script stored in the Taproot script path, but never appears in the UTXO set.
Since it takes more resources to maintain/modify the UTXO set, this practice can save a lot of resources, increase the amount of data stored in a chunk — meaning there is now space to store images, videos, and even games — inadvertently making the deployment of Ordinals possible. The most commonly used inscription address is the Taproot (P2TR) address.
Since the consumption of Taproot scripts can only be made from the already existing Taproot output, the inscription is minted using a two-stage submit/reveal process. First, in the commit transaction, a Taproot output of a script that promises to contain the contents of the inscription is created. Then, in the reveal transaction, initiate the transaction by taking the UTXO corresponding to that inscription as input. At this time, the corresponding inscription content is made public to the whole network.
Ordinals and Brc20: Creating a batch of blue-chip assets for BTCFI, opening the door to indexer-based programming
Ordinals has fulfilled the wish of Bitcoin OG to buy and buy on the Bitcoin mainnet, and its market cap has surpassed that of Ethereum NFTs.
Ordinals was proposed in January 2023 by Bitcoin Core contributor Casey Rodarmor, and its core is ordinal number theory, which aims to give the smallest unit of Bitcoin - satoshis (sats) a unique identity and attributes, and convert it into a unique non-fungible token (NFT), by inscribed with diverse data (pictures, text, videos, etc.) in the satos, the Ordinals protocol enables the creation and trading of Bitcoin NFTs.
This process not only increases the usefulness of Bitcoin, but also allows users to create and trade digital assets directly on the Bitcoin blockchain. The permanent value lies in the fact that Ordinals is based on the satoshi of Bitcoin, and its underlying value is linked to Bitcoin itself and does not theoretically go to zero.
BRC-20 is an on-chain record-keeping, off-chain processing token system that utilizes ordinal inscriptions of JSON data to deploy token contracts, mint coins, and transfer tokens.
It serves the inscription as an on-chain ledger that records the deployment, minting, and transfer of BRC-20 tokens.
In terms of settlement, it is necessary to rely on third-party indexing tools to retrieve Bitcoin blocks through off-chain queries, record the deployment, minting and transfer operations of all BRC-20 tokens, and query the final balance of BRC-20 tokens of each user. This may result in different platforms having different results for a query of an account's balance.
Ordinals and Brc20 not only provide BTCFI with trading needs and blue-chip assets, but also provide many BTCFI projects with new ideas based on indexer-based programming to improve the ability of Bitcoin contracts Function, and even many projects that propose to build a smart contract platform on the first layer of Bitcoin use indexer-based programming schemes.
MuSig2: Decentralized mode to play with Bitcoin Restaking and LST
The multisig scheme enables a group of signers to produce a joint signature on a message, MuSig allows multiple signers to create an aggregate public key from their respective private keys, and then jointly create a valid signature for that public key, it is an application of Schnorr signatures, as we said earlier, the standard form of Schnorr signatures is (R, s), give (R, s'), as long as you know x is the secret value (secret), you can let s = s' + x, and get (R, s), The private key plus a nonce value is also used to generate the aggregate public key and valid signature.
The MuSig2 solution only needs two rounds to complete multi-signature, and the aggregate public key created by this method is indistinguishable from other public keys, improving privacy and significantly reducing transaction fees, and Taproot has upgraded to be compatible with the Musig2 multi-signature scheme, and its BIP proposal was released in Bitcoin BIP-327: MuSig2 for BIP340-compatible Multi-Signatures in 2022.
Liquid staking on Ethereum can be realized through smart contracts, Bitcoin lacks the contract capabilities required to achieve liquid staking, and as mentioned above, Bitcoin whales generally dislike centralized custodians and need MuSig2 to realize decentralized Bitcoin liquid staking, let's take Shell Finance's scheme as an example:
The user and Shell Finance calculate an aggregate public key and the corresponding MulSig2 multisig address P based on the private key data of both parties and the two nonce random numbers generated by the wallet.
PSBT transactions are constructed by Shell Finance, users and Shell Finance assets are pledged to Babylon from the multisig address P supported by MuSig2, and the wallet side provides nonce random number support again, and the aggregate public key corresponding to the multisig address is passed.
When the Babylon staking time ends, Shell Finance will construct a PSBT unlock transaction, and the user and Shell Finance will jointly sign to unlock the pledged assets.
The third-party wallet that generates the nonce random, the staking user and the LST project party jointly create the aggregate public key and signature, in this process, the user and the project party can only keep one private key, and no nonce value can generate the aggregate public key and signature to retrieve the funds; Wallets do not have private keys and cannot access funds. If the nonce value is generated by the project team, the project team is at risk of evil, and users need to pay attention.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
Unpublished Technical Documentation: No publicly available sources
The current application scenarios of BTCFI
Bitcoin programming is not complicated, it is even much simpler than Rust and other languages, its focus is on creating verifiable, trustworthy commitments, and being able to provide superior technical security than Ethereum, which delineates the boundaries for the development of BTCFI, the most difficult thing is what kind of PMF (project market fit) compliant BTCFI products can be developed within the boundary, just like when the Ethereum solidity contract was just launched, developers did not know that they could use it to develop x*y=k's amm algorithm is the same, but it first chooses to start exploring from the direction of ICO, order book, peer-to-peer lending, etc.
Liquidity enhancer: Babylon - the catfish in BTCFI
Babylon has built a set of staking protocols that are completely free of middlemen and no need to trust, which can directly stake a layer of bitcoin and obtain interest-bearing income, and at the same time can also withdraw bitcoin security and share it with the POS chain, as a general shared security layer, providing POS security guarantee for cosmos and other bitcoin layer2, and sharing bitcoin economic security.
Absolute security: One of the significant advantages of BTC staking over other forms of staking is that if the protected POS chain is attacked and crashes, the impact will not be spilled over to the staked Bitcoin. Specifically, if a POS chain is attacked and its token value is zeroed, users who hold the POS chain token will face losses; However, in the case of BTC staking, even if the protected POS chain is attacked and fails, the user's Bitcoin principal remains safe and unscathed.
Slashing mechanism: If a user has a double signature or other evil behavior on a PoS chain that is leased by Babylon, then EOTS (extractable one-time signatures) can unlock this part of the assets, and the execution role in the network will force a part of the assets to the burning address
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
At present, the Babylon mainnet has been launched, and the first phase of 1,000 BTC staking has been completed, and the second phase will be launched soon.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
https://btcstaking.babylonlabs.io/
At present, the BTC pledged in the first phase is dominated by large investors, accounting for 5% of the gas payment, and more retail investors may join in the second and third phases.
Attracting a huge amount of BTC to BTCFI staking for the first time:
Although Babylon does not provide the ETH-based income of POS itself as a basis like Ethereum, for some income expectations are not high, security is a priority, and is unwilling to accept solutions such as cross-chain wrap, inert large Bitcoin miners and even European, American and Asian funds that are optimistic about the Bitcoin ecology, 3-5% APY is also attractive, so when the total deposit is 100,000 BTC, only more than 100 million US dollars of equivalent token income is needed to meet.
Babylon is currently actively cooperating with well-known projects such as Cosmos Hub, Osmosis, Injective, etc., allowing them to become AVS in the future and provide their own tokens as Bitcoin re-staker rewards, which can further open Babylon's BTC deposit limit.
Babylon injects a lot of liquidity into the development of the BTCFI ecosystem, educates users and stimulates the vitality of the ecosystem
The vast majority of Bitcoin holders are unwilling to take risks for custody and cross-chain, which is equivalent to their first experience of BTCFI, and perhaps they may also experience LST and other gameplay for the first time.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
Babylon ecology only LST track has appeared StakeStone, Uniport, Chakra, Lorenzo, Bedrock, pSTAKE Finance, pumpbtc, Lombard, Solvbtc and other dozens of projects, and the rest of the various Defi projects, for the Bitcoin ecological project party that is difficult to obtain the initial TVL, you can use the power of Babylon's BTC Staking, Use LST to attract a batch of BTC, and its LST assets can also be used in your own ecological business.
Since the income generated by Babylon is denominated in the form of tokens instead of BTC/ETH, the attraction of this giant is limited, and the overall pattern will not be as centralized as ETH staking, but because the profits that its tokens can generate are also uncertain, there are opportunities for early-stage startups that can find another way.
The Bitcoin mainnet is expected to give birth to multiple blue-chip LST assets, generating demand for BTCFI
Babylon has created a new track of native BTC pledge to earn interest, allowing the 100 billion scale of the sleeping mainnet BTC for the first time to have a large-scale application scenario, a large number of pledged BTC derived from a large number of liquidity staking tokens, these BTC-derived pledge certificates can become natural blue-chip collateral for scenarios such as mortgage lending, so that lending, stablecoins and Swap that are BTCFi based on Bitcoin's native assets have the conditions to develop.
The core reason for the difficult development of BTCFi is that the Bitcoin mainnet has lacked high-quality assets for a long time, which directly leads to the lack of collateral for lending, the lack of transaction exchange demand for swaps, and the lack of depth in the pool. Currently, the only blue-chip assets on the Bitcoin mainnet are sats and ordi in brc20 and node monkey in ordinals NFT.
However, if a part of the staking amount in Babylon can derive liquidity staking tokens, just like the steth issued by lido on Ethereum, it can become collateral for loans such as AAVE and compound, and form a very high transaction depth on uniswap, BTCFi will have the conditions for development.
Think about it, perhaps many stakers hope to be able to lend BTC through liquidity staking tokens, or use it for nesting dolls to put in staking, or to hedge risks.
Asset issuance innovation: unisat and magic eden are two DEXs that will be launched soon
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
Unisat's brc20 swap will be launched in September, and Renes will also be supported by mapping Runes to brc20, and subsequent tokens can be issued and traded by adding liquidity pools, without the need to raise gas mint tokens, or trade token inscriptions one by one like trading NFTs, to achieve batch trading.
Magic eden的runes dex也将在今年Q4上线。
A fully BTC-native peer-to-pool lending stablecoin protocol will go live
Liquidium is a borrowing and lending that is built entirely on the Bitcoin mainnet through the aforementioned Partially Signed Bitcoin Transactions (PSBT) and the Prudential Journal Contract DLC, specifically:
The lender fills in the offer, including LTV (the ratio of debt quantity / collateral), interest, floor price, etc., and deposits Bitcoin.
The borrower chooses a lender based on the offer on the platform and deposits NFT or Runes assets.
It was launched in October 2023 and received 2,227 BTC trading volume in less than a year after its launch, indicating that there is a demand for BTCFI lending for Bitcoin mainnet assets.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
https://dune.com/shudufhadzo/liquidium
The core problems are:
Inefficient use of funds: If no borrower takes the initiative to accept the offer, the lender's bitcoin will be idle, and there will be a fee for each order cancellation, in other words, it does not have the order matching function, and there is a process of discovery.
Peer-to-peer liquidation: The liquidator here has only the borrower and the borrower, and no one else can participate.
Once the NFT or RUNES falls below the borrowed value under LTV, the lender will not repay, and the person who offers the offer can only get the NFT or rune, which is equivalent to bearing the risk of falling.
On the other hand, as long as the borrower's NFT or RUNES falls, they will 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 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/
Shell Finance uses the synthetic stablecoin $bitUSD to maximize the liquidity in lending and clearing scenarios, realizes the Bitcoin version of peer-to-pool lending, and is expected to achieve a strong scale effect in the future through the positive flywheel of $bitUSD borrowing and repayment.
In the process of clearing and structuring transactions, the Prudential Contract DLC and partially signed PSBT are also used to achieve no custody and decentralized liquidation of borrowed collateral and funds, specifically:
Borrowers can stake Ordinals NFTs, BRC-20 and Runes assets within the platform (and in the future, other assets on the first layer of Bitcoin, such as assets issued by the Arch network and RGB++ mapped assets), and borrow synthetic assets $bitUSD.
By building a liquidity pool for the BTC/BitUSD trading pair in the swap of unisat and magic eden, borrowers can exchange synthetic assets $bitUSD for BTC, and LPs can earn fee income in the borrower's exchange.
At the time of repayment, the borrower needs to return BitUSD to the protocol, and there is a need to exchange BTC to BitUSD.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
https://shellfinance.gitbook.io/shell
At the time of liquidation, BitUSD is also liquidated, and anyone can participate in the liquidation of positions to be liquidated. When a vault is liquidated, the liquidator needs to pay the debt and get back the corresponding collateral asset, and the difference between the collateral asset and the market net value is the liquidator's income. Taking a loan with 30 $ORDI collateral and 600 $BitUSD of assets as an example, the liquidation process of the position is as follows:
When the price drops below 28.5 USD, the LTV is below 80%. Therefore, the position reaches the liquidation line, and the position opens the liquidation state;
For the current collateral asset value of 855 USD, a 48-hour auction of Netherlands positions will be opened. Bidders are required to provide $BitUSD to acquire the pending asset, with a starting price of 855 BitUSD and an ending price of 600 BitUSD, with the auction price decreasing linearly over time.
When the liquidator clears through the Netherlands auction, the liquidator enters 700 BitUSD priced through the auction, and the remaining 100 BitUSD after Shell Finance deducts the 600 BitUSD debt that needs to be repaid will be added to the insurance fund.
After Shell Finance checks the liquidator's transaction information, the collateral assets are added to the PSBT, and the liquidator can get 30 Ordi of collateral in the vault
Shell Finance's starting oracle reveals the "Secert secret value", which can complete the signatures of participants (lenders and protocols) to perform the operation of transferring collateral from the vault to the liquidator's 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 can borrow in batches, and its APY is only 10%, which can support longer-term borrowing.
As we mentioned above, Shell finance is still using MuSig2 as an LST for Bitcoin, using LST assets as a new collateral and then giving BitUSD to stakers, which expands the application flywheel of BitUSD and increases the project ceiling.
A number of BTCFI expansion solutions based on UTXO were launched
The Bitcoin community generally believes that the BTC Layer2 innovation and ceiling of the EVM system are very low, but if you want to explore more complex BTCFI, you need a stronger Bitcoin contract.
We categorize according to whether these extensions are settled on the Bitcoin mainnet.
If you settle on the Bitcoin mainnet, you can reuse the liquidity of the mainnet, and you can directly compatible with assets such as Runes without cross-chain.
If you don't settle on the Bitcoin mainnet, you'll need to deposit assets across chains.
BTCFI expansion scheme for Bitcoin mainnet settlement
Arch Network: With the expansion of computing power as the core, the off-chain ZKVM builds a smart contract network
Arch leverages a decentralized network of validator nodes and a Turing-complete zero-knowledge virtual machine (zkVM) built outside of the Bitcoin mainnet to integrate with the Bitcoin mainnet, which allows it to share liquidity with the Bitcoin mainnet and integrate asset protocols such as Runes with indexers:
ZKVM: After each smart contract execution, Arch zkVM generates ZK proofs, which are used to verify the correctness of the contract and state changes
Decentralized network: The generated ZK proofs are then verified by Arch's network of decentralized validator nodes. The network plays a vital role in maintaining the integrity and security of the platform. By relying on a decentralized architecture, Arch strives to ensure 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, as determined by the application logic, are ultimately passed back to Bitcoin. This final step completes the execution process, and all transactions and status updates are finalized directly on the Bitcoin blockchain.
UTXO model: Arch's state and assets are encapsulated in a UTXO, with state transitions through a single-use concept. The state data of the smart contract is recorded as state UTXOs, while the original data assets are recorded as Asset UTXOs. Arch ensures that each UTXO can only be spent once, providing secure state management
DeFi applications that want 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
By introducing a sandbox environment with its own indexer, sandbox parser (instruction set), and global database, AVM provides Atomicals with an advanced execution environment capable of handling smart contracts and dApps, with custom instruction sets for enhanced performance, while reducing gas fees and optimizing state transitions to increase parallel processing power, resulting in increased throughput and scalability. At the same time, AVMs enable interoperability and cross-chain communication.
In the sandbox operating environment, the entire simulator is in a controlled and isolated environment, so that the execution in the sandbox and the execution outside the sandbox do not interfere with each other;
State hashing, which allows participants to verify that the state of their indexers is properly synchronized, prevents the potential for aggressiveness of state inconsistencies.
AVM enables the Atomicals protocol to perform a variety of BTCFI tasks, more than just a simple token issuance mechanism.
BTCFI scaling scheme based on UTXO binding but not settled on Bitcoin mainnet
Fractal Bitcoin: Leverage the existing Bitcoin architecture to extend the BTCFI system in parallel
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
Fractal Bitcoin is a self-replicating extension that wraps the entire Bitcoin Core into a deployable and operational blockchain package called the Bitcoin Core Package, which can independently run one or more BCSP instances and be linked to the Bitcoin mainnet through recursive anchoring.
Fractal Fractal produces a block in 30 seconds, which can be 20 times faster than the Bitcoin mainnet that produces a block in 10 minutes, and indiscriminately supports and is compatible with all protocols on the main chain (such as Ordinals and brc-20), and runs synchronously with the main chain at different physical settlement rates, and mainnet miners can mine a Fractal block every 90 seconds. At the same time, Fractal retains the optional ability to settle and anchor via inscriptions on the mainnet.
On the one hand, Fractal is relatively consistent with the consensus of the main chain and is easy to communicate at the protocol level.
On the other hand, it was able to get rid of the physical constraints and historical baggage of the main chain, remove some codes that once existed in history but no longer have practical significance, and streamlined the implementation of the system on the premise of retaining complete consensus, and obtained a more concise and lightweight implementation.
It will implement OP_CAT and other opcode proposals faster than the BTC mainnet, which is consistent with the basic path of Bitcoin upgrade, but the upgrade speed is faster, and the inscribed BTCFI contract can be implemented through scripts in the future.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
50% of Fractal's tokens are generated by mining, 15% to ecological projects, 5% to investors, 20% to advisors and core contributors, and 10% to build partnerships and liquidity, which shows 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 merged-mining, ASIC miners and mining pools can use existing mining rigs to mine the Bitcoin mainnet and mine Fractal at the same time, that is, to incentivize miners through Fractal Bitcoin earnings, while using their computing power contributions to protect the network from potential 51% attacks.
Fractal Bitcoin activates OP_CAT directly when the mainnet goes live. 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 wrapped assets.
HTX Ventures: Exploring the Rabbit Hole of BTCFI from a Bitcoin Programmability Perspective
In general, compared to the Bitcoin mainnet, which focuses on high-value assets, Fractal Bitcoin focuses on the storage of sub-important assets, providing a fertile ground for asset innovation and application innovation, but it remains to be seen whether Fractal Bitcoin will be able to emerge as a blue-chip asset and high-quality applications.
RGB++: Development of BTCFI unique to UTXO model
RGB++ leverages Turing-complete UTXO chains (such as CKB or others) as shadow chains to process off-chain data and smart contracts, further enhancing Bitcoin's programmability.
The UTXO of the shadow chain and the UTXO of Bitcoin are homogeneously bound to ensure the consistency of state and assets between the two chains and ensure security. Therefore, RGB++ can support assets on the Bitcoin mainnet such as Runes, and RGB++ assets can also be mapped directly 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
RGB++ takes full advantage of the UTXO model and is able to implement many unique BTCFI features:
Bridgeless cross-chain Leap through UTXO isomorphic binding: Assets on RGB++ can jump back and forth between the Bitcoin mainnet and L2 or L2, which can avoid many risks of traditional cross-chain bridges, and also have 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: as long as the input and output information required in a transaction is signed and submitted to the chain for verification, such as UTXO input and an output that undertakes asset purchase, to bid for asset transactions, and the transaction details in between.
UTXOSwap has been launched on mainnet: the actual experience is almost no different from Uniswap. UTXOSwap divides each transaction into two steps, the first step is for the user to submit their intention to the chain, and the second step is for the Aggregator to aggregate everyone's intentions, and after the merge, initiate a transaction to interact with the liquidity pool.
UTXO has a mechanism for nesting contract scripts, which only needs to be operated once, and a series of transactions can be generated continuously, simplifying the user's account delivery 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 soaring price will eventually drive the development of BTCFI in the future
Although we may be pessimistic about BTCFI because of the current depression in the inscription market and the decline of Bitcoin, it is necessary to remember that the biggest difference from other ecosystems is that Bitcoin will continue to rise in the future and will continue to attract new retail investors, and there is no doubt that Bitcoin has become a high-frequency word in this year's United States election, United States will legalize Bitcoin as a federal reserve and Russia mining in the future, and the current mainstream society is actively embracing Bitcoin, Moms with babies and every Uber driver at the Bitcoin conference in Nashville have become or are preparing to become Bitcoin holders as a safe-haven asset.
When Bitcoin breaks through new highs, various Bitcoin-denominated assets in the Bitcoin ecosystem will also rise, which will naturally stimulate the market demand for BTCFI, such as collateralizing assets to lend funds to buy more new assets; For example, trying to stake it to earn interest.
There's another fact that's easy to overlook:
In the last two cycles, Ethereum assets such as ICOs and NFTs are a strong culture, and new crypto users may see celebrities sending NFTs into the circle, and often choose to use Ethereum wallets such as metamask, and are also used to buying Ethereum for airdrops, memes and other interactions, and idle Ethereum for participating in Defi.
In this cycle, Bitcoin has become a strong culture, users may be because they see the Bitcoin elements in the United States election into the circle, and then it may be that Bitcoin continues to break through new highs into the circle, often choose to use Bitcoin wallets such as Unisat first, and get used to buying Bitcoin, and their idle BTC may also be used to participate in BTCFI.
There was always a feeling that Bitcoin should return to the digital gold narrative, 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 that will be at the forefront of BTCFI innovation, attracting new Bitcoin holders and educating other Bitcoin bigwigs and miners.
—----------------------------------------
关于 HTX Ventures
This article was written by the research team at 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 over 11 years of experience in blockchain construction and specializes in identifying cutting-edge technologies and emerging business models within the space. To drive growth within the blockchain ecosystem, we provide comprehensive support for projects, including financing, resources, and strategic advice.
HTX Ventures currently supports more than 300 projects across multiple blockchain sectors, and some high-quality projects have been traded on Huobi HTX. In addition, as one of the most active FOF funds, HTX Ventures invests in 30 top funds around the world and cooperates with the world's top 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 to invest and cooperate, please do not hesitate to contact [email protected]
disclaimer
1. HTX Ventures has no affiliation with the projects or other third parties involved in this report that affects the objectivity, independence or impartiality of the report.
2. The information and data cited in this report have been obtained from compliance sources and are believed to be reliable by HTX Ventures and have been verified for their authenticity, accuracy and completeness as necessary, but HTX Ventures does not guarantee their truthfulness, accuracy or completeness.
3. The content of the report is for reference only, and the conclusions and opinions in the report do not constitute any investment advice for the relevant digital assets. HTX Ventures shall not be liable for any loss arising from the use of the contents of this report, except as expressly provided by laws and regulations. Readers should not make investment decisions based on this report alone, nor should they lose their ability to make independent judgments based on this report.
4. The information, opinions and projections contained in this report only reflect the judgment of researchers as of the date of finalization of this report, and there is a possibility that opinions and judgments may be updated in the future based on industry changes and data and information updates.
5. The copyright of this report is only owned by HTX Ventures, if you need to quote the content of this report, please indicate the source. If you need to quote a large amount, please let us know in advance and use it within the scope of permission. Under no circumstances may this report be quoted, abridged or modified in any way contrary to its original intent .
