Settlement and Validation

From Commitment to Verification

Once your contract is compiled, you anchor its bytecode commitment hash on Bitcoin. That anchor is your contract's permanent fingerprint. Every node uses it to judge future calls. No central coordinator and no voting rounds, simply Bitcoin as the source of truth.

Anatomy of a call

Every contract call is a signed call envelope containing the network, contract ID, function name, arguments, caller key, a unique call ID, and the caller's signature. The envelope also names the exact Bitcoin outpoint that its anchoring transaction must spend.

The anchoring transaction carries a protocol stamp in an OP_RETURN output: a compact commitment of the envelope hash and the contract ID. When that transaction confirms, the call is final and ordered.

This binding closes replay and front-running holes structurally:

• An envelope can't be re-anchored in a different transaction, because the anchor outpoint wouldn't match.
• A third party can't front-run your call with their own transaction, because they can't spend your outpoint.
• The confirmed stamp binds the routed function to the committed envelope, so a forged wrapper can't redirect a call to a different function than the one committed on-chain.

What a node does on every call

At intake (from a client or gossip):

1. Fetch the payload and parse the envelope.
2. Validate the anchor binding: the anchoring transaction's first input must spend the outpoint the envelope names.
3. Queue the pending call for execution once its transaction confirms.

At confirmation (block by block):

1. Scan the block for protocol stamps.
2. Re-validate the anchor binding: this check is consensus-critical and deterministic. A mismatched or unparseable envelope is invalid on every honest node, with no execution.
3. Derive context from Bitcoin: block height, sender address, and the anchor transaction's inputs and outputs.
4. Deterministically execute the call against the anchored contract bytecode and context.
5. Commit the resulting write-set with undo data, and fold it into the block's state root.

No consensus ceremony is needed. Determinism plus public anchors mean every honest node reaches the same verdict independently.

State roots and replay consistency

At every Bitcoin block, each node computes a Merkle state root over all contract state. State roots make divergence detectable at a glance: two nodes with the same root at the same height provably hold the same state, and anyone can re-derive the root from the confirmed call log to audit it.

Reorg handling

Bitcoin reorganizes occasionally, and SCL settlement follows the chain. Nodes keep undo logs and a block journal covering the last 144 blocks (about one day). A shallow reorg rolls state back automatically and replays the new branch. Deeper divergence triggers a full re-derivation from the confirmed call log.

Guarantees

• Deterministic replay. Same payload and context → same result on every honest node.
• Objective disputes. You can prove correctness from the Bitcoin anchor, the execution trace, and the block's state root.
• Automatic rejection. Invalid calls never "sneak through." They fail locally, with no votes and no leaders.
• Replay and front-run resistance. Anchor binding ties every call to one specific Bitcoin transaction.
• Lightweight by design. Verification is deterministic VM steps plus Bitcoin context. Because SCL is bounded, and your node hard-limits resources, the cost stays predictable and low. Nothing like Proof-of-Work.
• Batch-friendly. Inputs are fixed and public. You can rerun large histories offline and verify them yourself.

Next steps

For deployment and ops, see Node Operations (running hosts, indexing history, REST).