# Core concepts

The ideas the protocol is built on: contracts sealed to Bitcoin outputs, calls bound to the transactions that carry them, verification by deterministic replay instead of consensus, and XRB, the token in the mandatory path of every chargeable action.

> Part of the SQRL documentation, section "Protocol".
> Rendered page: https://docs.sqrl.tech/protocol/core-concepts

## UTXOs as single-use seals

In SCL, a contract's deployment is bound to a Bitcoin UTXO.
This UTXO acts as a one-time "seal" for the contract's origin. Once it is spent, the deployment is finalized, and its commitment is permanently recorded on Bitcoin.

This commitment is a **hash of the contract bytecode and parameters**.
It does not store the contract's evolving state, only the immutable reference to its original definition.

  State changes happen off-chain in the SCL node network, but every change is committed on Bitcoin and must be verifiable against this anchored commitment and Bitcoin-derived context.

## Bitcoin as the source of truth

When a contract is deployed in SCL, nodes compile its source code into deterministic VM bytecode.
A **commitment hash** of that bytecode is embedded into a Bitcoin transaction output, anchoring the contract's definition to Bitcoin's immutable ledger.

This commitment covers the contract's compiled logic and any compile-time constants.
It does not include mutable state, such as balances or ownership records, which are managed off-chain by the SCL node network.

## Every call is anchored too

Contract calls don't float freely through the network. Each call is a signed **call envelope** (the contract, the function, the arguments, and the caller), and a hash of that envelope is committed on Bitcoin inside the anchoring transaction (a **protocol stamp** in an `OP_RETURN` output).

The envelope also names the exact Bitcoin outpoint its anchoring transaction must spend. That binding means a call can't be replayed, re-anchored, or front-run: if anyone tries to attach your envelope to a different transaction, validation fails structurally on every honest node.

When validating a confirmed call, nodes:

1. Read the protocol stamp from the Bitcoin transaction.
2. Check the envelope's anchor binding: the transaction must spend the outpoint the envelope names.
3. Derive execution context from Bitcoin (block height, sender, transaction inputs and outputs).
4. Replay the call deterministically against the anchored contract bytecode.

This model ensures that the contract's origin can be independently verified at any time, and that all state changes are provably linked back to on-chain commitments, call by call, block by block.

## Verification without consensus

SCL execution is deterministic: the same inputs always produce the same outputs. Given the payload, original commitment, and Bitcoin context, every honest node will compute the same result.

No voting. No leader election. If a payload doesn't match the rules or anchor, your node drops it.

Nodes also publish a **state root** at every Bitcoin block: a single hash committing to all contract state at that height. Anyone can recompute it from the confirmed call history and check that their node agrees.

**Practical impact**

* **Low runtime cost.** You pay only for VM steps for this call. Nothing Proof-of-Work-level to compute.
* **Light resource footprint.** Verification is local execution plus reading the anchor and Bitcoin-derived context.
* **Rerun at will.** Inputs are fixed and public, so you can batch-replay large histories offline and verify them yourself.
* **Bounded behavior by design.** Non-Turing-complete + no nondeterminism means predictable runs, fewer edge cases, and cleaner failure modes.

  This removes the need for network-wide voting. Anyone can verify by replaying against Bitcoin.

  Invalid transactions simply fail verification on all honest nodes.

## XRB: the incentive layer

Verification without consensus still needs verifiers. On the canonical ledger, accredited validator seats replay every contract execution, publish state roots and co-sign attestations, and anyone can check their work by replaying the same inputs. Every contract also consumes shared resources: compute on every node that replays it, and storage on every node that holds its state.

**XRB** is the network token that aligns both sides:

* **Validator seats earn XRB** from a fixed, front-loaded emission pool released per Bitcoin block and weighted by attested activity.
* **Every chargeable action burns XRB**: execution above the free T0 envelope, subnet checkpoints and batch settlement. The T0 envelope is sized to a single basic operation, so simple token transfers stay free; complexity, composition and state growth are what pay.

The supply is fixed, there is no block subsidy, and usage resolves to burned XRB. See [XRB and network economics](/protocol/network/economics); the full model, including the fee schedule, is in the companion tokenomics paper.