Exploring the origin of Bitcoin’s DeFi: Why is application expansion so complex?

The process of developing tokens, NFTs and DeFi on Bitcoin is actually much more complicated than it seems on the surface. For example, smart contracts are Turing complete on Ethereum Virtual Machine (EVM) and other smart contract platforms, which means that new features or options can be added by just deploying a custom contract. But in Bitcoin, developers must be careful to innovate without triggering a hard fork, and can only operate within the limitations of existing protocol functions. As we mentioned in the previous article, one of the key factors in the reason why Bitcoin has unique importance and value is its persistence in "primitiveness". The main chain has hardly experienced much changes over time.

Despite this, Bitcoin is the first blockchain to be widely adopted. Many subsequent technologies implemented on more flexible blockchains have actually appeared on Bitcoin. In fact, NFTs originally appeared on Bitcoin in the form of "Colored Coins"; the concept of State Channels is quite similar in design to today's L1-L2 architecture; and Atomic Swaps lays the foundation for modern cross-chain bridges. We have partially introduced these developments in the previous article "From Bitcoin: The True Origin of DeFi". But to truly understand the unparalleled value of Bitcoin as the infrastructure of Botanix and other Bitcoin chains, we need to have a deeper understanding of how these early innovations pave the way for today’s ecosystem. Although Bitcoin itself is relatively "simple", it is actually one of the most complex and fascinating ecology in the Web3 field, with the richest history.

Discussing Bitcoin’s functional theory: Is Bitcoin’s capabilities

sufficient to support complex ecology?

When Bitcoin was launched in 2009, a scripting language was built-in, which not only enables simple payments, but also supports more complex operations such as multi-sig and time-lock from the beginning. Satoshi Nakamoto even described that unconfirmed transactions using nLockTime and sequence number can be updated multiple times between the two parties for high-frequency transactions, only the final state will be written to the chain.

Bitcoin Script is a very interesting mechanism: on the one hand, it is incomplete and limits its functionality; on the other hand, it also keeps it simple and secure. Therefore, when building any complex functionality on Bitcoin, developers must design within the framework provided by Script. It contains a large number of commands (Opcode) for programming various actions, which will eventually be written into the transaction data.

Bitcoin Script is the script language ontology used by Bitcoin to define the spending conditions of coins. You can understand Script as a recipe—a complete set of steps to bake a cake. Opcodes is the building block of this language -they are basic instructions used by programmers when writing scripts, such as "mixing", "heating", etc. To understand the functionality of Script more clearly, we briefly review the most common script types:

• P2PK (Pay To Public Key) - This is the most primitive BTC transfer method, which was later replaced by P2PKH. It consists of several Opcodes, such as: OP_DATA_65 OP_CHECKSIG OP_DATA_33 OP_CHECKSIG.

• P2PKH (Pay To Public Key Hash) ——The script form is: OP_DUP OP_HASH160 OP_DATA_20 OP_EQUALVERIFY OP_CHECKSIG. This script quickly became mainstream because it uses a 32-byte public key hash to optimize transaction size, which saves space compared to a 64-byte P2PK. The smaller the transaction data, the lower the fees—this is especially important in the context of increased Bitcoin usage and handling fees.

• Store any data – This type of script is usually locked in a very small amount and is mainly used to store ASCII text, links, or scripts. For example: OP_0 OP_DATA_20 # 20 bytes of custom data. In addition, there is also a standardized way to use OP_RETURN to store data. For example, the Bitcoin Color Coin Protocol (the predecessor of NFT) embeds token metadata through OP_RETURN.

A study by NCC Group summarized 156 different Script patterns and conducted a detailed analysis of these script structures.

So, can we try to organize DeFi-like mechanisms on Bitcoin using Script? Let's continue to discuss the next step.

Lending mechanism:

As we mentioned earlier, opcodes can be used in combination to build a series of small instruction chains to achieve more complex behaviors. For example, developers can construct complex scripts with lending contract functions by combining opcodes. This can be achieved by combining time locks and multiple signs:

• OP_CHECKSEQUENCEVERIFY (CSV): Used for relative time locks (for example, locking X blocks of funds after a transaction);

• OP_CHECKLOCKTIMEVERIFY (CLTV): Used for absolute time locks (for example, a loan expires at a specific block height or timestamp);

• OP_CHECKMULTISIG (or multiple OP_CHECKSIGs cooperate with OP_ADD): requires multiple parties to sign together;

• Conditional logic opcode OP_IF / OP_ELSE: Define different expenditure paths (such as repayment vs default).

These tools can implement "bilateral hosting contracts with timeout capabilities". For example: Suppose Alice provides BTC as collateral and Bob lends her stablecoins offline. They want to set the following rules through the contract: Bob will get her BTC if Alice expires and has not repaid; if it is repaid on time, BTC will be unlocked and returned to Alice. To do this, they can use a 2-of-2 multi-signal output (both Alice and Bob both require signatures to use funds). They can then set the script logic: If the payment has not been paid after reaching a certain block height, only Bob can use the funds alone.

