# Security model

SQRL assumes one thing: that Bitcoin remains secure, since settlement, ordering and finality derive from it. On that assumption the protocol gives guarantees any party can check for itself.

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

## Guarantees

* **Deterministic replay.** Identical inputs yield identical outputs on every node.
* **Objective disputes.** Correctness is provable from the contract commitment, the protocol stamp, execution traces and the block's state root.
* **Automatic rejection.** Invalid transitions are discarded without forks or coordination.
* **Replay and front-run resistance.** Anchor-outpoint binding ties every call envelope to exactly one Bitcoin transaction.
* **Divergence detection.** Per-block state roots make any disagreement between nodes detectable and auditable from the confirmed call log.
* **Bounded stall exposure.** Partition-scoped state confines data withholding to the withholder's own transaction footprint, time-boxed by the void window. See [Global and partitioned state](/protocol/contracts/state-partitioning).
* **Validator accountability without validator trust.** Seats attest to state they cannot falsify undetected; a dishonest quorum can disrupt the liveness of attestation, never the correctness of state.
* **Subnet integrity without subnet transparency.** A closed subnet's history is bound to Bitcoin anchors it cannot rewrite, while its data stays inside the membership boundary.
* **Quantum-reliable integrity.** Verifying the ledger is replay against hash-based commitments, which survive quantum cryptanalysis. See [Post-quantum security](/protocol/security/post-quantum).

## Cryptographic primitives

* **Commitments.** The hash of a contract's bytecode binds its semantics; any change produces a different hash with overwhelming probability.
* **Collision resistance.** With SHA-256, the probability of two different bytecodes sharing a hash is negligible (below 2⁻¹²⁸).
* **Authorisation.** Calls are authorised by the keys that control the Bitcoin outputs they spend.
* **Replay protection.** Each envelope names the unique outpoint its anchoring transaction must spend.

## Trust boundaries

* **Bitcoin data source.** Nodes read transactions and UTXOs from a configured backend and verify the fields used for execution: commitment outputs, relevant UTXOs and confirmation depth.
* **Caches.** Cached Bitcoin responses and indexes are optimisations; every correctness-critical decision is reproducible from canonical inputs.
* **Reorgs.** Recent transactions are pending until a confirmation threshold, and a 144-block journal rolls back and replays shallow reorganisations.

## Keys

The protocol imposes no custody model beyond standard Bitcoin key ownership. Institutional anchoring and issuer keys are expected to live in the institution's existing HSM and key-ceremony infrastructure; individual signers use hardware wallets or the SQRL wallet. Confirm transaction outputs and `OP_RETURN` contents before you sign.

## Denial of service

Execution ceilings, payload and request limits, rate limiting on expensive endpoints, and configurable retention for payload history and indexes bound the worst-case cost of evaluation and storage for adversarial workloads. The reference implementation maintains golden test vectors, cross-platform determinism checks and fuzzing to keep independent evaluators in agreement.