The design space for Ethereum's post-quantum transaction signatures

A lot has been said about the post-quantum transition over the course of this year, on practically every blockchain worth mentioning.

The lever that accelerated the urgency perceived by the tech community is to be attributed to Google's paper 'Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities: Resource Estimates and Mitigations', published in March 2026.

Further, particularly interesting papers followed, such as 'Shor’s algorithm is possible with as few as 10,000 reconfigurable atomic qubits', also published in March 2026 by quantum startup Oratomic and the California Institute of Technology.

The surge in interest, progress and urgency is also due to the very rapid progress of AI models available to the general public (US admin permitting). A key example of this progress is the work of the researchers at Eigen Labs, who have put online a collaborative project to match and surpass (currently by 44%!) the research results of Google's paper.

This article will focus on the design space of post-quantum solutions for Ethereum users, centered on protecting assets and therefore on the execution layer. Our argument, in short: the best answer here is more than a signature, it's a protocol, a set of choices and Ethereum components that have to work together.

The piece is the fruit of months of work by our team to bring the 'Ephemeral Keys protocol' to life and to develop the protocol's reference implementation, our 'NiceTry' wallet.

Spoiler: it is not simple. But you didn't expect an article titled "The design space for Ethereum's post-quantum transaction signatures" to be easy stuff, did you?

1. How did we get here

Many of the topics discussed in this article are the product of discussions that arose in the Ethereum Foundation's Post-Quantum Transaction Signatures (PQTS), carried forward by researcher and cryptographer Antonio Sanso, in which our team has taken part regularly along with several other teams and researchers, as well as from the chats and various Telegram groups born out of those discussions and conversations.

A special role in accelerating the conversations is to be attributed to EthCC 2026, held in Cannes, France, which coincided with the publication of Google's paper and left plenty of room for conversation.

2. Account abstraction as a design pillar

For anyone approaching this conversation for the first time, it's important to grasp a key concept: account abstraction is the foundation of all short and medium-term solutions, and it could offer interesting and unique benefits in the future too.

Smart wallets can in fact sign Ethereum transactions with arbitrary signature schemes and are not limited, unlike traditional EOAs, to ECDSA signatures.

ECDSA signatures are precisely at the root of the problem and are the main target of Shor's algorithm and of a potential attack carried out with a cryptographically relevant quantum computer.

Thanks to this flexibility offered by account abstraction, we can build wallets and signing infrastructure that use various post-quantum signature schemes which, as we will see, address different needs of the industry.

Without account abstraction we couldn't have this conversation as things currently stand, and we would have to accelerate the preparation of extremely premature and dangerous Ethereum forks if we wanted to keep users' assets safe.

The most pedantic readers will want to point out that it's possible to build EOA wallets that change address after every transaction, while not being able to use most of DeFi. Sure, that's possible, but with so many tradeoffs and such an ugly design that we certainly wouldn't be here writing an article about it.

2.1 The advent of Frame Transactions and EIP-8141

Without getting too deep into Frame Transactions, which we covered in a separate article, in the near future Ethereum could offer native account abstraction via EIP-8141.

This means that, beyond the canonical ERC-4337, the design space for post-quantum solutions on Ethereum has to account for this possible upgrade, and the solutions must be equally functional, or ideally better, under the new paradigm too. We at Riva Labs are optimistic about Frame Transactions, and we are making sure that all of our work on post-quantum infra for Ethereum can remain compatible when (and if) the upgrade comes to life.

