We Migrated 50,000 Users from EOAs to Account Abstraction. Here's What Broke

ethereum_emma · March 12, 2026, 11:25am

Spoiler: Everything. Everything broke.

I’m a full-stack developer at a mid-size DeFi protocol. In Q4 2025, we decided to offer account abstraction wallets to our existing user base.

“This will be amazing for UX!” we said. “Users will love it!” we said.

Three months and six figures later, here’s the truth: AA migration is harder than launching a new protocol from scratch.

The Context

We had:

50,000 active users on EOA wallets (MetaMask, Rainbow, etc.)
$120M in TVL across lending pools and liquidity positions
Integration with 12 partner protocols
A roadmap that said “AA migration: 3 weeks”

Narrator: It was not 3 weeks.

Challenge 1: You Can’t Convert EOAs to AA

This was our first brutal realization.

We assumed: “Users will just upgrade their existing wallet to AA mode.”

Reality: You can’t convert an EOA into a smart contract wallet.

EIP-7702 (from the Pectra upgrade) helps—it lets EOAs delegate to smart contracts—but:

Still requires user action (they have to understand what’s happening)
Not all wallet providers support it yet
It’s a new standard with bugs still being discovered

For full AA benefits, users needed entirely new addresses.

Challenge 2: Migration = Moving EVERYTHING

New address means:

Transfer all tokens (costs gas)
Transfer all NFTs (more gas)
Close positions in protocols (gas + potential slippage)
Re-open positions in new wallet (more gas)
Re-do all token approvals (users have to sign dozens of transactions)
Update integrations with partner protocols

The Gas Cost Nightmare

We estimated $12 per user in gas costs.

Reality: $47 per user average (ranging from $8 to $380 depending on number of positions).

For 50,000 users: $2.35M in gas costs.

We decided to sponsor migration (because users won’t pay that). Our “UX improvement” budget just became a seven-figure expense.

The Approval Hell

Each user had to:

Approve our migration contract to move their tokens (1 signature per token type)
Confirm each position closure (1 signature per protocol)
Approve the AA wallet for new positions (more signatures)

Average user: 23 signatures during migration.

Support tickets: “Why do I have to sign so many times? I thought AA was supposed to make this easier?”

(AA does make it easier. AFTER you migrate. Getting there is hell.)

Challenge 3: Partner Protocol Integration

We thought: “We’ll just migrate users, no problem.”

Forgot about: Protocols that whitelist addresses.

Turns out 4 of our partner protocols had:

Address-based access control
Hardcoded integrations with our old contract addresses
Governance processes for updating whitelists

Migration timeline:

Week 1-2: Build migration tooling
Week 3-6: Wait for partner protocols to update their contracts
Week 7-8: Coordinate simultaneous updates
Week 9-12: Actually migrate users

Three-week estimate. Three-month reality.

Challenge 4: User Education & Support

This was the part we completely underestimated.

Most Common Support Ticket

“Where did my seed phrase go?”

AA wallets with social recovery don’t use seed phrases. We thought this was a feature.

Users thought this was a bug.

We had to explain:

What account abstraction is
How social recovery works
Why they don’t have a seed phrase anymore
What happens if our bundler goes down (we didn’t have a great answer for this one)

Support ticket volume increased 400% during migration.

The “Undo” Problem

Users who migrated and then changed their minds: “Can I go back to my old wallet?”

Answer: “Yes, but you have to migrate everything AGAIN. And pay gas AGAIN.”

This happened more than we expected. People migrated, didn’t like the new UX, wanted their old wallet back.

The Trust Issue

“Why should I trust you with social recovery?”

We’re a DeFi protocol, not a wallet provider. Users (reasonably) didn’t want us involved in their wallet recovery process.

We ended up integrating with third-party social recovery providers, which added another month to the timeline.

Challenge 5: Edge Cases Everywhere

NFTs with Transfer Restrictions

Some NFTs can’t be transferred. Migration broke for users holding these.

Protocol-Specific Positions

Some DeFi positions couldn’t be easily moved. We had to build custom migration logic for each protocol.

Tax Implications

Users asked: “Does migrating trigger taxable events?”

We’re not tax advisors. We panicked. We hired tax advisors.

Answer (in the US): “Maybe? Depends on interpretation. IRS hasn’t issued guidance.”

Users: “That’s not a helpful answer.”

Us: “We know.”

What We Learned (The Hard Way)

Lesson 1: Start with AA from Day One

If you’re launching a new protocol: Start with AA wallets.

