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 summarizes 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 rotates the signer commitment there. This is intentional and conformant, with two documented consequences:

  • Revert behavior. 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; under the legacy WOTS+C scheme it was not.
  • 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 behavior.

All validation touches only the account's own storage, satisfying ERC-7562 storage-access rules.

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

EIP-8141 introduces frame transactions, a transaction type built from a sequence of framed calls with native VERIFY/SENDER semantics. NiceTry uses it to express signer rotation natively, without ERC-4337: a VERIFY frame checks the FORS signature and requires the next frame to rotate the owner.

The full design, the rotation invariant, and why the implementation is currently abstract (draft opcodes aren't yet expressible in solc) are on the Frame Transactions page.

Related standards

ERC-7579 (modular accounts)

The rotation-validation logic is packaged as ERC-7579 validator modules for the legacy schemes (KernelRotatingECDSAValidator, KernelRotatingWOTSValidator), installable on compliant modular accounts (Kernel, Nexus, …) without deploying a new account. Module state is keyed by account address as the outermost mapping key to satisfy ERC-7562. A FORS+C validator module does not exist yet; the FORS+C path currently ships only as the standalone ERC-4337 SimpleAccount. The 7579 interfaces and integration mocks live under other-implementations/kernel/.

EIP-1271 (contract signatures)

None of the Ephemeral Keys schemes implement EIP-1271. For FORS+C and WOTS+C this is fundamental: verification mutates state (the rotation), while EIP-1271 requires a pure view function. For the legacy ECDSA scheme it's a current limitation rather than a fundamental one. The proposed workaround is a dedicated permit-signer with its own isolated key stream and rotation policy.