A Decade of Ethereum Wallet UX: The History of Account Abstraction (1)

Hi, I’m Junghyun Colin Kim, CEO of BaeRae. In this blog, I write about blockchain, wallets, and how the financial infrastructure we live in is being shaped and transformed — from my own perspective. You can find more posts on blockchain, wallets, and the structural changes in digital assets at https://baerae.substack.com.

This is the first of a two-part series on Account Abstraction (AA).

Don’t worry if the term is unfamiliar.

The story really comes down to one question:

What have Ethereum developers been trying to fix for the past decade — and why has it taken this long?

Why Is the Wallet Still So Painful?

Anyone who’s tried Ethereum for the first time runs into the same walls.

You need to write down 12–24 seed phrase words just to create a wallet. Lose them, and your assets are gone forever. Every transaction requires ETH for gas. Even a simple DeFi swap can demand multiple signatures.

For experienced users, this is second nature. For everyone else, the barrier is simply too high.

The root of the problem lies in Ethereum’s account structure.

Ethereum has two types of accounts. One is the EOA (Externally Owned Account) — a regular wallet controlled by a private key. The other is a smart contract account — an account that runs on code.

The problem is the EOA.

EOAs are hardcoded to use only one signature scheme: ECDSA. Gas must be paid in ETH. Signing authority is locked to a single key. Social recovery, multisig, gas sponsorship — none of these are possible by default.

Account Abstraction means making these rigid EOA rules flexible.

Free choice of signature scheme. Decoupled gas payments. Programmable account logic.

A goal that sounds simple enough. So why did it take ten years?

2016: The First Knock — EIP-86

The first formal attempt to address this was made by Vitalik in 2016.

EIP-86 had a straightforward idea: separate signature verification and nonce handling from the protocol itself. If users could define their own “account contracts” with custom signature schemes and security models, wallets could become far more flexible.

The direction was right.

But the proposal went nowhere.

It required changes to Ethereum’s consensus layer — the core of the protocol. At the time, the development team was extremely cautious about touching the consensus layer. Other critical upgrades were in the queue, and EIP-86 was shelved with a verdict of “good idea, but not now.”

2020: Two More Attempts, Two More Dead Ends

Years passed, and the same problem resurfaced.

EIP-2938 proposed a new transaction type called AA_TX_TYPE. It was a thoughtful design, distinguishing between single-tenant AA for individual wallets and multi-tenant AA for DeFi applications.

But it still required consensus layer changes. Same conclusion.

Then came EIP-3074. This one took a slightly different angle — touch the consensus layer, but only minimally. It proposed adding two new EVM opcodes, AUTH and AUTHCALL, allowing EOAs to delegate transaction execution to smart contracts.

Transaction sponsorship, batch execution, gas abstraction — the features everyone wanted were finally within reach.

But adding new opcodes still meant a hard fork. Every client had to agree and upgrade. Security concerns were significant too: a malicious invoker contract could drain a user’s entire account if delegation went wrong.

EIP-3074 stalled as well.

Three attempts from 2016 to 2020. All stopped at the same wall.

Changing the consensus layer is too hard.

I have some personal history with this problem. At Klaytn, where I worked, we took a different path and built key update functionality directly into the protocol core. While Ethereum was hesitating on consensus layer changes, we just went ahead and did it — our own way. I even had the opportunity to present this work at Devcon 2019. But the feature never saw wide adoption across services and remained a well-intentioned experiment. Maybe the timing was off..? Still, having built this, shipped it in a real product, and used it firsthand — that experience connects directly to what we’re building with ZKAP today.

2021: Finding a Different Path — ERC-4337

So — could AA be implemented without touching the consensus layer at all?

The answer Vitalik and co-developers published in 2021 was ERC-4337.

It was a fundamental shift in thinking. Instead of changing the protocol, build a new infrastructure layer on top of it.

Here’s how it works.

Instead of a regular transaction, a user creates a UserOperation — an object that encodes their intended action. UserOperations go into a separate alt mempool, not the standard one. A new class of participants called Bundlers package multiple UserOperations into a single standard transaction and submit it to the network. An on-chain EntryPoint contract handles validation and execution.

Need gas sponsorship? Attach a Paymaster contract. A service can cover gas on behalf of users, or let them pay in ERC-20 tokens like USDC instead of ETH.

Not a single line of the consensus layer was changed.

AA — built entirely out of smart contracts.

In March 2023, the EntryPoint contract was deployed to Ethereum mainnet. In the two years since, over 40 million smart accounts have been created and more than 100 million UserOperations processed.

After five years of trying, a working answer had finally arrived.

Why Did It Take This Long?

Looking at ERC-4337’s arrival, one pattern becomes clear.

The direction was right from the beginning. EIP-86’s problem statement in 2016 is nearly identical to what ERC-4337 solves. What changed was the approach.

Every attempt that tried to modify the protocol hit a wall. Consensus layer changes require unanimous agreement from all clients, take years to validate, and are almost impossible to reverse if something goes wrong.

ERC-4337 succeeded for a simple reason.

It didn’t depend on the protocol.

Smart contracts are deployable on day one. No client agreement needed. Fast to experiment with, easy to iterate.

That said, the architecture is far from perfect. It depends on external Bundler infrastructure. The EntryPoint becomes a single point of trust. Gas costs are higher than standard transactions. Existing EOA users still have to manage two accounts.

So the story doesn’t end here.

What’s Next

ERC-4337 made Account Abstraction real — without touching the consensus layer.

But developers didn’t stop there.

How did the modular smart account standards get resolved? Can EOAs be transformed into smart accounts entirely? And how is Ethereum finally completing AA at the protocol level?

In the next post, I’ll walk through the standards that emerged from 2023 onward — ERC-7579, EIP-7702, EIP-7701, and all the way to EIP-8141.

This evolution connects directly to what we’re building at ZKAP. Passkey-based self-custodial wallets became possible on top of the smart account infrastructure that ERC-4337 created. I’ll tie that thread together in Part 2.

For more on blockchain, wallets, and the structural shifts in digital assets, visit https://baerae.substack.com. If you’d like to talk further or explore a collaboration, feel free to reach out anytime for a coffee chat — X, Telegram, or LinkedIn.