Contents
Bitcoin historically couldn’t support Web3 apps due to the limited programmability of Bitcoin Script. Now it’s possible to build a wide range of Web3 apps on Bitcoin, thanks to Bitcoin layers. These emerging layers and projects are creating new programming languages for writing Bitcoin smart contracts—and, by extension, creating Bitcoin apps.
These projects take different approaches and use different languages to empower developers to create Web3 apps for Bitcoin. So, let’s dive into the options to discover which Bitcoin smart contract programming language is the right option for you.
A Quick Recap on Smart Contracts
Smart contracts are automated programs that execute when predetermined criteria are satisfied. They enable a shift from central institutions to open networks and are often called “trustless” for that autonomy and lack of central authority.
This trustlessness is vital because it allows for democratized access to permissionless systems. No third party dependencies. That is at the core of blockchain’s promise and potential.
Smart contracts play a vital role in Web3 because they are the backbone of Web3 apps. They are the logic that enables apps to interact with on-chain data, whether that be verifying a user’s identity via their on-chain address, triggering transactions between users, and more.
All of this logic is secured by the smart contract’s code, bypassing the need for a third party. But this creates a new question.
Rather than “what third party can I trust?”, we have to think about “which programming language is best for smart contracts?” In the world of Bitcoin, there are a few options for you to choose from.
Choosing a Bitcoin Smart Contract Programming Language
The Bitcoin programming language that you choose is determined by what Bitcoin layer or project you build on, a choice that involves considering what type of decentralized application you want to build, what tradeoffs you are willing to make across the blockchain trilemma, and what functionality you need from a smart contract language.
In this post, we’ll be taking a look at smart contract programming languages in different Bitcoin layers. This does not mean we will be covering every Bitcoin layer. For example, we will not touch on the Lightning Network—one of the most popular Bitcoin layers which has implementations in the languages Go, C, and more—because Lightning does not support smart contracts.
For a more comprehensive overview of the various projects building on Bitcoin, click here.
What’s Possible With Bitcoin Script?
Bitcoin is a difficult blockchain to build on. Bitcoin Script, the programming language of Bitcoin, has a very simple design and facilitates BTC transactions on a trustless peer-to-peer network. It offers limited programmability, and that’s by design. It makes Bitcoin more secure and reduces the surface area for possible exploits.
However, if you want to build apps on Bitcoin, there are a few functionalities at your disposal. These functionalities are enabled by Opcodes, which are a set of 254 commands and functions in Bitcoin Script. Devs have figured out how to do some exciting things with Opcodes, including ways to issue assets on Bitcoin (Bitcoin ordinals).
However, the possibilities of Opcodes are limited and don’t enable fully expressive smart contracts on Bitcoin. Instead, you can build limited programmability, such as:
- Multi-signature scripts: Multiple addresses must sign a transaction before BTC held by that script can be sent.
- Time-locked scripts: A certain period of time must elapse before BTC in the script can be sent.
Introducing new Opcodes requires a BIP and a hard fork (which is hard to do). There is work being done on this front to introduce new Opcodes and increase programmability on the Bitcoin blockchain, including covenants (BIP 118 & BIP 119), Drivechains (BIP 300 & BIP 301). But that work is in the R&D phase with no clear timeline or path to Bitcoin mainnet.
For now, let’s focus on how you can build Bitcoin smart contracts today, which brings us to Bitcoin layers.
Bitcoin Programming Languages for Bitcoin Layers
If you want to build Bitcoin apps today, realistically you need to build with a Bitcoin layer. The good news is that you have several options to choose from:
Clarity (Stacks)
Stacks is one of the most popular Bitcoin layers and uses the programming language Clarity for writing fully expressive smart contracts. Being fully expressive means that developers can build almost anything with Clarity. Clarity also has native read access to the Bitcoin network—it can read and react to native Bitcoin transactions.
Are you a visual learner? Discover the potential of Stacks in this conversation between two developer advocates in the Stacks ecosystem:
Approach
Clarity is a LISP-based programming language. LISP, or list processing, was designed to handle the manipulation of data strings easily. Clarity is a decidable (non-Turing complete) language, which means that smart contracts are predictable and developers can statically analyze contract execution, helping them debug the code and provide accurate execution cost estimates to users.
Clarity code is parsed and committed to the chain in the same way that it was written. There are no compilers that add a layer of complexity and limit readability, which means that the human-readable source code is available on the blockchain for developers and users alike to reference and learn from.
Use Cases
Smart contracts aren’t required for every decentralized app, but for those that need smart contract capabilities, Clarity provides a secure foundation with its emphasis on predictability and transparency. Today, more than 80,000 smart contracts have been deployed on Stacks, and these contracts power dozens of apps all over the world, from NFT marketplaces to DEXs and everything in between. With Clarity on the Stacks blockchain, there are almost limitless possibilities.
Limitations
As a LISP-based language, Clarity is less flexible in terms of the functions that it can perform. For example, recursion is not possible with Clarity, and variables are immutable. While this ultimately makes smart contracts more secure and less susceptible to attacks, it requires developers to take a different approach to building common decentralized applications.
Solidity (Rootstock)
Rootstock (formerly RSK) is a Bitcoin layer that is merge-mined with Bitcoin and has a tokenized BTC asset on its network. Rootstock is a general-purpose smart contract platform that is EVM-compatible. This means that you can create fully expressive smart contracts on Rootstock using Solidity (Ethereum’s programming language) and the Ethereum Virtual Machine.
Approach
To create smart contracts on Rootstock using Solidity, developers are required to use the RSK Virtual Machine (RVM), which is a fork of the Ethereum Virtual Machine (EVM). RVM is compatible with existing tools for writing, deploying, and interacting with smart contracts on Ethereum and EVM-compatible chains.
For example, Rootstock developers can use the popular tool Hardhat to compile Solidity smart contracts into bytecode and deploy them to the blockchain with JavaScript. In other words, writing Bitcoin smart contracts on Rootstock feels alot like writing Ethereum smart contracts, and you have access to the most comprehensive development tool kits in Web3.
Use cases
Solidity is already being used to create a wide range of apps for the Bitcoin ecosystem through Rootstock, with an emphasis on DeFi apps. These DeFi applications include DEXs, stablecoins, lending protocols, and more.
Limitations
Solidity does not have visibility into Bitcoin state, which means contracts cannot react to native Bitcoin transactions (whereas some options in this list do have that read access). Additionally, Solidity is a Turing-complete programming language, which introduces a variety of attack vectors, such as conditional jumps, infinite loops, and contract reentrancy. Another limitation is that in a merge-mined chain like Rootstock, network security relies on a subset of Bitcoin miners, which introduces centralization and security implications.
RPC Languages (Liquid Network)
Liquid is a federated Bitcoin sidechain that features expressive Bitcoin smart contracts. Liquid brings programmability to its network through a synthetic Bitcoin asset. Similar to Rootstock, a user tokenizes their Bitcoin into a programmable synthetic asset on Liquid, which can be converted back into BTC on the Bitcoin blockchain at any time. Liquid Network enables developers to create Bitcoin smart contracts using any language that uses the Remote Procedure Call (RPC) specification, a list that primarily includes Python, Node.js, and JavaScript.
Approach
Liquid is built on Elements, an open-source blockchain platform, and the platform provides the opportunity to use a versatile range of Web2 programming languages to create Web3 applications, making it easier for developers to hit the ground running when developing on Liquid. Elements also provides a number of resources to speed up development, such as Libwally, a collection of wallet primitives, that can be used with C, Python, JavaScript, and more.
Use cases
Liquid offers confidential transactions, where the amounts and asset types of a transaction are hidden from third parties, and the sidechain is designed for asset issuance and financial products. Some of Liquid’s live use cases include browser-based wallets, solutions for trustless swaps, digital art marketplaces, trustless exchanges, and crypto lending solutions.
Limitations
Liquid Network’s main limitation is that in exchange for programmability, Liquid sacrifices decentralization. Liquid is a federated network, and the underlying Bitcoin collateral is held by the federation’s limited group of trustworthy parties. Liquid also does not have visibility into the Bitcoin blockchain, and smart contracts on Liquid cannot react to native Bitcoin transactions.
Motoko (Internet Computer Protocol)
Motoko is the programming language of DFINITY’s Internet Computer Protocol (ICP), an independent blockchain that launched a Bitcoin integration in April 2023. Unlike the projects listed above, ICP is not a Bitcoin layer and supports other chains, including Ethereum. ICP is a top 20 project by market cap and uses these integrations to bring liquidity from other chains into its ecosystem.
By using Motoko, developers can create “Canisters” (smart contracts) to build decentralized applications for Bitcoin. These canisters can communicate with the Bitcoin network and replicate Bitcoin chainstate on ICP’s mainnet. These canisters also generate Bitcoin addresses and can sign Bitcoin transactions (so users can deposit and withdraw BTC), with the secret key being held by a federation of nodes. These canisters then mint Chain-Key Bitcoin, or ckBTC, which individuals can then use to interact with apps on ICP.
Approach
Motoko is a programming language developed specifically for ICP that takes its inspiration from JavaScript. It is a strongly typed, object-oriented, statically compiled language that is compatible with WebAssembly. Motoko supports an actor model, in which objects called “actors” have both private state and methods to process messages sent to it (a canister smart contract is an example of an actor). While Motoko is the native language in ICP, you can also use Rust to create canisters on ICP as well, and the network plans to support any language “with a compiler that targets WebAssembly”
Use cases
Motoko enables a wide range of Bitcoin apps, and BTC holders can convert their BTC to ckBTC and use that asset in a variety of apps, such as DEXs, crowdfunding apps, decentralized social media, and more. Note: while ICP is very popular, the Bitcoin integration is relatively new, and only ~80 BTC have been deposited on the network.
Limitations
One of the challenges of building with Motoko is that actors communicate asynchronously. Motoko enables you to code sequentially, but it requires an extra layer of logic when building your app. There are trust assumptions in canister design, where users rely on a federated node network to sign Bitcoin transactions and process BTC withdrawals from the ICP network. It is also expensive: users must pay “know your transaction” fees upon both deposits and withdrawals, reducing the permissionless nature of the language.
Rust (Mintlayer)
Mintlayer is a Bitcoin sidechain designed to enable the tokenization and trading of various assets. Mintlayer takes a lot of inspiration from Bitcoin’s design. Like Bitcoin, Mintlayer uses an Unspent Transaction Output (UTXO) system for transactions. This means that there is no user account at the blockchain level on Mintlayer. Instead, Mintlayer keeps a history of all transactions, with each transaction composed of a series of inputs and outputs.
This comes with several benefits, including being compatible with technologies already implemented on Bitcoin (e.g. Lightning Network and atomic swaps), prioritizing privacy because a single wallet can utilize multiple addresses (making it harder to distinguish which belong to a single user), and enabling payments to be batched together in a single transaction, saving block space.
Approach
As a network, Mintlayer supports WebAssembly smart contracts and natively supports ink!, a framework for smart contract development in Rust. Rust offers speed, memory-safety, type-safety, concurrency, and an active developer community that Mintlayer devs can tap into. Developers can also use Solang to compile Solidity contracts to WebAssembly if they are already familiar with Ethereum’s programming language.
Use cases
Mintlayer just launched on mainnet on January 29th, 2024. Now that it is live, you can build a number of apps there. In particular, Mintlayer hopes to support a range of apps and primitives, starting wallets, block explorers, and tooling. To accelerate growth, Mintlayer has launched an incubator, accelerator, and grants program for devs.
Limitations
The UTXO model is less efficient than an account base model (most second generation blockchains). The nature of transaction storage creates “dust” - small amounts that are too costly to transfer, given the cost of the transaction fee itself. Since Mintlayer’s Chainscript offers limited functionality (like Bitcoin Script), Mintlayer effectively outsources functionality to Web Assembly, but this potentially introduces additional layers of complexity.
Bitcoin Smart Contract Programming Languages in R&D
Beyond these Bitcoin layers, there are a number of Bitcoin smart contract programming languages that are currently in R&D. Some of these are more active than others, but none are ready for primetime on mainnet. Let’s take a closer look.
Contractum (RGB)
RGB, which stands for “Really Good for Bitcoin,” is a client-side smart contracts system for Bitcoin that operates on layers two and three of the Bitcoin ecosystem. It also works with Lightning Network, the Bitcoin layer specializing in payments. Contractum is a proposed prototype for RGB’s contract language.
Approach
Smart contract data is stored off-chain, but relies on a blockchain for cryptographic proofs. RGB uses client-side validation, and users are required to keep data (source code) client-side with the risk of losing access. Outside of the final cryptographic seal, the state of a contract cannot be publicly referenced once it has been established.
IN RGB, smart contracts don’t use imperative programming, but are declarative. Details on the language Contractum are scarce since it is a prototype in development, but it is described as “as functional as Haskell and nearly as close to the bare metal as Rust.” It is possible to create RGB contracts without Contractum via Rust or Assembly, but the process is complex.
Use Cases
RGB is currently in beta testing and is projected to be used to privately trade NFTs or assets (e.g., the stablecoin Tether). Since transactions through RGB occur off-chain, RGB could improve the privacy and censorship resilience of a stablecoin like Tether, whose on-chain address on blockchains like Bitcoin and Ethereum, for example, can be readily monitored.
Limitations
A global state does not exist in RGB. Without that, there are no network effects for live smart contracts online. Additionally, since these smart contracts are not open source, they cannot be leveraged or built upon by other developers, limiting feedback loops and the growth of smart contracts.
Discreet Log Contracts (DLC)
Discreet Log Contracts (DLC) add a smart contract implementation to Bitcoin operating on preset conditions. These “invisible smart contracts,” as they’re known, are constructed with Bitcoin Script and resemble normal multi-signature transactions on the Bitcoin network.
Approach
DLC establishes blockchain oracles that are simple, safe, and easy to use. Oracles are employed as a third party to complete the transaction by signing the contract corresponding to the outcome’s hash. DLC offers better privacy and more flexible smart contracts without the trust risks of a sidechain. Anyone searching for a transaction on the ledger will not be able to tell if it is a smart contract.
Use Cases
DLC is still in beta testing, with betting as the planned first use case. For example, you can imagine a use case of sports betting. If someone bets on one team to win, then the future conditions would have to be met for anyone to be paid, which is where the oracle comes into play. However, DLC use cases could grow to include longing/shorting BTC and settling commodities in the future.
Limitations
Much like RGB, DLC does not have a global state. DLC requires a smart contract off-chain component to handle overhead coordination with parties, which presents scalability issues. What this means is that Bitcoin scripting is utilized without gas assets or a fully expressive smart contract platform. The use of oracles in DLC also creates a security weakness. There is a chance that an oracle may fail to report or reach the requisite number of reports to execute payouts.
Sapio (Judica)
Sapio is a Bitcoin programming language in development by Jeremy Rubin through Judica, a Bitcoin research and deployment organization. Sapio is implemented in Rust, and while significant expertise in Rust is not mandatory to use Sapio (Sapio typically runs simple Rust programs), the deeper your understanding of Rust, the faster you’ll pick up Sapio.
Approach
Sapio enables developers to create stateful Bitcoin transactions by defining state transitions and creating mechanisms for enforcing these state transitions. Sapio enables developers to create smart contracts for the Bitcoin ecosystem by leveraging the concept of “covenants,” which introduce more “rules” around transactions, such as setting conditions to restrict how Bitcoin in a particular wallet can be transferred, as an example. Sapio is dependent on CHECKTEMPLATEVERIFY (CTV), a proposed Bitcoin soft-fork that has not yet been approved.
Use cases
Sapio is still in development, and is dependent on a Bitcoin Improvement Proposal (BIP-119) being approved and ratified by the Bitcoin community. CTV and Sapio together could improve the statefulness of Bitcoin transactions and enable things like Bitcoin vaults (addresses that restrict the movement of BTC inside them, preventing the vault controller to run off with the funds) and traffic control (enabling users to wait out periods of high transaction fees).
Limitations
Sapio is a domain-specific Web3 programming language for Bitcoin and is limited to stateful transactions. Importantly, the success of Sapio is dependent on BIP-119 being approved and implemented by the Bitcoin community. Sapio code is written in Rust with an embedded Rust playground, and thus the code needs to be compiled into bytecode, introducing the risk of compiler errors and limiting the transparency of the network. Sapio is currently in an Alpha-testing stage, and developers are encouraged to exercise caution before using the language with real money.
Why You Should Use Clarity for Bitcoin Smart Contracts
Clarity is the only general-purpose smart contract solution for Bitcoin that is used by live applications today and doesn’t sacrifice decentralization or the ability to react to Bitcoin’s global state. Clarity does not compile, which means that the original source code for every smart contract is visible on the blockchain. As a result, anyone may verify the code for any smart contract.
In addition, Clarity is a decidable language, meaning you can accurately predict what the program will do before executing the code. In contrast, Solidity, which runs on Ethereum, is non-decidable (Turing-complete), which means you cannot predict what the code will do before execution, introducing additional risk for bugs in the code.
While projects such as Discreet Log Contracts (DLC) and Really Good for Bitcoin (RGB) are meritable scripting advancements for Bitcoin smart contracts, Clarity enables a more robust DeFi and decentralized app ecosystem to thrive.
We’re excited to see all of the recent innovation happening in the Bitcoin ecosystem. Experimentation and developer activity are signs of a healthy network and are good for Bitcoin as a whole. Here’s to a decentralized internet, built on Bitcoin.
Want to learn more about Bitcoin? Download our free guide on Bitcoin DeFi and discover a new wave of innovation happening on Bitcoin.
