# Introducing our quantum-safe wallet design > This article explains how our quantum-safe smart wallet design for Ethereum/EVM works, leveraging technologies that already exist today. - Author: Matteo Vena - Published: March 19, 2026 - Tag: Post-Quantum - URL: https://www.riva.xyz//blog/introducing-our-quantum-safe-wallet-design --- This article explains how our quantum-safe smart wallet design for Ethereum/EVM works, leveraging technologies that already exist today. As described in our team's publication on [Ethresear.ch](https://ethresear.ch/t/achieving-quantum-safety-through-ephemeral-key-pairs-and-account-abstraction/24273), our design uses ephemeral key pairs and Account Abstraction to protect user assets from future attacks exploiting the vulnerability of ECDSA signatures. The quantum threat to elliptic curve cryptography is no longer a distant concern. Shor's algorithm efficiently solves the elliptic curve discrete logarithm problem, which breaks ECDSA. While a cryptographically relevant quantum computer doesn't exist yet, the timeline is shrinking. The Ethereum Foundation has established dedicated post-quantum research efforts, and Vitalik has recently outlined a broader PQ roadmap. On Ethereum, an EOA that has never transacted is effectively quantum-safe, since its public key is hidden behind a hash. But the moment it signs a transaction, the public key is permanently exposed onchain, making that address compromised from a quantum-resistance standpoint. Significant work is being done to bring post-quantum signature schemes directly to the EVM, most notably Falcon ([1](https://ethresear.ch/t/so-you-wanna-post-quantum-ethereum-transaction-signature/21291), [2](https://ethresear.ch/t/falcon-as-an-ethereum-transaction-signature-the-good-the-bad-and-the-gnarly/21512), [3](https://ethresear.ch/t/the-road-to-post-quantum-ethereum-transaction-is-paved-with-account-abstraction-aa/21783), [ETHFALCON](https://github.com/ZKNoxHQ/ETHFALCON)) and [Poqeth](https://ethresear.ch/t/poqeth-efficient-post-quantum-signature-verification-on-ethereum/21554). These efforts are essential for the long term, but onchain verification still costs upwards of 1M gas for Falcon, while hash-based signatures are currently in the \~200k gas range. These costs could be further reduced by [EIP-8051](https://eips.ethereum.org/EIPS/eip-8051) and [EIP-8052](https://eips.ethereum.org/EIPS/eip-8052) precompiles once they are added to the EVM. Gas cost is not the only challenge facing post-quantum signatures: standardization, hardware wallet compatibility and proven resistance to classical attacks are significant obstacles that a new standard for ETH signatures will need to overcome. Even if such a signature were ready, standardization needs time, and fully replacing ECDSA requires protocol-level changes ([EIP-7701](https://eips.ethereum.org/EIPS/eip-7701), [RIP-7560](https://github.com/ethereum/RIPs/blob/eedf04cdeeb4feb141a271cede23260eb66d03b8/RIPS/rip-7560.md)). Our approach is complementary: rather than replacing ECDSA, we make it disposable. For more details on Falcon aggregation trade-offs in PQ mempools, [see this analysis](https://ethresear.ch/t/revisiting-falcon-signature-aggregation-for-pq-mempools/24431) by Sanso, Thiery, and Wagner. ## Proposed Design We can leverage Account Abstraction to maintain a static identity towards the rest of the blockchain (the smart account), while switching the signer's identity after every transaction. This does not prevent quantum computers from recovering the user's private key. Rather, it makes the private key that was used to sign the previous transaction useless to sign any future transaction. The scheme is simple: User appends an address to the calldata of their userOp The smart contract wallet validates the transaction The userOp is executed The authorized signer on the smart contract wallet is changed to the new address After the transaction is executed, the old private key, even if recovered, is completely useless. Only the address has been communicated to the smart contract wallet, so only part of the hash of the public key has been revealed, making the new private key quantum-safe until the next transaction. A few practical optimizations are possible: for instance, the user can derive the next addresses from a BIP44 derivation path rather than choosing arbitrary ones. This is already supported by existing wallets. ![Diagram of the signer rotation scheme](/images/blog/img_signer_rotation1.webp "Diagram of the signer rotation scheme") ## Practical Implementation This design can be implemented by making some minor tweaks to the base [SimpleWallet](https://github.com/asanso/account-abstraction/blob/95d36a70162e48612dd25e2e28f77a95cf627e7f/contracts/samples/SimpleAccount.sol). All we need is a way to extract the next authorized address from the calldata and change the owner of the smart contract wallet. We implemented a basic version of the solution at this [repo](https://github.com/RivaLabs-Core/NiceTry/blob/ba0ad5d5c3a0b02ba44c0cf5ce4a34fa4a14f72d/src/SimpleAccount.sol). This implementation also aims to solve a key issue we identified: we need to rotate the signer even if the userOp reverts. Otherwise a failed transaction would mean the signer is already exposed. We instead emit an event if a userOp fails, but still finalize the transaction and execute the rotation. With this implementation we recorded some transactions ([example](https://sepolia.basescan.org/tx/0x90a7626224823d5b9bc4eeab95c66ee93d3ff06d5303d65a941af1687d885d54)) and measured \~136k gas units for an ERC20 transfer, a gas overhead of less than 100k compared to the same token transfer on the same chain ([example](https://sepolia.basescan.org/tx/0x9e9128d6ce1e23108b0b7738c21a51f6512e23e4a3e8173e69b569bdf6712b83)). This overhead, which is already significantly lower than post-quantum signature verifications as of today, comes with the added benefits of Account Abstraction. The gas cost of the rotation itself, if added to a pre-existing Account Abstraction-based wallet, is even lower and almost negligible in the greater picture. ## Known Vulnerabilities There is a vulnerability to this design that we are aware of: the mempool waiting period. In this period the user's public key is visible and a quantum-capable attacker could retrieve the private key and frontrun the transaction. This is a limited concern in practice, given the restricted timeframe an attacker would have to recover the private key, making the attack significantly harder to execute if not impossible. For those who want complete safety, private mempools can eliminate the issue entirely. The vulnerability is further mitigated on L2s, where block times are shorter. ## NiceTry: our smart wallet infrastructure project We are building a smart wallet infrastructure project that implements our solution for quantum safety alongside all the security and user experience features we believe smart wallets can enable. A demo of the project (which does not require connecting a wallet) is live on [@base](https://x.com/base) Sepolia at [nicetry.xyz](https://nicetry.xyz/).