The promise of Account Abstraction sounded revolutionary: crypto wallets with the UX of Venmo, no more seed phrase anxiety, gasless transactions that “just work.” Since ERC-4337 launched in March 2023, over 40 million smart contract wallets have been deployed across Ethereum and L2 networks—nearly 20 million in 2024 alone. The ecosystem celebrated this as the breakthrough that would finally bring crypto to the masses.
But there’s a critical detail buried in the technical specifications that most users never see: most AA wallets are upgradeable via proxy patterns. This means the wallet’s logic can be changed post-deployment—usually by a multisig or DAO that controls the upgrade mechanism.
The OWASP 2026 Warning Signal
OWASP’s Smart Contract Top 10: 2026 just added “Proxy & Upgradeability” as the #10 vulnerability category, documenting $905 million lost across 122 incidents in 2025. The report explicitly calls out re-initialization attacks and storage slot collisions in upgradeable contracts.
When I audit AA wallet implementations, I now ask three questions that most users never consider:
-
Who controls the upgrade keys? Is it a 3-of-5 multisig? A DAO with unknown token distribution? The wallet provider’s internal team?
-
What’s the upgrade timelock? Can changes be pushed instantly, or is there a 48-hour window where users could withdraw funds if they detect a malicious upgrade?
-
Is there an immutable option? Can users opt for a non-upgradeable wallet deployment if they’re willing to trade convenience for true self-custody?
The Uncomfortable Question
Here’s the philosophical paradox: If a group of strangers (even well-intentioned ones) can modify your wallet’s code via an upgrade transaction, are you really holding your own keys? Or have we just recreated traditional banking’s trust model with extra steps and higher gas fees?
I’m not saying upgradeability is inherently malicious. Bug fixes and security patches are legitimate use cases—we’ve seen critical vulnerabilities discovered post-deployment that required emergency upgrades. But the smart contract security community has learned (the hard way, to the tune of billions in exploits) that every privilege is a potential attack vector.
Real Attack Scenarios
Let me walk through three realistic scenarios that keep me up at night:
Scenario 1: Governance Capture
A DAO controls the upgrade multisig. An attacker accumulates governance tokens, proposes an “optimization” upgrade, and gets it passed during a holiday weekend when participation is low. The upgrade contains a hidden function that drains all wallets to the attacker’s address. By the time anyone notices, it’s too late.
Scenario 2: Insider Threat
The wallet provider’s upgrade multisig is compromised—either through social engineering, a disgruntled employee, or a supply chain attack on the hardware wallets holding the keys. The attackers push a malicious upgrade disguised as a “gas optimization patch.”
Scenario 3: Accidental Bricking
The development team discovers a critical security vulnerability and rushes to deploy a fix. Due to a storage layout error (remember those storage slot collisions?), the upgrade inadvertently corrupts wallet state for 30% of users, making their funds permanently inaccessible.
What We Should Demand
The AA ecosystem needs to mature beyond “trust us, we’re the good guys”:
- Mandatory transparency: Every AA wallet should clearly disclose its upgrade mechanism in the UI, not buried in documentation
- Immutable options: Providers should offer immutable wallet deployments for users who prioritize security over convenience
- Upgrade notifications: Users must be notified before upgrades execute, with clear explanations of changes
- Time-locked upgrades: Minimum 48-72 hour timelocks should be standard, giving users time to exit if they disagree with changes
- Formal verification: Upgrade logic should undergo formal verification to prevent storage corruption and privilege escalation
The Bigger Picture
I’m a huge proponent of improving crypto UX. Seed phrases are genuinely terrible for mass adoption. But we can’t solve UX problems by recreating the trust assumptions we’re trying to escape.
ERC-4337 and Account Abstraction represent genuine innovation. But the current implementation path—defaulting to upgradeable proxies with opaque governance—feels like we’re trading “not your keys, not your coins” for “not your upgrade keys, not really your wallet.”
Security is not a feature we can patch in later. It’s an architectural decision we make at the foundation. And right now, the foundation of most AA wallets includes a trapdoor with a key held by others.
Trust but verify, then verify again.
What are your thoughts? Am I being overly paranoid, or is the upgradeable wallet model a fundamental compromise of self-custody principles?
Upgrade multisig signers are anonymous
Named, doxxed multisig signers with reputation at stake
Level 3 Upgrade Transparency” to help users make informed decisions.