Clear control boundaries: how SQRL separates authority, execution and settlement

A regulated institution needs to answer a short list of questions about every transaction. Who authorised it? Which rules applied? What software ran them? What did it consume? Who checked the result? Where is it recorded?

SQRL is built so that each of those questions has its own layer and its own record.

Before anything executes

Every instruction on SQRL is a signed call envelope that binds the network, contract, function, arguments, caller key, call ID, signature and a specific Bitcoin outpoint. A protocol stamp in the Bitcoin transaction commits the envelope hash and contract target. Nodes validate that binding, derive the Bitcoin context and only then hand the call to the SQRL virtual machine.

Contracts are written in SCL and compiled to a canonical artefact. Given the same artefact, call, prior state and Bitcoin context, independent nodes reproduce the same write set and compare the same state root.

Where XRB fits

Running contracts uses computation and storage on every validating node, so the network needs a fair, deterministic way to link the capacity a contract can use to the work validators do. XRB does this. Contracts stake XRB to set an execution tier; computation and storage are assessed under bounded rules; validators replay calls and keep verifiable state.

The engineering is built into the node's execution lifecycle. Production activation is a separate protocol event, gated until the activation height and XRB parameters are set.

One job per layer

• SQRL defines how an instruction is signed, committed, validated and settled across each bank's subnet.
• SCL is the language the contract is written in, run by the SQRL virtual machine.
• XRB supplies contract resource capacity and validator incentives.
• Lightning carries payments between subnets.
• Bitcoin provides the common ordering, settlement and verification record.
• Orobit maintains the technology and the token foundation.

Because responsibilities are separate, failures are attributable. A bad signature belongs to the instruction. A rejected call belongs to validation or execution. A state mismatch belongs to replay. A custody decision belongs to whoever holds the key. The bank remains accountable for the services it runs, on infrastructure that shows its work.

Why market-structure rules make this relevant

In the United States, the Senate Banking Committee advanced the Digital Asset Market CLARITY Act (H.R. 3633) on 14 May 2026, with updated text following in July. As at 1 September 2026 it had not become law, and its language may still change.

We do not present SQRL or XRB as compliant with proposed legislation. The connection is architectural. These debates keep returning to the difference between issuers, intermediaries, software publishers, custodians and people holding their own keys. That difference is hard to assess in a system that hides every role behind one interface. SQRL produces four separate records instead:

• The contract record: canonical bytecode, ABI, metadata and contract ID.
• The instruction record: caller, signature, function, arguments and call ID.
• The Bitcoin record: the committed envelope, contract target, bound outpoint and confirmed order.
• The execution record: the write set, resource receipt and state root needed for replay.

These records do not settle a legal classification or prove that a disclosure is accurate. They show exactly what the system received, executed, consumed and committed, which is where any supervisor starts.

Industry commentary only; not legal advice.