The development of tokens, NFTs, and DeFi on Bitcoin is actually much more complex than it appears at first glance. For instance, on EVM-based and other smart contract platforms, smart contracts are Turing-complete, meaning that adding a new feature or option can simply be done by deploying a custom smart contract. In Bitcoin, however, developers must carefully navigate the constraints of avoiding hard forks while innovating within the limits of the existing protocol functionality. As we mentioned in our previous article, one of the key elements that define Bitcoin’s importance and value is its commitment to remaining original, with the chain undergoing minimal changes over time.

That being said, Bitcoin was the first blockchain to achieve widespread adoption, and many technologies that were later realized in more flexible blockchains have their early roots in Bitcoin. In fact, NFTs first appeared on Bitcoin through Colored Coins; the idea of State Channels conceptually resembles today’s L1-L2 architectures; and atomic swaps laid the groundwork for modern cross-chain bridges. Some of these developments were touched upon in our previous article, "Beginning with Bitcoin: The Real History of DeFi." However, to fully appreciate Bitcoin’s unparalleled value as the foundational base for Botanix and other Bitcoin-based chains, it’s important to dive deeper into the early innovations that paved the way for today’s ecosystems. Despite its relative simplicity, Bitcoin is, in reality, a complex and fascinating ecosystem with one of the richest histories in the entire Web3 space.

Theorisation with Bitcoin’s Functionality: Are Its Capabilities Sufficient to Build a Complex Ecosystem?

Bitcoin’s launch in 2009 introduced a built-in scripting language that enabled more than just simple payments — for example, multi-signature scripts and time-locks were possible from the very beginning. Satoshi Nakamoto even described how unconfirmed transactions with nLockTime and sequence numbers could be repeatedly updated between parties for high-frequency trading, with only the final state ultimately recorded on-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, this ensures simplicity and security. Therefore, when building anything complex on Bitcoin, developers must work within the possibilities offered by Script. It includes a fairly large number of commands (opcodes) that program various actions, which are in turn recorded in transactions.

Bitcoin Script is the entire scripting language that Bitcoin uses to define the spending conditions for coins. It's like the programming language itself. Script is like a recipe — a complete list of steps to bake a cake. Opcodes are the building blocks of Script — they are the individual operations (instructions) that developers use to write scripts. Opcodes are like individual actions (e.g., "mix," "stir," "bake"). To understand what Script does, let’s briefly review the most common types:

- P2PK (Pay To Public Key) — This is the original method of sending BTC from one wallet to another, later replaced by a shorter variant, P2PKH. It consists of several opcodes (OP_XXXX ) and looks like: OP_DATA_65 OP_CHECKSIG OP_DATA_33 OP_CHECKSIG .

- P2PKH (Pay To Public Key Hash) — This script looks like: OP_DUP OP_HASH160 OP_DATA_20 OP_EQUALVERIFY OP_CHECKSIG . P2PKH quickly gained wider adoption because it uses a 32-byte public key hash to optimize transaction size, resulting in smaller transactions compared to the 64-byte P2PK. The smaller the size, the cheaper the transactions — especially important as Bitcoin’s usage and transaction costs grew.

- Storing arbitrary data — Typically, these scripts lock zero or a very small amount of satoshis, and many of them carry ASCII data, links, or scripts. An example of such a script: OP_0 OP_DATA_20 # Arbitrary 20 bytes of data storage . There is also a standardized method for storing arbitrary data via the OP_RETURN opcode. For example, Bitcoin colored coin protocols (early NFT analogs) used OP_RETURN to embed token metadata.

A more detailed description of different Scripts was compiled in a research by NCC Group, where they identified 156 different script patterns using their parser.

Can we attempt to organize processes similar to DeFi in Bitcoin using Script? Let’s take a look.

Lending:

As we mentioned above, opcodes can be combined, allowing small instruction chains to be built that can, in turn, create more complex actions. For example, by using opcodes, it is possible to construct complex scripts that perform lending contract functions. This can be achieved through a combination of timelocks and multi-sig:

- OP_CHECKSEQUENCEVERIFY (CSV) for relative time locks (e.g., funds locked for X blocks after a certain transaction),

- OP_CHECKLOCKTIMEVERIFY (CLTV) for absolute time locks (e.g., loan expiry at a specific block height or timestamp),

- OP_CHECKMULTISIG (or multiple OP_CHECKSIG with OP_ADD ) to require multiple parties’ consent,

- Conditional logic opcodes OP_IF/OP_ELSE to define different spend paths (e.g., repayment vs. default).

