If you install a new lock but leave the old key working, what exactly have you secured? That’s one question I’d ask about any cryptographic migration including @Starknet’s. Adding a new signature method is important. But if an account still accepts an older method that later becomes vulnerable, that old route could undermine the upgrade. That’s why cryptographic agility isn’t just about adding options. It also needs a way to retire them. The StarkWare Quantum Hub’s checklist separates two capabilities: → Downgrade protection: preventing an attacker from forcing a return to weaker cryptography. → A sunset mechanism: stopping new use of an old algorithm across the migrated account’s authorisation routes. They address a practical problem: a stronger front door doesn’t help if an insecure side entrance remains open. For Starknet, programmable accounts provide flexibility to change signature-verification logic without requiring a network-wide upgrade. The important follow-up is what that account will still accept after the change including its recovery and alternative authorisation routes. This is why I find the checklist useful as a set of questions, not a “quantum-safe” badge. There are records of evidence of these capabilities for Starknet within its defined assessment scope. That does not establish that every account has migrated or that Starknet is fully quantum-safe. My takeaway: a security upgrade needs more than a new way in. It needs a clear decision about when the old way stops working. Explore the Quantum Hub: quantum.starkware.co/ Checklist evidence and methodology: quantum.starkware.co/network…