Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
Free 30-min Web3 Consultation
Book Consultation
Smart Contract Security Audits
View Audit Services
Custom DeFi Protocol Development
Explore DeFi
Full-Stack Web3 dApp Development
View App Services
wallet-wars-smart-accounts-vs-embedded-wallets
Blog

Why Your Smart Account Factory Is Your Biggest Attack Surface

A technical analysis of how the centralized factory contract in ERC-4337 and modular account architectures creates a single point of failure, capable of compromising every user account it deploys.

introduction
THE VECTOR

Introduction

Smart account factories are the most critical and vulnerable component in the account abstraction stack.

Factory logic is unchangeable. The factory contract's createAccount function defines the deterministic address and initial state for every deployed smart account. A bug here compromises every future user.

Deployer keys are high-value targets. Factory ownership or admin keys, like those managed by Safe{Wallet} or Biconomy, control upgrade paths and fee logic. A single breach bricks an entire ecosystem.

Counterfactual addresses create false security. Users assume safety because their wallet isn't deployed, but the ERC-4337 entry point can force-deploy it through a malicious factory, pre-funding attacks.

Evidence: The Polygon zkEVM incident where a compromised proxy admin key threatened 173M USD demonstrated the systemic risk of centralized upgrade control in foundational infrastructure.

thesis-statement
THE FACTORY FLAW

The Centralized Bottleneck of Decentralization

The smart account factory contract, a single point of failure, undermines the decentralized security model of the entire account abstraction stack.

The factory is the root of trust. Every ERC-4337 or ERC-6900 smart account originates from a factory contract. This contract holds the logic to deploy and initialize accounts, making it a single point of compromise for all accounts it creates.

Upgradeability creates systemic risk. Most factories use proxy patterns for upgradability, controlled by a multisig or DAO. A breach of these admin keys allows an attacker to deploy malicious logic to every user's account in a single transaction.

Counter-intuitively, decentralization fails at the edges. While the bundler and paymaster networks are permissionless, the factory remains a centralized chokepoint. This mirrors the security failure of early multi-sigs where the factory was the exploit vector.

Evidence: The Biconomy and ZeroDev smart account factories are upgradeable via multisigs. A compromise would affect hundreds of thousands of accounts instantly, a risk profile similar to a bridge hack on LayerZero or Wormhole.

ARCHITECTURAL VULNERABILITY

Factory Risk Assessment: Major Smart Account Providers

Compares the security and decentralization posture of the core factory contracts for leading ERC-4337 and smart account implementations. A compromised factory is a single point of failure for all deployed accounts.

Risk Vector / FeatureSafe{Core} ProtocolZeroDev KernelBiconomy Smart AccountAlchemy Account Kit (ERC-4337)

Factory Upgradeability Model

Fully immutable (v1.4.1)

Transparent Proxy (Owner-controlled)

UUPS Proxy (Admin-controlled)

Minimal Proxy (Non-upgradeable)

Factory Admin Key Risk

None (immutable)

Single EOA (High Risk)

Multi-sig (4/7 Gnosis Safe)

Bundler whitelist (Alchemy)

EntryPoint Version Pinning

v0.6 (Immutable)

Configurable by admin

Configurable by admin

v0.6 (Immutable via bundler)

Account Creation Cost (Gas, Approx.)

~450k gas

~250k gas

~300k gas

~200k gas

On-chain Verification (e.g., Etherscan)

Full source-verified, deterministic

Proxy, verification required

Proxy, verification required

Minimal proxy, verification required

Factory Deployment Security Audit

4+ major audits (OpenZeppelin, etc.)

1 audit (Spearbit)

2 audits (Quantstamp, Peckshield)

Audit pending (Q3 2024)

Default Guardian/Recovery Setup

Multi-sig or module required

Social recovery module (optional)

Embedded EOA guardian

Not applicable (wallet-defined)

deep-dive
THE SINGLE POINT OF FAILURE

Anatomy of a Factory Poisoning Attack

A compromised smart account factory grants attackers a universal backdoor to all accounts it creates.

