diff --git a/anchor/README.md b/anchor/README.md
index 575c85a..eae7df2 100644
--- a/anchor/README.md
+++ b/anchor/README.md
@@ -35,10 +35,35 @@ 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.
+### Where this sits among the known defences
+
+The literature calls this attack **posterior corruption**, also known as the founders' attack, the
+long-range attack, history revision, or costless simulation. Tas, Tse, Gai, Kannan, Maddah-Ali and
+Yu survey the mitigations in "Bitcoin-Enhanced Proof-of-Stake Security: Possibilities and
+Impossibilities" (arXiv 2207.08392) and count four: social consensus by a trusted committee;
+key-evolving signatures, where validators forget their old keys; verifiable delay functions; and
+timestamping onto an existing proof-of-work chain.
+
+That paper also proves an impossibility, and it deserves to be stated correctly rather than
+paraphrased into something scarier or softer than it is. **Slashable safety**, meaning safety plus the
+ability to punish the attacker, is not achievable by a proof-of-stake chain without an external
+trusted source. Plain safety against posterior corruption is a weaker property, and key-evolving
+signatures are shown to provide it under an honest majority. So the impossibility is not "you cannot
+defend yourself"; it is "you cannot make the attacker pay, on your own."
+
+**This anchor does not claim slashable safety and does not compete with checkpointing on that
+ground.** What it addresses is the case where key-evolving signatures stop working. Their guarantee
+rests on a validator's old key being *gone* once deleted. Against an adversary with a
+cryptographically relevant quantum computer, an old secp256k1 key does not need to have been kept or
+stolen. QBFT headers carry validator addresses rather than public keys, but every seal a validator
+ever wrote is an ECDSA signature from which its public key can be recovered, and those seals are in
+the chain forever. From the public key, a quantum adversary derives the private one. Deleting the
+private key buys nothing, because the chain reconstructs it. The certificate under the block hash is what still has to be forged, and forging it requires
+a secret the adversary cannot derive.
+
+Put plainly: this is the post-quantum analogue of what key-evolving signatures give classically, for
+the setting in which their central assumption no longer holds. It is narrower than checkpointing and
+it borrows nothing from another chain, and both of those are true at the same time.
 
 ---