---
updatedAt: 2026-08-26T01:45:32.000Z
agentTools:
  projectIndex: https://docs.liquid.net/llms.txt
---

# Smart Contracts

A beginner-friendly orientation to Simplicity and how it enables smart contracts on Liquid.

Liquid supports use cases beyond just payments and asset issuance. It also supports programmable spending conditions through **Simplicity**, a smart contract language designed for Bitcoin-style UTXO chains. Simplicity is live on Liquid today.

This page is a short orientation. The authoritative reference is the [Simplicity documentation](https://docs.simplicity-lang.org/) site.

## 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](https://docs.liquid.net/docs/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](https://docs.simplicity-lang.org/) and [SimplicityHL examples](https://docs.simplicity-lang.org/understand/example-contracts-basic/) are the right place to go next.

## Resources

* [Simplicity documentation](https://docs.simplicity-lang.org/)
* [Simplicity execution model](https://docs.simplicity-lang.org/documentation/execution-model/)
* [Simplicity quickstart](https://docs.simplicity-lang.org/get-started/quickstart/)
* [Simplicity whitepaper](https://blockstream.com/simplicity.pdf)

## Next steps

* [Liquid Assets](/docs/liquid-assets): the asset model that Simplicity contracts can lock and release
* [LWK Overview](/docs/get-started): start building wallet integrations on Liquid