SQRL protocol

SQRL applies permission only where banks require it. A canonical ledger is operated by a named set of accredited validators. Banks and consortia run closed subnets from the same codebase, publishing only Bitcoin-anchored commitments. Value moves between subnets through the canonical ledger, and instruments issued on either tier move instantly over Lightning through multi-asset channels with in-flight FX. Settlement, ordering and the audit trail stay permissionless on Bitcoin.

#Who this section is for

The protocol pages are for the teams that review SQRL and connect to it before a pilot, and for the developers who build on it.

• Engineering teams connecting a subnet. How a subnet connects and routes, the node API, and the ways to integrate. Start with Subnets and routing and SDKs and integration.
• Risk and security reviewers. Keys, guarantees, settlement and finality, stated plainly for due diligence. Start with the Security model and Batch settlement and finality.
• Regulators and supervisors. How a supervisor replays state through an observer node instead of reading reports. Start with Supervisors and observer nodes and Verifying it yourself.
• Developers writing contracts. SCL, the compiler and the node. Start with the Quickstart and the SCL contract overview.

Treasury and operations teams will find what they run day to day in SQRL Enterprise and SQRL Markets.

#The four layers

Permission decreases downward: the layers institutions touch are gated; the layer that settles is open. See Network architecture.

#Why SCL

You write contracts in SCL, compile them to deterministic bytecode, and anchor them to Bitcoin. Every contract call is committed on-chain in a Bitcoin transaction, and every node can replay your contract locally. Verification is just: load the Bitcoin context, run the payload, and check the outcome.

SCL is deterministic and deliberately not Turing complete: no time, no randomness, no oracles, no unbounded loops. Every execution runs under hard ceilings:

• 100k instructions per call, shared across nested cross-contract calls
• 1024 stack depth
• 64 call depth
• 64 KB persistent storage per contract
• 64 KB maximum payload

For a settlement network these are not abstract properties. Deterministic, bounded execution is what makes every balance and every transfer independently re-derivable by a counterparty bank, an auditor or a supervisor, with no privileged party whose word must be taken.

#Built for regulated money

• Issuance of payment stablecoins and deposit tokens on the SQRL token standard.
• Interbank transfer inside and between subnets, routed through the canonical ledger.
• FX corridors that convert currency inside a Lightning payment, atomically.
• Supervisory visibility by design, through observer nodes that replay state rather than read reports.
• Quantum reliability: integrity rests on hash commitments, and the endpoints SQRL controls run NIST-standardised post-quantum cryptography. See Post-quantum security.

#Products built on the protocol

• SQRL Enterprise: issue and govern tokenised assets under your own keys and rules, with multi-party custody, compliance, redemption and reserve attestation.
• SQRL Markets: cross-border payments and FX for banks, converted in flight over the Lightning layer.
• SQRL Developer: an SDK and sandbox for payments and tokens. Early access
• SQRL Pay: the non-custodial SQRL wallet for Bitcoin and SQRL assets over Lightning. Beta

#Where to start