Why Smart Account Upgradability Is a Developer's Faustian Bargain

The dominant upgrade model (e.g., EIP-1967, UUPS) uses a proxy contract to delegate logic calls. This creates a single, permanent admin key as a central point of failure.

• Critical Flaw: Compromise of the admin key allows an attacker to upgrade the logic to a malicious contract, draining all associated user assets in one transaction.
• Historical Precedent: The Parity Wallet hack ($150M+ lost) and numerous DeFi exploits stem from flawed proxy ownership management.

A timelock (e.g., Compound, Aave model) mandates a delay between upgrade proposal and execution, allowing users to exit. This trades instant agility for reaction time.

• Inherent Lag: A 24-72 hour delay is standard, crippling rapid response to critical bugs or exploits.
• False Security: Sophisticated attacks (e.g., reentrancy, logic errors) can drain funds in minutes, making a multi-day timelock irrelevant for the most dangerous threats.

Emerging L2s like StarkNet and zkSync Era deploy smart accounts with immutable core logic. Upgrades require deploying a new account and migrating state, eliminating the proxy risk entirely.

• Absolute Security: No admin key exists to hijack the core account logic.
• Developer Tax: Forces complex migration tooling and user onboarding flows, increasing friction and potentially fragmenting liquidity across account versions.

Delegating upgrade control to a DAO (e.g., Uniswap, Maker) replaces a technical key with a political process. This distributes risk but introduces new attack vectors.

• Governance Attacks: An attacker can acquire enough tokens ($50M+ for major protocols) to pass a malicious upgrade, as theorized in flash loan governance attacks.
• Decision Paralysis: Critical upgrades get bogged down in weeks of forum debates and snapshot votes, delaying essential fixes.

The ERC-6900 standard for modular smart accounts proposes a radical shift: upgrading individual modules (e.g., validation, recovery) instead of the monolithic account.

• Minimized Blast Radius: A compromised module manager doesn't grant control over the entire account's asset logic.
• Complexity Explosion: Introduces a new attack surface in the module registry and interconnection logic, requiring rigorous formal verification for each component.

Every upgradeability model is a Faustian bargain. Proxy patterns trade security for simplicity. Timelocks trade speed for reaction time. Immutable cores trade agility for safety. DAO governance trades technical risk for political risk.

• First-Principle Truth: The upgrade mechanism's security is inversely proportional to its speed and convenience.
• Strategic Imperative: Choose the model that aligns with your protocol's time-to-exploit versus time-to-response profile.

The centralized upgrade key is a single point of failure that never expires. Every deployed smart account inherits this liability, creating a permanent attack surface that outlives the original team.

• Key Risk: A compromised admin key can rug-pull or brick all user accounts in a single transaction.
• Key Liability: Users must place perpetual, blind trust in an entity that may not exist in 5 years.

In-place upgrades cannot migrate on-chain state, forcing a choice between abandoning user data or maintaining legacy logic forever. This leads to protocol ossification.

• Key Problem: Critical fixes require deploying new account instances, stranding user assets and history in the old version.
• Key Consequence: Teams are incentivized to avoid breaking changes, locking in suboptimal or vulnerable code.

Every upgrade invalidates prior audits, requiring users to re-audit the entire system or blindly trust the diff. This breaks the trust-minimization promise of smart contracts.

• Key Issue: Auditing a complex upgrade's side-effects is often as costly as a full audit ($50k-$500k+).
• Key Result: Only well-funded projects can upgrade safely, centralizing innovation and creating a two-tier system.

ERC-4337 (Account Abstraction) sidesteps the Faustian bargain by decoupling upgrade logic from the account core. The EntryPoint and Bundler network manage execution, while user logic lives in separate, replaceable modules.

• Key Solution: Users can swap wallet providers without migrating assets, as the core account address remains static.
• Key Benefit: Security audits are scoped to individual modules, enabling incremental, lower-risk improvements.

Frameworks like the Diamond Standard promise modular upgrades but introduce profound complexity. Managing a facet registry and proxy storage shifts risks from the contract to its configuration.

• Key Risk: Upgrade logic becomes a consensus-critical protocol itself, vulnerable to governance attacks or delegate collisions.
• Key Liability: The system's security is now defined by its weakest facet, creating a sprawling attack surface difficult to audit holistically.

Ultimately, any upgrade path that isn't user-permissioned requires off-chain social consensus. This recreates the governance challenges of DAO treasuries or L1 protocol upgrades at the application layer.

• Key Problem: Users are forced to become protocol citizens, constantly monitoring for upgrade proposals that affect their assets.
• Key Consequence: The upgrade mechanism becomes a governance minimization problem, often leading to stagnation or contentious hard forks.

Most upgradeable account models rely on a single admin key, creating a centralized failure point. If compromised, an attacker can upgrade the logic to drain all user funds. This negates the core Web3 promise of user sovereignty.

• Single Point of Failure: A single key controls logic for millions of accounts.
• Irreversible Damage: A malicious upgrade can be executed in one transaction, bypassing all existing security.

The ERC-4337 standard proposes a time-lock for upgrades, forcing a delay between proposal and execution. This allows users to monitor and exit before a malicious upgrade. However, it's a social solution that fails for non-vigilant users and creates liquidity blackouts.

• Social Scalability Failure: Requires users to actively monitor upgrade proposals.
• Capital Lockup: During the delay, funds are effectively frozen, breaking DeFi composability.

The only architecturally sound model is an immutable core wallet with pluggable, user-approved modules. Think of it as a smartphone OS: the kernel is fixed, but apps can be installed/removed with explicit permission. This is the approach of Rhinestone and Eclipse.

• User Sovereignty: Each new module requires a signature from the user's current key.
• Risk Containment: A malicious module can only act within its pre-approved permissions, isolating damage.

StarkNet accounts can be upgraded via a proof that the new logic is a valid transformation of the old state, verified on-chain. This moves security from social consensus (governance/time-locks) to cryptographic guarantees. The upgrade is trustless if the proof is valid.

• Cryptographic Guarantee: State transition is proven correct, not just voted on.
• No Exit Rush: Users don't need to flee; the system's integrity is mathematically enforced.