The process of developing tokens, NFTs, and DeFi on Bitcoin is actually much more complex than it appears on the surface. For example, on the Ethereum Virtual Machine (EVM) and other smart contract platforms, smart contracts are Turing complete, meaning that new features or options can be added simply by deploying a custom contract. However, on Bitcoin, developers must innovate carefully without triggering a hard fork and can only operate within the limitations of existing protocol functionalities. As mentioned earlier, one key factor that gives Bitcoin its unique importance and value is its adherence to "originality," with the main chain experiencing very few changes over time.

Despite this, Bitcoin is the first blockchain to achieve widespread adoption, and many technologies that were later implemented on more flexible blockchains actually had their earliest seeds in Bitcoin. In fact, NFTs initially appeared on Bitcoin in the form of "Colored Coins"; the concept of State Channels is designed similarly to today's L1-L2 architecture; and Atomic Swaps laid the groundwork for modern cross-chain bridges. We have partially introduced these developments in our previous article "Starting from Bitcoin: The True Origins of DeFi." However, to truly understand the unparalleled value that Bitcoin possesses as the infrastructure for Botanix and other Bitcoin chains, we need to delve deeper into 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 space, with the richest history.

Exploring the Theoretical Functions of Bitcoin: Is Bitcoin's Capability Sufficient to Support a Complex Ecosystem?

When Bitcoin launched in 2009, it came with a built-in scripting language that not only enabled simple payments but also supported more complex operations like multi-signature (multi-sig) and time-lock from the very beginning. Satoshi Nakamoto even described how unconfirmed transactions using nLockTime and sequence numbers could be updated multiple times between parties for high-frequency trading, with only the final state being written to the chain.

Bitcoin Script is a very interesting mechanism: on one hand, it is Turing incomplete, which limits its functionality; on the other hand, it maintains simplicity and security. Therefore, when building any complex functionality on Bitcoin, developers must design within the framework provided by Script. It contains a large number of commands (Opcodes) used to program various actions, all of which will ultimately be written into transaction data.

Bitcoin Script is the scripting language used to define the conditions for spending Bitcoin. You can think of Script as a recipe—a complete set of steps for baking a cake. Opcodes are the building blocks of this language—they are the basic instructions used by programmers when writing scripts, such as "stir," "heat," etc. To better understand the functionality of Script, let's briefly review some of the most common script types:

• P2PK (Pay To Public Key) — This is the most primitive way to transfer BTC, 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. By using a 32-byte public key hash to optimize transaction size, this script is more space-efficient compared to the 64-byte P2PK, quickly becoming mainstream. The smaller the transaction data, the lower the fees—this is especially important in the context of increasing Bitcoin usage and transaction fees.

• Storing arbitrary data — These scripts typically lock 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 is also a standardized way to use OP_RETURN to store data. For instance, the Bitcoin Colored Coins protocol (the predecessor of NFTs) embedded token metadata through OP_RETURN.

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

So, can we attempt to use Script to organize DeFi-like mechanisms on Bitcoin? Let's continue exploring.

Lending Mechanism:

As mentioned earlier, opcodes can be combined to construct a series of small instruction chains, thereby achieving more complex behaviors. For example, developers can construct complex scripts with lending contract functionality by combining opcodes. This can be achieved through a combination of time-locks and multi-signatures:

• OP_CHECKSEQUENCEVERIFY (CSV): Used for relative time-locks (e.g., locking funds for X blocks after a certain transaction);

• OP_CHECKLOCKTIMEVERIFY (CLTV): Used for absolute time-locks (e.g., a loan maturing at a specific block height or timestamp);

• OP_CHECKMULTISIG (or multiple OP_CHECKSIG combined with OP_ADD): Requires multiple parties to jointly sign;

• Conditional logic opcodes OP_IF / OP_ELSE: Define different spending paths (e.g., repayment vs. default).

These tools can implement "time-bound bilateral escrow contracts." For example: suppose Alice provides BTC as collateral, while Bob lends her stablecoins offline. They want to set the following rules through a contract: if Alice fails to repay by the due date, Bob will receive 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 access the funds). Then, they can set the script logic: if repayment has not occurred after reaching a certain block height, only Bob can access these funds.

However, there is still a significant challenge: Bitcoin itself cannot automatically calculate interest, monitor collateral ratios, or enforce liquidations. Any interest payments must be completed off-chain or through pre-signed transactions (which is quite complex in practice). If the price of BTC drops during the loan period, the Bitcoin script itself cannot know this and thus cannot automatically trigger a liquidation. To achieve this functionality, oracles or off-chain protocols must be used. Without oracles, contracts can only make judgments based on the final due date.