However, there is still a major difficulty here: Bitcoin itself cannot automatically calculate interest, monitor collateral rates, or enforce liquidation. Any interest payment must be done off-chain or achieved with the help of pre-signature transactions (which is quite complex in practice). If the BTC price falls during the loan period, the Bitcoin script itself cannot know and it will not automatically trigger liquidation. To achieve this function, it is necessary to use oracles or off-chain protocols. Without oracles, the contract can only be judged based on the final expiration time.

Therefore, it is very difficult to directly implement trustless BTC-solidated stablecoin lending on the first layer of Bitcoin. Current practice methods usually rely on trusted third parties, or indirectly implemented with the atomic exchange mechanism on other chains.

AMM Features:

As mentioned above, the lending and pledge mechanism can theoretically be implemented through Bitcoin Script, but it is less efficient in actual operation. However, we can still explore whether it is possible to build more complex mechanisms like automated market makers (AMMs) on Bitcoin. The Bitcoin script contains mathematical opcodes such as OP_ADD, OP_SUB, and OP_MUL (although some of them have been disabled), and there are comparison opcodes similar to OP_LESSTHAN. In theory, these functions can be used to implement price calculation logic.

In theory, developers can construct a script with built-in fixed prices or a set of predefined acceptable price points, but cannot dynamically adjust prices after each transaction. The reason is that Bitcoin adopts the UTXO model, and each transaction generates new UTXO and scripts, so each possible state must be pre-calculated, or a contract needs to be redeployed after each transaction.

Another key factor in AMM implementation is asset exchange capabilities. In theory, Bitcoin supports Atomic Swaps, which can be built into an order book form rather than a liquidity pool. AMM-like behavior can also be simulated by building a series of HTLCs (hash time lock contracts) or publishing pending orders at different price points, thus forming a static automatic market making system (similar to a return curve). However, maintaining such a system is very cumbersome. After each transaction, you need to manually update the script and re-release UTXO, which is extremely costly on-chain.

Therefore, although AMM can be built in theory, it actually faces a bigger problem: only one native asset, BTC, exists on the main website of Bitcoin. Although the Omni protocol provides a token mechanism, these assets exist in the metadata of the transaction and cannot be recognized and processed by scripts. Therefore, real asset-to-asset exchange or liquidity pool maintenance cannot be achieved through Bitcoin Script. In addition, Bitcoin’s UTXO model does not support a single contract holding multiple-party funds at the same time and updating part of the balance – new transactions and multi-party signatures are required for each state change.

Extended Script functionality:

The above points explain why Bitcoin is regularly updated to enhance its functionality. One of the important updates is Taproot, which was introduced through soft forks, but has greatly changed the way Script is designed.

Taproot's OP_SUCCESS mechanism:

With the introduction of the Taproot upgrade (BIP 342), many of the previously disabled or retained opcodes (opcodes) were converted to OP_SUCCESS opcodes in Tapscript (i.e. SegWit v1 script). OP_SUCCESS indicates that the script will be terminated successfully immediately as long as the opcode is executed. This design makes it easier and safer to add new opcodes through soft forks. Specifically, in Tapscript, if the value of the opcode is within a specific range (for example: 0x50, 0x62, 0x7E–0x81, 0x83–0x86, 0x89–0x8a, 0x8d–0x8e, 0x95–0x99, 0xbb–0xfe), it will be considered OP_SUCCESSx. Once these opcodes are encountered, the script will unconditionally determine that it is successful and ignore other logic.

This mechanism replaces the old OP_NOP (empty opcode) upgrade method, bringing higher security and flexibility. Future soft forks can redefine the behavior of an OP_SUCCESS opcode, and older version nodes will still regard it as "script success", thus avoiding invalid transactions due to version inconsistencies. In summary, all opcodes that are not listed as "available" are either reserved and unused or have been converted to always return successful OP_SUCCESS in Taproot.

Another important aspect is that the opcode can be proposed through the BIP (Bitcoin Improvement Proposal) process, and there are currently some powerful proposals under consideration or have been rejected. Some of these proposals, if adopted, will significantly expand the capabilities of Bitcoin, allowing it to perform more complex operations:

• OP_CAT (connection operator): is used to enhance the ability to combine and process data in Bitcoin scripts, greatly improving expression capabilities. OP_CAT originally existed in early Bitcoin (disabled in 2010), and its function is to take out two byte strings from the stack and connect them before pushing them into the stack. This simple but powerful operation can be used to dynamically build messages and calculate Merkle tree hashing in scripts and other complex logics. The proposal recommends that the result after a connection is limited to no more than 520 bytes (i.e. the maximum stack element limit).

• OP_CHECKSIGFROMSTACK / OP_CHECKSIGFROMSTACKVERIFY (OP_CSFS for short): This opcode can realize oracle-based script verification. For example, a script can verify whether the signature information of an external condition (such as price or event result) comes from a specific oracle. Despite the simple execution logic, OP_CSFS can unlock new capabilities for Bitcoin. For example: the oracle signs a message “BTC falls below $20,000 at point X” and the lending script verifies this signature through OP_CSFS, allowing the lender to liquidate the collateral—a process that does not require a third party to keep the private key. In addition, after the borrower repays the loan, the oracle or lender can sign "Repayment received" and return the collateral after verification of the script. Without OP_CSFS, such automatic contracts based on external conditions will either not be implemented or can only be completed through an oracle as a joint signer, which poses a higher risk of trust.

