EIP-8397: Frame Authenticator Signatures

EIPs EIPs core
1

Discussion topic for the draft EIP Frame Authenticator Signatures, a companion Core EIP to EIP-8141 adding a bounded AUTHENTICATOR signature scheme.

Draft PR: Add EIP: Frame Authenticator Signatures by leekt · Pull Request #12244 · ethereum/EIPs · GitHub

Summary

AUTHENTICATOR lets a frame transaction carry a custom authentication proof whose expensive cryptographic verification is executed by protocol in a bounded, state-independent context. Account authorization stays in the ordinary VERIFY frame.

[scheme, signer, msg, signature]

scheme    = AUTHENTICATOR (0x03)
signer    = authenticator address
signature = key_id || proof

authenticator.authenticate(digest, proof) -> authenticated key_id
require authenticated key_id == claimed key_id
resolved_signer = authenticator
-> VERIFY frame: account decides whether it trusts the authenticator

What it provides

  • Arbitrary signature schemes validated by protocol with a fixed AUTHENTICATOR_GAS_LIMIT (50k) in a pure context: no state, no block/env reads, only precompile STATICCALLs.
  • Separation of expensive crypto (protocol) from stateful policy (VERIFY).
  • Authenticated credential identity: the authenticator returns key_id, checked against the claimed value, so it cannot be forged by the tx author.
  • Builders/sequencers see (authenticator, key_id) before execution for routing, caching, batching, and DoS accounting; account code can optionally read key_id via existing SIGDATACOPY.
  • Permissionless authenticators at a fixed consensus cost; no registry or allowlist.
  • compute_sig_hash unchanged; the signature bytes remain uncommitted witness like every other EIP-8141 scheme.

Left to account / authenticator implementations

Actor registries keyed by (authenticator, key_id), per-key scopes and policies, session keys and expiry, rotation/revocation, recovery and guardians, JIT key authorization (AUTHENTICATOR sig + root sig with explicit msg), ERC-1271, call-phase executors. None of this is enshrined; a companion ERC can standardize it.

Work left (separate EIPs / EIP-8141 amendments)

  1. Existing code-less EOA same-address establishment / first-tx custom auth.
  2. MAX_VERIFY_GAS: sender + payer both using AUTHENTICATOR (2 x 52,600) exceeds the 100k public-mempool cap.
  3. Canonical account profile in EIP-8141’s direct-evaluation list.
  4. Canonical valid_after verifier.
  5. Same-sender parallel public mempool over EIP-8250.

Feedback welcome, in particular on the fixed 50k authenticator budget, the block-access-list treatment of the authenticator code read, and whether key_id should stay in the wire format.

Update Log

External Reviews

None as of 2026-08-26.

Outstanding Issues

None as of 2026-08-26.