Therefore, directly implementing trustless BTC-collateralized stablecoin lending on Bitcoin's layer is very difficult. Current practices often rely on trusted third parties or use atomic swap mechanisms on other chains to achieve this indirectly.

AMM Functionality:

As mentioned earlier, lending and staking mechanisms can theoretically be implemented through Bitcoin Script, but in practice, they are inefficient. However, we can still explore whether it is possible to build a more complex mechanism similar to an automated market maker (AMM) on Bitcoin. Bitcoin Script includes mathematical opcodes such as OP_ADD, OP_SUB, and OP_MUL (although some of these have been disabled), as well as comparison opcodes like OP_LESSTHAN. Theoretically, these functionalities can be used to implement price calculation logic.

In theory, developers could construct a script that embeds a fixed price or a set of predefined acceptable price points, but they cannot dynamically adjust the price after each transaction. The reason is that Bitcoin uses a UTXO model, where each transaction generates new UTXOs and scripts, so every possible state must be pre-calculated, or a new contract must be redeployed after each transaction.

Another key factor in implementing AMM functionality is the ability to exchange assets. Theoretically, Bitcoin supports atomic swaps, which can be constructed in an order book format rather than a liquidity pool. AMM-like behavior can also be simulated by constructing a series of HTLCs (Hash Time-Locked Contracts) or placing orders at different price points, thereby forming a static automated market-making system (similar to a yield curve). However, maintaining such a system is very cumbersome, requiring manual updates to scripts and reissuing UTXOs after each transaction, leading to high on-chain costs.

Therefore, while it is theoretically possible to construct an AMM, there is a larger issue: the Bitcoin mainnet only has BTC as a native asset. Although protocols like Omni provide token mechanisms, these assets exist in the transaction metadata and cannot be recognized and processed by scripts. Therefore, true asset-to-asset exchanges or liquidity pool maintenance cannot be achieved through Bitcoin Script. Additionally, Bitcoin's UTXO model does not support a single contract holding funds from multiple parties and updating partial balances simultaneously—every state change requires a new transaction and multi-signature.

Extending Script Functionality:

The points above explain why Bitcoin periodically undergoes significant updates to enhance its functionality. One important update is Taproot, which introduces a new design for Script through a soft fork.

The OP_SUCCESS Mechanism of Taproot:

With the introduction of the Taproot upgrade (BIP 342), many previously disabled or reserved opcodes have been transformed into OP_SUCCESS opcodes in Tapscript (i.e., SegWit v1 script). OP_SUCCESS indicates that as long as this opcode is executed, the script will immediately terminate successfully. This design makes it simpler and safer to add new opcodes through soft forks. Specifically, in Tapscript, if the value of an opcode falls within a specific range (e.g., 0x50, 0x62, 0x7E–0x81, 0x83–0x86, 0x89–0x8a, 0x8d–0x8e, 0x95–0x99, 0xbb–0xfe), it will be treated as OP_SUCCESSx. Once these opcodes are encountered, the script will unconditionally be deemed successful, ignoring other logic.

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

Another important aspect is that opcodes can be proposed through the BIP (Bitcoin Improvement Proposal) process, and there are currently some powerful proposals under review or that have been rejected. Some of these proposals, if adopted, would significantly expand Bitcoin's functionality, enabling it to perform more complex operations:

• OP_CAT (Concatenation Operator): This opcode enhances the ability to combine and process data in Bitcoin scripts, greatly improving expressiveness. OP_CAT originally existed in early Bitcoin (disabled in 2010) and functions by taking two byte strings from the stack, concatenating them, and pushing the result back onto the stack. This simple yet powerful operation can be used to dynamically construct messages, compute Merkle tree hashes in scripts, and other complex logic. The proposal suggests limiting the concatenated result to no more than 520 bytes (the maximum stack element limit).

• OP_CHECKSIGFROMSTACK / OP_CHECKSIGFROMSTACKVERIFY (abbreviated as OP_CSFS): This opcode enables oracle-based script verification. For example, a script can verify whether the signature information of an external condition (such as a price or event outcome) comes from a specific oracle. Although the execution logic is simple, OP_CSFS can unlock new capabilities for Bitcoin. For instance, an oracle signs a message stating "BTC falls below $20,000 at time X," and a lending script verifies this signature through OP_CSFS, allowing the lender to liquidate collateral—this process does not require a third party to hold the private key. Additionally, after the borrower repays, the oracle or lender can sign "repayment received," and upon script verification, the collateral is returned. Without OP_CSFS, such automated contracts based on external conditions would either be unachievable or could only be completed with the oracle as a co-signer, posing higher trust risks.

