We deal with lost seed phrases every day: a client wrote down 12 words on a piece of paper, put it in a desk drawer, and forgot. According to Chainalysis, 20–25% of all bitcoins are irretrievably lost this way. Our engineers develop wallets with social recovery—a mechanism that saves assets when a key is lost. Order such a turnkey implementation: we design the contract, configure guardians, and conduct an audit. On average, a project takes from 4 to 12 weeks depending on complexity.
Social recovery is an idea by Vitalik Buterin, implemented in Argent and Loopring, and now natively available through Account Abstraction (ERC-4337). The wallet is a smart contract with two modes: an owner key for everyday transactions and a guardian set for recovery.
How social recovery works at the contract level
Guardian set and threshold recovery
Guardians are addresses that can collectively change the owner key. The owner appoints N guardians and a threshold (typically 3-of-5). Guardians do not touch assets—they only call initiateRecovery and finalizeRecovery. This is a key difference: a compromised guardian cannot steal funds, only initiate a key change.
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;
}
}
Why timelock is critical
recoveryDelay is a mandatory parameter. Without it: threshold compromised → instant loss of control. With timelock (Argent uses 24–48 hours, for institutional 72+ hours) the owner has a window to cancel. In practice, this reduces the risk of asset loss by 3 times compared to instant recovery.
Guardian management with delay
Adding and removing guardians also uses a timelock—otherwise the owner could replace all guardians before selling. We use the pendingGuardianAdd pattern:
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];
}
How to choose guardians?
Choosing guardians is a socio-architectural task. Options:
- Trusted persons: 3 close people, each holds a guardian key in their wallet. Simplest scheme.
- Hardware wallet + phone + guardian service: a backup Ledger + phone + a service (Argent or custom). If two out of three are lost, recovery.
- Multisig as guardian: Safe{Wallet} as guardian. Recovery requires a quorum in Safe. Suitable for corporations.
- Smart contract guardian: a timelock contract of the organization, recovery via governance voting.
| Guardian type | Convenience | Decentralization | Suitable for |
|---|---|---|---|
| Trusted persons (3-of-5) | High | High | Retail users |
| Hardware + mobile + service | Medium | Medium | Power users |
| Corporate multisig | Low | High | Corporate |
| DAO governance | Very low | Maximum | Protocol-owned |
ERC-4337 and social recovery: gasless recovery
Account Abstraction (ERC-4337) makes social recovery a native pattern. The wallet is already a smart contract, no need to convert EOA. UserOperation enables:
- Gasless recovery: Paymaster covers gas for guardians and the user.
- Batched approvals: multiple guardians in one bundled batch.
- Social login as guardian: key stored in passkey/WebAuthn on phone.
Implementation via Kernel (ZeroDev) or Biconomy Smart Account v2: both have a plugin system where social recovery is a module.
ERC-4337 recovery flow
// Guardian signs UserOperation for approveRecovery
const userOp = await guardianSmartAccount.buildUserOperation({
target: walletAddress,
data: wallet.interface.encodeFunctionData('approveRecovery', [])
});
// Paymaster sponsors gas
const sponsoredOp = await paymasterClient.sponsorUserOperation(userOp);
await bundlerClient.sendUserOperation(sponsoredOp);
This changes UX: the guardian does not need ETH for gas, they just sign an approval on the phone.
Attack protection
Griefing via spam recovery
Any guardian can initiate recovery and block the wallet. Solution: recovery does not block owner transactions, or it can be initiated only by several guardians collectively.
Social engineering
An attacker convinces guardians that the user lost the key. Protection: timelock + notifications (email/push/telegram bot) + out-of-band verification.
Front-running finalizeRecovery
An attacker sees finalizeRecovery in the mempool and replaces the address. Protection: commit-reveal or private mempool.
Off-chain guardian coordination
Guardians need coordination without on-chain gas. Options:
- Centralized guardian service (Argent) – convenient but central point.
- IPFS + signature aggregation – guardians publish signatures on IPFS, aggregator sends batchApprove.
- E2E encrypted messaging – via Signal/Matrix, low-tech, maximum independence.
Our hybrid: a notification server notifies guardians, they approve via dApp, and an aggregator batches.
What is included in development
We provide a complete package: architecture documentation, smart contract source code (Solidity), frontend (wagmi+viem), Foundry configurations, deployment instructions, a training webinar for the team, and one month of support after launch. We will evaluate your project for free—contact us.
Work process
- Analysis (3-5 days). Target audience, guardian choice, need for AA, gasless, multichain.
- Contract design (3-5 days). Guardian management, timelock parameters, recovery flow, ERC-4337 integration.
- Development (4-8 weeks). Core contract → guardian management → recovery flow → frontend → guardian coordination UI.
- Audit. Mandatory: the contract manages funds. We check reentrancy, timelock, griefing vectors.
- Testing. Fork tests on mainnet, full recovery flow simulation.
| Stage | Duration (days) | Result |
|---|---|---|
| Analysis | 3-5 | Technical specification |
| Design | 3-5 | Contract architecture |
| Development | 28-56 | Source code, frontend |
| Audit | 7-14 | Audit report |
| Testing | 5-7 | Fork tests |
Stack and tools
Solidity 0.8.x + OpenZeppelin, Foundry, ERC-4337 SDK, wagmi + viem, WalletConnect v2. We use Tenderly for monitoring.
Timeline and cost
A basic wallet without AA: 3-5 weeks. With ERC-4337, gasless recovery, and guardian UI: 8-12 weeks. Cost is calculated individually—contact us for an estimate.
We have completed 20+ projects in the field of Social Recovery over 5 years of work. Our engineers are authors of articles on ERC-4337 and contributors to open-source solutions.