diff --git a/anchor/README.md b/anchor/README.md
index d6934c2..575c85a 100644
--- a/anchor/README.md
+++ b/anchor/README.md
@@ -22,8 +22,23 @@ The threat it addresses is not "harvest now, decrypt later". A signature is publ
 to harvest. The threat is **retroactive rewriting**: validator keys recovered later can be used to
 re-sign old blocks, and a chain whose history is authenticated only by ECDSA cannot distinguish the
 rewrite from the original. Binding a post-quantum certificate into the hash of every anchored header
-means a rewrite must also forge the post-quantum signatures. The reasoning follows Azouvi, Danezis,
-Nikolaenko, "Winkle" (IACR 2019/1440, AFT 2020).
+means a rewrite must also forge the post-quantum signatures.
+
+The threat is not ours to claim. It is the long-range attack, and the peer-reviewed treatment is
+Azouvi, Danezis and Nikolaenko, "Winkle: Foiling Long-Range Attacks in Proof-of-Stake Systems"
+(IACR 2019/1440; AFT 2020, pp. 189-201). Two things should be said plainly about that citation,
+because we checked it rather than repeated it. **Winkle does not mention quantum adversaries at
+all**: it treats old validator keys becoming compromised, by any means. The quantum framing is
+ours. And **Winkle's own defence is not ours**: it adds a secondary layer of client-based
+validation, where clients sign a hash of the previously sequenced block. A second published defence
+for the same threat, Azouvi and Vukolic, "Pikachu: Securing PoS Blockchains from
+Long-Range Attacks by Checkpointing into Bitcoin PoW using Taproot" (arXiv 2208.05408, 2022),
+checkpoints into Bitcoin's proof of work.
+
+So: the threat has peer-reviewed grounding, and the defence in this repository is ours. Anyone
+weighing it should weigh it against checkpointing, which is the established answer. The honest
+difference is that checkpointing borrows security from somewhere else, and this borrows nothing: the
+guarantee is carried inside the header, by the validators who signed it.
 
 ---