Setting Up a Decentralized Social Recovery System

Social recovery is a cryptographic mechanism that allows a user to regain access to their smart contract wallet if they lose their private key. Instead of relying on a single seed phrase, control is delegated to a trusted group of guardians—other wallets or entities. To execute a recovery, a predefined threshold of these guardians must collectively sign a transaction to authorize a new signing key for the account. This model, popularized by projects like Ethereum's ERC-4337 and Safe{Wallet}, shifts security from individual key management to social trust, significantly reducing the risk of permanent loss.

The core components of a social recovery system are the account abstraction wallet, the guardian set, and the recovery module. The wallet is a smart contract (like a Safe or an ERC-4337 Account) that holds assets. The guardian set is a list of addresses, which can include friends' wallets, hardware devices, or institutional services like Coinbase's Delegated Recovery. The recovery module is the logic, often a separate smart contract, that defines the rules: how many guardians are required (the threshold), how to add or remove them, and the process for initiating and executing a recovery request.

To implement a basic recovery module, you can write a smart contract that inherits from a base account. Below is a simplified Solidity example for an ERC-4337-compatible account with social recovery features, using a multi-signature scheme for guardians.

solidityCopy
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

import "@account-abstraction/contracts/core/BaseAccount.sol";

contract SocialRecoveryAccount is BaseAccount {
    address[] public guardians;
    uint256 public threshold;
    mapping(bytes32 => RecoveryRequest) public recoveryRequests;

    struct RecoveryRequest {
        address newOwner;
        uint256 approvals;
        bool executed;
        mapping(address => bool) hasApproved;
    }

    function initiateRecovery(address _newOwner) external onlyGuardian {
        bytes32 requestId = keccak256(abi.encodePacked(_newOwner, block.timestamp));
        RecoveryRequest storage request = recoveryRequests[requestId];
        request.newOwner = _newOwner;
        request.approvals = 1;
        request.hasApproved[msg.sender] = true;
    }

    function approveRecovery(bytes32 requestId) external onlyGuardian {
        RecoveryRequest storage request = recoveryRequests[requestId];
        require(!request.hasApproved[msg.sender], "Already approved");
        request.approvals++;
        request.hasApproved[msg.sender] = true;
        if (request.approvals >= threshold && !request.executed) {
            _transferOwnership(request.newOwner);
            request.executed = true;
        }
    }
    // ... additional functions for adding guardians
}

Choosing and managing guardians is critical for security and practicality. A balanced approach is recommended: use 5-7 guardians with a threshold of 3-4. Your set should include diverse device types: a primary mobile wallet, a hardware wallet in a safe, a trusted family member's wallet, and potentially a professional custodian service. Avoid concentration risk; all guardians should not use the same cloud backup provider or exchange. Services like Safe{Wallet}'s Recovery Hub or Etherscan's Guardian Service can act as verifiable, non-custodial guardians. Remember, guardians only sign recovery transactions; they cannot access funds unilaterally.

The user flow involves initiation, approval, and execution. If a user loses their device, they contact their guardians out-of-band (e.g., via phone). A guardian initiates a recovery request to the smart contract, specifying a new wallet address the user controls. Other guardians independently verify the user's identity through their trusted channel and submit their approval transactions. Once the threshold is met, the contract logic automatically updates the account's owner to the new address. The entire process occurs on-chain, is transparent, and can be configured with time delays (e.g., a 48-hour waiting period) to allow the original owner to cancel if it's fraudulent.

For production use, leverage established audited solutions instead of writing custom contracts. For Safe smart accounts, enable the Safe Recovery Hub module. For ERC-4337, use account implementations like SimpleAccount with a social recovery plugin or frameworks such as ZeroDev's Kernel that have built-in guardian support. Always test recovery on a testnet (like Sepolia) with real guardian addresses before mainnet deployment. Document the recovery process for your guardians, and consider setting up a dead man's switch service like Sarcophagus to automate initiation if you become unresponsive, completing a robust, user-owned recovery system.

