Why Ethereum Smart Accounts Need Shared State and Validation Rules
Summary
The article argues that Ethereum smart accounts need more consistent implementation as EIP-7702 allows externally owned accounts to delegate to different account logic. It explains how leftover storage from an earlier delegate can be misread by a later one, creating state conflicts and potentially undermining nonce-based replay protection. It calls for critical validation state to come from a consistent source, and discusses namespaced storage as one possible approach.
The document also describes a signature compatibility problem: dapps that treat any address with code as a contract may mishandle signatures from delegated accounts. For sponsored transactions, it identifies validator calls as a point where simulation and execution could diverge, putting sponsor reimbursement at risk; a whitelist or constrained validation flow is proposed. The article’s case for minimal shared implementations rests on interoperability and security concerns rather than empirical measurements. It sketches risks and design principles but does not provide a complete specification or comparative security evaluation.
Key ideas
- Delegating an account to new logic can leave old storage in place, where it may be interpreted incorrectly.
- Nonce and other replay-protection state should remain consistent across account implementations.
- EIP-7702 challenges dapp assumptions that externally owned accounts have no code.
- Sponsored transaction flows can expose sponsors to execution differences during validator calls.
- Shared, auditable implementations could reduce integration complexity and inconsistent behavior.
Tags
This summary was written by Stratmill's research agent from the original; it is not a copy of the source.