Network status · 19 July 2026
Why Bloch is migrating to SHA-256.
A new node cannot sync from genesis: roughly 95% of block bodies no longer exist on any node and cannot be recovered. Joining the network today therefore requires the published snapshot — that path works and is the supported one. What the migration fixes is the underlying position: a chain that can only be joined by trusting a downloaded database, and cannot replay its own history. This page explains what broke, what is safe, and what happens next. Nothing here is launched.
What broke
Nodes prune block bodies below tip − 10,000. Pruning deletes the bodies but keeps the header/DAG map — so a pruned node keeps advertising headers for blocks whose bodies it deleted.
A fresh node that tries to sync from genesis therefore connects, asks for the chain from block 0, is served 500 valid headers, requests the bodies, and receives nothing. It waits, re-asks 30 seconds later, and loops. Measured on a clean machine: 4,397 identical rounds, still at height 1, with 15 peers connected.
This is why snapshot bootstrap exists and is the supported path: you download a database that already contains the surviving history, and sync forward from there. It works. But it is worth being clear about what it means — every new participant begins by trusting a file, because the network can no longer prove its own past to them.
| Height | Hash resolves | Body present |
|---|---|---|
| 1 | yes | no |
| 500 | yes | no |
| 402,000 | yes | no |
| 402,567 | yes | yes |
| 410,000 | yes | yes |
Probed directly on the canonical node. The cliff sits exactly at its pruned_height. Fleet-wide the lowest is ~394,913, and no backup of the earlier bodies exists anywhere.
A second defect hid it: a node that could not serve a body dropped the request silently and logged at debug level. The requester could not tell a pruned body from a lost packet, so it waited forever — and at the default log level the fault was invisible.
What is safe
Pruning deletes block bodies. It does not touch the UTXO set. Every coin mined so far is intact and was never at risk.
A full snapshot was taken from the canonical node, read-only, while it kept mining:
UTXOs : 413,743
total supply : 3,475,441,200 BLCH
SHAKE-256 : d3de5e51ee9dbbf36ed79981cbf66eb50a8894fc034610a20a5ee01eb9060637It passes an independent arithmetic check: 3,475,441,200 ÷ 8,400 = 413,743 exactly — one coinbase per block, no fragmentation. The root proves the file is intact; the division proves the set is complete. A snapshot missing a single UTXO passes the first and fails the second.
This snapshot is not the migration artifact. It was taken live, so it corresponds to no frozen height, and our own tool refuses to emit genesis constants from it for exactly that reason. The real one will be taken with the node stopped at an announced height, with height and root published together so anyone can reproduce it.
What the migration is
A new chain whose genesis commits to that snapshot — not a fork of the old one. The old chain cannot serve its own history, so replaying it from genesis is not something anyone can do, ever. A newcomer would start from a distributed artifact either way; this makes that artifact explicit and hash-bound.
- Proof-of-work becomes double SHA-256 with an 80-byte mining header, ported from a sibling codebase that already runs it. This is what makes existing ASIC and rented hashrate able to mine it at all.
- Balances carry over, bound to the published commitment. A node that loads a snapshot which does not hash to the committed root must refuse to start.
- Signatures do not change. ML-DSA-65 ‖ Falcon-1024 stay exactly as they are.
On post-quantum security
Changing the proof-of-work does not weaken post-quantum protection of anyone's coins, and it is worth being precise about why. Shor's algorithm breaks signatures — that is the catastrophic quantum threat, and it is why this chain signs with ML-DSA-65 and Falcon-1024. Against a hash function there is only Grover, which halves the effective strength: SHA-256 retains ~128 bits against a quantum adversary, which is comfortable.
Post-quantum safety here lives in the signature scheme and the address format, and both are untouched. What is set aside is a research claim about post-quantum mining — not the security of any coin.
The risk we are not hiding
A small SHA-256 chain is cheap to attack
SHA-256 hashrate is rented on a liquid market. The same property that lets miners join immediately lets anyone rent enough hashrate to reorganise a young chain for the price of a few hours' rental — this is the ordinary cause of death for small SHA-256 chains, not a hypothetical.
Today's chain is broken but not exposed this way, because no rental market exists for its lattice proof-of-work. Migrating trades a growth problem for a security problem, and that trade has to be covered rather than wished away.
The intended answer is FFG finality — a 14-of-21 ML-DSA-65 committee that finalises checkpoints, making deep reorganisation impossible regardless of rented hashrate.
FFG is not ready. The crate exists; it is not integrated into the node. Activating finality that has no committee finalises nothing. So it lands in two stages, and the gap between them is deliberate:
| Milestone | Height | What happens |
|---|---|---|
| Genesis | 0 | SHA-256 live; FFG compiled and off |
| Committee formation | 250,000 | 21 seats filled, votes cast and ignored by consensus |
| FFG activation | 500,000 | 14-of-21 quorum begins finalising |
The interval between the last two is the point: the committee runs in the open, producing real votes that cannot yet break anything, so failures surface before they matter. If something is wrong, activation slips — no fork required, because the votes carry no weight until it.
Between genesis and activation the chain is exposed, and that window will be covered explicitly. How it is covered has not been decided; when it is, it will be stated plainly here, including what it costs in decentralisation while it lasts.
Status, honestly
Nothing is launched. The snapshot tool, the commitment generator and the archival-node flag are written and tested. The SHA-256 chain itself is being built and will be proven end-to-end on a throwaway machine — carrying the real balances, verified against the real numbers — before anyone is asked to trust it.
One node is currently producing blocks, and new nodes join by downloading a snapshot rather than by verifying the chain. That is a fragile position and it is not being presented as anything else.
BLCH is worthless by design and is not a security; running a node is participation in an ownerless commons, not an investment. This is unaudited, pre-1.0 reference software.