Migrating later is 10x harder than building it right the first time.

Lesson 2: Build Address Abstraction Early

We should have used proxy patterns and address abstraction from the beginning.

Users interact with a proxy → proxy points to their actual wallet → you can swap the underlying wallet without changing the user-facing address.

We didn’t do this. Painful.

Lesson 3: Budget 3x Time and 5x Support Resources

Our estimates:

3 weeks development
2 support staff

Reality:

3 months development
6 support staff + contract consultants + tax advisors

EVERYTHING takes longer than you think.

Lesson 4: Phased Rollout Is Your Friend

We tried to migrate everyone at once. Big mistake.

Should have done:

Beta group (100 users, expect chaos, learn from it)
Early adopters (1,000 users, fix obvious issues)
General rollout (everyone else)

We learned about our biggest issues when 10,000 users were already mid-migration. Too late to fix cleanly.

The Bright Side (There Is One)

After the migration was complete:

Support tickets dropped to 50% of pre-migration levels
User satisfaction scores up 30%
Onboarding completion rate went from 35% to 88%
Gas complaints basically disappeared (sponsored transactions)

AA is genuinely better for users. Getting there is just really, really hard.

Questions for Other Devs

Has anyone successfully migrated a large user base from EOAs to AA without massive pain? What did you do differently?
What’s your bundler failover strategy? (We learned about this risk mid-migration and scrambled to add redundancy.)
Is anyone building “hybrid” wallets (EOA + AA side-by-side)? Or does that just kick the can down the road?
For new projects: Are you starting with AA from day one, or waiting for the ecosystem to mature?

If you’re planning an AA migration, learn from our mistakes. Budget 3x what you think. Expect 5x the support load. Do phased rollouts.

Or just start with AA from the beginning and save yourself the nightmare.

If anyone wants to commiserate about migration horror stories, my DMs are open. Misery loves company.

solidity_sarah · March 12, 2026, 11:25am

Emma, this is brutally honest and incredibly helpful. We’re planning an AA migration for Q2 and your post just made us reconsider our entire approach.

EIP-7702 Helps, But Doesn’t Solve Everything

You mentioned EIP-7702 as helping with migrations. Let me add some technical context on what it actually does (and doesn’t do).

What EIP-7702 Enables

EOAs can delegate execution to a smart contract address via a new transaction type. This means:

Your EOA address stays the same
The account can execute code (like an AA wallet)
You retain the private key

Huge win for migration: No new address, so no token transfers needed.

What EIP-7702 Doesn’t Solve

Still requires user action: Users have to submit an EIP-7702 delegation transaction. They need to understand what they’re doing.
Wallet support is spotty: As of March 2026, only a handful of wallets fully support it. MetaMask has partial support. Many others are still implementing.
Smart contract interactions get weird: Some protocols check if an address is an EOA (using EXTCODESIZE). After delegation, that check fails. Creates integration issues.
Gas costs still exist: The delegation transaction costs gas. Not as much as full migration, but not free.
Reversibility concerns: Can users “undo” delegation? What happens if the delegated contract has bugs?

Our Approach: Hybrid Wallets

Based on your experience, we’re building “hybrid” wallets:

EOA for legacy protocol integrations
AA smart account for new features
User sees one interface, we handle routing behind the scenes

Advantages:

No address migration needed
Backward compatible
Users can graduate to full AA when ready

Disadvantages:

Complex architecture under the hood
Confusing for users (“Why do some transactions need gas and others don’t?”)
Maintenance burden (we’re supporting two systems)

Maybe this is just kicking the can down the road, like you asked. But it feels less risky than forced migration.

Question for You

You mentioned building “address abstraction early” with proxy patterns.

Can you elaborate? Would you do:

Proxy contracts that users interact with (adds gas overhead)
DNS-like address resolution (requires ecosystem adoption)
Something else?

I’d love to avoid the migration nightmare you experienced, but I’m not sure what the right architectural pattern is.

product_manager_alex · March 12, 2026, 11:25am

Emma, I’m reading this as a PM who just put “AA integration” on our Q2 roadmap, and I’m breaking out in a cold sweat.

The Estimate Problem

Your “3 weeks estimated, 3 months actual” timeline is painfully familiar.

As a product manager, I’ve learned: Developer estimates for new technology are always optimistic by 3-5x.

Not because developers are bad at estimating. Because:

Unknown unknowns (you don’t know what you don’t know)
Integration complexity (everything talks to everything else)
Edge cases (the long tail is LONG)
Support burden (nobody budgets enough support time)

