Ready to start your Web3 development journey?
→ Download our guide to developing smart contracts

A Guide to Web3 Programming Languages for Bitcoin Apps

So you want to create a business or application on Bitcoin. Now, you have to decide what programming language you’ll use to build it. In this article, we list the different programming languages for Bitcoin smart contracts and break down the pros and cons of each, so you can pick the right language and code the best version of your idea.

Type
Deep dive
Topic(s)
Bitcoin
Clarity
Published
October 19, 2022
Author(s)
Community Manager
Bitcoin Languages
Contents
Copy link

Bitcoin historically couldn’t support Web3 apps. Now it is possible to build a wide range of Web3 apps on Bitcoin, thanks to new projects creating 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 programming language is the right option for you. 

A Quick Recap on Smart Contracts

Smart contracts are programs that run when certain criteria are satisfied and are recorded on a blockchain. They enable a shift from centrally administered institutions to open networks like Decentralized Finance (DeFi). This is possible because blockchain technology is a trustless system. Rather than a central institution verifying “the truth” (such as a bank verifying that a wire transaction occurred), a dispersed network of independent nodes verifies transactions through a process called mining.

Importantly, anyone can choose to become a node and participate in that verification process. It’s open to the public. In other words, smart contract transactions can be delivered automatically without the assistance of a third party, and the public can verify those transactions in a “trustless” process. 

Trustlessness is vital for smart contracts because it allows for democratized access to permissionless systems without depending on potentially misaligned third parties. Smart contracts for Bitcoin can handle multi-party agreements. Those agreements are secured by the 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 developers to chose from. 

Choosing a Web3 Programming Language for Bitcoin Smart Contracts

The Web3 programming language that you choose is determined by what Bitcoin 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 the Bitcoin ecosystem, Web3 programming languages can be grouped into three broad categories: languages related to Bitcoin Script, those used in Bitcoin sidechains, and languages used in independent blockchains. 

Note: click here for an overview of Bitcoin projects.

Web3 Programming Languages Related to Bitcoin Script 

Bitcoin Script is the programming language designed to facilitate transaction operations on the Bitcoin blockchain. It is primarily used for locking and unlocking transactions, but it is intentionally kept simple with limited expressiveness as part of Bitcoin’s security.  

Over the past several years, there have been attempts to improve on the Bitcoin script by creating new scripting languages on Bitcoin with more functionalities beyond locking and unlocking transactions. 

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, which is a layer-two decentralized payment protocol. Contractum is a proposed prototype for RGB’s contract language. 

Approach

Smart contract data is stored off-chain but relies on blockchain for cryptographic proofs. RGB uses client-side validation. 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.

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 to 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 first use case. However, it could grow to include longing/shorting BTC and settling commodities in the future. 

One example of the betting use case could be the outcome of a football game. If someone bets on the Browns to win over the Patriots, then the future conditions would have to be met for anyone to be paid. If the Browns win, then the person who made the bet would receive their payout. 

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 developed 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) amd 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. 

FastKitten

FastKitten is another idea for how developers could potentially write complex smart contracts for Bitcoin at a very low cost using off-chain computations. The research proposal for FastKitten was introduced at the 28th USENIX Security Symposium in 2019. The proposal suggests the implementation of FastKitten using the Python Scripting engine. 

Approach

Using the Python Scripting engine, developers can create smart contracts to lock assets into an off-chain smart contract (called a Trusted Execution Environment, or TEE). A centralized operator manages the TEE, and the operator publishes the final state of the ledger after the terms of the smart contract have been fulfilled. The proposal also suggests that developers will be able to create smart contracts with FastKitten using other memory-safe programming languages such as Go or Rust.

Use cases

Based on publicly available information, this proposal doesn’t seem to have been developed or worked on since its introduction. However, if developed, it is an interesting project that takes a different approach to creating dApps for Bitcoin by moving computations off-chain rather than onto a sidechain.

Limitations

FastKitten is still at the proposal stage, but one of the limitations is that the model is centralized: since FastKitten relies on a centralized operator, it cannot create decentralized solutions. Further, since the contracts exist off-chain, there is no global state for other developers to reference, and various smart contracts cannot interact with each other.

Web3 Programming Languages on Bitcoin Sidechains 

Like all blockchains, Bitcoin’s design makes tradeoffs across the blockchain trilemma of security, decentralization, and scalability. Sidechains provide developers with opportunities to build new applications on another platform that is connected to the Bitcoin network but without the limitations of Bitcoin.

RSK

