L2-3: Social Recovery (Social Recovery Wallet) #

1. Problem #

Create a smart contract wallet that supports social recovery: when the owner loses their private key, a set of pre-designated "guardians" can replace the owner through unanimous consent.

2. Why #

The biggest risk of traditional EOA wallets: lost private key = permanently lost assets.

Social recovery solves this by trusting a set of "guardians" (friends, family, institutions):

• Normal operation: the owner controls everything
• Lost private key: contact guardians to vote for an owner replacement
• Recovery condition: all guardians must agree

Vitalik has repeatedly championed social recovery wallets as a key technology for improving user experience.

3. Solution #

Architecture #

owner ── normal operations ──→ call(any contract, ETH, calldata)
guardians ── unanimous vote ──→ signalNewOwner(newOwner) → auto-execute recovery
owner ── manage guardians ──→ addGuardian / removeGuardian

Core Mechanism #

• signalNewOwner(_proposedOwner): Each guardian can only vote for the same proposedOwner once
• When signalCount == guardianCount: auto-replace owner
• Signals for different proposedOwners are tracked independently

4. Pitfalls Encountered #

4.1 Unanimity vs Majority Trade-off #

This level uses unanimity (all guardians), meaning:

• Any single guardian can unilaterally block recovery
• If a guardian also loses their key → recovery becomes impossible

4.2 Guardian Set Changes #

If the owner adds or removes guardians during recovery, changes to guardianCount may:

• Adding guardians: what was previously unanimous is no longer unanimous
• Removing guardians: partial votes may prematurely trigger recovery

4.3 Multi-Candidate Signal Tracking #

Guardian A votes for proposedOwner1, Guardian B votes for proposedOwner2 — their signalCounts are tracked separately and do not affect each other.

5. Why the Pitfalls Exist #

5.1 #

Unanimity is a trade-off between security and liveness. Unanimity favors security (requires full agreement), while majority favors liveness (won't be blocked by one or two unreachable guardians).

5.2 #

This is a design choice: this level requires unanimity and does not include a timelock. Industry-grade implementations (such as Argent, Safe) typically use majority (e.g., 3/5) + timelock.

5.3 #

In signalNewOwner, signalCount is tracked independently per _proposedOwner dimension:

mapping(address => mapping(address => bool)) public hasSignaled; // proposedOwner → guardian → signaled
mapping(address => uint256) public signalCount;                   // proposedOwner → count

6. How to Solve the Pitfalls #

• In production, use majority (e.g., N-of-M) + timelock + cancellation mechanism
• Guardian selection: trustworthy + technically capable + geographically distributed
• After owner change, consider clearing old signals (simplified in this level — not implemented)

7. Technical Takeaways #