• OP_CHECKTEMPLATEVERIFY (OP_CTV for short): This opcode allows users to pre-set the future usage of their Bitcoin, for example: they can only transfer money to a certain set of addresses, or they can only be spent if they meet certain handling fees. OP_CTV can be used to build batch transactions, channel factories, and other advanced use cases based on the "covenant" mechanism to ensure that certain predefined rules are enforced.

But why are these opcodes still not approved?

The main reason may be: the Bitcoin developer community is extremely cautious about maintaining the original form of Bitcoin.

On the one hand, the introduction of new features can indeed enhance the availability and scalability of Bitcoin; on the other hand, Bitcoin itself is a network designed to be "slow", and this "slow" is also regarded to be its "original" feature to some extent. For example, taking OP_CSFS as an example to apply to the clearing mechanism, speed is a key factor. If the market crashes and the BTC price falls sharply, a paradox may arise:

First, blockchain load soared and network speeds further declined;

Secondly, the transaction processing speed in the Bitcoin network will lag significantly, and the price has long been out of the current market level, while centralized and decentralized exchanges (CEX and DEX) have long been responding quickly.

It is very likely that the price has rebounded before the on-chain liquidation transaction is completed.

Therefore, Bitcoin itself runs slowly and has extremely high transaction fees when it is high load, making the attempt to implement DeFi-related mechanisms on the main network basically meaningless.

Because of this, developers have gradually come to a more reasonable conclusion: expansion layers should be built on top of Bitcoin. This is actually the predecessor of Rollup's idea - that is, the concept of "proto-payment channel": by supporting multiple micro transactions off-chain, it is finally compressed into an on-chain settlement transaction.

As early as April 2011, Namecoin, the first code branch of Bitcoin, was launched, which achieved decentralized domain name registration (DNS ".bit") through Bitcoin technology.

Namecoin’s case—storing “name-value” pairs on chains—presents for the first time: Bitcoin designs can be used not only for currency transactions, but also for other assets, although independent blockchain structures may be required. These concepts lay the foundation for subsequent asset tokenization, decentralized transactions, and Bitcoin’s off-chain expansion innovation.

Stablecoin: How effective is it in the Bitcoin ecosystem?

Stablecoins have become a key component of any Web3 ecosystem, even those that have no direct relationship with DeFi. They allow users to avoid volatility risks and do not need to worry about changes in asset prices when transferring money. As mentioned earlier, the Bitcoin network always finds a balance between functional simplicity and the amount of recordable data. Interestingly, the earliest attempts to issue assets on Bitcoin were implemented through the development of "Colored Coins", which is somewhat similar to NFT.

As early as 2012, JR Willett proposed the idea of ​​issuing new assets on Bitcoin and proposed the concept of "color coins". He then helped create the Mastercoin protocol (later renamed Omni), laying the foundation for realizing asset tokenization on Bitcoin (including tokens anchored by fiat currencies).

Since there is no direct "token" opcode in standard Bitcoin Script scripts, developers can only use OP_RETURN to embed token metadata into transaction output (OP_RETURN will make the output non-spendable and accompany data). Before OP_RETURN standardization, even multi-signature scripts were used to encode data by "curve the country".

The Bitcoin script itself cannot enforce any token rules – rules are maintained by off-chain software that parses Bitcoin transactions.

Protocols such as Colored Coins, Omni Layer (formerly Mastercoin), Counterparty and Open Assets all represent tokens by "coloring some satoshi or UTXOs". For example, the Open Assets protocol uses an OP_RETURN output containing metadata, which specifies the number of tokens and asset ID.

Essentially, the Bitcoin blockchain itself does not know the existence of "tokens" - it simply processes data. The validity of tokens (such as supply, attribution) is tracked by an external wallet after parsing the OP_RETURN data.

It is worth noting that OP_RETURN has a data size limit. The standard policy of Bitcoin core client stipulates that each OP_RETURN output can contain up to 80 bytes of any data. Data exceeding 80 bytes will be considered "non-standard transactions" and will not be forwarded by default. In theory, a transaction can contain multiple OP_RETURN outputs to increase the accompanying data volume (up to 80 bytes each), but to prevent spam transactions, Bitcoin’s current standard relay strategy generally allows only one OP_RETURN output per transaction.

This ability to "embed metadata in bitcoin transactions" led to the birth of the Mastercoin protocol in 2012, which was later renamed Omni. Omni Layer played a key role in the early Tether operation and became the first batch of underlying transmission protocols for USDT transfers.

For some time in the mid-2010s, USDT based on Bitcoin (Omni) was the most important stablecoin on the market, and was widely used in exchanges such as Bitfinex. Omni transactions are essentially standard bitcoin transactions, plus additional metadata. Omni subsequently developed several different implementation categories, forming its own technological evolution route.