• OP_CHECKTEMPLATEVERIFY (abbreviated as OP_CTV): This opcode allows users to predefine how their Bitcoin can be used in the future, for example: it can only be transferred to a specific set of addresses or spent under certain fee conditions. OP_CTV can be used to construct batch transactions, channel factories, and other advanced use cases based on "covenant" mechanisms, ensuring that certain predefined rules are enforced.

But why have these opcodes not been approved to date?

The main reason may be that the Bitcoin developer community is extremely cautious about maintaining Bitcoin's original form.

On one hand, introducing new features can indeed enhance Bitcoin's usability and scalability; on the other hand, Bitcoin itself is designed to be a "slow" network, and this "slowness" is, to some extent, regarded as part of its "authentic" characteristics. For example, in the case of applying OP_CSFS to liquidation mechanisms, speed is a key factor. If the market crashes and the BTC price plummets, a paradox may arise:

First, blockchain load surges, further decreasing network speed;

Second, the transaction processing speed in the Bitcoin network will lag significantly, while prices have already deviated from current market levels, and both centralized and decentralized exchanges (CEX and DEX) have already reacted swiftly.

It is highly likely that by the time on-chain liquidation transactions are completed, the price has already rebounded.

Therefore, Bitcoin's inherent slowness and extremely high transaction fees under high load make attempts to natively implement DeFi-related mechanisms on the mainnet essentially meaningless.

Because of this, developers have gradually reached a more reasonable conclusion: an expansion layer should be built on top of Bitcoin. This is essentially the precursor to the Rollup concept—the idea of "proto-payment channels": supporting multiple off-chain microtransactions that ultimately compress into a single on-chain settlement transaction.

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

The Namecoin case—storing "name-value" pairs on-chain—first demonstrated that Bitcoin's design could be used not only for currency transactions but also for other assets, although it might require a separate blockchain structure. These ideas laid the foundation for subsequent asset tokenization, decentralized trading, and off-chain expansion innovations for Bitcoin.

Stablecoins: How Effective Are They in the Bitcoin Ecosystem?

Stablecoins have become a key component of any Web3 ecosystem, even those that are not directly related to DeFi. They allow users to avoid volatility risks and transfer assets without worrying about price fluctuations. As mentioned earlier, the Bitcoin network is always seeking a balance between functional simplicity and the amount of data that can be recorded. Interestingly, the earliest attempts to issue assets on Bitcoin were achieved through the development of "Colored Coins," which are somewhat similar to NFTs.

As early as 2012, J.R. Willett proposed the idea of issuing new assets on Bitcoin and introduced the concept of "Colored Coins." He subsequently helped create the Mastercoin protocol (later renamed Omni), laying the groundwork for asset tokenization on Bitcoin (including tokens pegged to fiat currencies).

Since standard Bitcoin Script does not have a direct "token" opcode, developers could only embed token metadata into transaction outputs using OP_RETURN (which makes the output unspendable and carries data). Before the standardization of OP_RETURN, even multi-signature scripts were creatively used to encode data.

Bitcoin Script itself cannot enforce any token rules—the rules are maintained by off-chain software responsible for parsing Bitcoin transactions.

Protocols like Colored Coins, Omni Layer (originally Mastercoin), Counterparty, and Open Assets represent tokens by "coloring" certain satoshis or UTXOs. For example, the Open Assets protocol uses OP_RETURN outputs containing metadata that specifies the token quantity and asset ID.

Essentially, the Bitcoin blockchain itself does not know of the existence of "tokens"—it merely processes data. The validity of tokens (such as supply and ownership) is tracked externally by wallets that parse 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 contain a maximum of 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 (each up to 80 bytes), but to prevent spam transactions, Bitcoin's current standard relay policy generally only allows one OP_RETURN output per transaction.

This ability to "embed metadata in Bitcoin transactions" enabled the creation of the Mastercoin protocol in 2012, which was later renamed Omni. Omni Layer played a crucial role in the early operation of Tether, becoming the underlying transmission protocol for the first USDT transfers.

For a period in the mid-2010s, USDT based on Bitcoin (Omni) was the dominant stablecoin in the market, especially widely used on exchanges like Bitfinex. Omni transactions are essentially standard Bitcoin transactions with additional metadata. Omni subsequently developed multiple different implementation categories, forming its own technological evolution path.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。