Which quantum threat applies to a blockchain signature, which does not, and what the anchor actually defends against.
The threat that does not apply
"Harvest now, decrypt later" does not apply to signatures. It is a threat to encrypted data: an adversary records ciphertext today and decrypts it when a capable machine exists. A signature is public the moment it is made. There is nothing to harvest.
A claim that HNDL threatens a chain's signatures mixes up two different things, and it is visible to any reader who knows the difference.
The threat that does apply, and it is worse
A quantum adversary who can recover a private key from a public key can recover validator keys that signed blocks years ago. With those keys they can produce an alternative history that is internally valid, signed by the same validator set, and rewrite the past. This is the long-range or posterior-corruption attack.
It is worse than the HNDL framing because it does not need the adversary to be present at the time. The keys are already published, in every block header those validators ever sealed.
What the anchor does about it
An adversary holding every classical validator key and no Falcon key can rewrite at most the tail since the last anchor: at most 32 blocks, roughly 20 seconds (at most 128 blocks, roughly 75 seconds, from 2026-09-05 to 2026-09-29). Rewriting anything below an anchor changes that anchor's parent hash, which forces the anchor to be reproduced, and reproducing it needs Falcon signatures the adversary does not have.
Added 2026-10-01, with the AIP-22 erratum of that date. One exception: the seals in a certificate do not carry the consensus round, so an anchor can be certified over the undecided sibling of the decided block, with honest validators' seals. It needs those validators to have sealed, at the height of the last anchor's parent, a block in rounds that did not decide it; an adversary that controls the order of messages across three round changes at that height can bring that about. The rewrite can then reach the anchor's parent: one block deeper than the bound above. While headers carry ECDSA commit seals (before stage 5 of AIP-22, which chain 2800 has not activated), forging the headers takes a quorum of classical keys, which the adversary above holds and a single validator does not; from stage 5 the anchor's header needs its proposer's Falcon-512 seal, which the adversary above does not have and a single validator does. This is measured in a test fixture with the production rules and has not been exercised on any network. With a repair that is in code and not yet deployed, no node takes the anchor's parent as decided from such a certificate, only the anchor's grandparent, the block both siblings share.
History below the anchor activation height (block 13,014,000) has no certificates of its own. The anchor cannot reach backwards. What covers that history is the hash chain: a node that knows the hash of one recent anchor is protected, because a rewrite at any height changes every hash above it and would have to reproduce every certificate up to that anchor. A node that syncs with no reference point at all is not. (Until 2026-10-05 this paragraph said only "protected by ECDSA alone, permanently".)
Where this sits in the literature
The threat has peer-reviewed treatment: Azouvi, Danezis and Nikolaenko, "Winkle: Foiling Long-Range Attacks in Proof-of-Stake Systems", IACR 2019/1440, published at AFT 2020, pages 189 to 201.
Two things must be said precisely about that citation:
- Winkle does not say "quantum" anywhere. It supports the *threat*, that is long-range attacks
through old compromised keys. The quantum framing is ours.
- Winkle's defence is a different one. It proposes a secondary validation layer in which clients
sign a hash of the previous block. Ours is a validator certificate under the block hash. So the correct sentence is: the threat has peer-reviewed grounding, the defence is our own.
There is a second published defence for the same threat, "Pikachu" (arXiv 2208.05408), which anchors into Bitcoin through Taproot. If you are wondering why we did not simply checkpoint into another chain, that paper is the honest comparison, and the answer is that checkpointing moves your trust to that other chain's liveness and its own signature scheme.
What is not defended
- An adversary who holds the Falcon keys as well. The anchor is a binding on validator behaviour,
not a defence against a compromised validator set.
- Equivocation. Signing two conflicting anchors is not slashable.
- Anything at the account layer. Ordinary accounts on chain 2800 are secp256k1, exactly as on
Ethereum. See Overview.