Post-Quantum Readiness for EdDSA Chains and a Possible Solution for Some ECDSA Wallets - Part 1

This post looks at a recent paper, Post-Quantum Readiness in EdDSA Chains, and what it means in practice. The paper can be found here.

The paper’s main takeaway is  that blockchains using EdDSA with RFC-8032 key derivation (Sui, Solana, Near, Stellar, Aptos) have a structural property that makes post-quantum migration simpler. You can prove control of an account in a post-quantum-secure way, keep the same address, and avoid putting new elliptic-curve data on-chain. Even inactive accounts can be upgraded if the seed is still available.

That’s the first part of the post, breaking down the paper and explaining exactly how and why this works for EdDSA.

The second part extends the work in the paper further and looks at whether the same approach could help some ECDSA wallets, used on chains like Bitcoin and Ethereum. In general, it can’t be applied to every account, but there may be a path for some wallets that use standardized BIP-32/BIP-85 derivation. With bespoke zero-knowledge proofs for those derivations, certain ECDSA addresses could also migrate without moving funds. We’ll go through how that could work, and the limitations.

While the paper focuses on proving identity through zero-knowledge, our product, yellowpages.xyz, takes a similar approach using cross-signatures instead. It achieves the same binding of a legacy address to a post-quantum key, but without the need for a proof system.

Seed: a short, uniformly random secret bitstring. In EdDSA with RFC-8032 derivation, this is the root secret you back up, i.e. private key.

Scalar: a large integer modulo the curve order. In elliptic curve cryptography, multiplying a scalar by the curve’s base point G gives you another point on the curve.

How a scalar relates to keys:

• In ECDSA, your private key is one such scalar, chosen directly at random. There is no standard, deterministic link from any higher‑level “seed” to this scalar.
• In EdDSA (RFC-8032 derivation), the scalar is not picked directly, instead it is computed from a seed by hashing. This makes the seed the true root secret; the scalar is just a deterministic output you can recreate from the seed at any time. The seed itself never participates directly in signing.

Secret key (sk): The specific private scalar you use for signing.

• In ECDSA: sk is the randomly generated scalar that is your private key.
• In EdDSA: sk is deterministically computed from the seed:

sk = HashToScalar(SHA‑512(seed)[:32])

So sk is not the deepest secret; it’s an image of the seed under a hash. Even if sk is someday recovered from pk by a quantum adversary, the seed remains hidden behind SHA‑512 (more on this later).

Public key (pk): The point on the elliptic curve that corresponds to your sk. It is computed as:

pk = sk·G

where G is the curve’s base point. The public key is shared so others can verify your signatures.

Address: What the chain uses as your on‑chain identity. Derived from pk by chain‑specific rules.

This post will not discuss the threat quantum poses to classical cryptography and blockchains in detail. For this, see our blog where we have many posts covering this topic.

For completeness, here is a quick overview:

1. Shor’s algorithm breaks discrete logs. If pk is on‑chain, a quantum attacker can compute sk.
2. Grover’s algorithm only gives a quadratic speedup on hash preimages. A good hash (like SHA‑512) still has strong preimage security and thus is not vulnerable to a quantum attack.

The difference between Shor’s impact on public key cryptography and Grover’s impact on symmetric cryptography and hash functions is extremely important and largely misunderstood. This difference is also the core of the paper and discussion within this post. If your private signing material is a hash of a seed, the seed can stay safe, even if one day sk is not.

Quantum computers that can run Shor’s algorithm at scale will break discrete logs. If your public key (pk) is on‑chain, a quantum adversary can compute your private key (sk). That means forged signatures and seized funds. Many accounts have already exposed public keys in past transactions. Many accounts are dormant or lost and thus will never be able to upgrade to post-quantum keys and move assets to a fresh quantum-safe address.

This is both an engineering problem and a regulatory one. Migration to post-quantum cryptography is no longer optional. However, migration that forces an address change is both risky and costly. A migration means that every single user will need to generate new private keys. Every single NFT, stablecoin, and smart contract mapping from address → (token, balance, some data) will need to be re-written. Every vault and multi-sig will need to be redeployed.

Ideally, we need a path that lets you press once and say “from now on, this same address will accept post‑quantum signatures” with no asset transfers or address rotation.

A one‑time user action that moves all future authorizations for the same address to a post‑quantum scheme. Past signatures stay as they were and addresses do not change. On top of this, dormant accounts can be secured if someone still holds the seed.