This enables the implementation of two-sided escrow with a timeout. For example, suppose Alice provides BTC as collateral and Bob lends her stablecoins off-chain. They want a contract where Bob will get Alice’s BTC if she fails to repay the loan by a certain deadline, but if she repays, the BTC will be unlocked and returned to her. They could use a 2-of-2 multisig output (Alice and Bob), which by default requires both parties’ signatures to spend the funds. Then, to handle default, they set up the script so that after a certain block time only Bob can spend the funds.

However, there is another challenge: Bitcoin cannot automatically compute interest, monitor collateral ratios, or enforce liquidations. Any interest payments must be made either off-chain or via additional pre-signed transactions (which is fairly complex). If the price of BTC drops during the loan period, the Bitcoin script would not know — it would require an oracle or off-chain agreement to trigger early liquidation. Without oracles, the contract is simplified: it only knows the final deadline. As a result, trustless stablecoin loans against BTC are hard to implement directly on Bitcoin L1; instead, people either use trusted third parties or atomic swap mechanisms with other chains.

AMM Functionality:

As discussed above, lending and staking mechanisms can theoretically be implemented but are practically inefficient. However, it is worth exploring whether a more complex mechanic similar to an AMM could be theoretically constructed on Bitcoin. Bitcoin includes mathematical opcodes such as OP_ADD , OP_SUB , and OP_MUL (although some have been disabled), as well as comparison opcodes like OP_LESSTHAN , among others. In theory, this functionality could enable the enforcement of a pricing formula. It would be theoretically possible to create a script encoding a fixed price or a predefined set of acceptable price points, but not one that dynamically adjusts after each trade. Such an implementation would face the structural limitation that every transaction in Bitcoin creates a new UTXO with a new script, meaning all possible states would need to be precomputed or a new contract would have to be deployed after each trade.

Another essential aspect for AMM functionality is the ability to swap assets. In theory, Bitcoin can support atomic swaps, which could be structured as atomic swap order books instead of liquidity pools. AMM-like behavior could also be simulated by constructing a series of HTLCs or offers at different price points, forming a static Automated Market Maker (similar to a yield curve of offers). However, maintaining such a system would be highly cumbersome — it would require constant manual updates and reposting of UTXOs with new scripts after each trade, resulting in significant on-chain costs.

Thus, theoretically, an AMM could be built. However, another critical problem arises: on Bitcoin’s mainnet, only BTC exists — there are no native tokens. It might seem that the existence of Omni could solve this, but this is not viable because Omni assets are not embedded in scripts; they exist as metadata. Therefore, direct asset swaps and liquidity pool maintenance for asset pairs cannot be implemented through Bitcoin Script alone. Additionally, Bitcoin’s UTXO model does not allow a single contract to hold funds from multiple parties and update partial balances; every state change would require a new transaction and signatures from the controlling parties.

**Expanding Script functionality: **

The above-mentioned points determine why Bitcoin periodically gets major updates to improve the functionality. Among such important updates is Taproot, which was done as a soft-fork, but has changed the approach to Script quite a bit. Taproot OP_SUCCESS mechanism: With the Taproot upgrade (BIP 342), many opcodes that were previously disabled or reserved have been turned into OP_SUCCESS opcodes in the context of Tapscript (SegWit v1 scripts). An OP_SUCCESS opcode means that if it is executed, the script immediately terminates successfully. This design simplifies adding new opcodes via soft fork. Specifically, in Tapscript, any opcode with numbers in certain ranges (for example: 0x50, 0x62, 0x7E–0x81, 0x83–0x86, 0x89–0x8a, 0x8d–0x8e, 0x95–0x99, and 0xbb–0xfe) is treated as OP_SUCCESSx​. If encountered, it causes the script to succeed regardless of any other logic. This replaces the old OP_NOP upgrade mechanism with one that is safer and more flexible​ – future soft forks can redefine an OP_SUCCESS opcode to have new behavior, and older nodes (which already treat it as success) won’t consider such scripts invalid. In summary, any opcode not listed above as active is either reserved/unused or has been turned into an “always-true” OP_SUCCESS in Taproot.

Another important aspect is that opcodes can be proposed through the BIP (Bitcoin Improvement Proposal) process, and many interesting proposals are either in progress or have been rejected. Currently, several opcodes are awaiting approval, some of which could significantly expand Bitcoin’s functionality by laying the foundation for executing more complex actions. Among these are:

- OP_CAT — designed to expand the ability to package and combine data, which could dramatically enhance Bitcoin’s scripting capabilities. OP_CAT would allow for more expressive scripts, such as those needed for certain covenant mechanisms and advanced applications. Originally present in early Bitcoin (disabled in 2010), OP_CAT would pop two byte strings from the stack and push their concatenation​. This simple yet powerful operation would enable scripts to dynamically build messages or perform complex checks, such as constructing Merkle tree hashes within a script. The BIP proposes a limit for the concatenated result to <= 520 bytes (the maximum stack element size).

