Written by: HTX Ventures
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 Ethereum's 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 MuSig2, 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 Ethereum's DeFi protocol. WBTC's 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
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 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 sender's conditions are met.
A "script" is just a "predicate". It's actually just a function that evaluates to either true or false. But predicate is a long and uncommon word, so I'll 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 every possible transaction type I designed many years ago. This includes 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 Nakamoto's design fourteen years ago laid the foundation for Bitcoin programming. The Bitcoin network does not have the concept of "accounts", but only "outputs", whose full name is "transaction outputs" (TXO), which represent a sum of Bitcoin funds and are the basic unit of the Bitcoin system state.
When you spend an output, you make it the input of a transaction, or provide funds 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 Bitcoin's 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 must be provided, namely the unlocking script, also called the script signature (scriptSig). 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 P2PKH (pay to public key hash) script in Bitcoin.
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 Ming's public key in the locking script of the UTXO (and add an operator to check the signature). In this way, only Xiao Ming's private key as the signature of Xiao Ming's 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 form is M ... N OP_CHECKMULTISIG means that it records n public keys, and the signatures of m public keys are required to unlock this UTXO.
For example, the signatures of two of the three people (or three public keys) Alice, Bob, and Chloe can spend this script, and its script code is: 3 OP_CHECKMULTISIG, OP_CHECKMULTISIG is the opcode that verifies that the signature matches the provided public key.
Uses include:
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 wallet manufacturers from doing evil. M manufacturers must conspire to withdraw funds.
Transaction Arbitration:
Assume that Alice and Bob want to make a transaction, such as buying ordinarys 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 ordinarys 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 been optimized 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 whether 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 opcode, 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 is 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, for example, the 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 form of the hash lock is OP_HASH160 OP_EQUAL , verify that 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 pledge transaction also uses MAST, which improves the efficiency and privacy of the transaction, 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 signer's expectations or entrustment of the purpose of the signature. For example:
SIGHASH_SINGLE | ANYONECANPAY signs the input and the output with the same index number as the input, and the rest of the input and output 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, and the unlocking script provides data. 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:
There are only a limited number of available verification procedures: implementing zero-knowledge proof or other verification procedures requires a fork, so the BTCFI expansion solution Fractal launched by unisat, although 100% consistent with BTC, is also partially separated from the Bitcoin mainnet in terms of liquidity and security in order to implement "controversial" operation code proposals such as OP_CAT and ZK native verification OPCode.
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, which 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.
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 BTCFI's 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 by Tadge Dryja (research scientist) and Gert-Jaap Glasbergen (software developer) at the Digital Currency Initiative at MIT in 2017 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 layman's terms, the standard form of a 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 place bets on opposite outcomes of a sports match (assuming no draw), each betting 1 $BTC. Whoever predicts the winner wins the entire 2 $BTC stake. They lock the stake 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 is involved in the DLC. Its job is strictly limited to providing the outcome, and once the event occurs, the oracle publishes a cryptographic proof, called a commitment, indicating 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, and 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.
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 status. DLC allows the liquidator to liquidate the position without permission in the pending liquidation state, while ensuring that it cannot operate the user's 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 below 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 asset ownership remains unchanged.
Then, we need the oracle to commit to publish 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 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), and the protocol can then complete the counterparty’s adapter signature and add its own signature, making the above transaction a valid transaction, broadcasting it to the network and 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 be 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, which 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 Transaction (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 PSBT 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 don't trust each other, what do they need to do to ensure the safety of their funds?
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 Yuga's address for escrow, which seriously threatened the security of the funds.
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. BIP340 (BIP-Schnorr): Supports multiple parties signing a single transaction, as well as the aforementioned DLC application of the cautious log contract, which requires that predetermined conditions be met before a transaction can be executed. The amount of data they commit to Bitcoin is the same as the amount of data in a standard single-signature transaction.
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 (P2SH) transactions, MAST allows users to selectively disclose part of the script on demand, improving privacy and efficiency. MAST is also well used in Babylon's BTC pledge transactions, building its multiple locking scripts into a transaction containing multiple scripts, three locking scripts:
TimeLockScript time lock, to achieve the lock function of pledge;
UnboundingPathScript Unstaking: realize the function of terminating the pledge in advance;
SlashingPathScript: Implementing 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
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 (P2TR) addresses, starting with bc1p, 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 that 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 (P2TR) address.
Since the consumption of Taproot scripts can only be done from existing Taproot outputs, inscriptions are minted using a two-stage commit/reveal process. First, in the commit transaction, a Taproot output is created that promises to contain the 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 BRC20: 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 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 uses inscriptions 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 user's BRC-20 tokens. This may result in different results for queries on a certain account balance on different platforms.
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 programming to enhance the capabilities of Bitcoin contracts. The combination of Json's "op" field can further evolve into inscription-based defi and even socialfi and gamefi, including AVM, tap protocol, brc100, unisat's swap function, and even many projects that propose to build a smart contract platform on the Bitcoin layer all use solutions based on indexer programming.
MuSig2: A decentralized model 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 valid signature.
The MuSig2 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. The Taproot upgrade is 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.
Liquidity pledge on Ethereum can be achieved through smart contracts. Bitcoin lacks the contractual capabilities required to achieve liquidity pledge. As mentioned earlier, Bitcoin whale generally dislike centralized custodians and need MuSig2 to achieve decentralized Bitcoin liquidity pledge. Here we take Shell Finance's solution as an example:
The user and Shell Finance calculate an aggregated public key and the corresponding MulSig2 multi-signature address P based on the private key data of both parties and the two nonce random numbers generated by the wallet.
Shell Finance constructs the PSBT transaction, and the user and Shell Finance assets are pledged to Babylon from the multi-signature address P supported by MuSig2. The wallet again provides nonce random number support and passes in the aggregated public key corresponding to the multi-signature address.
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 pledge user and the LST project jointly create the aggregate public key and signature. During this process, the user and the project can only keep one private key. Without the nonce value, the aggregate 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 pay attention.
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 layer2, 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 affect 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 user's Bitcoin principal is still safe and intact.
Severance mechanism: If a user has double-signing or other malicious behavior on a PoS chain that is leased security 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.
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.
https://btcstaking.babylonlabs.io/
Currently, the BTC pledged in the first phase is 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 and other solutions, and even European, American and Asian funds that are optimistic about the Bitcoin ecosystem, 3-5% APY is also attractive. Therefore, when the total deposit amount is 100,000 BTC, only the 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 Injective. Allowing them to become AVS in the future and provide their own tokens as rewards for Bitcoin re-stakers can further open up Babylon's 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 Layer2 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.
In the LST track of Babylon ecosystem alone, there are dozens of projects such as StakeStone, Uniport, Chakra, Lorenzo, Bedrock, pSTAKE Finance, pumpbtc, Lombard, Solvbtc, etc., and there are various Defi projects in the rest. For Bitcoin ecosystem projects that find it difficult to obtain initial TVL, they can use the power of Babylon's 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 BTCs 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 Swap, namely BTCFi, based on Bitcoin native assets.
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 brc20 and node monkey in ordinarys 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, it can become the collateral for loans such as aave and compound, and form a very high trading depth in uniswap, then BTCFi will have the conditions for development.
Imagine that perhaps many stakers hope 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
https://docs.unisat.io/knowledge-base/brc20-swap-introduction
https://magiceden.io/runes/DOG%E2%80%A2GO%E2%80%A2TO%E2%80%A2THE%E2%80%A2MOON
Unisat's brc20 swap will be launched in September, and will also support Renes by mapping Runes to brc20. Subsequently, tokens can be issued and traded by adding liquidity pools. There is no need to raise 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 Discreet 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 the existence of BTCFI lending demand for Bitcoin mainnet assets.
https://dune.com/shudufhadzo/liquidium
The core problem is:
Low efficiency in capital utilization: If no borrower actively accepts the offer, the lender's 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.
Peer-to-peer clearing: The clearing agents here are only the borrower and the lender, and no one else can participate.
Once the 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 the NFT or RUNES, which means they bear the risk of falling.
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 term can only be limited to more than ten days, and the APY is very high.
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 synthetic stablecoins $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 partially signed 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) to borrow synthetic assets $bitUSD.
Build a BTC/BitUSD trading pair liquidity pool in the swap of unisat and magic eden. Borrowers can exchange synthetic assets $bitUSD into BTC, and LP can obtain transaction fee income from the borrower's exchange.
When repaying the loan, the borrower needs to return BitUSD to the agreement, and at this time there is a need to convert BTC into BitUSD.
https://shellfinance.gitbook.io/shell
During 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 take back the corresponding collateral assets. The price difference between the collateral assets and the market net value is the liquidator's income. Taking a loan with 30 $ORDI as collateral and 600 $BitUSD as an example, the position liquidation mainly follows the following process:
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;
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.
When the liquidator conducts liquidation through the Dutch 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 included in the insurance fund.
After Shell Finance checks the liquidator's transaction information, it adds the collateral assets to PSBT, and the liquidator can obtain the 30 Ordi collateral in the vault.
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 liquidator's address. The price oracle will automatically close the corresponding DLC process.
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 MuSig2 to develop Bitcoin's LST, using LST assets as a new collateral and then giving BitUSD to pledgers, which further expands the application flywheel of BitUSD and increases the project's ceiling.
A batch of UTXO-based BTCFI expansion solutions are launched
The Bitcoin community generally believes that the EVM-based BTC Layer2 has a very low innovation and upper limit. 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, and innovated the BTCFI model based on the UTXO model. We classify these expansion solutions 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 done 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 generates 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 vital 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 the unsigned transactions. These transactions, including state updates and asset transfers determined by the application logic, are eventually 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: Arch's 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 such as lending and decentralized exchanges that wish to be compatible with Bitcoin mainnet assets can be built on Arch.
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 that was previously available.
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
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 executable 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 main network 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.
https://fractal-bitcoin.notion.site/Fractal-Bitcoin-Public-b71cbe607b8443ff86701d41cccc2958
Mining Incentive Model
50% of Fractal's 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 Bitcoin mainnet and Fractal at the same time, 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.
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 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 UTXO of the shadow chain is isomorphically bound to the UTXO of Bitcoin, ensuring the consistency of the state and assets between the two chains and guaranteeing security. Therefore, RGB++ can support assets of the Bitcoin mainnet such as Runes, and RGB++ assets can also be directly mapped to the Bitcoin mainnet and extended to all Turing-complete UTXO chains.
https://github.com/ckb-cell/RGBPlusPlus-design/blob/main/docs/light-paper-en.md
RGB++ fully leverages the advantages of the UTXO model and can implement many unique BTCFI functions:
Bridgeless cross-chain Leap is achieved through UTXO isomorphic binding: assets on RGB++ can jump back and forth between the Bitcoin mainnet and L2 or 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: it can be completed by simply submitting the signatures of the desired input and output information in a transaction for on-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 everyone's 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 user's 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 year's 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 stake them to earn interest.
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 chose 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 ordinarys 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.
