Native Ephemeral Key Rotation via Frame Transactions

Cryptography
,
1

Native Ephemeral Key Rotation via Frame Transactions

Thanks to @mvicari for his contributions and to @asanso for his feedback

Abstract

This is a follow up to our previous post Achieving Quantum Safety Through Ephemeral Key Pairs and Account Abstraction.

We propose integrating ephemeral key rotation directly into the frame transaction format (EIP-8141), without requiring a separate Account Abstraction layer. By adding a singleton registry contract, signing authority can be decoupled from onchain identity at the protocol level, and native bundling from Frame Transactions enables us to add a frame to rotate signer to each transaction, enabling disposable ECDSA keys with minimal overhead and maximum uniformity, making key rotation available uniformly to all senders.

Motivation

EIP-8141 introduces frame transactions, which decouple validation logic from the transaction sender, opening the door to arbitrary signature schemes. Independently, in our prior work we show that key rotation after every transaction, implemented at the AA layer, effectively neutralizes the quantum threat to ECDSA by making every exposed key immediately useless.

Frame transactions already provide a natural home for this rotation logic: rather than implementing key rotation inside each smart contract wallet independently, we can bake it into the transaction format itself, making it available uniformly to all senders.

Design

The proposal requires two components to work:

1. A Signer Registry Contract

A singleton contract deployed at a well-known address maintains a mapping from account address to its current authorized signer:

mapping(address account => address signer) public signerOf;

We built an example implementation of this registry contract at our git repo.

In the future, we plan on upgrading this contract to also contain the code necessary to handle the whole VERIFY process of frame transactions using ECDSA signatures.

2. An Additional Frame in the Frame Transaction

To achieve the rotation it is necessary to add a frame which targets the singleton contract, changing the authorized signer to the next signer. Bundling is native in frame transactions, so this frame can be added to any transaction without requiring protocol changes.

Validation Flow

In the VERIFY frame, the current signer for tx.sender is looked up in the registry. The transaction signature is verified against that signer (rather than against tx.sender directly).

  • If signerOf[sender] == address(0), the user signature is verified against tx.sender directly, preserving EOA-like behavior as the default.
  • If validation passes, the registry entry for tx.sender is updated to nextSigner, completing the rotation:
signerOf[tx.sender] = nextSigner;

This last step is done in an additional frame, as the validation frame cannot make state changes.

This rotation must occur even if other execution frames revert, mirroring the same invariant identified in the AA-based approach: a failed transaction must not leave the current signer exposed without rotating it.

FrameTxScheme.png1360×1120 77.1 KB

Rotation Toggle

If no rotation frame is included in the transaction, no signer rotation will occur, making the key rotation feature completely optional. The user can decide to switch it on and off on any Ethereum account simply by adding the appropriate frame to a transaction.

Properties

  • Decoupled signing from onchain identity: the account address never changes; only the authorized signer rotates.
  • Quantum mitigation: each private key is used exactly once; even if later recovered by a quantum computer, it cannot authorize future transactions.
  • Opt-in by default: accounts that never write to the registry (or set nextSigner = 0 permanently) experience standard behavior with no overhead.
  • No per-wallet logic required: sender-signer decoupling is handled at the transaction validation layer, not inside each contract, removing the need for custom smart wallet implementations.
  • BIP44 compatibility: the nextSigner address can be derived from a BIP44 path, making the scheme compatible with existing HD wallet infrastructure.

Comparison with AA-Based Rotation

The AA-based approach from our previous post implements this same rotation inside the smart contract wallet’s validateUserOp, showing that this approach is viable today and demonstrated at ~136k gas for an ERC20 transfer. This frame transaction approach differs in that:

  • Rotation is a first-class protocol feature, not a per-wallet convention.
  • All frame-transaction senders benefit without needing to deploy or upgrade a smart wallet.
4 Likes