Building a quantum-safe wallet for Solana that works today (DeFi included)

Much has been said about quantum readiness applied to blockchains. As the urgency to prepare a migration plan keeps rising, driven by leading companies publishing groundbreaking results and by nation states acting on it, it is important to understand that migration is not a single button that fixes an entire ecosystem.

At Riva Labs we build digital asset infrastructure for the post-quantum world, and admittedly spend an unhealthy amount of time thinking about this set of problems.

While we wait for the major chains to move forward with their proposals, and contribute to them where we can, we wanted to know how much of the problem you can solve in the meantime.

Looking at Solana, and at the part that matters most to a user, which is whether their assets still belong to them, the answer turns out to be all of it. You can build an account today, on Solana as it exists right now, that no quantum computer can take from you. It requires no protocol change, no SIMD, and no permission from anyone.

What we set out to prove

The purpose of the work is to demonstrate that, with Solana as it is today, all of the following are possible:

1. Build a quantum-safe wallet, with a stable address you can use for everything, keeping user assets safe.
2. Protect transactions with post-quantum cryptography, while using a conventional Solana transaction as the transport envelope.
3. Use the wallet to interact with DeFi on Solana. In our case, a swap through Jupiter's API.
4. Deposit some USDC on Kamino Earn.
5. Use the wallet as a quantum-safe co-signer in a multisig created with Squads.

So, in a nutshell, what we are defending is ownership of assets in a specific account on Solana mainnet, without requiring any protocol changes.

We are not defending consensus, validator identity, block production, or the transaction envelope. Even individual DeFi protocols and their admin keys will need to be upgraded to post-quantum security for a full migration.

Why the threat on Solana is different from other major networks

At the execution layer there are two main types of attack a cryptographically relevant quantum computer (CRQC) could be used for. The first is stealing funds directly from an address, by deriving the private key from the public key. The second is taking over the keys behind an admin role on an asset or protocol, a stablecoin or an RWA issuer for instance, where mint, freeze, blacklist and upgrade powers sit. The second is worse than the sum of the balances it touches, because those powers allow an attacker holding them to drain reserves or reissue supply, and the assets are only freezable while whoever can freeze them is still in control.

Bitcoin offers partial cover here. A P2PKH address is a hash of the public key, so the key only becomes visible when the output is spent. Coins sitting in an output that has never been spent are not exposed, which is why address reuse matters so much. Ethereum follows a similar paradigm, as Ethereum addresses are the first 20 bytes of a hash of the public key, which is hidden until a transaction is signed by that address. The protection is still short lived, since broadcasting a transaction reveals the key before it confirms, and an attacker with a fast enough CRQC could race the transaction in the mempool.

Solana has no equivalent. The string you paste into a wallet to receive funds is the Ed25519 public key that controls the account, so exposure begins the moment the address exists, whether or not it has ever been spent. That makes alternatives worth having now rather than later, particularly for wallets meant to hold value over long horizons, and for the scenario where a breakthrough triggers a rush and every address on the network is already exposed.

What we built and the main features

To build the quantum-safe wallet for Solana we started from our existing wallet, 'NiceTry'. It works like a traditional browser extension, offering a UI familiar to crypto users while hiding the cryptographic complexity underneath.

A stable address

A stable address is the starting point for any modern wallet. Without one, most of what a blockchain is for becomes unreachable, especially on a finance-oriented chain like Solana, and DeFi in particular. What remains is a vault you can hold assets in, with painful operational management around it.

The address we use is a Program Derived Address, derived once from the initial FORS identity and a commitment to the SPHINCS+ backup keys. Both are fixed when the account is created, so the address holds for the life of the account while the signing authority underneath it changes on every operation.

Hash-based quantum-resistant signatures

Hash-based schemes are among the most conservative post-quantum signatures available, since their security rests entirely on hashes, a primitive that is well understood and well supported everywhere.

