ERC-8403 author publishes local account-key demo

Daniil Ankushin published an Ethereum Research post on October 11 presenting a local demonstration of account-key management around his ERC-8403 proposal. The linked code explores adding, replacing and revoking keys while keeping the account address unchanged. It runs on two local Nethermind nodes, rather than a public Ethereum deployment.

The research post introduces the demonstration and discusses possible post-quantum extensions. ERC-8403 itself is older: its pull request was opened on August 29 and remained open and unmerged when checked on October 11. The proposed specification is marked Draft.

How the proposed key model works

An account commits to its set of authorities through one root hash. For a key-based authority, authorization requires both evidence that the key belongs to that set and a signature approving the transaction. Membership alone is insufficient. Adding a key, rotating one or removing one changes the committed root.

This separates the account's address from its changing key set. For example, replacing a laptop key with a phone key changes the account's authority records instead of requiring a different account address. The proposal binds this check to the account's authorization step, including the EIP-8141 frame-transaction design.

What the local code leaves out

The demo README specifies a pinned Nethermind build and describes a minimal account, not a complete ERC-8403 implementation. Any key in its tree can change the root. Its second chain relies on a home chain with one signer, and its recent-root window is implemented by the account contract instead of EIP-8272.

The distinction between recent and current roots matters: the draft's first tier permits roots within a recency window, while its second tier checks current account state. Removing a key therefore does not make every previously accepted root disappear immediately.

The demo uses secp256k1 keys and contains no post-quantum key. The proposed extensions in the research post are separate from that local implementation. The new development is inspectable demonstration code and a research explanation, with standardization and wider deployment still unresolved.