- OP_CHECKSIGFROMSTACK / OP_CHECKSIGFROMSTACKVERIFY (OP_CSFS) — could enable scripts and agreements based on oracles. For example, a script could require a signature from an oracle confirming an external condition (such as a price feed or event outcome) by verifying the signed message within the script. Despite the simplicity of its execution, OP_CSFS would unlock a completely new level of functionality for Bitcoin. For instance, an oracle could sign a message like "BTC price dropped below $20k at time X," and a loan contract script could use OP_CSFS to verify this signature, thereby allowing the lender to liquidate collateral if the oracle’s message is valid. In this way, on-chain collateral seizure could occur based on external data (such as price feeds) without relying on a trusted third party holding keys. Similarly, OP_CSFS could ensure that a borrower’s repayment has occurred: the oracle (or lender) could sign a message such as "Payment received," allowing the release of collateral back to the borrower. Without CSFS, these types of conditions are either unachievable today or require an oracle to act as a co-signer, which is less secure due to potential collusion.

- OP_CHECKTEMPLATEVERIFY (OP_CTV) — allows users to restrict how their coins can be spent in the future (e.g., requiring that coins be sent only to a predefined set of addresses or under specific fee conditions). CTV can be used to create batch transactions, channel factories, and other covenant-based constructions, ensuring that certain predefined operations are enforced.

But why have they still not been approved? Most likely, it is because the Bitcoin developer community is extremely careful about preserving Bitcoin in its original form. On one hand, new features would increase functionality. On the other hand, Bitcoin is inherently designed as a slow network, and this slowness can also be considered a form of "originality." For example, considering the use case of OP_CSFS in the context of liquidations, speed plays a crucial role. If a collapse occurs and the BTC price drops sharply, a paradoxical situation may arise: first, the load on the blockchain will spike and the network speed will decrease; second, transactions in the Bitcoin network will be processed at significantly outdated prices, while CEXs and DEXs react much faster. Most likely, prices will begin to recover before liquidations are even completed. The slow operational speed of Bitcoin, combined with the extremely high transaction costs during periods of heavy load, renders attempts at native implementation of DeFi-oriented solutions on the mainnet largely meaningless.

So the builders came to the conclusion that it was more logical to make something on top of Bitcoin. This is what can be considered the progenitor of rollups: that was the concept of a proto-payment channel, hinting that Bitcoin could support multiple off-chain microtransactions compressed into one final payment. In April 2011, the first code fork of Bitcoin, Namecoin, was launched to implement decentralised domain name registration (DNS ‘.bit’) using Bitcoin technology. The Namecoin example - storing name-value pairs on the blockchain - showed that the Bitcoin design could be used not only for currency but also for other assets, even if it required a separate blockchain. These ideas laid the groundwork for subsequent innovations in asset tokenisation, decentralised trading and off-chain scaling of Bitcoin.

Stablecoins: How Effective Are They in Bitcoin?

Stablecoins have become an essential part of any Web3 ecosystem, even those not directly related to DeFi. Stablecoins allow users to avoid volatility and perform transfers without concern that the asset's price may change. As shown earlier, the Bitcoin network constantly balances between functional simplicity and the amount of data that can be recorded. Interestingly, the first steps toward asset creation on Bitcoin were made through the development of Colored Coins, which resemble NFTs. The idea of issuing new assets on Bitcoin dates back to 2012, when J.R. Willett proposed “colored coins” and later helped create the Mastercoin protocol (later renamed Omni) on Bitcoin. This laid the groundwork for tokenizing assets (including fiat-pegged tokens) on Bitcoin.

Standard Bitcoin Script does not include a direct “token” opcode, so token metadata is embedded in transaction outputs via OP_RETURN (which marks an output as provably unspendable with attached data). In earlier implementations, even multi-signature scripts were repurposed to encode data before OP_RETURN became standardized. There is no opcode to enforce token rules—rules are maintained by off-chain software that interprets Bitcoin transactions. Protocols such as Colored Coins, Omni Layer (Mastercoin), Counterparty, and Open Assets represent tokens by “coloring” specific satoshis or UTXOs. For example, the Open Assets protocol uses an OP_RETURN output containing metadata that specifies token quantities and asset IDs. In essence, the Bitcoin blockchain itself has no knowledge of “tokens” — it only sees data. The validity of tokens (supply, ownership) is tracked externally by wallets that analyze these OP_RETURN messages.

OP_RETURN also has a size limitation. Bitcoin Core’s standard policy allows at most 80 bytes of arbitrary data in a single OP_RETURN output. Any data exceeding 80 bytes in OP_RETURN will be considered non-standard and will not be relayed by default. This limitation can be partially mitigated because, in theory, a transaction can include multiple OP_RETURN outputs to add more data (each up to 80 bytes). However, Bitcoin’s standard relay policy generally permits only one OP_RETURN output per transaction to prevent spam.