A decentralized social recovery system allows a user to regain access to their smart contract wallet if they lose their primary private key. Instead of a single point of failure, access is managed by a set of guardians—trusted individuals, other wallets you control, or decentralized services. The core prerequisite is a smart contract wallet that supports the ERC-4337 Account Abstraction standard or a similar modular design, as this enables the custom logic required for recovery. You will also need a development environment set up with tools like Hardhat or Foundry, Node.js, and a basic understanding of Solidity.

The first setup step is defining your guardian set. Guardians are represented by their Ethereum addresses. You can use addresses from other wallets you own (like a hardware wallet or a mobile wallet), addresses of trusted friends or family, or addresses from dedicated services like Safe{Wallet}'s Recovery Service. A critical security parameter is the recovery threshold—the minimum number of guardian signatures required to execute a recovery. For a set of 5 guardians, a common threshold is 3. This setup must be encoded into your wallet's smart contract, typically in its constructor or via an initialization function.

Next, you need to implement the recovery logic. This involves writing a function in your wallet contract, often called executeRecovery or similar, that allows a new signing key to be set. This function should be protected so it can only be called with signatures from a number of guardians meeting the predefined threshold. You will use cryptographic signature verification, such as ecrecover in Solidity or a signature aggregation library. Thoroughly test this logic on a testnet (like Sepolia or Goerli) using your development framework. Simulate various scenarios, including a successful recovery and attempted attacks with insufficient signatures.

Finally, you must fund the wallet and guardians. Your smart contract wallet needs ETH to pay for gas when the recovery is executed. Additionally, if you are using other EOAs (Externally Owned Accounts) as guardians, ensure those accounts have a small amount of ETH to sign the recovery transaction message, though they do not pay the main execution gas. For production, consider using a relayer or a paymaster (part of ERC-4337) to allow guardians to sign gasless meta-transactions, simplifying their participation. Document the recovery process clearly for your guardians, providing them with a simple interface or guide for how to provide their signature if needed.

Decentralized social recovery is a security model that allows a user to regain access to their smart contract wallet if they lose their primary private key. Instead of relying on a single seed phrase, control is distributed among a trusted group of guardians. These guardians can be other EOAs (Externally Owned Accounts), smart contracts, or even hardware wallets. When a recovery is initiated, a predefined threshold of guardians must approve the request to authorize a new signing key for the wallet. This system mitigates the single point of failure inherent in traditional seed phrase management.

The core architecture involves two main smart contracts: the Wallet Factory and the Recovery Module. The factory deploys individual wallet instances, each with its own set of configured guardians and threshold. The recovery module contains the logic for initiating recovery, collecting guardian signatures, and executing the final account recovery transaction. A common implementation uses a multi-signature scheme, where a recovery request creates a pending transaction that requires M-of-N guardian approvals. Popular frameworks like Safe{Wallet} (formerly Gnosis Safe) and ERC-4337 Account Abstraction standards provide foundational patterns for this.

To set up a basic system, you first define the guardian set. A robust configuration uses 5-7 guardians with a threshold of 3. Guardians should be diverse: - A hardware wallet you control - A wallet on a separate mobile device - Trusted family members' addresses - A dedicated smart contract that adds time-locks. The wallet's constructor or initialization function stores this list and threshold on-chain. The recovery function should include a time-delay period (e.g., 48-72 hours) after initiation, allowing the original owner to cancel if the recovery is malicious. This is a critical security feature to prevent guardian collusion.

Here is a simplified code snippet for a recovery module's core function using Solidity and OpenZeppelin's SignatureChecker library:

solidityCopy
function initiateRecovery(address newOwner, bytes[] calldata guardianSignatures) external {
    require(guardianSignatures.length >= recoveryThreshold, "Insufficient signatures");
    require(block.timestamp > recoveryInitiatedAt + RECOVERY_DELAY, "Delay not met");
    
    bytes32 recoveryHash = keccak256(abi.encodePacked(newOwner, recoveryNonce));
    address[] memory verifiedGuardians = new address[](guardianSignatures.length);
    
    for (uint i = 0; i < guardianSignatures.length; i++) {
        address signer = SignatureChecker.recover(recoveryHash, guardianSignatures[i]);
        require(isGuardian[signer], "Invalid guardian");
        verifiedGuardians[i] = signer;
    }
    require(hasDuplicates(verifiedGuardians) == false, "Duplicate signatures");
    
    owner = newOwner;
    recoveryNonce++;
    emit RecoveryExecuted(newOwner);
}

