Chain Finality

Soqucoin enforces a bounded-reorg finality rule at the consensus layer. A synced node rejects any block that builds on a fork more than 288 blocks (about 4.8 hours at 60-second blocks) below the active chain tip. This is the nMaxReorgDepth consensus parameter, enforced in block acceptance.

What it guarantees

Once a transaction is buried 288 blocks deep, it is final. No alternative history that reorganizes past that point will be accepted by any synced node, regardless of how much proof-of-work backs it. This is a deterministic local rule, not a probabilistic estimate. It cannot be out-hashed, rented around, or bribed.

This closes the attack most dangerous to a small merge-mined chain: a deep reorg in which an attacker rents scrypt hashpower, secretly builds a heavier chain, and rewrites history to double-spend a large exchange deposit. After the finality horizon, that rewrite is rejected outright.

Why Soqucoin uses it

A block reward normally does two jobs at once. It pays miners to produce blocks, and it funds the accumulated proof-of-work that makes rewriting history expensive. Soqucoin separates these:

• Block production is funded by merge-mining. Litecoin and Dogecoin miners produce SOQ blocks at near-zero marginal cost.
• History integrity against deep reorgs comes from the finality rule, not from the size of the subsidy.

Because deep-reorg safety no longer depends on a large perpetual subsidy, the chain can run a leaner emission schedule (see Tokenomics) without becoming cheap to rewrite. That failure mode has killed small merge-mined chains historically, such as CoiledCoin in 2012.

Why 288 blocks?

A natural question: why 288, and not a smaller or larger number?

The larger direction is the easy half. A longer window gives an attacker more time to attempt a deep reorg before finality locks a transaction in, so you do not want it any larger than necessary.

The smaller direction is the less obvious half, and it is the one that actually sets the number. The window is not really about the attacker. It is about how long the network can lose contact with itself and still recover.

Picture the blockchain as one shared ledger kept by nodes all over the world. Once in a while they lose contact, from an internet outage or a data center going down. While they are out of touch, each group keeps building on its own copy. When they reconnect, they have to merge back into a single chain. The 288-block rule sets the longest they can be apart and still merge automatically: about 4.8 hours.

Set that window too small, say one hour, and any normal outage longer than an hour would leave the chain permanently split into two conflicting versions that can never rejoin. Outages that long do happen, and a permanent split is far worse than waiting a few hours for a transaction to settle.

So the number is a balance. Too large, and an attacker gets more time inside the window. Too small, and the network cannot survive a routine connectivity drop. 288 blocks (about 4.8 hours) is long enough to ride out a realistic outage and heal itself, and short enough that high-value settlement does not wait an unreasonable amount of time. The value is set in the consensus parameters and is identical for every node.

Properties and tradeoffs

Finality is a deliberate engineering tradeoff, not a universal guarantee. The honest properties:

1. It protects nothing inside the window. Before 288 confirmations the usual probabilistic model applies, and a large hashpower rental can still reorganize recent blocks. Wait for the 288-block horizon before treating a large settlement as final. Crediting large deposits on a handful of confirmations is not safe.

2. Liveness is a separate problem. Finality seals history. It does not guarantee the chain keeps producing blocks. A majority of hashpower can still censor or stall block production. Finality is about safety (no rewrites), not liveness (blocks keep flowing).

3. Bootstrapping uses a recent reference (weak subjectivity). The rule is disabled during initial block download, since a node syncing from genesis must accept long valid histories. A brand-new node, or one offline for more than 288 blocks, should confirm it is on the canonical chain against a recent trusted reference (a known-good recent block hash) before relying on finality.

4. A long partition can split the chain. If the network is partitioned for more than 288 blocks (about 4.8 hours), each side finalizes its own tip and the two cannot automatically reconverge. By design, neither will reorg past its finality horizon. Recovery is a coordinated, manual decision. This is the fundamental tradeoff of any bounded-reorg rule: it chooses consistency (no rewrites) over availability (no stalls) under partition. Reliable peering and node connectivity are therefore operational requirements.

A worked example: why large value waits for finality

Property 1 (no protection inside the window) is the one that generates the most questions, so here is exactly what it means in practice.

Say an attacker deposits 10,000,000 SOQ to an exchange. The deposit lands in block H. The exchange credits at 200 confirmations, so at block H+200 it credits the account, and the attacker sells the SOQ and withdraws the proceeds.

The deposit is not final yet. Finality arrives at block H+288, so 88 blocks (about 88 minutes) of probabilistic-only protection remain. The attacker uses that gap. They have been secretly mining a competing chain that branches at block H-1, one block before the deposit, and in that secret chain the deposit never happened. They rent majority scrypt hashpower (cheap on a thin merge-mined chain), out-mine the public chain, and reveal the heavier fork before block H+288. The reorg depth is still under 288, so nodes accept it. The public chain rolls back to H-1, block H disappears, and the 10,000,000 SOQ is back in the attacker's wallet. They keep both the coins and the withdrawn proceeds. The exchange takes the loss.

The finality rule did nothing here, because the exchange settled inside the window. That is what Property 1 means.

It is a gradient, not a cliff

Do not read this as "block 287 is dangerous and block 288 is safe." 200 confirmations is already very safe. To reverse a deposit that deep, an attacker has to sustain majority hashpower for the full ~3.3-hour build, which is expensive and visible on-chain. Every confirmation makes it harder. The gap from 200 to 288 is the difference between "an attacker would need hours of sustained majority hashpower and you would likely see it coming" and "mathematically impossible." Small residual risk versus zero.

And it grows stronger over time

The probabilistic safety below 288 is not fixed. It increases as the chain matures.

Reversing a recent block means out-mining everyone else working on the chain. Early on, when little mining power has committed to SOQ, that does not take much, so a handful of confirmations is only "probably fine." As more mining power commits, out-mining the network becomes far more expensive, and the same number of confirmations becomes much safer.

This is the same path Bitcoin walked. In its early days, with tiny hashrate, six confirmations were genuinely attackable. Today, with the world's mining power behind it, six confirmations are the gold standard. The number did not change. The network grew underneath it.

SOQ works the same way below 288. The 288-block ceiling is absolute from day one, and everything beneath it gets stronger as committed mining power grows. So lean toward more confirmations for large value early on. As the chain matures, the same shorter waits become solid on their own.

The decision an integrator is making

Below 288, you are making Bitcoin's bet: confirmations buy probability, so scale them to the deposit value. At 288 you stop betting, and it becomes certainty. The question for crediting early is just one:

Is this deposit worth more than the cost of renting majority hashpower for a few hours?

At launch, committed hashrate is thin, so that rental cost is low, and the value at which early crediting turns unsafe is also low. That is why a large deposit credited early is the case to avoid: high value (worth attacking), still reversible (before finality), and cheap to attack (thin early hashrate). For whale deposits, wait for the 288-block horizon and take the certainty. For everything else, your own confirmation policy is fine.

Practical guidance

Use case	Recommendation
Small, low-value transaction	A few confirmations (probabilistic) is sufficient
Large value, exchange deposit, bridge settlement	Wait for the 288-block finality horizon (about 4.8 h)
Node returning from downtime over ~4.8 h, or syncing fresh	Verify your tip against a recent trusted block before settling

Finality and merge-mined liveness work together. Merge-mining keeps blocks flowing, and the reorg limit keeps history sealed. Neither replaces the other, and each has the limits described above.