On 28 October 2026, a blockchain called Verona shipped an upgrade named Fermi. The headline feature is post-quantum signatures: accounts can now attach an ML-DSA-65 authenticator, the lattice signature standard from FIPS 204, and drop their old classical key if they want. For treasuries and cold vaults there is also SLH-DSA-128s, the hash-based standard from FIPS 205.
That part is not what caught my attention. Plenty of projects are adding post-quantum algorithms this year, and most of them will do it the hard way. What caught my attention is the part Verona did not have to do: nobody has to move. The address stays the same while the key underneath it changes.
That sounds small. It is the whole design lesson.
Most accounts are their key, and that is the trap
On most chains, your address is derived from your public key. Change the key and you change the address, which means you have to move everything: funds, permissions, history, every contract that knows you by that address. It is like changing the locks on your house by demolishing the house and building a new one next door, then telling everyone you know to update their address books.
Verona's announcement puts a number on what that costs at scale: it claims roughly a third of Bitcoin's supply sits in accounts with exposed keys. Whether that estimate is exact matters less than the shape of the problem. When the key and the identity are the same thing, a cryptographic migration becomes a mass relocation, and mass relocations do not happen cleanly. People miss the deadline, lose keys in the move, or simply never bother.
Verona avoided this by building accounts differently from the start. Every account is a smart contract that holds a set of pluggable authenticators. Today that set includes secp256k1 keys, passkeys, Ethereum wallets, JWT, and ZKEmail. Adding ML-DSA is, by their account, the same operation as adding a passkey. The contract owns the address, not the key, so the cryptography can change underneath while identity, history, and balances stay put. There is also a policy option that requires post-quantum authentication: an account can disable its classical keys, or force them to co-sign with a post-quantum key.
Read that as a vendor announcement, because that is what it is. It arrived as a GlobeNewswire press release, not an independent audit, and I have not verified their implementation. Phase two, moving validator keys to ML-DSA-65, is still ahead of them, and their convenience authenticators that depend on outside infrastructure, like JWT and ZKEmail, stay classical for now and cannot satisfy a post-quantum-required policy. The honest version of this story is that one project shipped a design that makes migration a key operation instead of a move, and the rest of the claims still need the usual scrutiny.
Even with that caveat, the design idea is worth stealing, because it is not really about blockchains.
I ran into the same shape of problem in a messenger
I build an encrypted messenger in the browser, and its protocol uses ML-DSA-65 identity signatures alongside a hybrid ML-KEM-768 and ECDH key exchange. When I added those signatures, the question that took the most thought was not which algorithm to pick. It was what happens to an identity when its keys change.
A messenger contact is, in practice, a key. If someone reinstalls the app, loses a device, or rotates keys after a scare, the other side sees a stranger unless something in the design says otherwise. Safety numbers, key transparency logs, and verification rituals are all patches over the same crack: the identity and the key material got fused together, and now every key event looks like an identity event to the user.
Verona's answer is to put a stable container between the two. The account is the container. Keys are members of it, added and removed by operations the container understands. That is a cleaner separation than most messengers have, and it maps directly: a contact identity that survives key rotation, with old keys revocable and new keys attachable, is strictly better than an identity that breaks every time cryptography moves.
It also changes how you think about algorithm agility. Verona ships lattice and hash-based signatures side by side, and says users can move between them if one assumption fails. It plans to add FN-DSA once NIST finalises FIPS 206. That is the right posture for a transition period. Nobody sane should bet a whole identity system on a single post-quantum algorithm in 2026. The bet should be on the ability to swap, not on the winner.
The migration problem is the problem
Verona's founder put it as "quantum resistance is a migration problem, not a technical problem." That line is marketing, but it is also accurate in a way that matters for builders outside crypto too.
The algorithms are standardised now. FIPS 203, 204, and 205 exist. NIST published its formal migration roadmap, IR 8547, on 28 October, the same week as Fermi, with federal deadlines for key establishment by 2030 and signatures by 2031. The UK's NCSC told organisations to finish cryptographic discovery and planning by 2028. The technical question, which algorithm, is largely settled. The operational question, how do you change the cryptography under a live system without stranding its users, is where projects will actually succeed or fail.
That is why I think Fermi is worth reading even if you never touch a blockchain. Ask of your own system the question Verona's design answers: can a user rotate to a post-quantum key without becoming a new user? If the answer is no, you do not have a migration plan. You have a moving day, and moving days are where things get lost.
Three practical things fall out of that question, and they apply to messengers, apps, and services alike:
First, separate the stable identifier from the key material, and make key rotation a first-class operation with its own audit trail, not a side effect of reinstalling or re-registering.
Second, support old and new algorithms at the same time during the transition, with a policy that can require the new one once you are confident, rather than a flag day where everything changes at once.
Third, make revocation as easy as enrollment. A post-quantum key you cannot remove is not much better than a classical key you cannot remove. The whole point is that keys are replaceable parts. Design them that way from the start, because retrofitting a container around a key-derived identity later is exactly the painful migration you were trying to avoid.
None of this makes quantum computers arrive sooner or later. No such machine exists today that breaks these signatures, and the timeline estimates keep moving. What it does is decide whether, when the migration becomes unavoidable, your users experience it as adding a key or as starting over. That difference is the difference between a system that survives a cryptographic transition and one that does not.
Verona still has to prove the rest: validator migration, real usage at scale, and the security of the contract layer that now guards every account. But the idea at the centre of Fermi is already portable, and it is free to copy. Build the container first. Keys come and go. The address, the contact, the account, that is what people actually need to keep.
Top comments (0)