Settlement
Spek has three settlement layers and states each for what it is. There is no finality gadget, and nothing on this page pretends there is.
The 4-block fork window
Each block adds its score to its chain's cumulative score, and the heavier chain wins. When a competing branch forks within 4 blocks of the tip, both branches are compared by cumulative score once each holds at least two blocks above the fork point, and the loser is dropped. Waiting for both sides avoids switching back and forth on every block. The reorg is checked against a copy of the ledger before any live state changes, and rollback on this path is bounded at 5 blocks.
Forks deeper than the window, such as the two sides of a healed network partition, go to a full download that finds the true branch point, compares cumulative score, and reorgs at any depth above the node's restoration pin.
Confirmations by attacker share
Draws are fixed per height, so an attacker can rewrite history only by out-scoring the honest chain over the same heights. The tables below give the probability that a transaction is ever reversible, and the confirmations needed for under one reversible slot per century, against an attacker holding share q of the draws who may choose its fork point in hindsight. Integrators choose their depth from the share they want to tolerate: for example 136 confirmations, about 68 minutes, against an attacker holding a third.
Probability that a transaction at k confirmations is ever reversible, for an attacker holding share q of the draws who may choose its fork point in hindsight (RFC-0012, Appendix B):
| q | k = 6 | 10 | 30 | 60 | 120 | 240 |
|---|---|---|---|---|---|---|
| 0.10 | 3.6e-4 | 4.8e-6 | 3.8e-15 | 1.3e-28 | 2.3e-55 | ~0 |
| 0.20 | 1.8e-2 | 2.4e-3 | 2.0e-7 | 2.2e-13 | 3.7e-25 | 1.4e-48 |
| 0.33 | 2.4e-1 | 1.3e-1 | 7.3e-3 | 1.4e-4 | 6.4e-8 | 1.8e-14 |
| 0.40 | 5.5e-1 | 4.3e-1 | 1.5e-1 | 3.5e-2 | 2.3e-3 | 1.3e-5 |
Confirmations for under one reversible slot per century (1,051,200 slots a year):
| q | 10% | 20% | 25% | 30% | 33% | 40% | 45% |
|---|---|---|---|---|---|---|---|
| k | 16 (8 min) | 37 (18 min) | 58 (29 min) | 95 (48 min) | 136 (68 min) | 412 (3.4 h) | 1,686 (14 h) |
Parameters marked as placeholders are substituted at launch. This document describes the implementation as it exists and is not an offer of any kind.
Restoration pins
A running node never reorganises below its restoration pin: the newest checkpoint boundary buried at least one full interval below its tip. Checkpoint boundaries sit every 4,000 blocks (about 33 hours), so the pin trails the tip by 33–67 hours.
The checkpoint barrier
A node with no history of its own, such as a new node or one that was offline for days, trusts the checkpoints compiled into its release and pin files signed by a threshold of checkpoint signers. A fork whose branch point lies behind the node's restoration pin or a hard checkpoint is never resolved automatically, and the peer offering it is banned.
No finality gadget
There is no finality gadget and no rollback cap shorter than the pin. A cap was designed and dropped: as drafted, both sides of a long partition would each have refused the other forever, and an eclipsed node would have accepted the eclipsing chain for good. Coinbase outputs mature after 3,000 blocks, about 25 hours.