The ability to embed metadata into Bitcoin transactions enabled the creation of Mastercoin in 2012, later renamed Omni. The Omni Layer was crucial for early Tether operations, serving as the transport layer for the first USDT transactions. For some time in the mid-2010s, USDT on Bitcoin (Omni) was the primary stablecoin in the cryptocurrency market, especially heavily used on Bitfinex and other exchanges. Omni transactions are Bitcoin transactions with additional metadata. Omni went through several implementation classes:

- Class A: Data was recorded by using two fake addresses (P2PKH outputs) to store information in the hash160 of the addresses.

- Class B: An Omni transaction included one or more 1-of-3 multisig outputs. For each such output, one public key belonged to the sender (allowing later redemption), and the other two public keys encoded Omni data.

- Class C: Utilized OP_RETURN , which allowed recording up to 80 bytes of data.

Thus, Omni could package data either into a 30-byte payload (in Class B) or directly into OP_RETURN (Class C). Even more complex Omni transactions beyond simple Send operations (16 bytes), such as trades or issuances, typically ranged from a few dozen bytes to approximately 40–60 bytes of actual data. Therefore, 80 bytes in OP_RETURN was generally sufficient.

Despite these innovations, stablecoins based on Omni inherited both Bitcoin’s strengths (decentralization and security) and its limitations. Each USDT transfer via Omni required a Bitcoin network fee and confirmation, with throughput constrained by Bitcoin’s block size and block time. Omni even implemented features like a decentralized exchange (supporting atomic swaps of Omni assets) and multi-token support. However, apart from Tether, there were very few assets on Omni, and interest in the protocol gradually declined. As the crypto industry evolved, the limitations of Omni became increasingly apparent. Rising Bitcoin transaction fees and 10-minute block intervals made Omni transactions slow and costly for active trading. By 2017, Tether began issuing USDT on faster platforms (starting with ERC-20 on Ethereum, followed by others), and exchanges quickly adopted these newer versions, where transactions were cheaper and faster.

The design of Bitcoin and its Script language inherently leaves little room for complex smart contracts necessary for linking to issuers, asset liquidation, treasury management, and other functionalities required for the proper operation of any collateralized stablecoin. This led to implementations that carried significant risks. For example, both Omni and Ordinals tokens rely on the issuer’s (Tether’s or Stably’s) promise to maintain fiat reserves.

Moreover, as mentioned in the previous section, Bitcoin does not natively support tokens, so every stablecoin solution effectively constitutes a workaround. Omni’s method of encoding data in OP_RETURN had strict limits on data size and required all participants to run specialized parsing software. This made wallet and exchange integration non-trivial. Many Bitcoin wallets never supported Omni tokens, complicating user access. Similarly, both Liquid and RSK require users to run separate node software or use specialized wallets, making them far less “plug-and-play” compared to an ERC-20 token on an Ethereum wallet.

Only recently, with the introduction of Taproot, Bitcoin gained new capabilities (via Taro or Ordinals) for associating asset data in a somewhat cleaner manner, but these features are still not widely supported across wallets. In practice, they inherit many of the same adoption challenges faced by Omni, despite improvements in data encoding methods. Stably’s BRC-20 stablecoin briefly captured attention in mid-2023. However, its supply and usage remain very low, partly because on-chain transactions are cumbersome and expensive. In essence, an Ordinals-based stablecoin is more of a theoretical proof-of-concept: it demonstrated the technical possibility but failed to achieve significant market adoption.

All other Bitcoin-related stablecoin implementations are effectively sidechains or Layer 2 solutions. For example, Drivechain, proposed by Paul Sztorc and Layer 2 Labs in the form of BIP 300, envisions peer-to-peer sidechains. Liquid, with its Liquid USDT (L-USDT), is also a sidechain designed for faster, more confidential transactions and digital asset issuance. RSK, with DOC (Dollar on Chain), is another example of a sidechain. The case of Ordinals demonstrates that using Bitcoin transactions directly for each transfer results in significant congestion and high fees during periods of network activity.

Given the availability of extremely fast and low-cost transaction technologies, the practicality of launching anything directly on Bitcoin is increasingly questionable. As blockchain technologies continue to evolve, this approach becomes less and less viable. Bitcoin remains a unique asset that holds intrinsic value in its current form. Therefore, Botanix aims to build a chain that maximally respects and inherits Bitcoin’s principles and lineage to maintain close affinity with the Bitcoin network. This approach allows for the creation of a modern system that still inherits all of Bitcoin’s advantages.