Factory is the root of trust. Every smart account inherits its logic and upgrade keys from the factory contract that deployed it. This creates a centralized dependency that defeats the purpose of a decentralized wallet.

Poisoning is a supply chain attack. An attacker who compromises the factory's admin keys or exploits a logic flaw can push a malicious implementation to all existing and future user accounts. This is not a hypothetical risk; it's the dominant attack vector for account abstraction.

Counter-intuitively, complexity kills security. Factories from Safe{Wallet} and ZeroDev bundles introduce intricate proxy patterns and module systems. Each new feature, like ERC-4337 entry points or gas sponsorship, expands the attack surface for poisoning.

Evidence: The 2023 Safe{Wallet} governance attack demonstrated this. A malicious proposal sought to upgrade the core singleton, which would have affected all ~4M Safe wallets instantly. The factory's centralized upgrade mechanism was the critical vulnerability.

counter-argument
THE TRUST TRAP

The Counter-Argument: "But We Need Upgradability!"

Upgradability in smart account systems creates a centralized trust vector that negates the core value proposition of self-custody.

The factory is the admin key. A smart account's upgrade logic resides in its factory contract. This makes the factory owner a centralized admin for every deployed account, creating a single point of failure for the entire user base.

Upgrades break user sovereignty. The promise of self-custody is nullified if a third party can unilaterally change the account's logic. This is not an upgrade; it's a trusted proxy model that users explicitly reject in wallet design.

Modularity beats monoliths. The ERC-4337 standard solves this by separating core validation from feature logic. New functionality is added via modular bundlers and paymasters, not by rewriting the core account contract. This is the Safe{Core} protocol model.

Evidence: The Polygon zkEVM incident (March 2024) demonstrated the risk, where a critical bug in a proxy upgrade mechanism forced a time-sensitive emergency upgrade, putting billions at risk due to a centralized admin key.

risk-analysis
SINGLE POINT OF CATASTROPHIC FAILURE

The Bear Case: What Happens When a Factory is Compromised?

A smart account factory is a centralized attack vector that, if breached, can compromise every account it ever created.

01

The Atomic Bomb: A Single Private Key Can Drain Millions

Unlike a compromised EOA, a hacked factory owner key can upgrade or drain all deployed smart accounts in a single transaction. This creates systemic risk proportional to the factory's adoption, not individual user error.

  • Impact: Mass asset seizure across all user accounts.
  • Scale: A factory with 1M+ accounts becomes a $1B+ honeypot.
  • Precedent: Proxy admin key compromises have led to nine-figure losses in DeFi.
1 Tx
To Drain All
>1M
Accounts At Risk
02

The Upgrade Trap: Malicious Logic Becomes Canon

A factory often controls the upgrade logic for its accounts. A malicious upgrade can introduce backdoors, fee siphons, or logic that bricks accounts, turning infrastructure into a weapon.

  • Permanence: Once upgraded, malicious logic is irreversible for users.
  • Stealth: Exploits can be time-locked or conditional, evading initial detection.
  • Trust Assumption: Users implicitly trust the factory's multisig/DAO, which is a political & technical vulnerability.
0-Day
Backdoor Risk
Irreversible
Once Live
03

The Dependency Collapse: Breaking the Entire Account Abstraction Stack

Factories are core infrastructure. A compromise doesn't just steal funds; it destroys the utility layer. Paymasters, bundlers, and indexers that rely on the factory's integrity will fail, causing a cascading failure across the AA ecosystem.

  • Network Effect: Breach invalidates sessions, subscriptions, and gas sponsorship for all users.
  • Reputation Damage: Erodes trust in ERC-4337 and smart accounts as a category.
  • Recovery: User migration is a logistical nightmare, requiring new signatures for all assets and permissions.
4337
Stack Failure
Cascading
Service Crash
04

Solution: Immutable Factories & Decentralized Governance

The only viable long-term solution is to remove the upgrade key. This requires immutable factory logic or decentralized, time-locked governance (e.g., a 30-day timelock DAO).

  • Best Practice: Treat the factory like a Layer 1 protocol—no admin key.
  • Fallback: Use social recovery modules (like Safe{Wallet}) at the account level, independent of factory control.
  • Verification: Demand formal verification of factory code before integration.