3. How to choose a viable post-quantum signature scheme that works today (and doesn't suck)

Today, every Ethereum EOA signs with ECDSA over secp256k1, and ecrecover (precompile 0x01, costing flat 3,000 gas) verifies a 65 B signature. Hardware signers manage to produce signatures in <100ms and Threshold Signature Schemes can be built based on it with relative ease. All these features are necessary for a signature to be used on Ethereum, and with quantum computers invalidating ECDSA we need to have a recipe to choose the right signature to replace it. To prepare this recipe, our cooks will need a set of ingredients. As mentioned, one of them is account abstraction.

Now you need a post-quantum signature scheme. Easy, right?

Choosing the right signature scheme is the crux of the whole matter. Over time we have seen many signature schemes proposed, debated and discarded, and the process has taught us something every time. To begin with, let's understand the key criteria behind the choice.

We'll take into consideration for numeric comparisons some of the signatures that emerged in the Post‑Quantum Transaction Signatures (PQTS) call series:

• Falcon (FN-DSA) - Lattice
• Dilithium (ML-DSA) - Lattice
• SPHINCS+ (SLH-DSA) - Hash
• SPHINCS- (C13) - Hash
• FORS+C (A=5, K=26, n=16) - Hash

3.1 Verification gas cost

To sign a transaction in the design we are discussing, the transaction will need to be validated onchain through a verifier. This is one of the most important points in the entire design. Every different signature scheme needs a dedicated verifier.

But every dedicated verifier needs to be audited, and ideally formally verified, to guarantee the highest possible security. This gives us a first clue for formulating the right commandments for the design of a post-quantum solution on Ethereum:

Using and trying to combine many different signature schemes increases the system's attack and failure surface.

On the contrary, it would be ideal to make nearly all signing use cases, which we will discuss in more detail below, converge on one or at most a few signature schemes, and to make sure the entire verification and signing process is battle tested in every possible way.

But let's get to gas cost. Every signature scheme used carries a verification cost that depends on the cryptographic design of the signature itself and on its implementation.

The signature schemes available today are considerably more expensive than a traditional ECDSA signature. This means that the next commandment of our design guide has to be:

At equal security, for most use cases, we must try to keep the gas cost as low as possible.

This doesn't mean that gas cost is the only metric to take into account, but it's without doubt a relevant factor.

Ethereum is designed to give anyone the possibility to execute transactions, and protocol development efforts are moving in the direction of offering ever lower transaction costs. Other competitor chains have made this feature their entire identity, and it seems like an assumption to always keep in mind. Users don't want to pay a lot for transactions.

Moreover, when doing the math, we mustn't forget that Ethereum gas is a variable cost, and calculating it for a single transaction at one specific moment in time is not enough.

But how much can it cost to verify a transaction of this kind?

Some of the gas estimates for Falcon and Dilithium come from the first Post‑Quantum Transaction Signatures (PQTS) Breakout. The estimate for SPHINCS+ is labelled with * because it's not coming from an actual measurement, it's an estimate based on other hash based signature data. An implementation of the SPHINCS+ verifier is in the works, we'll update this table with actual gas measurements once it's done.

3.2 Signature size

Another fundamental parameter for determining the choice of a signature scheme is signature size, that is, the answer to the question "how much space in the calldata will the signature take up?".

The answer determines how many transactions can be placed in a block. Here too it is essential to optimize the choice to obtain the smallest possible signature size that does not compromise the security of the solution.

3.3 Public key size and recovery

Unlike ECDSA, not all PQ signatures allow for recovery of the public key from a signed digest. This makes the size of the public key a relevant parameter for these signatures, since it will be needed to add it into the transaction for the verification to be possible.

Schemes with recoverable public keys allow for verification code to take only a commitment to the public key as input, reducing the need for additional calldata.

3.4 From sizes to calldata cost

Signature and public key size only become an onchain cost once they hit calldata, priced since Pectra by the EIP-7623 floor of 40 gas per non-zero byte. The total calldata paylod is determined by the signature size plus the public key size. A recoverable scheme lets the verifier recompute the key from the signature instead of providing it in the calldata, so only a 20 to 32 byte commitment lives onchain and the key never enters calldata.

One note on upcoming changes: EIP-7976 (Glamsterdam) raises the floor to 60 gas per non-zero byte, growing every figure here by 50%. On the other hand, an L2 with EIP-4844 blobs moves the signature off L1 calldata entirely, an order of magnitude cheaper, softening the whole question wherever settlement is off L1.

3.5 Signature time

Depending on the signature scheme chosen, we will need to wait for the user's hardware to generate the signature. In the case of modern computers, servers and smartphones, the signing time is negligible.

But what about hardware wallets and their constrained hardware?

Several well-known post-quantum signature schemes result in extremely long signing times on these devices. This is a problem on several levels.

From a UX perspective the problem is simply the wait, which in the everyday use of a device is a hardly desirable factor. Another problem is the use of DeFi applications, like an AMM that quotes the price of a trade for a limited time, a lending market with limited deposit caps, or other activities that require responsiveness.

Signature times for SPHINCS- and FORS+C schemes are estimated from the SLH-DSA measurement. Assuming 2.2M hashes per signature with SLH-DSA it can be estimated a hash rate of 5820 h/s for a fair comparison, resulting in the listed time estimations. The Falcon, Dilithium and SPHINCS+ estimates are derived from a public presentation from the Ledger team.

3.6 The NIST security target

When it comes to post-quantum signature schemes, the most relevant authority in the world is the National Institute of Standards and Technology (NIST), a technology laboratory operating under the U.S. Department of Commerce.

NIST, besides carrying out a complex effort of analysis and standardization of the various signature schemes, sets out a series of parameters for signature schemes that define the mathematical constants, key sizes, and operational algorithms used to ensure both security and performance. These parameters vary entirely depending on the specific standard or PQC algorithm you are implementing.

From the standardization work, security levels have also emerged, that is, minimum standards on the choice and implementation of parameters and schemes that can guarantee an increasing level of protection against the future threat.

These parameters are extremely relevant in the design of PQ schemes for Ethereum for several reasons. It is in fact possible to choose parameters that produce lower signature size, gas cost and signature time than those achievable with NIST standards, but getting a lower security level or other tradeoffs in return.

Given all the uncertainty that exists around the post-quantum transition, we believe it is more sensible to adhere at least to internationally recognized standards. Moreover, since the post-quantum transition concerns all uses of cryptography, from communication to banking, it is useful to try to follow the standards and choices made on a large scale in the Web2 world and traditional finance, so as to employ signature schemes and standards that will be as battle tested as possible.

Many of the tables and analyses in this article make use of the NIST Security Level 1 standard or above, which means that any successful attack must require computational resources comparable to or greater than those of an exhaustive key search on a 128-bit block cipher (AES-128), NIST's reference primitive for the lowest of its five security tiers.

3.7 Stateful vs stateless schemes

A further criterion, specific to hash-based schemes, is whether they are stateful or stateless.

Stateful schemes like XMSS are built on a tree of one-time keys, and the signer has to track which keys it has already spent: each one is safe to use exactly once, and reusing a single key breaks the scheme outright. That bookkeeping can give us smaller and faster signatures, but it turns key management into an attack and error surface, because anything that duplicates or rewinds the state can reuse an index and collapse security entirely. Stateless schemes like SPHINCS+ pay for the opposite guarantee with larger and slower signatures, but they keep no state to lose or counter to corrupt.

To increase the security of stateful schemes, it is possible to use smart contracts and engineering solutions, as we will see below, that are not directly part of the signature scheme but rather of its implementation.

3.8 Different security assumptions

Different PQ signature schemes have different security assumptions. The main categories of signature schemes under discussion include hash-based and lattice-based schemes. This doesn't mean there are no other interesting categories of PQ signatures, but these two categories group together the main candidate schemes and NIST's standardizations.

Various signature schemes have different assumptions. They were created, researched and discussed over very different time spans, and therefore, when it comes to being battle tested and having passed the "test of time", they are not all on the same level.

Hash-based schemes, for example, are dumb, but in a good way. They work by basically hashing secret random values to commit to them as a public key, and then signing by selectively revealing the right pre-images for the verifier to re-hash and check. That keeps their security surface confined to primitives that are well known and easy to test and audit. Whatever construction sits on top of it, the core operation is always a hash evaluation, so the whole scheme rests on hash non-invertibility and second-preimage resistance, two of the most scrutinized and battle-tested assumptions in all of cryptography.

The quantum picture is just as clean. Because there is no algebraic structure to exploit, the only generic quantum lever against a hash function is Grover's algorithm, an unstructured search that offers a quadratic speedup and brings the cost of finding a pre-image down from 2ⁿ to 2^(n/2). That is the entire quantum threat, and it is closed by a single design choice, since doubling the output length pushes Grover back up to the original 2ⁿ target.

None of this makes the structured alternatives any less secure, but rather harder to verify. A lattice signature, for instance, rests both on the average-case hardness of structured problems and on a secret-dependent sampler whose constant-time implementation and whose concrete security are still active research questions. These are simply a few more moving parts than a single hash evaluation carries.

This means that under equal parameters, size, gas and so on, the scheme's security assumptions are also relevant.

3.9 Aggregation

On aggregation the two families diverge. Lattice schemes have rich algebraic structure to exploit, so many signatures can be compressed into one through aggregate-signature constructions and lattice-tailored proof systems, keeping aggregation relatively compact. Hash-based schemes like SPHINCS+, and FORS by extension, have no such structure, so the only route is the generic one: proving a whole batch of verifications inside a post-quantum SNARK or STARK, heavier on the prover but fully scheme agnostic. This is where the ecosystem is heading, and EIP-8141 already keeps raw signatures non-introspectable so they can be aggregated this way later. The weight is real, since a hash-based signature runs to several kilobytes (FORS+C is about 2.4 KB), so without aggregation a block spends meaningful calldata on signatures alone.

Aggregation, more than the other criteria, is interconnected with other Ethereum upgrades and with discussions still to come.

3.10 How specific use cases add more criteria

Ethereum is not a simple system for sending and receiving transactions. The chain hosts a variety of use cases, financial and otherwise, a variety of assets, and is used by many different users, ranging from institutions to simple individual users, and now even AI agents.

In this variety of use cases and users, specific evaluation criteria emerge for post-quantum signature schemes, and more generally for post-quantum solutions, that can move the needle.

3.10.1 TSS friendliness

One example involves multi party computation (MPC). While many DeFi-related custody setups are managed through multisig systems that are easily adaptable to the new signature schemes, as demonstrated by our team in a dedicated article, in the institutional context it is very common to use MPC solutions for custody. However, MPC requires following specific rules, where some signature schemes are more MPC-friendly or efficient than others. Hence, if a particular type of user needs MPC, another selection factor is added that was not considered before.

Lattice-based schemes lend themselves to threshold constructions, or lattice TSS, though not all of them are equally well suited to MPC. Dilithium looks like a strong candidate for lattice-based MPC, in good part because it avoids the Gaussian sampling that complicates other lattice schemes and signs instead with uniform sampling and constant-time integer operations that are easier to reproduce across parties. Falcon, due to its specific constructions (see floating-point FFT and discrete Gaussian sampling), is a harder case.

During one of the Ethereum Foundation's Post-Quantum Transaction Signatures (PQTS) breakout calls, a demo of Dilithium-based MPC was shared, though we have not yet had a chance to see the paper and the details.

Hash-based schemes are not considered a good fit for this purpose, although research is ongoing, including from our team at Riva Labs. The core difficulty is that signing a hash-based scheme in a distributed way generally calls for garbled circuits, which are heavy enough to cause serious efficiency problems. A single SPHINCS signature, for example, can involve on the order of two million hash evaluations, and carrying that many out inside a garbled circuit pushes the signing time well past anything viable. This has been a recurring theme in the PQTS breakout calls.

Some trusted proposals have been discussed, but they fall outside of the scope of this article.

3.10.2 Specific nuances for large scale custodial platforms

Another example involves platforms that, besides providing custody on behalf of users, have reached a critical mass of adoption and count tens of millions of users. Take the case of the SPHINCS signature scheme. Already standardized by NIST as SLH-DSA, the scheme has been the subject of study and further variations, as in the case of SPHINCS-, extensively described and documented in a research post by Ethereum Foundation researcher Nicolas Consigny. The two schemes differ, besides in their parameters, in the bounded signature count, that is, to simplify, the maximum number of times the signature can be safely reused. In the case of SPHINCS+ the number is 2⁶⁴, approximately 10¹⁹ signatures, while in the case of SPHINCS- the number is 2¹⁶-2²⁴ depending on the parameter set, which means a signature budget in the range 65,536-16,777,216.

While for a normal user (and for the vast majority of use cases) the number of uses granted by a single SPHINCS- signature goes well beyond the presumed reasonable usage, even over a long time, wallets used in a context where a very large number of users have to carry out at least a few operations per year pose a very different problem. In these cases, the risk of reaching the bounded signature count limit increases, and if not properly managed can lead to catastrophic results.

The issue can be further mitigated through transaction bundling, but remains nonetheless a factor to consider while designing the appropriate solution.

4. Who is the user of these designs?

The short answer would be everyone. However, the adoption cycle of post-quantum solutions is probably going to start from institutional players and from users controlling high-value keys.

When people talk about post-quantum, the only type of attack described is often the derivation of a wallet's private key and the consequent theft of funds. However, there is a second type of attack that, for the same effort, could cause even more serious damage: admin keys.

4.1 The attack on admin keys

Many assets are issued on Ethereum with special functions such as mint and freeze. This is the case for all the major stablecoins and for Real World Assets (RWAs). The same mechanism comes into play when it comes to upgrading non-immutable smart contracts, such as those of many large DeFi protocols, and again when it comes to governing Ethereum layer 2s.

The keys controlling this type of address share the same vulnerability as standard ones, but they are far more dangerous attack targets. In fact, even by compromising a single mint key of a major stablecoin, it is possible to mint infinite quantities of that asset, to then swap via an AMM for ETH or other immutable assets, or to use as collateral on a lending market, and so on.

This type of keys, and the users who control them, are certainly target users of the solutions described here and should be early adopters.

Still, a good design should take into consideration the needs of all types of users.

5. On precompiles

When we started discussing these topics with researchers in the field, our impression was that the idea of a single precompile, one that would make a specific signature super efficient and could give EOAs the same simple characteristics they enjoy today with ECDSA, was the obvious way to go.

A precompile could meaningfully lower verification cost, mostly for lattice schemes, whose bottleneck is the NTT and field arithmetic the EVM handles badly. The savings are sizable, for example a dedicated verifier takes Dilithium and Falcon from millions of gas in pure EVM down to a few thousand (EIP-8051, EIP-8052), and a generic NTT precompile (EIP-7885) could cover both at once.

The problem is that shipping a precompile is awkward. It is consensus critical code every client must reimplement identically, hard to price, and effectively permanent, all while the protocol is already trying to make this class of precompile unnecessary. On this specific criterion, hash-based schemes come out ahead, because they need no new precompile and can instead lean on the Keccak one that exists today.

6. How Ethereum upgrades change the design space

Ethereum's upgrades, both planned and under discussion, can represent another variable in this design space.

An example of a positive change in the direction of post-quantum readiness is EIP-7851 and EIP-8151. These proposals are strictly tied to EIP-7702, which introduces a new transaction type that sets the code for an EOA. Once this is done, the signature verification can be done with arbitrary smart contract code, which allows for the migration of EOAs to PQ signatures.

At the moment, this is not enough to make EOAs quantum resistant, since there is no way to disable the base ECDSA signature validity. This is exactly what EIP-8151 proposes, disabling the original authorization mechanism and allowing EOAs to become fully PQ. This change will make the transition from existing wallets to the new designs much more manageable and convenient for a large number of users.

Each of the upgrades under discussion can become a variable in this design process and must be taken into account.

7. A concrete design example: the Ephemeral Keys Protocol

In this section we describe the Ephemeral Keys Protocol, designed by our team at Riva Labs, and show how it builds on all the criteria described above, combining several components to achieve post-quantum security on Ethereum.

7.1 Key components of the protocol

For a more complete technical description of the protocol, see the GitHub repository.

1. The starting point is account abstraction. As explained in the dedicated section, it's a fundamental ingredient of the design. Through AA we get a stable address that can be used for all common use cases.
2. The second fundamental component of our protocol is key rotation. First introduced in the research post "Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction", the mechanism rotates the signer on every transaction. This property makes it especially well suited to one-time or few-time signature schemes, and it ensures there is no long-lived key sitting around to attack.
3. nextSigner storage onchain. The account keeps one storage slot, owner, holding the 20-byte commitment to the current signer, owner = last20(H(pkSeed ‖ pkRoot)). There's no pre-registered next-signer slot: the next keypair's commitment arrives with the transaction that spends the current key and is written into owner atomically during validation, as the trailing 20 bytes of userOp.callData under ERC-4337, or via a mandatory SENDER frame calling rotateOwner(nextOwner) under EIP-8141. Advancing the slot is a single SSTORE, so the address stays stable while the key rotates every transaction.
4. FORS as the primary signature scheme. The primary signer is standalone FORS+C at n = 16, K = 26, A = 5: the FORS few-time primitive lifted out of SPHINCS+/SLH-DSA with no XMSS hypertree, so the public key is just the compression of the FORS roots. That's what makes onchain verification affordable; a full SLH-DSA verify costs an order of magnitude more gas.
5. The recover function. Verification is a single pure function, recover(bytes sig, bytes32 digest) → address, on the ISignatureVerifier interface (implemented by ForsVerifier). The function returns the signer address, or address(0) on any failure, so the account stores no public key, only the 20-byte address. It recomputes dVal = H(pkSeed ‖ R ‖ digest ‖ dom_FORS ‖ counter), checks the +C constraint that dVal's K-th A-bit field is zero, opens the 25 trees (leaf plus height-5 auth path) into their roots, compresses those into pkRoot, and returns last20(H(pkSeed ‖ pkRoot)). The account accepts only on an exact non-zero match against owner, then rotates.
6. The recovery scheme. A secondary, stateless signature scheme is used by the protocol as an emergency recovery mechanism, and also to cover certain special cases. At present, SPHINCS- and SPHINCS+ are the two signatures we have considered for this purpose, but depending on the implementation and the infra they can be replaced by other schemes. In certain edge cases, for example a wallet error, a mempool-related event, or a transaction speedup, the same FORS key can end up being used too many times. The graceful degradation of FORS means the user is not directly exposed when this happens, but the protocol must still force a transition to a different signer.

7.2 Learnings from the choice of signature schemes: FORS over WOTS

An earlier version of the protocol used WOTS signatures instead of FORS, with the same rotation mechanism. Measured against several of the criteria above, that scheme performs excellently: 69 K verification gas cost, 468 B signature size, and a fast signature time (averaging 90 ms on ST33K1M5 - 70MHz).

However, in conversations with other researchers, it became clear that under this setup a single attack causing key reuse would be catastrophic. The attack surface would have been limited to a few highly sophisticated attacks, but the severity of a successful one, together with the mitigations it would have forced on us, made the overall risk distinctly higher than with FORS. So, even though the main criteria favored WOTS, the process made clear that the better choice was FORS, for security reasons.

The reason comes down to how the two schemes fail. A WOTS key is strictly one-time: sign with it twice and enough of the secret can leak to forge new messages, so any reuse is effectively total compromise. FORS, by contrast, is a few-time scheme. Each signature reveals only a small, randomized subset of its secret, so an accidental second or third use does not hand an attacker a forgery. FORS degrades gracefully under exactly the kind of rare misuse that a rotation bug or a sophisticated attack might cause, where WOTS would simply break.

7.3 One address on Ethereum and L2s

Using a few-time signature scheme forbids the indiscriminate reuse of the same key, even across chains. To ensure this, in the Ephemeral Keys Protocol each chain uses a completely separate derivation path, identified by chain id.

This poses a different challenge: the address of a user's smart contract wallet is determined by CREATE2 at the moment of deployment, and it depends on the initialization arguments. If different chains use different derivation paths, and hence different signer addresses, the derived address on different chains will differ too.

To avoid this, our smart contract wallet initial signer is not identified by a simple address, but from a Merkle tree root built with the first signers from the derivation paths of a predefined set of chains. This merkle root is a commitment that authorizes any of the signers contained in the leaves to sign a transaction on the smart contract wallet, while maintaining the initialization arguments fixed across chains. The first signature of the user is verified against that merkle root instead of a specific signer address, and then the signer rotation defined by the Ephemeral Keys Protocol initializes the authorized signer address to the next one in the derivation path, returning to the default operational mode. This method ensures that the address of the smart contract wallet will be static across chains, while avoiding signature reuse by design.

The Merkle tree size needed for this is rather small: the number of chains on which account abstraction is available is smaller than 256, meaning that a tree of depth 8 has enough leaves to contain all first signers, and even smaller trees can be used if a specific subset of chains is selected deliberately. Moreover, the overhead due to the Merkle tree commit verification is contained both in signature size and gas: the signature must contain an additional 32 bytes per tree level, and verifying the signature just needs an additional hash per tree level.

What happens if a new L2 is added and its chain id is not in the commitment? In this case, the only solution for the user to keep using the same address on this new L2 is to keep the same merkle root, but authorize the first transaction with the recovery signer (e.g. SPHINCS). This is significantly more expensive, but it's only necessary for the first transaction in this edge case.

7.4 Ideas from the Bitcoin world: SHRINCS and SHRIMPS

Some of the ideas behind our protocol come from work shared by researchers in the Bitcoin community.

One of the more useful insights to come out of that work is that you do not need brand-new cryptography to make a post-quantum scheme practical. You can get most of the way there by recombining parts that are already trusted. SPHINCS+ layers two well-understood primitives, WOTS and FORS, into one large hypertree. Taken apart and reassembled, those same building blocks can produce far leaner schemes that rest on exactly the same proven hash-based assumptions, with nothing new to audit.

Blockstream Research has put this to work in SHRINCS and its multi-device successor SHRIMPS, which split signing into two tiers. Everyday transactions travel a compact, efficient stateful path, so a hardware wallet never has to grind out a full stateless signature just to move funds. The heavy, slow stateless signature is held in reserve for backup and recovery, for example when a device loses its state and has to fall back to it.

7.5 Parameters and cost

Below is a recap of parameters and costs of the protocol.

8. Hybrid solutions

Another technique that could help the adoption of these designs for the post-quantum transition is to use hybrid models. The key idea is that combining a PQ signature with an ECDSA signature lets you reduce the security risks introduced by new, less battle-tested systems, by initially pairing the new schemes with ECDSA, the signature that has secured the network from its very origins.

This kind of design can help in the early phases of adoption, for example in the context of a multisig, where ECDSA and PQ signatures can be combined to balance the security assumptions.

9. The criteria checklist

In summary, here is a powerful checklist of most of the criteria for properly designing a post-quantum signature solution on Ethereum that works today, can scale, offers quantum readiness, and is balanced.

• 1. Embrace account abstraction, and don't forget about frames.
• 2. Try to keep the verification gas cost as low as possible. Even a 2X improvement is massive for scalability and long-term sustainability. Unless you're bearish on ETH price and Ethereum block space usage. Are you?
• 3. Try to keep signature size as low as possible. Be mindful that huge transactions might create problems in a world where you need bundlers.
• 4. Signature time is important. Actually, UX is extremely important. That's all users will see. Also, even among market leaders (Ledger), most users probably still have the older devices, so optimizing for the newest chip only won't do.
• 5. Public key size is relevant.
• 6. If you need to derive the public key from the signature, you have limited options.
• 7. Different families of schemes carry different trust assumptions. The prudent way is probably the best.
• 8. Consider hybrid solutions in this scenario.
• 9. State management risks can be solved. Don't exclude these solutions entirely.
• 10. NIST security levels can't be ignored. Level 1 security is a must.
• 11. MPC and specialized use cases can't be forgotten.
• 12. Aggregation is a factor that can't be ignored.
• 13. Non-PQ Ethereum upgrades can make or break any solution.
• 14. Auditability matters. Also these things will need formal verification.
• 15. Trusted setups defeat the purpose of all this work (and of Ethereum itself).
• 16. Simplicity is key. Trying to add endless levels of ZK complexity and cost to the mix will not help anyone.

What we see as a good path is: FORS with key rotation (our protocol) for standard use; SPHINCS- and SPHINCS+ for recovery, but also as standalone signatures for certain specific use cases (and certain regulatory requirements); and one or two options for MPC.

This mix should cover the full spectrum and give Ethereum's execution layer the tools for post-quantum readiness very soon. It can also offer a great UX, as demonstrated in this video using our reference wallet NiceTry.

10. Conclusion

The design space for these solutions, as we have seen, is not limited to the choice of a signature scheme. No single solution is perfect, and the best design, more than a signature, is a protocol. A set of choices, decisions and Ethereum components that, working together, offer post-quantum security, balanced costs and efficiency, strong and well-managed security assumptions, as well as good coverage of the various use cases.

The solution is as much engineering as it is cryptography. The transition will change the infrastructure of Ethereum wallets at its most important and delicate level, and it requires a cautious approach, spread out over time, that can result in a simple, secure and familiar UX for all the network's users.

We are planning to turn our protocol, work and learnings into an ERC soon, so stay tuned for that.