Rootstock platform, or RSK, is a Bitcoin network–secured, general-purpose smart contract platform. The RSK network is a sidechain merge-mined with Bitcoin and enables the tokenization of Bitcoin for use in its ecosystem. RSK enables fully expressive smart contracts using Solidity (the Ethereum programming language) and the Ethereum Virtual Machine (EVM) via a synthetic version of Bitcoin.

Approach 

To create smart contracts on RSK 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, RSK developers can use the popular tool Truffle to compile Solidity smart contracts into bytecode and deploy them to the blockchain with Javascript. In other words, writing Bitcoin smart contracts on RSK feels alot like writing Ethereum smart contracts.

Use cases

Solidity is already being used to create a wide range of DeFi dApps for the Bitcoin ecosystem through RSK. These DeFi applications include oracles, marketplaces, payments, on-chain credit pools, and more.

Limitations 

RSK uses Solidity, which does not have visibility into the Bitcoin state (whereas some options in this list do). 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 RSK, network security relies on a subset of Bitcoin miners, which introduces centralization and security implications. 

Liquid Network

Liquid is a federated Bitcoin sidechain that features expressive Bitcoin smart contracts. Liquid brings programmability to its network through a derived Bitcoin asset. Similar to RSK, a user tokenizes their Bitcoin into a programmable synthetic asset, which can be converted back into Bitcoin 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.

Mintlayer

Mintlayer is a Bitcoin sidechain designed to enable the tokenization and trading of various assets. Mintlayer implements Chainscript, its own scripting language and a superset of Bitcoin script and is interoperable with both the Bitcoin and Lightning networks.

Approach

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 payments can be batched together in a single transaction, saving block space.

As a network, Minelayer supports WebAssembly smart contracts and natively supports ink!, a framework for smart contract development in Rust. Developers can also use Solang to compile Solidity contracts to WebAssembly if they are already familiar with Ethereum’s programming language.

Use cases

Mintlayer is currently live on testnet, and its mainnet is scheduled to launch in 2023. When fully launched, developers will be able to mint new DeFi assets, issue stablecoins, facilitate confidential settlements, and more.

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.

Web3 Programming Languages on Independent Blockchains 

Some independent blockchains provide developers with Web3 programming languages for writing smart contracts and creating dApps for the Bitcoin ecosystem. These blockchains have consensus protocols, miners, and transactions that are independent of Bitcoin; yet still establish and maintain a connection to Bitcoin.

Stacks

On the Stacks blockchain, Clarity is the programming language for writing fully expressive smart contracts for Bitcoin. 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 application, but Clarity gives decentralized apps additional capabilities. Some of those capabilities are access control (pay to access), non-fungible and fungible tokens, business model templates, app-specific blockchains, and more. 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.

Internet Computer Protocol

Motoko is the programming language of DFINITY’s Internet Computer Protocol (ICP), an independent blockchain working on a plan to integrate directly with Bitcoin. Writing Bitcoin smart contracts with Motoko is dependent on the success of ICP’s proposed integration with the Bitcoin chain.

Approach 

By using Motoko, developers can create “Canisters” (smart contracts) to build decentralized applications for the Bitcoin ecosystem. Developers will be able to use Motoko smart contracts to create Bitcoin dApps because Motoko’s Canisters can communicate with the Bitcoin network and replicate the Bitcoin chainstate on the mainnet of the Internet Computer.

It is also expected that developers will be able to use Canister contracts written in Motoko to query and receive information on Bitcoin’s unspent transaction output (UTXO). If ICP succeeds in integrating with Bitcoin, developers will be able to create dApps on ICP, and those dApps will be able to execute transactions on the Bitcoin chain.  

Use cases 

ICP’s integration with Bitcoin is still in the works, and there aren’t any live use cases of what could be built on Bitcoin using Motoko. However, ICP recently introduced the launch of the beta version of their BTC integration on testnet

Limitations

It’s difficult to pinpoint the limitations of writing smart contracts for Bitcoin with Motoko since the project is not yet live. However, ICP’s connection to Bitcoin suggests that it skews toward centralization. Therefore, you’ll need to rely on a federated model where some trusted nodes on the ICP subnet approve transactions before they are replicated on the Bitcoin chainstate. 

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.

Would you like to see how the Bitcoin ecosystem compares to other Web3 ecosystems? Download our free guide to the Web3 ecosystems of 2022.

Download the Guide
Copy link
Hiro news & product updates straight to your inbox
Only relevant communications. We promise we won’t spam.

Related stories