TL;DR: Simplicity is a smart contract language created by Blockstream Research engineer Dr. Russell O'Connor for Bitcoin and the Liquid Network. Built from nine primitive combinators with formal semantics defined in the Coq proof assistant (renamed Rocq in 2025), Simplicity enables contracts that can be mathematically proven correct before execution. It launched on the Liquid Network in July 2025 after more than a decade of research and development.
Simplicity is a typed, combinator-based functional programming language for blockchain smart contracts, created by Blockstream Research engineer Dr. Russell O'Connor. Unlike general-purpose smart contract languages, Simplicity is deliberately not Turing-complete. It can express any finite computation needed for smart contracts while guaranteeing termination, bounded resource usage, and compatibility with formal verification. Simplicity runs in production on the Liquid Network, which Blockstream Research is using to build the case for eventual Bitcoin mainchain activation.Why Simplicity Exists
Bitcoin Script is intentionally limited. Satoshi Nakamoto designed it with a small set of opcodes, no loops, and a stack-based execution model that favors simplicity over expressiveness. Several opcodes were even disabled early in Bitcoin's history due to security concerns. The result is a scripting system that handles basic spending conditions (signature checks, timelocks, hash locks, multisig) but struggles with anything more complex.
This conservatism has served Bitcoin well. The scripting system is small enough to reason about, and its limitations reduce the attack surface for consensus-critical code. But it also means Bitcoin cannot natively express programmable vaults, covenants, complex delegation schemes, or many of the financial primitives that developers want to build.
On the other end of the spectrum, Ethereum's Solidity and the Ethereum Virtual Machine (EVM) offer Turing-complete programmability with global mutable state. The trade-off: a vastly larger attack surface. The DAO hack in 2016, the Parity wallet freeze, and billions of dollars lost to reentrancy bugs, integer overflows, and logic errors across thousands of contracts demonstrate the cost of that expressiveness. When a bug in a financial contract means lost funds with no recourse, the programming model matters.
Simplicity occupies the space between these two extremes. It provides the expressiveness to build complex smart contracts (covenants, vaults, decentralized exchanges, derivatives, advanced custody schemes) while maintaining the safety properties that financial applications demand. Every Simplicity program terminates, its resource costs are known before execution, and it can be formally verified: mathematically proven to behave exactly as specified.
Dr. Russell O'Connor first envisioned Simplicity in 2012 and published the formal whitepaper, "Simplicity: A New Language for Blockchains," in 2017 at the ACM SIGSAC Workshop on Programming Languages and Analysis for Security (PLAS 2017). The paper defines the core nine combinators, the type system, and the denotational semantics that remain the foundation of the language today. After more than a decade of research, formal specification, and engineering, Simplicity launched on the Liquid Network on July 31, 2025.
How Simplicity Works
Simplicity is a functional language built from a minimal set of primitives. Where Bitcoin Script uses a stack machine with dozens of opcodes, and the EVM uses a complex virtual machine with 140+ opcodes plus global state, Simplicity uses exactly nine combinators. Every Simplicity program, no matter how complex, is composed from these nine combinators.
The Nine Combinators
Simplicity expressions are pure functions: they take an input and produce an output, with no side effects. The nine core combinators fall into four categories:
| Category | Combinator | Type Signature | Function |
|---|---|---|---|
| Product (structured data) | pair | A → B, A → C creates (B, C) | Creates a pair from two sub-expressions |
| take | (A, B) → A | Accesses the first component of a pair | |
| drop | (A, B) → B | Accesses the second component of a pair | |
| Sum (branching) | injl | A → (A + B) | Tags a value as "left" (first option) |
| injr | A → (A + B) | Tags a value as "right" (second option) | |
| case | (A + B) → C | Branches on the tag, evaluating one of two sub-expressions | |
| Unit | unit | A → 1 | Returns the single value of the unit type, ignoring its input |
| Plumbing | iden | A → A | Returns its input unchanged (identity function) |
| comp | (A → B), (B → C) | Composes two expressions sequentially |
This is the entire core language. There is no if statement, no variable assignment, no function definition, no loop construct. All control flow is expressed through case (branching on tagged values). All data manipulation is expressed through pair, take, and drop. All sequencing is expressed through comp.
The Type System
Every Simplicity expression has a precisely defined input type and output type. The type system is built from three constructors:
- Unit type (1): Contains exactly one value. Functions from the unit type represent constants.
- Sum type (A + B): Contains either a value of type A (tagged left) or type B (tagged right). Represents choices.
- Product type (A × B): Contains both a value of type A and a value of type B. Represents structured data.
From these three constructors, developers build all the data types a smart contract needs. A single bit is the sum type 1 + 1 (either a left-tagged unit or a right-tagged unit). A byte is a product of eight bits. A 256-bit hash is a product of 32 bytes. Every type in Simplicity contains only finitely many values, which is a critical property for formal verification and resource analysis.
Sequent Calculus Foundations
Simplicity's theoretical foundation is sequent calculus, a framework from mathematical logic. Each combinator corresponds to a proof rule in sequent calculus, and composing combinators corresponds to composing proofs. This connection between programs and proofs (the Curry-Howard correspondence) is what makes Simplicity's formal verification properties so natural. Proving properties about a Simplicity program is structurally equivalent to proving a theorem in logic.
Under the Hood: Commitment Merkle Root (CMR)
Every Simplicity expression has a unique fingerprint called its Commitment Merkle Root (CMR). The CMR is a 256-bit hash computed recursively over the expression's structure: each combinator type has a unique tag, and the CMR of a compound expression is derived by hashing the combinator tag together with the CMRs of its sub-expressions. For example, the CMR of comp s t is computed as SHA-256(tag_comp || CMR(s) || CMR(t)), where tag_comp is a fixed initialization vector specific to the comp combinator.
This recursive hashing produces a Merkle tree over the program's abstract syntax tree (AST). The root of this tree, the CMR, is a compact, collision-resistant commitment to the entire program. Two programs have the same CMR if and only if they have identical structure.
CMRs serve three critical functions in Simplicity's design. First, they enable on-chain commitment: a transaction output commits to a Simplicity program by including only its 32-byte CMR, not the full program code. The program itself is revealed at spending time. Second, CMRs enable pruning of this Merklized AST (MAST): because each sub-expression has its own CMR, unrevealed branches can be replaced by their hashes, proving they exist without disclosing their content. Third, CMRs are the mechanism by which jets are identified. The validator maintains a lookup table mapping known CMRs to their optimized C implementations. When a sub-expression's CMR matches a table entry, the jet fires.
Simplicity also defines two additional Merkle roots: the Identity Merkle Root (IMR), which additionally commits to witness data, and the Annotated Merkle Root (AMR), which commits to type annotations. Together, these three hashes provide a complete commitment scheme that covers program structure, runtime data, and type information.
Formal Verification: Proving Contracts Correct
Formal verification is the process of using mathematical proofs to demonstrate that a program behaves exactly as specified under all possible inputs. In the context of smart contracts, where bugs can mean permanent, irreversible loss of funds, formal verification transforms contract security from "we tested it and it seems right" to "we proved it is right."
What Formal Verification Means in Practice
Consider a vault contract that should enforce a 24-hour time delay before funds can be moved, with an immediate recovery path to a pre-defined cold storage address. In a formally verified system, a developer can prove the following properties about the contract:
- No spending path exists that bypasses the time delay (other than the recovery path)
- The recovery path sends funds only to the specified cold storage address
- No combination of inputs can cause the contract to behave outside these two paths
These proofs are mathematical certainties, as rigorous as a geometric proof, rather than confidence levels inferred from testing. If the proof holds, the contract does what it claims.
Simplicity's Formal Semantics in Coq
Simplicity's formal semantics are defined in the Coq proof assistant, a widely-used tool for constructing machine-checked mathematical proofs. The specification lives in the Simplicity Coq library (available in the official repository under Coq/Simplicity/), with core definitions in Core.v and the Bit Machine formalization in BitMachine.v. The Coq specification covers:
- Denotational semantics of the full Simplicity language, including extensions for witness data, assertions, and delegation. These define what each combinator means mathematically.
- Operational semantics of the core language, defined through an abstract machine called the Bit Machine. These define how each combinator executes in terms of concrete machine operations.
- Proof of equivalence between denotational and operational semantics, establishing that the mathematical meaning and the execution behavior agree.
The Bit Machine is a formal model of computation that tracks the exact memory and computational steps required to evaluate any Simplicity expression. Because every Simplicity type contains finitely many values and the language has no recursion or unbounded loops, the Bit Machine provides guaranteed upper bounds on both time and space for any program.
Why Other Languages Cannot Offer the Same Guarantees
Security tooling exists for Solidity (formal verifiers like Certora, fuzzers like Echidna), but it faces a fundamental obstacle: the EVM's Turing-complete execution model with global mutable state. Verifying a Solidity contract requires reasoning about all possible interactions with all other contracts on the network, since any external call could trigger arbitrary code execution. The attack surface is not just the contract itself but the entire global state of the blockchain.
Simplicity sidesteps this entirely because it has no global state and no external calls. Each Simplicity expression is a pure function from input to output, so verifying a contract means verifying a single, self-contained function, and the Coq specification provides the formal framework to do it rigorously.
Bitcoin Script also lacks formal semantics in Coq and is defined primarily through its C++ reference implementation. While Script's limited feature set makes informal reasoning feasible, it does not support formal verification in the mathematical sense.
Simplicity vs. Bitcoin Script
Bitcoin Script and Simplicity share a philosophical commitment to safety and predictability, but they differ in expressiveness and verification capabilities.
What Script Can Do
Bitcoin Script handles the spending conditions that the Bitcoin network relies on daily: pay-to-public-key-hash (P2PKH), pay-to-script-hash (P2SH), multisig arrangements (2-of-3, 3-of-5), hash time-locked contracts (HTLCs) for Lightning, and basic timelocks. These cover the vast majority of real-world Bitcoin transactions.
What Script Cannot Do
Several capabilities sit outside Script's reach, and each one blocks an entire category of applications. Script cannot inspect the transaction that spends it, so it has no introspection and cannot enforce covenants (conditions on where funds go next). Its arithmetic is capped at 32-bit integers, data concatenation is unavailable because OP_CAT was disabled, and its conditional logic does not extend beyond basic branching.
What Simplicity Adds
Simplicity can express any finite computation. On the Liquid Network, this means developers can build:
- Covenants: Contracts that restrict where and how funds can be spent in subsequent transactions. Simplicity's introspection capabilities allow a contract to examine the transaction spending it and enforce rules on outputs.
- Vaults: Time-delayed spending with emergency recovery paths. Funds enter the vault and cannot be moved for a specified period, with a separate "panic button" that redirects to cold storage.
- Complex delegation: Authorize a third party to sign transactions on your behalf, but only under specific conditions (amount limits, destination restrictions, time windows).
- Advanced multisig: Beyond simple m-of-n schemes. Policies like "2-of-3 for amounts under 1 bitcoin, 3-of-5 for larger amounts, with a 48-hour time-locked 1-of-5 recovery fallback."
- Arithmetic and data operations: Full 64-bit arithmetic, SHA-256 hashing, elliptic curve operations, and data manipulation that Script's disabled opcodes prevent.
Simplicity achieves this without sacrificing the properties that make Script safe. Every Simplicity program terminates (no infinite loops). Every program's resource costs are known in advance (no gas estimation uncertainty). And the language's design makes formal verification practical, not just theoretically possible.
Native MAST Support
Every Simplicity program is natively structured as a MAST. The program is organized as a tree, and at redemption time, only the executed branch and its Merkle path are revealed on-chain. Unused branches are pruned away.
This provides two benefits. First, privacy: observers learn only the conditions that were actually used, not the full set of conditions in the contract. Second, efficiency: on-chain size scales logarithmically with program complexity. A contract with 1,024 branches only needs to reveal about ten nodes in the Merkle path, not all 1,024 branches.
Simplicity vs. Solidity and the EVM
Simplicity and Solidity represent fundamentally different philosophies about what a smart contract language should be.
Turing Completeness: A Deliberate Omission
Solidity is Turing-complete. It supports arbitrary loops, recursion, dynamic memory allocation, and interaction with global state shared across all contracts on the network. This makes it powerful, but also makes it impossible to statically determine whether a given contract will terminate, how much computation it will consume, or how it will behave when interacting with other contracts.
Simplicity is deliberately not Turing-complete. The technical term is "finitarily complete," meaning it can express any finite function. For blockchain applications, this is the relevant boundary. Smart contracts do not need to compute the digits of pi or solve the halting problem. They need to verify signatures, check conditions, and enforce spending rules. All of these are finite computations, and all of them are expressible in Simplicity.
The practical consequence is that every Simplicity program has a provably bounded execution time and memory footprint, which lets fees be computed exactly ahead of time rather than estimated. Denial-of-service through computational exhaustion is structurally impossible because no program can run longer than its static bound.
Global State vs. Stateless Execution
The EVM maintains a global state that all contracts share and modify. A Solidity contract can call any other contract, which can call any other contract, creating complex call chains with unpredictable behavior. The reentrancy attack that drained The DAO exploited exactly this property.
Simplicity has no global state. Each Simplicity expression receives an input (the transaction data and witness data) and produces an output (accept or reject the transaction). It runs in isolation, unable to call other contracts or share state with them. The contract's behavior depends entirely on its code and its input, nothing else.
Design Philosophy Comparison
| Property | Simplicity | Solidity / EVM |
|---|---|---|
| Computation model | Pure functions (input to output) | Stateful computation with global state |
| Turing completeness | No (finitarily complete) | Yes |
| Guaranteed termination | Yes | No (relies on gas limit) |
| Resource costs | Exactly known before execution | Estimated via gas (can vary) |
| Formal verification | Native support via Coq semantics | Possible with external tools, limited scope |
| External calls | None | Arbitrary (reentrancy risk) |
| UTXO model | Yes (Bitcoin-native) | No (account-based) |
| On-chain privacy | MAST pruning hides unused branches | All contract code public |
These differences are deliberate design decisions that optimize for the specific requirements of financial contracts: verifiability, predictability, and security.
Jets: Making Simplicity Practical
Building a Schnorr signature verifier from Simplicity's nine combinators is possible, but the resulting program would be enormous. Implementing SHA-256 from scratch using only pair, take, drop, case, and friends produces a Simplicity expression measured in thousands of bytes. For a blockchain where every byte costs money and consensus time, raw Simplicity alone would be impractical for real-world use.
Jets solve this problem.
What Jets Are
A jet is a pre-compiled, optimized implementation of a Simplicity expression. When a validator encounters a Simplicity program fragment that matches a known jet, it substitutes the high-performance C implementation for the raw Simplicity bytecode. The validator executes the optimized code instead of interpreting the Simplicity combinators one by one.
The critical property: a jet is logically identical to the Simplicity expression it replaces. The optimized C code produces the same output as the raw Simplicity code for every possible input. This means jets are transparent to formal verification. When proving properties about a Simplicity program, developers can reason about the Simplicity expressions directly, ignoring the jets entirely. The proofs hold regardless of whether the jet optimization is applied.
Performance Impact
Consider Schnorr signature verification, which Blockstream Research implemented as Simplicity's "Hello, World!" demonstration:
| Implementation | Size |
|---|---|
| Pure Simplicity (raw combinators) | 14,635 bytes |
| Simplicity with jets (C + libsecp256k1) | 448 bytes |
| Equivalent Bitcoin Script | 107 bytes |
Jets reduce the Schnorr verifier from 14,635 bytes to 448 bytes, a 97% reduction. The remaining size overhead compared to native Bitcoin Script reflects the additional structure of the Simplicity program (Merkle tree encoding, type annotations), which provides the formal verification properties that Script lacks.
How Jets Work Under the Hood
The jet system works at the consensus level. The Liquid Network's node software includes a standard set of jets for common operations: SHA-256 hashing, Schnorr (BIP-340) signature verification, secp256k1 elliptic curve operations, and arithmetic operations.
When a Simplicity program is submitted in a transaction, the validator parses the program tree and identifies sub-expressions that match known jets. The matching mechanism uses CMRs: each jet has a known CMR corresponding to the Simplicity expression it replaces, and the validator compares sub-expression CMRs against a lookup table of jet CMRs. Because CMRs are collision-resistant hashes of the program's full structure, a CMR match guarantees structural identity between the sub-expression and the jet's reference Simplicity expression. For each match, the validator calls the native C implementation rather than interpreting the Simplicity bytecode. The result is the same; the execution is orders of magnitude faster.
The current Liquid Network jet table includes over 300 jets spanning categories such as SHA-256 hashing, Schnorr (BIP-340) signature verification, secp256k1 elliptic curve point operations, 32-bit and 64-bit arithmetic (add, subtract, multiply, divide, modulo), bitwise operations, and transaction introspection primitives. Each jet carries a pre-computed cost bound used for fee calculation, ensuring that jetted operations are priced accurately without runtime metering.
New jets can be added over time through network upgrades. Each new jet accelerates programs that use the matching pattern, without changing the semantics of any existing program. Programs written today, using raw Simplicity for some operation, will automatically benefit from a future jet that matches that operation.
Simplicity on the Liquid Network
Simplicity launched on the Liquid Network on July 31, 2025, reaching the locked-in phase on July 30 before activating the following day. This brought a formally specified smart contract language into production on a Bitcoin-based network, the culmination of more than a decade of research.
The Liquid Network is a Bitcoin layer-2 sidechain operated by a Strong Federation. Fifteen functionary operators sign blocks with an 11-of-15 threshold, within a broader federation of more than 85 member entities (as of April 2026) spanning exchanges, trading desks, infrastructure providers, and wallets. Liquid bitcoin (LBTC) is pegged 1:1 to bitcoin on the mainchain. The network produces blocks approximately every one minute with deterministic finality, supports Confidential Transactions (which hide both transaction amounts and asset types from outside observers), and enables native asset issuance.
Simplicity's deployment on Liquid serves multiple purposes:
- Production validation: Real financial contracts with real funds test the language's safety and correctness properties under actual market conditions, not just test environments.
- Developer ecosystem growth: Developers build and deploy Simplicity contracts on a live network, creating tooling, libraries, and patterns that benefit the entire ecosystem.
- Staged rollout toward Bitcoin: Liquid is a proving ground where demonstrating Simplicity's reliability strengthens the case for eventual Bitcoin mainchain activation.
The Liquid Network, built on the open-source Elements platform, provides the consensus and transaction infrastructure that Simplicity operates within. Elements handles block production, transaction validation, and the federated peg mechanism, while Simplicity extends the scripting capabilities available for constructing transaction outputs.
What You Can Build With Simplicity
Simplicity's expressiveness opens categories of applications that neither Bitcoin Script nor previous Liquid scripting could support. The following use cases are possible on the Liquid Network today.
Programmable Vaults
A vault is a self-custodial security mechanism. Funds deposited into a vault cannot be immediately spent. Instead, a "vaulting" transaction initiates a time-delayed withdrawal (for example, 24 hours). During this delay, the vault owner can cancel the withdrawal by sending funds to a pre-defined recovery address, typically cold storage.
Simplicity enables vaults because it supports both introspection (the contract can inspect the spending transaction) and covenant logic (the contract can enforce conditions on where funds go). The time delay and recovery path are enforced by the contract itself, not by a third party.
Covenants
A covenant restricts how a UTXO can be spent in future transactions. Simplicity's transaction introspection allows contracts to examine output addresses, amounts, and scripts in the spending transaction, then enforce rules.
Examples include spending limits (no single transaction can move more than a specified amount), destination restrictions (funds can only be sent to a whitelist of addresses), and chain-of-custody rules (each subsequent transfer must satisfy the same covenant conditions).
Blockstream researcher Sanket Kanjalkar demonstrated a working implementation of CTV (CheckTemplateVerify) semantics using Simplicity. On the Liquid Network, where Simplicity is already active, the covenant functionality that has been proposed for Bitcoin as a new Script opcode can be expressed directly in a Simplicity program, without a network-wide consensus change to add a dedicated opcode.
Complex Multisig and Delegation Schemes
Bitcoin Script supports basic m-of-n multisig, but Simplicity enables far more sophisticated policies. A corporate treasury might use a scheme where day-to-day operations require two of three executive signatures, large withdrawals require three of five board signatures, and an emergency recovery path activates after 30 days with a single key held by a designated trustee.
Delegation schemes allow a keyholder to authorize a third party to sign transactions within specific constraints: maximum amounts, approved destinations, time windows. The delegation is enforced on-chain by the Simplicity contract, not by trust in the delegate.
Discreet Log Contracts (DLCs)
DLCs are a protocol for creating Bitcoin-settled financial contracts (futures, options, insurance, event-based payouts) using oracle attestations. Two parties lock funds into a contract, and the payout is determined by an oracle's signature on the outcome of a real-world event.
Simplicity enables more expressive DLC constructions because it can perform the elliptic curve arithmetic and conditional logic that DLCs require, without the workarounds and size limitations that Bitcoin Script imposes.
Stateless Decentralized Exchanges
Because Simplicity operates on the UTXO model without global state, exchange contracts settle atomically within individual transactions. Two parties can swap Liquid assets (LBTC for USDT, for example) through a contract that verifies both sides of the trade and settles in a single transaction, with no intermediary and no risk of partial execution.
Advanced Custody Solutions
Institutional custody requires policy enforcement: role-based access, approval workflows, spending limits, audit trails. Simplicity can encode these policies directly into the contracts that control the funds, reducing reliance on external policy engines for enforcement. The policy rules are transparent, auditable, and mathematically verifiable.
The Development Ecosystem
SimplicityHL: The High-Level Language
Writing raw Simplicity combinators by hand is like writing assembly language: powerful, but not practical for most developers. SimplicityHL (formerly called Simfony; renamed in 2025) is a high-level programming language with Rust-like syntax that compiles down to Simplicity bytecode.
The relationship mirrors how Rust compiles to machine code. Developers write readable, structured code in SimplicityHL, and the compiler generates the raw Simplicity expressions. The compiled output retains all of Simplicity's formal verification properties because the compilation is semantics-preserving.
SimplicityHL is available as an open-source project under the BlockstreamResearch GitHub organization. While still under active development, it provides the primary developer-facing interface for writing Simplicity contracts today.
Developer Tools
The current Simplicity development ecosystem includes:
| Tool | Language | Purpose |
|---|---|---|
| SimplicityHL compiler | Rust-like syntax | Compiles high-level code to Simplicity bytecode |
| In-browser IDE | Web | Write and test Simplicity contracts without local setup |
| rust-simplicity | Rust | Library for constructing and manipulating Simplicity programs |
| hal-simplicity | CLI | Command-line tools for working with Simplicity programs |
| Coq specification | Coq | Formal semantics implementation for proof construction |
| Haskell implementation | Haskell | Interpreter, type-checker, and serializer using tagless final style |
| Example contracts | SimplicityHL | Reference implementations demonstrating vaults, covenants, and signature verification |
Getting Started
Developers looking to build on Simplicity can start with the official documentation at simplicity-lang.org, which covers the language specification, SimplicityHL syntax, and deployment on the Liquid Network. Blockstream Research also maintains tutorials and onboarding materials, with Liquid Bootcamps providing structured learning paths for new Simplicity developers.
For developers familiar with the Coq proof assistant, the formal specification provides the definitive reference. The Haskell implementation offers an alternative entry point for those who prefer working with functional programming tools directly.
Russell O'Connor's ongoing series of posts on Delving Bitcoin provides deep technical discussion of Simplicity's design philosophy, covering topics from data types and side effects to programs and addresses.
Simplicity's Future
The "Last Soft Fork" Thesis
Blockstream developer Christian Lewe has described Simplicity as potentially "the last soft fork" that Bitcoin would need. The logic: rather than debating individual opcode additions (OP_CTV, OP_CAT, SIGHASH_ANYPREVOUT) as separate consensus changes, a single Simplicity activation would subsume all of them. Any functionality that these opcodes would provide can be implemented as a Simplicity program.
There is technical nuance to this claim. New jets would still require consensus changes to add optimized implementations of common patterns. The core language itself, however, is expressive enough that new scripting capabilities would not require language-level changes.
Path to Bitcoin Mainchain
Bringing Simplicity to Bitcoin mainchain would require a soft fork. No formal proposal for this has been made. The current development strategy follows a deliberate staged approach:
- Liquid testnet: Initial testing and iteration (completed)
- Liquid mainnet: Production deployment with real financial use (current, since July 2025)
- Bitcoin support: developed in Blockstream Research's open-source Simplicity repository, separate from the Bitcoin Core project
- Bitcoin mainnet proposal: After sufficient validation on Liquid, a formal soft fork proposal
The Liquid deployment provides the strongest possible evidence for a Bitcoin mainnet proposal: a track record of real contracts, real funds, and real-world usage demonstrating the language's safety and utility.
Ongoing Development
Blockstream Research continues active development across multiple fronts:
- SimplicityHL maturity: Expanding the high-level language with more features, better error messages, and comprehensive documentation
- New jets: Adding optimized implementations for commonly used Simplicity patterns
- Tooling and wallet support: Integrating Simplicity contract support into wallet software and developer tools
- Community education: Liquid Bootcamps, documentation, tutorials, and developer outreach
- Formal verification tooling: Making it easier for contract developers to write and check proofs about their programs
Blockstream is actively hiring developers and smart contract engineers to work on Simplicity. Contributors to the project include Sanket Kanjalkar, Christian Lewe, Andrew Cann, and Andrew Poelstra, working under the Blockstream Research umbrella.
Frequently Asked Questions
Is Simplicity Turing-complete?
No, and this is a deliberate design decision. Simplicity is finitarily complete, meaning it can express any finite computation. For smart contracts, this covers every practical use case (signature verification, conditional logic, hash operations, arithmetic) while guaranteeing that every program terminates and has bounded, predictable resource costs. Turing completeness adds the ability to express computations that never terminate, which is a liability, not a feature, in financial contracts.
Can Simplicity do everything Solidity can?
Simplicity can express any finite computation, which covers the vast majority of useful smart contract logic. What Simplicity deliberately excludes are patterns that depend on Turing completeness (unbounded loops, recursion) and global mutable state (reading or writing shared state across contracts). In practice, the applications people build with Solidity (exchanges, lending, vaults, governance) are expressible in Simplicity, with stronger safety guarantees and without the systemic risks of global state.
Do I need to write raw combinators?
No. SimplicityHL provides a Rust-like syntax that compiles to Simplicity bytecode. Most developers will write SimplicityHL code and never interact with the raw combinators directly, the same way most developers write C or Rust rather than assembly language. The raw combinator layer exists to provide a minimal, formally verifiable foundation.
Where can I deploy Simplicity contracts today?
Simplicity is live on the Liquid Network as of July 2025. Developers can deploy contracts on Liquid mainnet today. There is no timeline for Bitcoin mainchain activation; the Liquid deployment is a production proving ground for the eventual Bitcoin proposal.
Is Simplicity available on Bitcoin mainnet?
No. Simplicity runs on the Liquid Network, a Bitcoin sidechain, as of July 2025. It is not active on Bitcoin mainnet. Bringing Simplicity to Bitcoin would require a soft fork, and no formal proposal has been made. The current strategy uses the Liquid deployment as a proving ground to build the case for an eventual Bitcoin proposal through the standard BIP process.
What are jets, and why do they matter?
Jets are optimized, pre-compiled implementations of common Simplicity expressions. When the network validator recognizes a Simplicity fragment matching a known jet, it executes the optimized native code instead of interpreting the raw Simplicity. The matching works through Commitment Merkle Roots (CMRs): each jet has a known CMR, and the validator compares sub-expression CMRs against a lookup table to identify candidates. Jets reduce program size by up to 97% and improve execution speed by orders of magnitude, making Simplicity practical for real-world deployment. The Liquid Network currently supports over 300 jets covering hashing, signature verification, elliptic curve operations, and arithmetic. Jets are logically identical to the expressions they replace, so they do not affect formal verification.
Could Simplicity replace all future Bitcoin soft forks?
The core thesis is that a single Simplicity activation could provide the functionality of many proposed Bitcoin Script changes (OP_CTV, OP_CAT, SIGHASH_ANYPREVOUT, and others). New jets would still require consensus changes to optimize common patterns, but new scripting capabilities would not require language-level changes. Whether this reduces the need for future soft forks in practice depends on the Bitcoin development community's evaluation of the trade-offs.