The verification path behind every SQRL settlement
Every node on SQRL has to reach the same answer from the same inputs. This is the path from a signed instruction to a result another node can replay, and where XRB fits into it.
SQRL team, , 4 min read
A bank does not accept a payment because a system says it succeeded. It accepts it because the result can be checked. On SQRL, that check is built into the protocol: every node that receives the same instruction, the same contract and the same Bitcoin context must reach the same result, and must be able to show how it got there.
That requirement shapes four steps.
1. Identify the instruction before anything runs
Every state change on SQRL starts as a signed call envelope. The envelope binds the network, the target contract, the function and its arguments, the caller's key and signature, a unique call ID and the exact Bitcoin outpoint the transaction will spend.
The Bitcoin transaction carries a compact protocol stamp that commits the envelope hash and the contract target. Nodes check the signature, the hash and the outpoint binding before the call is executed. If any of them fail, nothing runs.
2. Run one exact contract
Contracts on SQRL are written in SCL and compiled into a canonical artefact: bytecode, an ABI and metadata. That artefact, not a product name or an interface, is what every node executes.
The complete input to a state change is: committed contract artefact + signed call + prior state + Bitcoin-derived context.
The SQRL virtual machine runs that input under fixed limits on instructions, memory, stack and nested calls. It produces a write set, and the resulting state root gives other nodes a compact checkpoint to compare against.
3. Make resource results deterministic
Execution uses shared resources, so every validator also has to agree on what a call consumed. This is XRB's role.
Each validator reads the same confirmed XRB stake for the root contract, selects the same execution tier, applies one budget across the whole call tree and produces the same resource receipt. A child call cannot open a new budget, and no wallet, deployer or node can substitute its own tier. Replays and reorganisations rebuild the result from chain state, so the same confirmed history gives the same outcome.
This path is built. Production activation is deliberately gated until the activation height and the XRB contract parameters are set. Live fees, burns and validator rewards are a separate claim, and not one we make today.
4. Verify the software doing the checking
Deterministic rules only help if every node runs the intended software. A version label such as v1.2.3 says nothing about the commit, compiler or container actually running.
Core Lightning's v26.06.7 security release showed why in August 2026: its maintainers warned that two automatically published container tags did not yet contain the intended fixes, although they reported the expected version. The lesson is simple. Check the artefact, not the label.
For SQRL nodes and contracts, a complete release record should carry the source commit, build recipe, compiler and runtime versions, a signed manifest, checksums and container digests, the contract bytecode and ABI, the XRB parameters, the resource schedule with test vectors, and a verified rollback artefact. That is the standard we are building towards across every release.
What this means for a bank
Each layer has one job. SQRL identifies and validates the instruction. The SQRL virtual machine runs the SCL contract. XRB accounts for the resources used. Bitcoin anchors and orders the commitment. Orobit maintains the technology and the token underneath. The result is a settlement record that a bank's own team, its auditors or its regulator can replay, rather than take on trust.
