Same input, same result: deterministic execution on SQRL
If two independent nodes receive the same contract, call, prior state and Bitcoin context, they must produce the same result. This is how SQRL makes that true by design.
SQRL team, , 3 min read
SQRL is built on one engineering requirement: two independent nodes given the same contract artefact, signed call, prior state and Bitcoin-derived context must produce the same state change. For a bank, that is the difference between a ledger it has to trust and a ledger it can check.
anchored contract + signed call + prior state + Bitcoin context = one reproducible write set
Bitcoin does not run SQRL contracts. It is the common settlement and verification layer. The SQRL virtual machine runs the contract, and any node can repeat the work.
It starts with the language
Contracts on SQRL are written in SCL and compiled to a canonical artefact containing bytecode, an ABI and metadata (sclc compile contract.scl --json). Nodes execute that artefact; they never recompile source or substitute their own reading of a function.
SCL leaves out the usual sources of non-determinism. Contracts cannot read the system clock, request randomness or use floating-point arithmetic. There are no unbounded loops, dynamic dispatch or runtime code generation. Loops have known limits, recursion is capped and arithmetic uses defined 64-bit integers.
Bounded execution makes failure predictable too
Every call runs inside fixed ceilings:
- 100,000 instructions
- 1,024 stack entries
- a call depth of 64
- 64 KB of contract storage
- a 64 KB call payload
A call that exceeds a ceiling fails the same way on every node. There is no fee auction or machine-specific timeout deciding the outcome, so a bank's engineers can test both the intended result and the exact point of failure.
One signed call, one Bitcoin anchor
Each state change is a signed call envelope naming the network, contract, function, arguments, caller key, call ID and signature, and the exact Bitcoin outpoint that anchors it. A compact stamp in the transaction commits the envelope hash and contract target, and the first input must spend the named outpoint, so an envelope cannot be re-anchored elsewhere.
Bitcoin records the commitment, not the full contract state. Confirmation puts accepted calls into Bitcoin's block order.
What every node checks
- Read the stamp and identify the call.
- Verify the envelope's hash, network, contract and signature.
- Confirm the transaction spends the named outpoint.
- Load the anchored contract and the prior state.
- Derive the Bitcoin context.
- Run the bytecode in the bounded virtual machine.
- Apply the write set and compute the new state root.
State roots show where nodes disagree
Matching state roots at the same height mean nodes committed the same result. A mismatch shows the first point of divergence, which can be replayed from a known prior state. Debugging stops being an argument between operators and becomes a replay.
Reorganisations are part of the design
SQRL keeps undo data with each applied write set and holds a 144-block reorganisation journal. If Bitcoin's active chain changes inside that window, affected changes are rolled back and replayed in the new order under the same rules. This is the documented model; production evidence and security review are separate work.
What determinism does not prove
It does not prove an issuer's honesty, the backing of an asset, legal ownership or custody controls. Those need their own evidence. What it does give a bank is a reproducible path from a signed request to a bounded result that anyone with the inputs can check.
