Wallets: Past, Present & Future

Main Paper

WPRC YYZ [1] Wallets: Past, Present & Future - Elliot Friedman (Kleidi), Darren (WPRC)                                        08 Mar 2026

Account Abstraction (AA) and smart contract accounts are currently a second class citizen on Ethereum, which has led to a tangle of competing standards and poor user and developer experience. EIP-8141 fixes this by creating a new frame transaction that allows true AA wallets.

(i) Validation logic becomes programmable at protocol-level to enable account modularity, reducing single points of failure. (ii) Accounts can swap validation logic, giving every Ethereum user a credible upgrade path as cryptographic standards evolve. (iii) One address and identity that has full native smart wallet capabilities, eliminating the need to maintain parallel accounts or try and force accounts and EOAs together. (iv) Improved user and developer experience as account abstraction and smart accounts become first class citizens.

EIP-8141 introduces "frame transactions," a transaction type that bundles up to 1,000 composable execution frames, each with its own mode (DEFAULT, VERIFY, or SENDER). This proposed technical upgrade aims to gradually render the ERC-4337 infrastructure obsolete, where smart accounts once had to route through a parallel alt-mempool, a singleton EntryPoint contract, and third-party bundlers to initiate a transaction. Using this new framework, validation logic becomes fully programmable at the protocol level. An account initiating a large transfer can require 2-of-3 signatures while allowing single-signer authorization for smaller ones. This upgrade also opens a migration pathway away from ECDSA entirely, which will matter greatly when quantum computing eventually threatens the current signature scheme.

(i) Protocol Developers (Vitalik, Weiss, etc.): Want to build protocols that eliminate EOA infrastructure limitations, building better standards than EIP-4337 while maintaining backward compatibility during the transition to native account abstraction wallets as the de facto way to transact on Ethereum. (ii) Wallet Users: Want security without single points of failure, they benefit from account-level policies such as rate limiting, credit delegation, conditional multisig, MFA, biometric authentication, and modular social recovery enforced at the protocol level. (iii) Smart Contracts Platforms (Safe, etc.): Want to retain retail and institutional clients by remaining the leading trusted digital asset manager as they benefit from 8141’s modular validation that treats smart contract accounts like “first-class citizens,” providing cost-effectiveness & reliability. (iv) 4337 Operators (Coinbase Cloud, Pimlico, etc.): Want to maintain bundler and paymaster revenue that has been built atop 4337 infrastructure. While they still benefit from the gradual transition timeline towards 8141, the elimination of the alt-mempool makes much of their core business transitory.

The Beginning of Ethereum: Ethereum, which launched in 2015, used a rigid two-account model, Externally Owned Accounts (EOA), which was controlled by a singular ECDSA private key and Contract Accounts, which was defined by code but was unable to initiate transactions. The EOA structure meant that if the ECDSA private key was lost or compromised, so was your account. Despite Ethereum recognising this, fixing it at the protocol level required consensus changes that could not be shipped safely before launch. Constraints & Workarounds: Over the following decade, workarounds have been built around this constraint. Gnosis Safe and ERC-4337 created a parallel custody infrastructure enabling multisigs and smart accounts. Though they were contract accounts, transactions to these wallets still required an EOA to bundle and submit. EIP-7702 improved on this by letting EOAs attach contract code to their wallet, but left the underlying private key problem unsolved. RIP-7212 then enabled elliptic curve cryptography using P-256 signature verification, which cut gas cost for biometric authentication, making passkey-based wallets viable. Future Threats: With the advent of quantum computing, ECDSA’s viability as the protocol’s sole signature scheme faces existential threat. If ECDSA is broken, every EOA will then be compromised without any mechanism to switch to a quantum-resistant alternative without moving assets entirely.

(i) Expressiveness vs. Misconfiguration - Native AA gives users programmable validation logic which allows transactions to be more customisable and secure but means more area for user misconfiguration and exploitation. (ii) Migration Speed vs. Ecosystem Stability— Moving to 8141 cleans up the technical debt from ERC-4337 but with millions of deployed accounts, a fast turnover will lead to risks of system instability, while a slow turnover will mean that parallel systems must maintain indefinitely.

