The process of developing tokens, NFTs, and DeFi on Bitcoin is actually more complicated than it appears. For example, on the Ethereum Virtual Machine (EVM) and other smart contract platforms, smart contracts are Turing complete, which means that new features or options can be added by simply deploying a custom contract. But on Bitcoin, developers must be careful to innovate without causing a hard fork and can only operate within the limitations of existing protocol functions. As we mentioned earlier, one of the key factors that makes Bitcoin uniquely important and valuable is its adherence to "originality", and the main chain has undergone few changes over time.
Despite this, Bitcoin was the first blockchain to gain widespread adoption, and many of the technologies that were subsequently implemented on more flexible blockchains actually had their earliest seeds on Bitcoin. In fact, NFTs first 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 laid the foundation for modern cross-chain bridges. We have already introduced some of these developments in the previous article "Starting 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 paved the way for today's ecosystem. Although Bitcoin itself is relatively "simple", it is actually one of the most complex and fascinating ecosystems in the Web3 field, with the richest history.
Exploring Bitcoin Functional Theory: Is Bitcoin’s capabilities sufficient to support a complex ecosystem?
When Bitcoin was launched in 2009, it had a built-in scripting language that not only enabled simple payments, but also supported more complex operations such as multi-sig and time-lock from the beginning. Satoshi Nakamoto even described that unconfirmed transactions using nLockTime and sequence numbers can be updated multiple times between two parties for high-frequency transactions, and only the final state will be written to the chain.
Bitcoin Script is a very interesting mechanism: on the one hand, it is Turing incomplete, which limits its functionality; but on the other hand, it also remains simple and secure. Therefore, when building any complex functions on Bitcoin, developers must design them 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 scripting language used by Bitcoin to define the conditions for spending coins. You can think of Script as a recipe - a set of steps to bake a cake. Opcodes are the building blocks of this language - they are the basic instructions used by programmers when writing scripts, such as "stir" and "heat". In order to understand the function of Script more clearly, let's briefly review the most common types of scripts:
P2PK (Pay To Public Key) — This is the original 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 format is: OP_DUP OP_HASH160 OP_DATA_20 OP_EQUALVERIFY OP_CHECKSIG. Since the 32-byte public key hash is used to optimize the transaction size, this script is more space-efficient than the 64-byte P2PK, so it quickly became mainstream. The smaller the transaction data, the lower the fee - this is especially important in the context of increasing Bitcoin usage and handling fees.
Storing arbitrary data - These scripts usually lock up a very small amount of satoshis and are mainly used to store ASCII text, links, or scripts. For example: OP_0 OP_DATA_20 # 20 bytes of custom data. There are also standardized ways to use OP_RETURN to store data. For example, the Bitcoin Colored Coins protocol (the predecessor of NFTs) 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 use Script to organize a DeFi-like mechanism on Bitcoin? Let’s continue to explore the next step.
Lending mechanism:
As we mentioned earlier, opcodes can be combined to build a series of small chains of instructions to achieve more complex behaviors. For example, developers can construct complex scripts with loan contract functions by combining opcodes. This can be achieved through a combination of time locks and multi-signatures:
OP_CHECKSEQUENCEVERIFY (CSV): for relative timelocks (e.g. lock funds X blocks after a certain transaction);
OP_CHECKLOCKTIMEVERIFY (CLTV): for absolute time locks (e.g., a loan expires at a specific block height or timestamp);
OP_CHECKMULTISIG (or multiple OP_CHECKSIG with OP_ADD): requires multiple parties to sign;
Conditional logic opcodes OP_IF / OP_ELSE: define different spending paths (e.g. repayment vs. default).
These tools can implement "bilateral escrow contracts with timeouts." For example: suppose Alice provides BTC as collateral, and Bob lends her stablecoins offline. They hope to set the following rules through the contract: If Alice does not repay the loan on time, Bob will get her BTC; if she repays on time, the BTC will be unlocked and returned to Alice. To do this, they can use a 2-of-2 multi-signature output (both Alice and Bob need to sign to use the funds). Then, they can set the script logic: if the loan is still not repaid 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 collateralization rates, or enforce liquidations. Any interest payments must be made off-chain or with the help of pre-signed transactions (which is quite complicated in practice). If the price of BTC falls during the loan period, the Bitcoin script itself cannot know and cannot automatically trigger liquidation. To achieve this function, an oracle or off-chain protocol must be used. Without an oracle, the contract can only make judgments based on the final expiration time.
Therefore, it is very difficult to directly implement trustless BTC-collateralized stablecoin lending on the Bitcoin layer. Current practices usually rely on trusted third parties or use atomic swap mechanisms on other chains to achieve this indirectly.
AMM Features:
As mentioned above, the lending and staking mechanisms can be implemented in theory through Bitcoin Script, but in practice they are less efficient. However, we can still explore whether it is possible to build more complex mechanisms like automated market makers (AMMs) on Bitcoin. Bitcoin Script contains mathematical opcodes such as OP_ADD, OP_SUB, and OP_MUL (although some of them have been disabled), as well as comparison opcodes like OP_LESSTHAN. In theory, these functions can be used to implement price calculation logic.
In theory, developers can construct a script with a fixed price or a set of predefined acceptable price points, but it is impossible to dynamically adjust the price after each transaction. The reason is that Bitcoin uses the UTXO model, and each transaction generates a new UTXO and script, so every possible state must be pre-calculated, or a contract must be redeployed after each transaction.
Another key factor in the implementation of AMM is the ability to exchange assets. In theory, Bitcoin supports atomic swaps, which can be built in the form of order books rather than liquidity pools. Similar AMM behavior can also be simulated by building a series of HTLCs (hash time lock contracts) or issuing pending orders at different price points to form a static automatic market making system (similar to a yield curve). However, maintaining such a system is very cumbersome, and the script needs to be manually updated and UTXO re-issued after each transaction, which has extremely high on-chain costs.
Therefore, although it is theoretically possible to build an AMM, there is a bigger problem in practice: there is only one native asset, BTC, on the Bitcoin mainnet. Although protocols such as the Omni protocol provide a token mechanism, these assets exist in the metadata of the transaction and cannot be recognized and processed by the script. Therefore, it is impossible to achieve true asset-to-asset exchange or liquidity pool maintenance through Bitcoin Script. In addition, Bitcoin's UTXO model does not support a single contract holding multiple parties' funds at the same time and updating partial balances - each state change requires a new transaction and multiple signatures.
Extended Script functionality:
The above points explain why Bitcoin undergoes major updates regularly to improve its functionality. One of the important updates is Taproot, which was introduced through a soft fork but greatly changed the way Script is designed.
Taproot’s OP_SUCCESS mechanism:
With the introduction of the Taproot upgrade (BIP 342), many previously disabled or reserved opcodes (opcodes) were converted to OP_SUCCESS opcodes in Tapscript (i.e., SegWit v1 scripts). OP_SUCCESS means that as long as the opcode is executed, the script will terminate successfully immediately. This design makes it easier and safer to add new opcodes through soft forks. Specifically, in Tapscript, if the value of the opcode is in 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 be unconditionally judged as successful and other logic will be ignored.
This mechanism replaces the old OP_NOP (no opcode) upgrade method, bringing higher security and flexibility. Future soft forks can redefine the behavior of a certain OP_SUCCESS opcode, and old version nodes will still regard it as "script success", thus avoiding invalid transactions caused by version inconsistencies. In summary, all opcodes that are not listed as "available" are either reserved or have been converted to always return successful OP_SUCCESS in Taproot.
Another important aspect is that opcodes can be proposed through the BIP (Bitcoin Improvement Proposal) process, and there are already some powerful proposals under consideration or rejected. Some of these proposals, if adopted, will significantly expand the functionality of Bitcoin, enabling it to perform more complex operations:
OP_CAT (concatenation operator): It is used to enhance the ability to combine and process data in Bitcoin scripts, greatly improving the expressive power. OP_CAT originally existed in early Bitcoin (disabled in 2010), and its function is to take two byte strings from the stack, concatenate them, and then push them into the stack. This simple but powerful operation can be used to dynamically build messages, calculate Merkle tree hashes in scripts, and other complex logic. The proposal recommends limiting the result after concatenation to no more than 520 bytes (i.e. the maximum stack element limit).
OP_CHECKSIGFROMSTACK / OP_CHECKSIGFROMSTACKVERIFY (OP_CSFS for short): This opcode enables oracle-based script verification. For example, a script can verify that a signed message of an external condition (such as a price or event outcome) came 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 time X", and the loan script verifies this signature through OP_CSFS, allowing the lender to liquidate the collateral - this process 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 the script verifies and returns the collateral. Without OP_CSFS, this type of automatic contract based on external conditions is either impossible to implement, or can only be completed through the oracle as a co-signer, which has a higher trust risk.
OP_CHECKTEMPLATEVERIFY (OP_CTV for short): This opcode allows users to predefine how their Bitcoin will be used in the future, for example, it can only be transferred to a certain set of addresses, or it can only be spent if a certain fee condition is met. 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 have these opcodes not been approved yet?
The main reason may be that the Bitcoin developer community is extremely cautious about maintaining Bitcoin's original form.
On the one hand, introducing new features can indeed enhance the usability and scalability of Bitcoin; but on the other hand, Bitcoin itself is a network designed to be "slow", and this "slowness" is, to some extent, also regarded as its "original" feature. For example, taking OP_CSFS applied to the liquidation mechanism as an example, speed is a key factor. If the market collapses and the price of BTC drops sharply, a paradox may arise:
First, the blockchain load soared and the network speed dropped further;
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 already responded quickly.
It is very likely that the price will have rebounded before the on-chain liquidation transaction is completed.
Therefore, Bitcoin itself runs slowly and has extremely high transaction fees under high load, making attempts to natively implement DeFi-related mechanisms on the mainnet basically meaningless.
Because of this, developers gradually came to a more reasonable conclusion: an extension layer should be built on top of Bitcoin. This is actually the predecessor of the Rollup idea, the concept of "proto-payment channel": by supporting multiple micro-transactions off-chain, they are finally compressed into an on-chain settlement transaction.
As early as April 2011, the first code branch of Bitcoin, Namecoin, was launched, which realized decentralized domain name registration (DNS ".bit") through Bitcoin technology.
The Namecoin example - storing name-value pairs on-chain - was the first to demonstrate that the Bitcoin design could be used not only for currency transactions, but also for other assets, although this might require a separate blockchain structure. These concepts laid the foundation for subsequent innovations in asset tokenization, decentralized transactions, and Bitcoin's off-chain expansion.
Stablecoins: How effective are they in the Bitcoin ecosystem?
Stablecoins have become a key component of any Web3 ecosystem, even those not directly related to DeFi. They allow users to hedge volatility risks and transfer money without worrying about changes in asset prices. As mentioned earlier, the Bitcoin network has always been looking for a balance between functional simplicity and the amount of data that can be recorded. Interestingly, the earliest attempt to issue assets on Bitcoin was achieved through the development of "Colored Coins", which is somewhat similar to NFTs.
As early as 2012, JR Willett proposed the idea of issuing new assets on Bitcoin and put forward the concept of "colored coins". He then helped create the Mastercoin protocol (later renamed Omni), laying the foundation for the tokenization of assets on Bitcoin (including tokens anchored to fiat currencies).
Since there is no direct “token” opcode in the standard Bitcoin Script, developers can only embed token metadata into transaction outputs with the help of OP_RETURN (OP_RETURN makes the output unspendable and comes with data). Before OP_RETURN was standardized, even multi-signature scripts were used as a “roundabout way” to encode data.
Bitcoin Script itself cannot enforce any token rules — the rules are maintained by off-chain software that is responsible for parsing Bitcoin transactions.
Protocols like Colored Coins, Omni Layer (formerly Mastercoin), Counterparty, and Open Assets represent tokens by “coloring certain satoshis or UTXOs.” For example, the Open Assets protocol uses an OP_RETURN output that contains metadata that specifies the number of tokens and the asset ID.
Essentially, the Bitcoin blockchain itself is unaware of the existence of "tokens" - it simply processes data. The validity of tokens (e.g. supply, ownership) is tracked by external wallets after parsing the OP_RETURN data.
It is worth noting that OP_RETURN has a data size limit. The standard policy of the Bitcoin Core client stipulates that each OP_RETURN output can only contain up to 80 bytes of arbitrary data. Data exceeding 80 bytes will be considered a "non-standard transaction" and will not be forwarded by default. In theory, a transaction can contain multiple OP_RETURN outputs to increase the amount of accompanying data (up to 80 bytes each), but in order to prevent spam transactions, Bitcoin's current standard relay policy generally only allows each transaction to contain one OP_RETURN output.
This ability to embed metadata in Bitcoin transactions led to the creation of the Mastercoin protocol in 2012, later renamed Omni. The Omni Layer played a key role in the early operation of Tether and became the underlying transmission protocol for the first batch of USDT transfers.
For a period of time in the mid-2010s, USDT based on Bitcoin (Omni) was the most dominant stablecoin on the market, especially widely used in exchanges such as Bitfinex. Omni transactions are essentially standard Bitcoin transactions with additional metadata. Omni has subsequently developed multiple different implementation categories, forming its own technical evolution path.