0
Admin Keys
30-Day
Min Timelock
future-outlook
THE VULNERABILITY

The Path Forward: From Centralized Factories to Verifiable Deployment

Centralized smart account factories create a single point of failure that undermines the entire promise of account abstraction.

The factory is the root of trust. A centralized smart account deployment contract holds the keys to every user's account logic. A compromise here means an attacker can upgrade or drain every account created by that factory, making permissionless deployment a security illusion.

Counter-intuitively, decentralization fails at deployment. Teams obsess over the modular security of a Safe{Wallet} or Biconomy account, but outsource its creation to a single, opaque contract. This creates a mass compromise vector that no modular signature scheme can mitigate.

Evidence: The ERC-4337 EntryPoint is a decentralized verifier, but the initial factory deployment is not. Projects like ZeroDev and Stackup must adopt verifiable, on-chain attestations for factory integrity, moving beyond trusted setup ceremonies.

takeaways
SMART ACCOUNT SECURITY

TL;DR: Audit Your Factory Like Your Life Depends On It

The factory contract is the single point of failure for all deployed smart accounts, making it the most critical and lucrative attack surface.

01

The Singleton Backdoor

A single bug in your factory can compromise every single smart account it ever creates. This is a force multiplier for attackers, turning a $100k exploit into a $100M+ catastrophe.

  • Attack Vector: Logic flaw in createAccount or initialization.
  • Consequence: Mass theft or bricking of all user accounts.
1:N
Exploit Scale
100%
User Risk
02

The Upgrade Poison Pill

If your factory handles account implementation upgrades (like a proxy admin), a compromised factory can maliciously upgrade all proxies to a rogue contract.

  • Real-World Precedent: Pattern seen in UUPS proxy vulnerabilities.
  • Mitigation: Use immutable, user-controlled upgrade paths or secure, timelocked multisigs.
0-Day
Persistence
Total
Control Loss
03

The EntryPoint Is Not Enough

Relying solely on the ERC-4337 EntryPoint for security is fatal. The factory is out-of-band for most bundler validation. A malicious factory can deploy accounts with hidden backdoors that bypass EntryPoint checks entirely.

  • Blind Spot: Bundlers validate user ops, not the factory's creation logic.
  • Requirement: Factory audits must be as rigorous as the EntryPoint's.
ERC-4337
Bypass Risk
Critical
Audit Tier
04

The Salt Mining Vulnerability

Deterministic address derivation (create2) via user-controlled salts is standard. A flawed salt calculation can lead to address collisions, allowing attackers to front-run and pre-deploy malicious contracts at a user's predicted address.

  • Core Function: The getAddress function must be perfectly aligned with createAccount.
  • Audit Focus: Verify cryptographic consistency across all chains and compiler versions.
Pre-Deploy
Attack
Deterministic
Failure
05

The Initialization Trap

Factory calls an initializer on the newly deployed account. If this call is unconstrained, it becomes an unchecked delegatecall during creation, a classic vulnerability vector.

  • Danger: Initializer can self-destruct or set malicious owners.
  • Best Practice: Use a strict, minimal initialization pattern and avoid arbitrary delegatecalls.
Delegatecall
Risk
Creation
Phase
06

The Cross-Chain Consistency Kill-Switch

For multi-chain factories (e.g., using LayerZero or CCIP), a compromise on one chain can be propagated. The factory must be upgraded in sync across all deployments, or a lagging chain becomes a permanent vulnerability.

  • Operational Hazard: Creates a race condition for safe upgrades.
  • Solution: Architect for atomic cross-chain upgrades or immutable factories.
N Chains
Sync Burden
Permanent
Risk Window
ENQUIRY

Get In Touch
today.

Our experts will offer a free quote and a 30min call to discuss your project.

NDA Protected
24h Response
Directly to Engineering Team
10+
Protocols Shipped
$20M+
TVL Overall
NDA Protected Directly to Engineering Team