ERC-4337 Mechanism: Rather than modifying Ethereum protocol, ERC-4337 built a transaction pipeline that allowed users to submit UserOperations (intent to execute a transaction)  to a separate alt-mempool. Within the mempool marketplace, third-party bundlers pick up the UserOperations, behaving like miners where they aim to maximise their revenue per unit of gas consumed. Bundlers pick “intents” up, aggregate them, and submit a single transaction to the Ethereum mempool on behalf of users. This transaction then calls a Global EntryPoint Contract, which validates and executes each UserOperation in sequence. Paymasters can then sponsor gas by depositing ETH into the EntryPoint's escrow to easily onboard new individuals. UserOperation: Each UserOperation specifies a maxFeePerGas and maxPriorityFeePer Gas, where the bundler will rely on its metric (total earnings after paying the base fee for inclusion into the blockchain) to select the order of transactions with constraints. Paymasters: Critical to the infrastructure for onboarding users into Ethereum. To perform actions on the Ethereum network, a user requires ETH as payment for gas fees. Yet, acquiring ETH, an action, already requires the user to be on the network, creating a blockage of access for new users. Paymasters sponsor gas on behalf of these users for user acquisition, retention and engagement within the application. However, given that 87% of UserOperations are sponsored, this infrastructure has become a gasless signup mechanism for consumer applications.

EIP-7702 Mechanism: Building upon 4337, which gave smart contracts the ability to initiate transactions, the system remained parallel whereby users who wanted to access smart account features had to migrate their assets to a new wallet, acting as a significant barrier to adoption. EIP-7702 resolves this by directly bringing smart account capabilities to existing EOAs without asset migration. When a user signs a 7702 authorisation, they produce a signature which authorises a smart contract address to write a pointer into the EOA’s code field during a transaction, which contains the chain ID, delegate contract address, and a nonce to track transactions. This Type 4 transaction inherits the logic and can execute multiple operations in a single transaction. Connection to 4337: An authorised EOA can submit UserOperations directly through the bundler infrastructure, which means that the infrastructure now also serves as an ecosystem for all EOA populations rather than having to deploy a smart contract wallet from scratch. However, 7702 does not replace the EOA model, instead the original ECDSA private key still has full-access regardless of the enforced contract. This meant that transactions were still at risk of being compromised. Usability and tradeoffs: using a 7702 wallet requires signing a transaction to attach bytecode to the EOA, which means users must sign a transaction to enable this functionality.

RIP-7212 Mechanism: 7212 addressed an entirely different constraint, the signature curve itself. Authentication mechanisms used by every smartphone and laptop on the planet rely on the P-256 elliptic curve, denoted by secp256r1. However, Ethereum’s EOA operates on a completely separate curve, secp256k1. Despite the seemingly minute shift, the lack of a native precompile for this cryptography means verifying P-256 signatures in Solidity costs 200,000 gas, making a password or passkey-based authentication expensive. RIP-7212 resolved this by deploying a native secp256r1 precompile across all major L2s to cut verification cost to 3,450 gas, by about 58x. secp256r1 vs secp256k1: In mathematics, these are the two most common elliptic curves, “r” stands for random, while “k” stands for Koblitz. Although random seems more secure, the preference for secp256r1 stemmed from a specific conspiratorial concern, that the NSA, operating through NIST, may have deliberately engineered a backdoor via its pseudo-random number generator. Because the curve parameters in secp256r1 are pseudo-randomised rather than derived from a transparent, verifiable process, a weak curve could theoretically be constructed and exploited by whoever controlled the random seed without any detection.

EIP-8141 Mechanism: Every system covered so far has been built around a singular constraint, where the EOA and its ECDSA private key build the foundation for each Ethereum account, and the protocol treats the key as the only authority. Introducing frame transactions, EIP-8141 is a new EIP-2718 transaction type composed of up to 1,000 frames that operate in one of three modes, default, verify, and sender. DEFAULT handles standard execution equivalent to a normal transaction. VERIFY runs validation logic directly at the protocol level. If it fails, the transaction is rejected by Ethereum itself, not by a smart contract layer sitting on top of it. SENDER designates which entity is authorising the frame. Together, these three modes eliminate the requirement for bundlers, alt-mempool, EntryPoint contract and paymaster that was required for 4337. EIP-2718: The envelope standard that allows frame transactions to exist. Initially, every Ethereum transaction had a fixed structure and would not be delivered if transactions did not fit the specified template. EIP-2718 introduced typed transactions, where a single leading byte identifies the transaction type, and the remaining bytes follow the format that type requires. This allows EIP-8141 to introduce fundamentally different transaction structures without breaking existing wallets that know how to parse through current Ethereum transaction types. Without EIP-2718, EIP-8141 would have no way of informing Ethereum nodes that a transaction should be read differently from prior transactions.

