Imagine: a user loses their phone with an installed crypto wallet, the seed phrase is not saved, and there are ERC-20 tokens worth $50,000 in the account. Without Social Recovery, the funds are lost forever. We implemented a mechanism that restores access through trusted people (guardians) without a seed phrase. Everything works at the smart contract level; the mobile app is a UX layer on top. Our experience with EIP-2525 and ready-made solutions from Safe and ZeroDev allowed us to cut implementation time in half compared to developing from scratch. Social Recovery saves users thousands of dollars in fees and eliminates the risk of total fund loss. Get a consultation on integrating it into your wallet.
How Social Recovery Works at the Contract Level
The candidate standard is EIP-2525 (not finalized) and implementations in Safe, ZeroDev, and Argent. The wallet is a smart account compliant with ERC-4337, allowing Social Recovery to be combined with batched transactions and gas sponsorship. Basic logic:
- The wallet is a smart account (ERC-4337 or custom).
- At setup, the owner defines a list of guardians (addresses) and a threshold (N out of M).
- On loss of access: guardians confirm
initiateRecovery(newOwner). - After collecting N signatures and an optional timelock (24–72 hours),
finalizeRecoverychanges the owner.
The mobile app implements: a guardian setup screen, a recovery initiation flow (for the new device), and a confirmation screen (for guardians).
Why Timelock Is Critical
If the owner is compromised rather than lost, the timelock gives time to cancel a fraudulent recovery via cancelRecovery with the original key. Without a timelock, an attacker who gains access to one guardian address could instantly take over the wallet. In our projects, we set a 48-hour timelock — the minimum time for the user to notice the issue and cancel the operation.
| Timelock type | Duration | Use case |
|---|---|---|
| Minimal | 24 hours | Fast recovery, high trust in guardians |
| Medium | 48 hours | Balance between security and speed |
| Maximum | 72 hours | Conservative settings, high fraud risk |
Who Are Guardians from a Technical Perspective?
Options vary: other wallets (addresses) of trusted people, email via ZK-Email Guardian (email verification without content disclosure), hardware wallets, or other smart accounts.
For a mobile app, the most practical option is guardian addresses of other app users. The flow:
- User A adds a guardian → enters an address or scans User B's QR code.
- User B receives a push notification and accepts/declines the guardian role.
- Accepting the guardian role triggers
addGuardianin User A's wallet contract.
How Recovery Happens on a New Device
The user installs the app on a new device, generates a new keypair, and initiates recovery with the new address — sending a request to guardians via push/email.
Each guardian sees: which wallet is being recovered, the new address, and the request timestamp. They confirm through their own wallet via approveRecovery UserOperation.
What Is Difficult in Implementing Social Recovery?
Off-chain state. Guardians are not always online during recovery. A centralized notification queue or push mechanism is needed. Without it, recovery stalls. We use Firebase Cloud Messaging with a queue that guarantees delivery within 5 minutes.
Guardian changes. If the user falls out with a guardian, a removal flow is needed. removeGuardian via the owner key. But what if the owner key is already lost? Then only through other guardians with an elevated threshold.
Status display. The user sees: "2 out of 3 guardians confirmed, waiting for 1 more, timelock expires in 18 hours." This requires polling the contract or event subscription via WebSocket (eth_subscribe).
| Component | Complexity | Solution |
|---|---|---|
| Guardian notifications | High | Push server with queue |
| Guardian changes on key loss | Medium | Only through other guardians |
| Recovery status display | Low | Polling or WebSocket |
What Is Included in the Implementation Work
- Audit of the existing contract architecture or selection of a ready-made solution (Safe, ZeroDev).
- UI development: guardian setup screen, recovery initiation and confirmation flows.
- Integration of push notifications for guardians (APNs/FCM).
- Recovery status monitoring via event subscription.
- Documentation for use and testing on TestFlight/Google Play Console.
- Code guarantee — 12 months of free bug-fix support.
Timeline and Cost
Estimated timeline: from 3 to 5 days for integration with an existing smart account if the contract already supports Social Recovery. If the contract needs to be developed from scratch, the scope is discussed in a preliminary meeting. The cost is calculated individually after analyzing the requirements. Order an audit of your current architecture or get a consultation on implementing Social Recovery in your wallet. Contact us for a detailed technical discussion.