EOA vs. Smart Contract Wallets: The Difference Between Reminders and Enforcement

This article has three layers:

1. Layer 1: The Intuition: A single-key safe vs. a rule-based vault
2. Layer 2: Real-World Use: Safe, ERC-4337, EIP-7702, and their limitations
3. Layer 3: Principles and Engineering details

Layer 1: The Intuition

1.1 A Single-Key Safe

An EOA is like a safe that has only one key:

• The key is in your hands; you can take out as much as you want;
• If the key is stolen, the thief can also take out as much as they want;
• The bank counter (wallet interface) can remind you that "this transaction is risky," but a thief won't go to the counter; they will simply use the key to open the safe.

Therefore, any risk control implemented on an EOA is essentially deterrence.

1.2 A Rule-Based Vault

A smart contract wallet is a vault managed by code:

• "Requires 2 out of 3 people to agree to open the door" (Multisig);
• "Maximum withdrawal of 10,000 per day" (Limit);
• "Can only transfer to addresses on a whitelist" (Whitelist);
• "Large withdrawals must be registered and can only be executed after 24 hours, during which they can be revoked" (Timelock).

These rules are written on-chain, and no one can bypass them, including a thief who has stolen one key.

Layer 2: Real-World Use

However, smart contract wallets are not omnipotent:

• Bybit (2025) used Safe multisig. The multisig rules themselves were not bypassed, but every signer signed the same malicious transaction on a tampered page (see "The Bybit Incident and Frontend Integrity"). Multisig prevents "loss of a single key," but it cannot prevent "all signers being deceived at once";
• The contract itself may have vulnerabilities or may be induced to execute delegatecall to replace the core logic;
• The same contract address on another chain might not exist or might be deployed by someone else; transferring money to that address on that chain might mean the funds can never be retrieved.

Layer 3: Principles and Engineering

3.1 Multisig (M-of-N)

The contract stores $N$ owner addresses and a threshold of $M$. For a transaction to be executed, signatures from at least $M$ owners must be collected.

A common personal configuration is 2-of-3:

The loss or theft of any single key is insufficient to transfer assets alone.

3.2 Guard and Module

• Guard: A check contract called before or after every transaction execution. It can implement rules such as "the recipient address must be on the whitelist," "single transaction cannot exceed a limit," or "prohibit delegatecall"; if requirements are not met, the transaction reverts;
• Module: Has the ability to bypass the multisig to execute transactions directly, used to implement automation (e.g., periodic payments). The permissions of a module are extremely high; adding a module is itself a high-risk operation.

3.3 Timelock

Splits large or sensitive operations into two steps: first register, then execute after a certain period, during which owners can cancel. It implements a "cooling-off period" on-chain: even if an attacker obtains enough signatures, they must wait for the timelock to expire, providing enough time for the owner to discover and revoke the transaction.

3.4 The Danger of delegatecall

delegatecall allows the current contract to run another contract's code using its own identity and on its own storage. Being induced to delegatecall a malicious contract is equivalent to allowing it to freely rewrite the wallet's storage, including the owner list and the contract implementation address. This was exactly the final step in the Bybit theft. Secure multisig interfaces and Guards should specifically warn against or directly prohibit operation = delegatecall transactions.

3.5 Comparison

Summary