Skip to content

Standards & EIPs

How NiceTry relates to Ethereum standards

NiceTry deliberately builds on existing account-abstraction standards rather than changing Ethereum's protocol. This page summarises how it uses, deviates from, or depends on each relevant standard.

ERC-4337

The SimpleAccount implements the ERC-4337 IAccount interface and runs against the canonical EntryPoint v0.7 (same address on mainnet, Sepolia, and major rollups).

Notable deviation: state write during validation. Most accounts only read state in validateUserOp; NiceTry burns the signing key and activates the next one there. This is intentional and conformant, with two documented consequences:

  • Revert behaviour. If the inner call reverts, rotation has already happened: a failed UserOp consumes a key just like a successful one. Under FORS+C this is recoverable via the bounded-reuse budget, and in the worst case through the SPHINCS backup.
  • Bundler constraint. Because state written during simulation isn't visible to later simulations in the same bundle, a bundler must not include more than one pending UserOp per sender per bundle. This is already standard bundler behaviour. Note that with multiple devices each device shares the account's nonce space, so the constraint applies to the account, not per device.

All validation touches only the account's own storage plus staticcalls into the two stateless verifiers, satisfying ERC-7562 storage-access rules.

The SphincsAccount family has none of this deviation: its validation is a view function that reads the stored key and calls the verifier, and replay protection is the EntryPoint nonce alone. Its only ERC-4337 peculiarity is size: a 6,176-byte signature field and a verification cost not yet measured for the current profile, so bundler limits and verificationGasLimit need checking.

FIPS 205 (SLH-DSA)

All three hash-based verifiers reuse the SLH-DSA structure with Keccak-256 substituted for SHAKE-256 so that everything is native on the EVM, and all three use the FIPS 205 §4.2 uncompressed 32-byte ADRS layout (layer, 96-bit tree address, type, three type-dependent words); the FORS+C verifier adopted it in July 2026. None is a standard SLH-DSA parameter set: FORS+C is the FORS component alone with the +C grinding trick, the backup SPHINCS is a retuned hypertree with grinding on both layers and a 2^22 budget, and the standard SPHINCS behind SphincsAccount uses the plain FORS and WOTS+ constructions at a non-NIST size (h=20, d=4, a=7, k=29, w=4). The standard verifier also reads WOTS and FORS digits LSB-first rather than in the FIPS 205 base_w order, which a signer must mirror. Distinct Hmsg domain pads (0xFF…FD for FORS+C, 0xFF…FF for both SPHINCS variants) keep FORS+C from ever colliding with SPHINCS on a digest.

EIP-7702

EIP-7702 lets an EOA delegate execution to a smart-contract implementation. If adopted, it could let users run Ephemeral Keys validation without deploying a new account or moving assets to a new address. The contract interfaces are compatible with 7702 delegation in principle.

The missing piece: a 7702-delegated EOA can always sign a normal transaction to change its own delegation, which would let the original (quantum-exposed) ECDSA key override the ephemeral-key logic. Full compatibility therefore also requires EOA deactivation, as described in EIP-7851. Until that exists, 7702 delegation alone does not provide the quantum-safety guarantee on its own.

EIP-8141 (frame transactions)

EIP-8141 introduces frame transactions, a transaction type built from a sequence of framed calls with native VERIFY/SENDER semantics. NiceTry explored expressing signer rotation natively with it: a VERIFY frame checks the FORS signature and requires the next frame to rotate the owner. The abstract FrameAccount that implemented this was removed from the main line and is preserved on the archive/dev-pre-cleanup branch. The design is documented on the Frame Transactions page.

Related standards

ERC-7579 (modular accounts)

Earlier revisions packaged the rotation-validation logic as ERC-7579 validator modules for the ECDSA and WOTS+C schemes (KernelRotatingECDSAValidator, KernelRotatingWOTSValidator), installable on Kernel or Nexus without deploying a new account. Those modules were archived together with the schemes they served. No ERC-7579 module exists for the FORS+C / SPHINCS path; it ships only as the standalone ERC-4337 SimpleAccount.

EIP-1271 (contract signatures)

Neither account implements EIP-1271. For the FORS+C path this is fundamental: verification mutates state (the rotation), while EIP-1271 requires a pure view function. For a SPHINCS key (the SimpleAccount backup or the SphincsAccount signer) an isValidSignature would be possible in principle since verification is stateless, but it is not part of the current contracts. The proposed workaround for the FORS+C path remains a dedicated permit-signer with its own isolated key stream and rotation policy.