Why Audit Checklists Are Obsolete for Dynamic Account Systems

A wallet's security is no longer defined by its own code, but by the sum of its attached modules and the sessions it approves. A checklist audit of the core contract is irrelevant when a user can attach a malicious validator module post-audit.

• Attack Surface is Dynamic: Security depends on the permission graph between the core account, modules (ERC-6900), and session keys.
• Combinatorial Explosion: Auditing every possible module combination is impossible; a system with 10 modules has over 1,000 potential state combinations.

Security must shift from verifying code to continuously enforcing user intent. This requires real-time policy engines, not one-time checklists.

• Real-Time Guardrails: Systems like Safe{Core} Protocol and ZeroDev's Kernel validate every user operation against a runtime policy (e.g., spend limits, allowed destinations).
• Automated Revocation: Suspicious activity triggers automatic session key revocation or module pausing, moving response time from days to ~500ms.

Account abstraction exposes new financial attack vectors that traditional checklists ignore: oracle manipulation and generalized MEV extraction via user operations.

• Oracle-Dependent Logic: Module logic relying on Chainlink or Pyth price feeds is only as secure as the oracle's latency and robustness.
• Generalized MEV: Bundlers and searchers can exploit the ordering of UserOperations in the mempool, creating sandwich and time-bandit attacks on batched transactions.

Mitigation requires economic safeguards and exhaustive simulation for every proposed user operation before inclusion.

• Economic Guarantees: Protocols like EigenLayer and AltLayer provide cryptoeconomic security for verification layers, slashing for malicious bundler behavior.
• Full-State Simulation: Bundlers must run a local simulation of the entire operation batch, checking for oracle staleness and MEV extraction, rejecting harmful bundles.

Flexible upgrade mechanisms (like proxies or module registries) introduce admin key risk. A checklist that says 'admin is a multisig' is insufficient.

• Sleeping Admin Key Threat: A compromised or lost upgrade key can upgrade the entire system to malicious code, bypassing all previous audit findings.
• Timelock Isn't Enough: While 24-72 hour timelocks (common in OpenZeppelin upgrades) provide a reaction window, they don't prevent sophisticated social engineering or key theft.

The only sustainable path is to minimize trust in upgrade keys through immutable cores or decentralized, programmatic upgrade approval.

• Immutable Kernel: Following the Ethereum L1 ethos, core account verification logic should be immutable; new features are added via new module attachments, not upgrades.
• DAO-Governed Upgrades: For essential upgrades, use a DAO vote (e.g., Compound Governor) with a 7-day+ timelock and on-chain proof-of-audit requirements before execution.

It's a delegate-call factory with mutable logic. A one-time audit of the singleton factory is meaningless for the security of the thousands of ERC-4337 Account and Safe{Wallet} instances it creates. The attack surface is the user's personalized configuration and the modules they install.

• Key Risk: A malicious or buggy module (e.g., a session key manager) can drain the account post-audit.
• Key Insight: Security shifts from code verification to runtime permission validation and module registry governance.

Security for restaked assets isn't a checklist; it's a live data feed. Operators run Actively Validated Services (AVSs) like EigenDA or OmniNetwork, with slashing conditions monitored in real-time.

• Key Mechanism: Dual-staking with cryptoeconomic penalties creates a continuous audit loop.
• Key Benefit: Faults are detected and punished dynamically, aligning security with real-world performance, not a snapshot audit report.

Users express outcomes ("get me 1 ETH"), not transactions. Systems like UniswapX and Across use fillers and solvers to fulfill these intents off-chain. Security isn't about auditing a swap function, but verifying the fulfillment pathway meets the signed intent.

• Key Mechanism: Cryptographic commit-reveal schemes and on-chain settlement verification ensure execution integrity.
• Key Benefit: Users are protected from MEV and routing manipulation without needing to audit the entire solver network.

For cross-chain accounts (LayerZero, Chainlink CCIP) or restaking positions, your true balance and permissions live off-chain in a consensus of oracles or verifiers. A smart contract audit is irrelevant if the off-chain attestation layer is compromised.

• Key Risk: A super-majority attack on the oracle network can forge arbitrary state changes.
• Key Insight: Security audits must target the decentralization and cryptoeconomic security of the oracle network, not just the destination contract.

With account abstraction, the security perimeter shifts from the transaction to the user's validation logic and off-chain infrastructure. A single EOA signature check is replaced by a dynamic graph of modular validators, session keys, and policy engines.\n- Attack surface expands to bundlers, paymasters, and signature aggregators.\n- A 'verified' smart account can be rendered insecure by a malicious module post-audit.

Adopt runtime monitoring and automated policy enforcement used by protocols like Safe{Wallet} and ZeroDev. Security must be measured in real-time across the entire stack.\n- Implement transaction simulation for every user op via services like Tenderly or Blowfish.\n- Enforce modular security policies (e.g., spend limits, allowlists) that are updatable without full re-audits.\n- Monitor for anomalous patterns in account behavior and module interactions.

A user's transaction can chain through UniswapX, CowSwap, and an Across bridge via a single intent. The smart account wallet is the integrator, but the security of each downstream protocol is out of its control.\n- A vulnerability in any composed protocol (e.g., a bridge like LayerZero or Wormhole) compromises the user's assets.\n- Traditional audits cannot assess the infinite combinatorial risks of modular DeFi.

Treat every external call as hostile. Implement rigorous, automated checks for every integrated module and protocol, inspired by frameworks like OpenZeppelin's Defender.\n- Maintain a real-time allowlist of audited and versioned module/contract addresses.\n- Use circuit-breaker patterns and value-at-risk (VaR) limits per transaction path.\n- Leverage risk engines from insurers like Nexus Mutual or Uno Re to score intent fulfillment routes.

ERC-4337 account logic and ERC-6900 modules are designed for upgrades, creating a moving target for auditors. A governance attack or a malicious upgrade on a widely-used module (e.g., a Biconomy validator) can compromise $1B+ TVL instantly.\n- The audit snapshot is obsolete the moment the code can change.\n- Users often blindly trust the account provider's upgrade multisig.

Mandate verifiable and delayable upgrade paths for all critical account infrastructure, similar to Compound or Aave governance. Shift security from pure code review to process transparency.\n- Require on-chain timelocks (e.g., 7 days) for all module upgrades, allowing user exits.\n- Implement EIP-7504 for immutable, versioned module registries.\n- Use attestation frameworks like EAS to create public audit trails for every change.