Key security considerations include guardian management and failure scenarios. You must implement functions to add or remove guardians, which should also require a multi-signature from the existing guardian set. Consider integrating with ENS (Ethereum Name Service) for human-readable guardian addresses to reduce errors. For maximum decentralization, the recovery logic can be deployed on multiple Layer 2 networks like Optimism or Arbitrum, with the wallet using a cross-chain messaging protocol like LayerZero or CCIP to synchronize guardian sets and recovery states. Always conduct thorough audits on the recovery module, as it holds ultimate control over the wallet's assets.

Real-world implementations show the evolution of this concept. The Safe{Wallet} uses a flexible Module system where social recovery can be added as a plugin. ERC-4337 account abstraction allows the bundling of recovery logic directly into the wallet's validation function, enabling gas sponsorship for recovery operations by guardians. Future developments may integrate zero-knowledge proofs to allow guardians to verify recovery requests without revealing their identity on-chain. When deploying, start with a testnet using tools like Hardhat or Foundry, simulate guardian loss scenarios, and ensure the time-delay and threshold mechanisms behave as expected under various network conditions.

Social recovery is a critical security mechanism for smart contract wallets, allowing users to regain access to their funds if they lose their primary private key. Unlike traditional seed phrases, it relies on a network of trusted guardians—other EOAs or smart contracts—to approve a recovery request. This guide walks through building a basic recovery module using Solidity, focusing on the core logic for proposing recovery, collecting guardian signatures, and executing the wallet owner change. We'll use OpenZeppelin contracts for foundational security.

The core contract requires several key state variables: the address of the wallet owner, a mapping of approved guardian addresses, a threshold number of confirmations required, and a struct to track active recovery proposals. Essential functions include addGuardian(address guardian) and removeGuardian(address guardian), which should be callable only by the owner. For proposal management, you need initiateRecovery(address newOwner) to start the process and confirmRecovery(bytes32 proposalId) for guardians to approve. A timelock period should be enforced between initiation and execution for security.

A critical implementation detail is signature verification. To prevent gas-intensive on-chain signature collection during confirmation, we recommend using EIP-712 typed structured data. Guardians sign an off-chain message containing the proposal ID, and the contract's confirmRecovery function uses ECDSA.recover to validate the signer. The contract must track which guardians have signed to prevent double-counting. Once the confirmation threshold is met, the executeRecovery(bytes32 proposalId) function becomes callable by anyone to finalize the owner change, updating the wallet's main ownership record.

For production use, integrate with a decentralized attestation service like Ethereum Attestation Service (EAS) or Verax. Instead of managing a guardian list directly, your contract can verify on-chain attestations. Guardians would create an attestation (a signed data record on EAS) approving the recovery to a new address. The recovery contract then checks the EAS schema registry and verifies the attestation's validity and revocable status. This pattern decouples the logic, leverages a battle-tested primitive for trust, and allows guardians to use familiar signing workflows.

Thorough testing is non-negotiable. Write Foundry or Hardhat tests covering: adding/removing guardians, initiating a recovery, collecting signatures from multiple guardians (both valid and invalid), executing after the timelock, and failing scenarios like insufficient confirmations or unauthorized calls. Consider edge cases like guardian revocation during an active proposal. After testing, the module must be audited before mainnet deployment. Key resources include the OpenZeppelin ECDSA library and the EAS documentation.

