Social Recovery Wallet Development

Social Recovery Wallet Development

A 12-word seed phrase is the worst UX in the history of finance. A user must reliably store a sequence of words that cannot be photographed, lost, or shown to anyone. As a result: one person wrote it on paper in a desk drawer, another saved it in phone notes, a third didn't save it at all. According to Chainalysis, 20–25% of all bitcoins are irretrievably lost this way.

Social recovery is a mechanism where loss of keys doesn't mean loss of assets. An idea by Vitalik Buterin, implemented in Argent, Loopring, and now natively available through ERC-4337 Account Abstraction. The essence: the wallet belongs to a smart contract that has two management modes — owner key for everyday transactions and guardian set for recovery.

Architecture: How Social Recovery Works at the Contract Level

Guardian Set and Threshold Recovery

Guardians are addresses (EOA or other smart contracts) that collectively can change the wallet's owner key. The owner appoints N guardians in advance and sets a threshold — the minimum number of confirmations for recovery. Classic example: 3 of 5.

Guardians never touch assets directly. Their only function is calling initiateRecovery and finalizeRecovery. This is a principled limitation: if a guardian is compromised, they cannot steal funds, only initiate a key change process.

contract SocialRecoveryWallet {
    address public owner;
    mapping(address => bool) public isGuardian;
    uint256 public guardianCount;
    uint256 public threshold;
    uint256 public recoveryDelay; // timelock in seconds

    struct RecoveryRequest {
        address proposedOwner;
        uint256 approvalCount;
        uint256 initiatedAt;
        mapping(address => bool) approvals;
    }

    RecoveryRequest public pendingRecovery;

    function initiateRecovery(address _proposedOwner) external onlyGuardian {
        require(pendingRecovery.initiatedAt == 0, "Recovery already pending");
        pendingRecovery.proposedOwner = _proposedOwner;
        pendingRecovery.initiatedAt = block.timestamp;
        pendingRecovery.approvalCount = 1;
        pendingRecovery.approvals[msg.sender] = true;
    }

    function approveRecovery() external onlyGuardian {
        require(pendingRecovery.initiatedAt != 0, "No pending recovery");
        require(!pendingRecovery.approvals[msg.sender], "Already approved");
        pendingRecovery.approvals[msg.sender] = true;
        pendingRecovery.approvalCount++;
    }

    function finalizeRecovery() external {
        require(pendingRecovery.approvalCount >= threshold, "Insufficient approvals");
        require(
            block.timestamp >= pendingRecovery.initiatedAt + recoveryDelay,
            "Timelock not expired"
        );
        owner = pendingRecovery.proposedOwner;
        delete pendingRecovery;
    }
}

Timelock — The Key Security Element

recoveryDelay is a mandatory parameter. If guardians colluded or were compromised, the owner has a window to cancel (cancelRecovery). Argent uses 24-48 hours. For institutional wallets, 72 hours or more makes sense.

Without timelock: guardian threshold compromised → instant loss of control. With timelock: the owner sees pending recovery in the interface, manages to cancel if they didn't initiate it.

Guardian Management

Adding and removing guardians should also go through a timelock — otherwise the owner could replace all guardians with controlled addresses just before selling. Pattern: pendingGuardianAdd with delay, similar to recovery.

mapping(address => uint256) public pendingGuardianAdditions;
uint256 public guardianAddDelay;

function scheduleAddGuardian(address _guardian) external onlyOwner {
    pendingGuardianAdditions[_guardian] = block.timestamp + guardianAddDelay;
}

function confirmAddGuardian(address _guardian) external {
    require(pendingGuardianAdditions[_guardian] != 0, "Not scheduled");
    require(block.timestamp >= pendingGuardianAdditions[_guardian], "Timelock active");
    isGuardian[_guardian] = true;
    guardianCount++;
    delete pendingGuardianAdditions[_guardian];
}

Who Can Be a Guardian

Choosing guardians is not a technical task, but a social and architectural one. Options:

Trusted persons. Three close people. Each stores a guardian private key in their own wallet. The simplest scheme, sufficient for most users.