If your private signing key can be deterministically derived from a short secret seed using a quantum-resistant hash, you can prove knowledge of that seed in a post-quantum-secure zero-knowledge proof. That proof can bind your existing address to a new post-quantum public key, without changing the address or revealing new curve data. EdDSA with RFC-8032 derivation has this property by design; ECDSA generally does not.

ECDSA does not define a canonical function from “seed” to the private scalar. RFC-6979 made signing nonces deterministic. It did not standardize private key generation. In practice, many wallets just sample a random scalar and call it a day. That scalar is opaque and specific to however the wallet decided to derive it.

For zero-knowledge migration to work, there must be a clear, consistent process that turns a secret into the key that defines your account (in zero-knowledge terms, this secret is the “witness”). Usually that means a seed runs through a known one-way function to produce the account’s key. If that function doesn’t exist, you can’t create one universal proof the whole network will accept.

You can try to lean on mnemonics (BIP‑39) and hierarchies (BIP‑32) and other derivation schemes (BIP-85), but then you inherit some problems:

• Derivations depend on private scalars not seeds. If a scalar in the path is recovered (e.g., via a quantum attack), descendants are at risk.
• Non‑hardened derivations let public information influence the path. This is great for watch‑only but bad under a quantum threat.
• Different chains use different HD paths. There’s no single proof circuit that covers the ecosystem.
• Many custodians and HSMs never used BIP‑39/32 at all.

You can build a wallet‑specific zero‑knowledge statement over a known BIP‑32 path. That can help subsets of users (we’ll go deeper on this later). But it’s not a chain‑wide invariant, and it won’t save sleeping accounts whose derivation you don’t know or whose owners lost the root.

In addition, the standard PBKDF2-HMAC-SHA512 step in BIP-32 runs 2048 iterations (as a defense against brute-force guessing of weak passphrases). This is quite impractical in zero-knowledge, since even with aggressive circuit optimizations, you’re left with millions of constraints just to reproduce the KDF. And that’s before you even reach the elliptic curve arithmetic. 

By contrast, schemes like SLIP-0010 that use a single HMAC step are far more ZK-friendly. This performance gap means that while wallet-specific ZK attestations are theoretically possible with BIP-32, in practice they’ll be too heavy for most proving systems today (certainly those that run client-side).

EdDSA with RFC-8032 derivation is a completely different design. The signing key is derived from a compact seed via hashing. The big difference is that this is at the protocol level, thus every wallet follows the same derivation logic.

Formally:

seed ∈ {0,1}^256
sk := HashToScalar(SHA‑512(seed)[:32])
pk := sk · G

This has three major consequences:

1. Determinism. There is a canonical function seed → sk.
2. Post-quantum safe. The seed sits behind SHA‑512. Grover’s only helps quadratically, so the preimage barrier remains extremely high.
3. ZK‑friendly witness. The seed is small and structured. You can prove things about it without revealing it.

This is the overlooked structural advantage of EdDSA chains. You can prove, in a post‑quantum‑sound zero‑knowledge proof, that you know the seed that leads to a specific address. You can do that without revealing sk or pk. You can then bind that proof to a post‑quantum signature scheme and from that moment, the account authorizes with post-quantum signatures.

Most wallets across both ECDSA and EdDSA often start from a BIP-39 mnemonic which creates a large seed. From there, ECDSA and EdDSA differ.

ECDSA (Bitcoin/Ethereum): BIP‑32

• You get a master scalar and chain code.
• Every node is a scalar.
• Hardened children depend on the parent private scalar.
• Non‑hardened children let you derive child publics from the parent public.
• If a parent scalar is ever recovered, child keys are vulnerable.
• The hierarchy is scalar‑centric.

EdDSA (Sui, Solana, Near, etc.): SLIP‑0010

• Every node is a seed, derived by a HMAC from the parent seed.
• The signing scalar is always seed → SHA‑512 → scalar.
• Seeds are never used for signing and remain off-curve.
• Even if a scalar is derived via a quantum attack, the seed remain secure.
• The hierarchy is seed‑centric.

This difference matters under quantum threats and in zero‑knowledge. BIP‑32 couples generations via scalars and one scalar leak can endanger an entire subtree. In SLIP‑0010, the seed chain remains intact even if a scalar is exposed at some point. The object of value, the seed, is hidden behind a hash. That is exactly what you want for a post‑quantum migration based on zero‑knowledge proofs.

Continue reading part 2 here.