ERC-8403 draft: keep an account's keys as one hash, then swap in post-quantum ones

Serguey Asael Shinder11 October 2026, 09:403 min read

A draft Ethereum standard, ERC-8403, was presented on the Ethereum Research forum on 11 October by its author, who posts as AnkushinDaniil. It is an individual draft, not an accepted standard, and the post ends with open questions. Its subject is a gap that native account abstraction leaves open: an account may hold many keys, but nothing standard says what adding or revoking a key means, so each account design invents its own answer and every wallet must support each one.

One root for everything. Each authority — a signing key, or a rule such as a spending limit or an unlock time — is a leaf, the hash of a stable 32-byte slot identifier and the thing the account checks (for a key, its public key). All leaves form a tree, and the account stores only its 32-byte root. Each transaction brings a membership proof that its leaf is under the root and a witness that the leaf's holder approved it, such as a signature over the transaction hash. Adding, rotating and revoking a key are all the same operation: write a new root. The address never changes. The draft ties the check to the frame transactions of EIP-8141 and, informatively, to the keystore of EIP-8130.

The trade-off the author states up front: revocation speed.

• Tier 1 reads a recent root named by the transaction (via EIP-8272) and no mutable storage, which keeps validation cheap enough for the public mempool. A revoked key keeps working until the old root leaves that window.
• Tier 2 reads the account's current root from storage. Revocation takes effect from the next block, but validation is no longer in the cheap tier.

The author's demo, on two local Nethermind nodes, makes the cost concrete: of seven attempts with revoked keys, foreign proofs and forged data, one succeeded — against the tier 1 account, inside its window — while the tier 2 account refused at once. An account that needs fast revocation, the post concludes, must use tier 2.

Other chains and recovery. The key set lives on one home chain; elsewhere a transaction adds a storage proof that the root sits in the account's slot at home, checked against a home root that chain already imports. How that home root arrives is left to existing mechanisms. If the account keeps leaf records in its own storage, a wallet that lost everything can rebuild the tree from any node.

Post-quantum keys. EIP-8288 takes large hash-based signatures out of the block and proves them with one recursive STARK per block; the author cites 3,000 gas per leanSPHINCS check in the current draft. ERC-8403 supplies what EIP-8288 does not: which key may sign and how to move from secp256k1 to a post-quantum key without changing the address — the new key is simply another leaf. The author has not yet run this step with a real post-quantum key, and notes a gap: one EIP-8288 test case asks for a transaction whose hash would have to contain itself, which an open pull request proposes to fix.

An optional second step moves the whole check into a proof, so the chain no longer sees which key signed. Measured outside any node on leanVM: about 0.1–0.3 s to prove on a 12-core server, proofs of 162–235 KiB, and 30,000 gas instead of about 3,000 — with no privacy yet, because leanVM proofs are not zero-knowledge.

Source: Ethereum Research, ERC-8403: an account as one hash, and post-quantum keys, 11 October 2026 — https://ethresear.ch/t/erc-8403-an-account-as-one-hash-and-post-quantum-keys/26147