Vitalik Buterin (Ethereum Foundation) — Co-founder; chief researcher; Thiel Fellow '14. Wrote the 2013 whitepaper; deployed mainnet 2015; has steered every major protocol shift for PoS, rollup-centric roadmap, EIP-4844, native AA.  Matt Garnett (Ethereum Foundation) — Execution layer dev (@lightclient); EF "Improve UX" co-lead 2026; ex-ConsenSys Quilt research; UCLA. Co-authored EIP-7685 (EL request formats), EIP-7002 (execution-triggered validator exits); co-founded ETHMagicians. Felix Lange (Ethereum Foundation) — Geth core dev (@fjl); original architect of go-ethereum's p2p networking layer. Owns RLP encoding, devp2p, freezer storage, and fork plumbing across every major hard fork. Yoav Weiss (Ethereum Foundation) — Security fellow; ex-Check Point, founder MobileSpaces (acq. Pulse Secure), co-founder TabooKey/OpenGSN. Took ERC-4337 from spec to audited mainnet at WalletCon 2023; now driving the Ethereum Interop Layer (EIL). Alex Forshtat (eth-infinitism) — AA core dev; ex-TabooKey/OpenGSN alongside Yoav and Dror. Co-authored ERC-4337, RIP-7560, EIP-7701; built the reference EntryPoint contract, bundler, and spec test suite. Dror Tirosh (eth-infinitism) — Co-founder TabooKey; co-authored ERC-4337, EIP-1613 (Gas Stations Network), and the native AA suite. Leads bundler and relay implementation; the longest-running hand in meta-transaction and gasless infrastructure on Ethereum. Shahaf Nacson (eth-infinitism) — AA core dev; co-authored ERC-4337, RIP-7560, EIP-7701, ERC-7562 (bundler DoS protection). Focused on mempool-level security and validation scope rules that make decentralized bundling viable at scale.

EIP-8141 represents the end of a decade-long architectural negotiation between what Ethereum promised and what its previous account models could deliver. Frame transactions do not merely patch the limitations of EOAs, they dissolve existing constraints entirely, replacing a fixed-key authentication model with fully programmable validation logic enforced at the protocol layer enabling MFA, YubiKeys and biometric authentication. The downstream implications are substantial: wallet tooling is greatly simplified, privacy protocols gain a native mempool path without public broadcasters, quantum-resistant signature schemes become an in-place upgrade path rather than an asset-migration exercise and atomic multi-operation transactions collapse what once required multiple signatures into a single operation. For developers, the removal of bundlers, EntryPoint contracts, and alt-mempool dependencies eliminates the most significant points of operational and counterparty risk in the current smart account stack. For end users, the result is a wallet experience indistinguishable from the Web2 authentication surfaces they already trust with passkeys, biometrics, multi-device access, all without sacrificing the self-sovereign guarantees that make Ethereum worth using. When the Hegota fork lands, the infrastructure  will be in place to support the next generation of users.

1. EIP-8141 — Frame Transactions (full specification) https://eips.ethereum.org/EIPS/eip-8141
2. Vitalik Buterin — Account abstraction, frame transactions, and the Hegota fork timeline https://x.com/VitalikButerin/status/2027774090627715377
3. Vitalik Buterin — Quantum-resistant signature efficiency (Firefly) https://firefly.social/post/lens/1gfeyxjzsajqk845t3h
4. EIP-7997 — Deterministic factory predeploy (cross-chain address consistency) https://ethereum-magicians.org/t/eip-7997-deterministic-factory-predeploy/24998
5. EIP-86 — The original account abstraction proposal (2016) https://github.com/ethereum/EIPs/issues/86
6. ERC-4337 — Account abstraction without protocol changes https://eips.ethereum.org/EIPS/eip-4337
7. EIP-7702 — EOA delegation for a single transaction https://eips.ethereum.org/EIPS/eip-7702
8. RIP-7712 — 2D nonces for parallel transaction flows https://docs.erc4337.io/core-standards/rip-7712.html
9. EIP-2718 — Typed transaction envelope standard (the foundation that makes frame transactions possible) https://eips.ethereum.org/EIPS/eip-2718
10. FOCIL — Fork-choice enforced inclusion lists (guarantees frame txs can't be censored) https://eips.ethereum.org/EIPS/eip-7805
11. Ethereum Foundation — Wallet security and AA research hub https://ethereum.org/en/roadmap/account-abstraction

EIP-8141 spec is still in active development and the linked Vitalik posts represent the most current thinking on implementation scope and timeline. The specification will evolve before the Hegota fork.