Hardware wallet + phone + guardian service. A backup Ledger in a safe + personal phone + Guardian service like Argent or custom. With loss of two out of three — recovery.

Multisig as guardian. Safe{Wallet} as the wallet's guardian. Recovery requires gathering quorum in Safe. Suits corporate wallets where HR procedures replace keys.

Smart contract guardian. Guardian is a timelock contract of the organization. Recovery is initiated through governance voting. An extreme case, but allows fully formalizing the procedure.

ERC-4337 and Social Recovery

Account Abstraction (ERC-4337) makes social recovery a first-class pattern. The wallet is a smart contract from the start, no conversion from EOA needed. UserOperation instead of a transaction enables:

• Gasless recovery: Paymaster pays gas for guardians and user
• Batched approvals: multiple guardian approvals in one bundled batch
• Social login as guardian: guardian key stored in passkey/WebAuthn on user's phone, doesn't require crypto knowledge

Implementation via Kernel (ZeroDev) or Biconomy Smart Account v2: both have plugin/module systems where social recovery is a pluggable module, not core logic.

ERC-4337 Recovery Flow

// Guardian signs UserOperation to approveRecovery
const userOp = await guardianSmartAccount.buildUserOperation({
    target: walletAddress,
    data: wallet.interface.encodeFunctionData('approveRecovery', [])
});

// Paymaster sponsors gas — guardian doesn't need ETH
const sponsoredOp = await paymasterClient.sponsorUserOperation(userOp);
await bundlerClient.sendUserOperation(sponsoredOp);

This fundamentally changes UX: guardians don't need to hold ETH for gas. They just sign approval on their phone, Paymaster covers the cost.

Protection Against Attacks

Griefing via Spam Recovery

Any guardian can initiate recovery — and thus block normal wallet operation (pending recovery prevents transactions in some implementations). Solution: only a threshold of guardians can initiate recovery collectively, or recovery doesn't block owner's transactions.

Social Engineering on Guardians

An attacker convinces several guardians that the user lost their key and recovery is needed. Protection: timelock provides a reaction window, pending recovery monitoring through notifications (email/push/telegram bot), mandatory verification through out-of-band channel.

Front-Running finalizeRecovery

An attacker sees finalizeRecovery in mempool with proposedOwner = legitimate address and front-runs with a different address. Protection: commit-reveal scheme or use flashbots/private mempool for the final transaction.

Off-Chain Guardian Coordination

Guardians need a way to coordinate without on-chain gas. Options:

Centralized guardian service. Argent stores guardian signatures off-chain, the user requests through the service. Convenient, but a central point of failure.

IPFS + signature aggregation. Guardians publish signatures to IPFS, an aggregator collects threshold signatures and sends one batchApprove call. Requires UI.

E2E encrypted messaging. Guardians exchange via Signal/Matrix, signatures are transmitted manually. Low-tech, maximum independence.

For production, we recommend a hybrid: a custom notification server notifies guardians, they approve through dApp, aggregator batches signatures.

Stack and Tools

Solidity 0.8.x + OpenZeppelin — basic contract implementation. Foundry — testing, especially timelock and recovery edge cases. ERC-4337 SDK (ZeroDev / Biconomy) — if building an AA wallet. wagmi + viem — frontend. WalletConnect v2 — connecting guardians from different devices.

Development Process

Analytics (3–5 days). Target audience, who will be guardians, whether AA is needed, gasless or not, multichain or single chain.

Contract design (3–5 days). Guardian management scheme, timelock parameters, recovery flow, ERC-4337 Account integration if needed.

Development (4–8 weeks). Core contract → guardian management → recovery flow → frontend → guardian coordination UI.

Audit. Mandatory: contract manages funds, recovery is a critical function. Special focus: reentrancy in execute, timelock correctness, guardian griefing vectors.

Testing. Fork tests on mainnet, simulate full recovery flow, test each attack vector.

Basic wallet without AA — 3–5 weeks. With ERC-4337, gasless recovery, and guardian coordination UI — 8–12 weeks.