Skip to content

Legacy Schemes

Earlier primary signers

Before FORS+C, the Ephemeral Keys protocol went through two earlier primary signing schemes. Both still work and remain in the repository under other-implementations/ for comparison and regression testing, but new deployments should use FORS+C unless there is a specific reason not to.

The evolution

GenerationSchemeWhy it was superseded
1Ephemeral ECDSANot actually post-quantum: relies on a rotation race and is vulnerable during the mempool window.
2WOTS+CPost-quantum, but one-time: any key reuse (a dropped/replaced tx) allows immediate classical forgery.
3 (current)FORS+CPost-quantum and few-time: reuse degrades gracefully, so failure modes are recoverable.

Each step kept the same architecture (a stable account address, one authorized signer at a time, rotation on every transaction) and changed only the signing primitive. FORS+C was introduced specifically to soften WOTS+C's catastrophic reuse failure mode while staying viable onchain.

Where they live

  • other-implementations/ecdsa/: SimpleAccount_ECDSA, RotatingECDSAValidator, KernelRotatingECDSAValidator
  • other-implementations/wots/: SimpleAccount_WOTS, WotsCVerifier, IWotsCVerifier, KernelRotatingWOTSValidator
  • other-implementations/kernel/: ERC-7579 module mocks (Kernel / Nexus) used by the integration tests
  • other-implementations/LegacySimpleAccountFactory.sol: a factory that can deploy the ECDSA/WOTS comparison accounts

The current FORS-only SimpleAccountFactory deploys only the FORS-backed account; the legacy schemes are reached through the legacy factory and the ERC-7579 modules.

Comparison

PropertyEphemeral ECDSAWOTS+CFORS+C (current)
Quantum resistancerotation-dependentunconditionalunconditional
Reuse on a single keycollapses to ordinary ECDSAimmediate forgerygraceful degradation
Signature size65 B468 B2,448 B
Verifier gas~3k (ecrecover)~93k~34–38k
Mempool exposureyes (residual risk)nonenone