Skip to content

Introduction

Quantum-safe Ethereum smart accounts

NiceTry is the reference implementation of the Ephemeral Keys Protocol, a quantum-safe smart account design for Ethereum that requires no protocol changes, no new precompiles, and no ecosystem-wide migration.

The Solidity contracts live in the NiceTry repository; the protocol specification and design rationale live in the Ephemeral-Keys-Protocol repository. Both are maintained by Riva Labs.

The idea in one paragraph

An Ethereum account is quantum-safe right up until it signs. At that moment its public key is exposed onchain, and Shor's algorithm can recover the private key from a known public key. Ephemeral Keys removes that long-term exposure: the account authorises one signer at a time and rotates to a fresh signer on every transaction, all behind a constant account address. The current signer is a post-quantum, hash-based FORS+C key, so a signature observed in the mempool reveals nothing a quantum adversary can act on.

Why FORS+C

NiceTry's primary signer is FORS+C, a standalone, hash-based few-time signature scheme (the Forest Of Random Subsets primitive from SLH-DSA / SPHINCS+, with the "+C" grinding compression). It was chosen over the earlier ECDSA and WOTS+C designs because:

  • Post-quantum. Security reduces to preimage resistance of Keccak-256. Grover's algorithm gives only a quadratic speed-up, which the parameters already account for.
  • Graceful degradation. Unlike WOTS+C (a one-time scheme that breaks instantly on reuse), a few-time scheme weakens slowly under accidental key reuse, which makes dropped/replaced transactions recoverable instead of catastrophic.
  • Onchain viable. Standalone FORS+C (no XMSS hypertree) verifies in ~34–38k gas, an order of magnitude cheaper than a full SPHINCS+ verify.

At the design target of one signature per key, FORS+C is NIST security level 1 (128-bit classical). See FORS+C → Parameters for the full numbers.

How rotation works

The account stores a single 20-byte commitment to the current signer. Every signed UserOperation carries the next signer in its calldata, and the contract advances the commitment atomically during validation.

Derive

Off-chain, the wallet derives the next FORS+C keypair from the user's seed and computes its 20-byte address last20(keccak256(pkSeed ‖ pkRoot)).

Sign

The user signs the UserOperation with the current key. The nextOwner address is appended to userOp.callData, so the signed userOpHash commits to it.

Validate & rotate

The account calls the FORS+C verifier, checks the recovered signer against the stored owner, and, on success, overwrites owner with nextOwner inside validateUserOp. Rotation happens at validation time, so a key is retired even if the inner call later reverts.

Execute

Execution proceeds through the ERC-4337 EntryPoint. The previous key is now useless: it is no longer the authorised signer.

The same rule can also be expressed natively as an EIP-8141 frame transaction, where a VERIFY frame requires the next frame to rotate the signer.

Contracts at a glance

ContractRole
ForsVerifierStateless FORS+C signature verifier (recover(sig, digest) → address)
SimpleAccountERC-4337 account; verifies + rotates the owner on every UserOp
SimpleAccountFactoryDeterministic CREATE2 factory for FORS-backed accounts
FrameAccountEIP-8141 frame-native variant of the same validation rule

Project status

  • Public demos: a standalone wallet demo and a MetaMask-powered demo are available at nicetry.xyz.
  • Strawmap roadmap: the ephemeral-keys design is listed on the strawmap Ethereum roadmap (see ephemeral keys).
  • Parameters are not final: the post-quantum parameter sets are still being tuned as the design and tooling mature.

Ecosystem & links