Decentralized social recovery is a security paradigm that replaces traditional seed phrases with a network of trusted guardians. These guardians, which can be other wallets, hardware devices, or even institutional services, collectively authorize the recovery of a user's smart contract wallet. This approach mitigates the single point of failure inherent in private key management. Protocols like Safe{Wallet} (formerly Gnosis Safe) and ERC-4337 Account Abstraction have pioneered this model, enabling programmable recovery logic directly within the wallet contract.

The core component is a smart contract wallet with a modular recovery module. You define a set of guardian addresses and a recovery threshold (e.g., 3 out of 5 guardians must approve). When a user initiates recovery, the contract enters a pending state. Guardians submit their approvals via signed messages or transactions. Once the threshold is met, the contract executes a pre-defined action, such as assigning a new signing key to the wallet. This entire process occurs on-chain, ensuring transparency and censorship resistance.

To integrate, you must interact with the wallet's recovery module ABI. For a Safe, this involves the SocialRecoveryModule contract. First, enable the module by calling enableModule on the Safe contract itself. Then, set up guardians using the module's addGuardianWithThreshold function. A typical off-chain flow involves generating a recovery request, collecting EIP-712 signatures from guardians, and finally submitting a multiSend transaction to execute the recovery.

Key design considerations include guardian selection, liveness requirements, and fee management. Guardians should be diverse: - A user's other wallet - Trusted friends or family members' wallets - A hardware wallet in a safe - Institutional custody services like Fireblocks or Coinbase Wallets. For ERC-4337 accounts, you can implement recovery as a custom UserOperation validator, bundling guardian signatures into a single operation for gas efficiency via a Bundler.

Security audits are critical. The recovery logic must be resilient to guardian collusion, address poisoning attacks, and griefing. Implement timelocks for recovery execution and allow users to cancel pending requests. Regularly test the recovery flow on testnets like Sepolia. By integrating social recovery, you significantly improve user onboarding and long-term security, reducing the risk of permanent asset loss—a major barrier to mainstream Web3 adoption.

Your system is now operational with a Safe wallet secured by a set of trusted guardians using the Safe{Core} Account Abstraction SDK and the Social Recovery Module. The key components you have deployed and configured are: the main Safe smart contract account, the SocialRecoveryModule managing guardian logic, and a set of guardian addresses (e.g., from hardware wallets, other Safes, or trusted individuals). The recovery threshold you set determines how many guardians must collaborate to initiate a wallet recovery, balancing security with practical accessibility.

For production use, rigorous testing is essential. You should simulate recovery scenarios on a testnet like Sepolia or Goerli. Test edge cases such as a guardian losing their key, adjusting the recovery threshold, and executing the full recovery flow from proposal to execution. Monitor gas costs for recovery transactions, as they involve multiple signatures and on-chain verification. Tools like Tenderly and OpenZeppelin Defender can help automate monitoring and simulate attacks to ensure your configuration is resilient against common threats like guardian collusion or malicious proposals.

To enhance your system, consider integrating with existing identity frameworks. Using Ethereum Attestation Service (EAS) schemas to create on-chain attestations for your guardians adds a verifiable, revocable layer of trust. You could also explore Zero-Knowledge Proofs (ZKPs) for privacy-preserving recovery, where guardians can prove they are part of the set without revealing their identities on-chain. For user experience, building a front-end interface with the Safe{Core} API and Auth Kit allows non-technical users to easily view guardian status, initiate recovery requests, and sign transactions.

The next logical step is to make your recovery system programmable. Using the Safe{Core} Protocol and its Hooks, you can set up automated rules. For example, a hook could automatically initiate a recovery proposal if the wallet has been inactive for 12 months, or temporarily increase the recovery threshold if a large transaction is detected. This moves security from a static setup to a dynamic, context-aware system. Review the official Safe{Core} AA SDK Documentation for the latest hooks and module specifications.

Finally, remember that social recovery is part of a broader security strategy. It should be combined with other best practices: using hardware signers for guardians, regularly reviewing and updating your guardian set, and ensuring clear, off-chain communication channels among guardians. The decentralized nature of this system shifts security from a single point of failure (a seed phrase) to a social graph, fundamentally changing how we think about asset ownership and recovery in a self-custodial world.