Our Original Plan

Week 1-2: Integration development
Week 3: Testing
Week 4: Rollout
Done!

Revised Plan After Reading This

Month 1: Research and architecture (learn from others’ mistakes)
Month 2-3: Build and internal testing (expect things to break)
Month 4: Beta rollout (100 users, assume chaos)
Month 5: Address beta feedback (there will be surprises)
Month 6: Phased general rollout (1K → 10K → everyone)

From 4 weeks to 6 months. This is going to be a fun conversation with stakeholders.

The Support Cost Nobody Budgets

Your “400% increase in support tickets” stat is terrifying.

We have 2 support staff for 30,000 users. If we see a 4x increase:

8 support staff needed during migration
Training time for new staff (they need to understand AA deeply)
Escalation to engineering (complex technical issues)

Support cost for a 3-month migration: $180K (6 additional staff for 3 months).

Our budget for “AA integration”: $50K.

We were off by… checks notes… 360%.

Lessons for Product Planning

1. Stop Calling It a “Feature”

AA migration isn’t a feature. It’s a platform migration.

Treat it like:

Migrating from monolith to microservices
Changing database systems
Replatforming an e-commerce site

Massive, risky, expensive, high-touch.

2. Phased Rollout Is Non-Negotiable

Beta → Early Adopters → General → Laggards

Expect to learn critical issues at each phase. Build in time to fix between phases.

3. Communication Plan Is As Important As Technical Plan

Users need to know:

What’s changing and why
What they need to do
What could go wrong
How to get help

We were planning a blog post. We need: email campaign, in-app notifications, video tutorials, FAQ, dedicated support channel.

4. Measure Success Correctly

“Migration complete” is not success.

Success is:

X% of users migrated
Support ticket volume back to baseline
User satisfaction maintained or improved
No major incidents

My Revised Roadmap

Q2 2026: Research, architecture, vendor selection
Q3 2026: Build, internal testing, beta program
Q4 2026: Phased rollout
Q1 2027: Completion and optimization

From “ship in Q2” to “complete by Q1 2027”.

Going to be a fun stakeholder meeting.

Questions for Emma

If you could go back, would you delay migration until ecosystem matured more? Or was it worth doing despite the pain?
What metrics did you use to decide migration was “done”?
Any mistakes you made that we should specifically avoid?

Thank you for this brutally honest post. You probably just saved us from a disaster.

web3_wallet_will · March 12, 2026, 11:25am

Emma, reading this from a wallet infrastructure perspective—your pain is real, and it’s why we decided to build hybrid wallets from the start.

The Hybrid Wallet Approach

You asked if hybrid wallets just kick the can down the road. Here’s why I think they’re actually the right long-term solution:

Architecture

EOA layer: User retains a traditional private key and seed phrase
AA layer: Smart contract wallet with social recovery, gas abstraction, etc.
Routing logic: Transactions automatically route to the right layer based on context

When We Use EOA

Legacy protocol integrations (especially ones that whitelist addresses)
When users explicitly want traditional wallet behavior
Fallback when AA infrastructure has issues

When We Use AA

New protocols that support smart wallets
Transactions that benefit from gas abstraction
Multi-sig or complex authorization flows

Why This Works

No forced migration: Users keep their existing addresses and can access AA features when they want
Backward compatible: Works with everything that expects EOAs
Future-proof: As ecosystem matures, we can route more through AA layer
User choice: Power users can stick with EOA, newcomers can use AA

The Complexity Trade-Off

You’re right that it’s complex under the hood. But:

User doesn’t see the complexity: They have one wallet, one interface
We handle the hard parts: Routing, failover, gas management
Worth it for smooth UX: No migration nightmare, no forced address changes

Is This Kicking the Can Down the Road?

Maybe. But I think of it as:

Short term: Hybrid gives us AA benefits without migration pain
Medium term: Ecosystem matures, more stuff routes to AA layer
Long term: Eventually AA becomes default, EOA is just for legacy edge cases

The alternative—forced migration—creates too much user friction and risk.

Our Stats After 6 Months

We’ve had hybrid wallets in production for 6 months:

85% of new transactions route through AA layer
15% still use EOA (mostly legacy protocol integrations)
Zero migration-related support tickets (because there was no migration)
User satisfaction with AA features: 88%

Not perfect, but way smoother than migrating 50K users.

Question for Emma

You mentioned wishing you’d built address abstraction early. Would a hybrid wallet architecture have solved your problem? Or are there issues with that approach I’m not seeing?