Image by Ideogram
Late last year, I wrote an article on how I built a quantum-resistant wallet on Ethereum. A lot has changed since then including the release of a free wallet on the Sepolia testnet for anyone to try (there is a registration step but it is only so user’s can choose which authentication method to use, I only see email addresses and no other details; with Apple logins, there is even an option to obfuscate the email address from me).
The previous article focused on the verification logic use by my smart contract so there is no need for me to repeat that. Since that time, however, I came across another project that had implemented a smart contract for generating SHAKE256 hashes.
As a quick reminder, my contract used a Keccak256 variant for hashing messages to avoid excessive gas consumption. Since that time, I have not only managed to incorporate the SHAKE256 function but also reduced the gas consumption for signature verification.
Okay, Claude code reduced the gas consumption for me. Some of the gas savings came from replacing the code with an assembly equivalent. A significant amount of gas savings came from changing some stored values from a large array (1024 elements) into a compressed byte32 array (with 32 elements). All of the code is publicly available here.
Claude code was able to reduce the gas consumption by 37%. A wallet using falcon-512 now uses about 4.8 million units of gas to verify a signature. At today’s ether and gas prices, that is about $5 for a transaction.
I also changed the mechanism for loading the public key into the smart account. Previously, an encoded key was required as input and the contract would decode it and then convert it into the NTT domain. The encoding reduced the size of a public key for falcon-512 from 1024 bytes to 896 bytes. The gas consumed decoding the key was not worth the reduced input size.
Some may wonder why I would share my work openly and not try to retain the intellectual property instead. There are a number of reasons:
The original implementation of Falcon is under an open MIT license and is available publicly.There are other teams working on similar contracts to mine from whom I have benefited.By doing so, the falcon verification contract on Ethereum can be standardised (similar to the EntryPoints for ERC4337) instead of multiple similar contracts being deployed and taking up storage.The Solidity contracts are just a small portion of what I have built over the last 8 months.The publicly available contracts are simple accounts and do not include additional features I have developed.
Since my wallet is using the account abstraction methodology, I have to run my own bundlers and paymasters. Existing paymasters are not likely going to support contracts using falcon signature verification because the gas consumption is much higher than what they would expect.
The structure of a user operation in account abstraction is complex and there are nuances to how different fields are used.
One such filed is the verification gas limit. With the traditional elliptic curve based cryptography, verification gas can be fairly low and unlikely to be more than half a million units of gas (and I would not expect to even see limits set that high).
As I have already mentioned, falcon-512 uses about 4.8 million units of gas so the verification limit needs to be set around 5 million to account for variations. The gas used for falcon-1024 verification is about double that.
Image by Ideogram
Existing bundlers may not support these wallets in the short term either without making substantial changes. Another field in the user operation is for pre-verification gas which is how bundlers collect payment for the work they do off-chain such as validating the signature as well as the call data. Bundlers may choose to increase their pre-verification gas to cover the additional costs of validating the falcon signature.
If a bundler submits a transaction that then reverts, they may not get reimbursed by the paymaster. It is important that they are confident a user operation will succeed before trying to submit the transaction to a node.
So any bundler looking to accept user operations for an account using falcon verification will need to adapt their code to verify the signature to avoid on-chain failure. They will also need to verify the gas limits set on these operations for the very same reason.
For a bundler to verify a transaction, there are two routes they can take. The first is to locally verify the signature using available falcon libraries; this can be faster and cheaper but those libraries may use key encoding methods for which the bundler will need to account; I removed the key encoding to save on gas remember.
The second, and more ideal method, would be to use the falcon contract on chain to verify the signature. This is where having one standard falcon contract fits better than multiple versions. The verification function is read-only and can be run from any node. Bundlers can verify a signature on the same contract that will be called by the smart account to verify the signature just prior to execution.
I have done more than just build a quantum-resistant wallet, I have built the entire ecosystem around supporting these wallets. For the free wallet mentioned earlier, I am running a bundler to handle the movement of user operations between the wallet application and the smart wallet contract. I am also running a paymaster service that credits each wallet with 100 free transactions; this is where the wallet is gasless, you do not need to hold sepolia ether in the wallet to be able to transact.
When I wrote about this late last year, I said that quantum-resistant custody is possible on Ethereum.
Now I am demonstrating fully functional wallets on Sepolia that use the falcon algorithm for signature verification.
Quantum-resistant wallets are here now.
An Update on Building Quantum-Resistant Wallets was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.