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 signing key at a time and rotates to a fresh key on every transaction, all behind a constant account address. The rotating key is a post-quantum, hash-based FORS+C key, so a signature observed in the mempool reveals nothing a quantum adversary can act on.

Two account families

The repository ships two ERC-4337 account families built on hash-based, post-quantum signatures:

AccountSignerSchemeSignatureVerify gas
SimpleAccountPrimary (every UserOp)FORS+C2,448 B~34k warm / ~38k cold
SimpleAccountBackup (recovery, bootstrap)SPHINCS3,688 B~105k
SphincsAccountOnly signerSPHINCS (standard FORS + WOTS+)6,176 Bnot measured

SimpleAccount is the ephemeral-keys design and carries two signers with different jobs:

  • FORS+C is a standalone Forest Of Random Subsets few-time signature (the FORS primitive from SLH-DSA / SPHINCS+, with the "+C" grinding compression and the FIPS 205 address layout). Security reduces to preimage resistance of Keccak-256. At the design target of one signature per key it is NIST security level 1 (128-bit classical), and accidental reuse degrades gracefully instead of breaking outright. The account rotates to a fresh FORS+C key on every UserOp.
  • SPHINCS is a stateless, many-time SPHINCS+/SLH-DSA variant tuned for the EVM. It is a durable cold key committed into the account address. It can sign any operation, recover an account whose rotation chain broke, and bootstrap the account on a chain that was not in the activation Merkle tree.

Both verifiers are shared, stateless contracts. The account routes each signature to the right one purely by its byte length. See Signature dispatch.

SphincsAccount is the stateless alternative: a single standard SPHINCS key signs every UserOp, with no rotation, no activation step and no recovery path. It costs roughly eight times the gas per operation but needs no key-management state in the wallet at all. See SPHINCS-only account.

How rotation works

SimpleAccount keeps a per-key authorisation state instead of a single owner slot. A FORS+C key is active exactly once, signs exactly once, and is then burned. Every signed UserOperation carries the next key in its calldata, and the contract advances the state atomically during validation.

Derive

Offchain, 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 that the recovered key is active, and, on success, burns it and activates 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 burned and can never be re-activated.

Because state is per key rather than per account, several devices can each run their own rotation chain on the same account. New devices are enrolled with addSigner(). See Signers & devices.

Contracts at a glance

ContractRole
ForsVerifierStateless FORS+C verifier (recover(sig, digest) → address)
SphincsVerifierStateless SPHINCS verifier (verify(pkSeed, pkRoot, digest, sig) → bool)
SimpleAccountERC-4337 account: FORS+C primary, SPHINCS backup, per-key auth state
SimpleAccountFactoryDeterministic CREATE2 factory; the address commits to the initial-signer root and the backup key
SphincsStandardVerifierStateless standard SPHINCS verifier (6,176-byte signatures)
SphincsAccount + factoryERC-4337 account with a single, never-rotated SPHINCS key

Project status

  • Public demos: a standalone browser-extension wallet 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: both the FORS+C and the SPHINCS parameter sets are still being tuned as the design and tooling mature.
  • SPHINCS verifiers are unaudited: the backup verifier is vendored verbatim from the upstream research implementation, and the standard verifier behind SphincsAccount has no reference vector yet, so its positive path is untested. Any real-funds deployment should be gated on an audit.
  • In progress: a runtime-parameterised SphincsParamVerifier and a multi-backup-signer account are being developed on the multiSphincs_account branch.
  • Archived: the earlier ECDSA and WOTS+C accounts, the ERC-7579 validator modules, and the EIP-8141 FrameAccount draft were removed from the main line and live on the archive/dev-pre-cleanup branch. See Archived designs.

Ecosystem & links