We Said Crypto-Agility Was the Point. Then We Proved It.

A few weeks ago we published two posts making an argument. The first (“Two Locks, Not One”) said you should never trust a single cryptographic lock — run a classical scheme and a post-quantum one together, and require both. The second (“A Bridge, Not a Destination”) pushed further: the locks themselves will change over time, so the property that actually lasts isn't any particular algorithm. It's whether you can replace one without tearing the building down.

That's an easy thing to write and a harder thing to mean. So here's the follow-up we owed you: we just did it. QuantumShield's classical signature layer is now Ed25519, running in production, paired with ML-DSA-65. This post is that migration — what changed, why Ed25519, and how a swap like this stays boring instead of becoming an emergency.

What actually changed

QuantumShield has always been a hybrid: two independent signatures, both required to verify, so a break in one doesn't open the door. The post-quantum half is ML-DSA-65 — the lattice-based scheme NIST standardized as FIPS 204 — and that half is unchanged.

What we upgraded is the classical half. It's now Ed25519, the Edwards-curve signature scheme defined in RFC 8032. Every authenticated request is signed with both Ed25519 and ML-DSA-65, and both must verify or the request is rejected. In the industry's terms, that's a PQ/T hybrid — post-quantum and traditional, side by side. The suite has a name in our code now: hybrid-ed25519-mldsa65.

Why Ed25519

When you're choosing the classical half of a hybrid, you want the least surprising, most battle-tested option available — the part whose job is to be boringly reliable while the post-quantum half carries the novel risk. Ed25519 earns that role on a few counts.

• It's deterministic. RFC 8032 signatures derive their randomness from the key and the message itself, so the same key signing the same message always produces the same signature. That closes off an entire category of failure — the nonce-reuse mistakes that have historically broken other curve-based signatures when a random number generator misbehaves. There's no per-signature randomness to get wrong.
• It's a real asymmetric keypair. A private key signs; a separate public key verifies. That gives you public verifiability — anyone with the public key can confirm a signature is genuine, without holding the secret. It's the property that makes a signature a signature.
• It's fast and it's everywhere. Ed25519 is small, quick to verify, and implemented in audited libraries across the ecosystem. For something that runs on every authenticated call, boring and fast is exactly right.

Paired with ML-DSA-65, you get the two-independent-foundations property we keep coming back to: Ed25519 rests on the elliptic-curve discrete-log problem, ML-DSA-65 on lattice problems. A breakthrough against one tells you essentially nothing about the other. Breaking the hybrid means breaking both, and both at once is exponentially harder than either alone.

The part that was supposed to be boring

Here's the real test of everything we'd written. Changing the signing primitive on a live authentication path is exactly the kind of change that becomes a crisis when a system wasn't built to expect it — the primitive is threaded through everything, so touching it means touching everything.

Ours wasn't threaded through everything. The signing logic lives behind a single seam — one module whose job is “sign this, verify that” — so swapping what happens inside it was one module's problem, not the whole codebase's. The hybrid structure stayed identical: still two signatures, still both-required, still the same shape everywhere else in the system. Only the inside of the classical half changed.

That's the whole thesis of “A Bridge, Not a Destination,” made concrete. We argued that the durable move is to keep every primitive behind a swappable boundary so that replacing it is routine. Then the moment came to actually replace one, and it was routine — a contained change behind the seam, not a month-long excavation. The bridge held because it was built to be a bridge.

What this means if you use SchnelPay

Nothing you have to do. Your account is protected by the hybrid-ed25519-mldsa65 suite automatically — a classical signature the whole industry trusts, and a post-quantum signature standardized for exactly the threat on the horizon, with both required on every authenticated call. You keep your keys, you keep your control, and the security layer underneath is now both stronger and, quietly, proof that we build the way we say we do.

The series argued a philosophy. This post is the receipt. Never fewer than two locks, always on independent foundations, and always ready to replace either one — not as a slogan, but as something we just executed in production without the building shaking.

If you haven't seen what SchnelPay actually is yet — a non-custodial, quantum-safe on-ramp with your choice of Stripe or Coinbase — that story is here, and you can try it at schnelpay.com.