The main build is constructed around Forest of Random Subsets (FORS), a hash-based few-time signature scheme also used inside SPHINCS+, which NIST standardized as SLH-DSA.

Few-time signatures, as the name implies, are meant to be used a limited number of times. Each signature reveals part of the secret, and past a threshold enough has been revealed that forgery becomes feasible. So we use a rotating design we call 'Ephemeral Keys', where each FORS key signs a single operation and the account moves to the next one. That makes this a stateful path, since something has to know which keys have been spent. Rather than trusting the wallet to hold that state, we use the one state machine the user is already trusting: the chain itself.

With the state onchain, the source of truth is the same ledger that settles the transaction, and it moves forward only. This is also where FORS earns its place over a one-time scheme. Under Winternitz (WOTS), a single reuse or state failure is catastrophic and puts funds at immediate risk. FORS carries a budget of several signatures per key, so a state mistake produces a measurable, gradual reduction in security level instead of a break, and the wallet retires the key well before the budget runs out.

A signature is 2,448 bytes, which is large next to the 64 bytes of Ed25519 and small next to many other post-quantum options: our SPHINCS+ profiles run from 3,028 to 7,856 bytes for the same security level. Verification costs 40,302 compute units, and the network fees for a complete operation came to 75,000 lamports, under a cent at the time.

A SPHINCS+ recovery path is included to cover device loss, a key that has reached its budget, and the case where the authority registered onchain has drifted from what the device derives.

The same SPHINCS+ signature can also authorize operations directly, giving a fully stateless path with no state to manage, at the cost of a larger signature and more compute. Everything we demonstrated while building this project is applicable to both the stateless and stateful paths.

Supporting components

• The program. The onchain verifier and the only thing that can act on the vault's behalf. It checks a FORS signature against the identity currently registered in the vault, or a SPHINCS+ signature against the backup keys committed when the account was created, rotates the identity either way, and runs the authorized instructions while signing as the PDA. The program is immutable: we renounced the upgrade authority, so nobody can replace it.
• A staging account. A 2,448-byte signature does not fit in a 1,232-byte transaction, so it travels separately. The wallet creates a temporary account owned by the program, writes the signature into it in chunks, and the execute transaction reads it back out. A freshly generated keypair signs the account's creation and every write, which keeps one operation from interfering with another, and the account records who paid its rent so only they can reclaim it.
• A relayer to pay network fees and front rent. Solana requires an Ed25519 signature in the fee payer position and a PDA cannot produce one, so a relayer signs the envelope. It covers more than the fee: the staging account and any token account the operation creates both need rent up front, which the relayer advances and recovers when the operation settles. The vault repays it inside the same authorized transaction, up to a cap the signature commits to. The relayer cannot produce a valid signature, cannot change which instructions run, and cannot appear as an account inside an operation.
• A validation service. Sits between the extension and the network, checking the cluster, the program, the fee payer and the transaction structure, and simulating the transaction before anything is broadcast. It also proxies the Jupiter API so credentials stay out of the extension, applies rate limits, and reclaims the rent from staging accounts left behind by abandoned operations.

Transaction flow overview

Results and mainnet transactions

The build covers everything we set out to prove: you can protect the assets in a Solana account from the quantum threat today, with network fees under a cent per operation, and still use all the major DeFi apps.

Our work set out to prove that user assets can be protected, and that is the whole of the claim. It does not reach the consensus layer, block production, or individual DeFi protocols, which will need their own upgrade to quantum-safe security. What it does require is nothing: no protocol change, no SIMD, just a browser extension and Solana as it is today.

The transactions from our tests:

• A send transaction
• A Jupiter swap
• A multisig approve transaction (Squads)
• A multisig execute transaction (Squads)
• A USDC deposit on Kamino

The GitHub repository covering the construct and the wallet extension will be published soon. If you are preparing your project for the quantum threat and are ready for a pilot, reach out.