Smart Contracts
Liquid is not just a payments and asset network. It also supports programmable spending conditions through Simplicity, a smart contract language designed for Bitcoin style UTXO chains. Simplicity is live on Liquid today, which makes Liquid one of the few production networks where you can build covenants and richer on chain logic without giving up Bitcoin's security model.
This page is a short orientation. The authoritative reference is the Simplicity documentation.
What Simplicity is
Simplicity is a typed, formally specified, deterministic language for expressing the spending conditions of a UTXO. It plays the same role Bitcoin Script plays on Bitcoin, but it is more expressive and more analyzable: every program has a precise mathematical specification, and properties of programs can be checked statically.
Developers usually don't write raw Simplicity. They write SimplicityHL, a higher level language with Rust like syntax that compiles down to Simplicity. The compiled program is committed to a UTXO via Taproot, and is only revealed when the UTXO is spent.
How programs run
A Simplicity program is reactive. It doesn't initiate transactions, hold balances, or run on a schedule. It examines a proposed transaction and answers a single question: "do I approve this spend or not?"
When a node validates a transaction that spends a UTXO controlled by a Simplicity program, it runs the program with three inputs:
- values hardcoded inside the program itself (for example, public keys),
- the inputs and outputs of the proposed transaction,
- witness data supplied by whoever is trying to spend the UTXO.
Because Simplicity is deterministic, every node reaches the same verdict. There is no I/O, no network access, no shared mutable state. Anything beyond the contract's own validation logic happens in client software (a wallet or a contract specific app) that drives the contract forward by constructing and submitting transactions.
What you can build
Simplicity fits financial logic that needs to live on chain:
- Multisig and threshold spending conditions
- Hash time locked contracts (HTLCs) for atomic swaps and Lightning style payments
- Covenants that constrain where assets can move next (recursive covenants are possible)
- Oracle driven contracts, where an off chain signer attests to a fact (a price, an event outcome) and the contract reacts to it
- Prediction markets, vaults, escrow, and structured settlement flows
What you should not put in a Simplicity program is anything that doesn't need to be re executed by every validating node: UI logic, projections, accounting that can be reproduced client side, and so on.
Why this matters for an integration
For a typical exchange or wallet integration around LBTC, USDt, or AMP2 assets, you don't need to write Simplicity. The flows in this guide work on standard Liquid transactions.
Simplicity becomes relevant when you want to build products on top of Liquid that go beyond plain transfers: programmable settlement, on chain swaps, vault style custody, structured products. In those cases, Simplicity is the substrate, and the Simplicity docs and SimplicityHL examples are the right place to go next.
Resources
Next steps
- Liquid Assets: the asset model that Simplicity contracts can lock and release
- LWK Overview: start building wallet integrations on Liquid