Why Smart Accounts Make Phishing Attacks Permanent

ERC-4337 session keys and permit2-style approvals are not one-time transactions; they are programmable permissions that attackers can exploit indefinitely.

• A malicious dApp can request a key with unbounded scope and duration.
• Unlike a drained EOA, the user's account remains 'secure' but is now remotely controlled.
• This creates a new class of low-and-slow attacks where funds are siphoned over months.

Shift from granting permissions to declaring outcomes. Users sign intents (what they want) not transactions (how to do it).

• Solvers compete to fulfill the intent, but never receive direct asset custody.
• Eliminates the need for token approvals and persistent session keys.
• The user's smart account logic becomes the final arbiter, not a third-party contract.

Smart accounts rely on singleton EntryPoint and account logic contracts. Compromising these via social engineering (e.g., malicious governance proposal) or code bug bricks or backdoors millions of wallets simultaneously.

• This centralizes risk at the infrastructure layer.
• Recovery mechanisms (guardians) are often on-chain and equally vulnerable to social attacks.
• Contrast with EOAs, where compromise is isolated to individual key pairs.

Move security critical decisions off-chain to decentralized networks of verifiers (e.g., Safe{Core} modules, ZeroDev kernels).

• Transaction policies are enforced by a consensus of attesters, not a single contract.
• Enables real-time threat intelligence and revocation feeds.
• Makes social engineering attacks prohibitively expensive by requiring collusion across multiple, independent entities.

Attackers no longer need your mnemonic. A single signature on a malicious UserOperation is enough. Fake dApp UIs can trick users into signing ops that:

• Install a malicious validation module.
• Add a compromised guardian for 'recovery'.
• Grant unlimited spending authority to a rogue contract.
• The signature is cryptographically valid, making detection by wallets nearly impossible.

Wallets must move beyond raw hex data. EIP-7212 (secp256r1 support) enables transaction simulation that shows human-readable outcomes before signing.

• Sign an intent hash, not contract calldata.
• Wallet-side simulation renders a plain-language preview: 'This will grant X contract control over Y tokens indefinitely.'
• Turns a cryptographic action into a user-centric consent flow, breaking the phishing chain.

Traditional phishing steals a one-time signature. Smart account phishing grants a permanent backdoor. A malicious dApp can request an infinite spending allowance for a specific token, which the user's smart account signs. The attacker can then drain that token indefinitely, at any time, even after the user revokes the dApp's connection.

• Permanent Risk: Unlike EOAs, revocation requires a new on-chain transaction.
• Stealthy Execution: The drain can happen weeks later, evading immediate detection.

Replace infinite allowances with scoped, time-bound permissions. Projects like Rhinestone and ZeroDev enable users to grant dApps temporary "session keys" with strict limits.

• Granular Controls: Cap spend amount, token type, and contract addresses.
• Time-Limited: Automatically expire after a set period (e.g., 24 hours).
• Revocable: User can invalidate the session key off-chain via the account's policy engine.

The ultimate defense is removing allowances entirely. Systems like UniswapX and CowSwap use intents: users sign a desired outcome ("swap X for Y"), not a permission. Solvers compete to fulfill it, never receiving direct asset custody.

• No Allowances: User assets never leave their account until the trade executes.
• MEV Protection: Solvers are incentivized to find best execution, similar to Flashbots.
• Future Standard: This pattern is core to Across and layerzero's intent-centric cross-chain vision.

ERC-4337 UserOperations are public mempool transactions, vulnerable to frontrunning and malicious bundlers. A phishing site can simulate a benign UserOp, then replace it with a malicious one before bundling.

• Mempool Sniping: Attackers monitor for signature requests to substitute transactions.
• Bundler Trust: Users must rely on bundlers not to censor or exploit their ops.
• Mitigation: Requires encrypted mempools (SUAVE) or direct bundler relationships.