Title: Social Recovery · Pattern · EthSystems

URL Source: https://original.es-internal.pages.dev/patterns/pattern-social-recovery/

Markdown Content:
---
description: Let a quorum of guardians authorize rotation of the signing key or enrollment anchor for an account or identity. A holder recovers after key loss or compromise without the original issuer, custodian, or centralized service.
title: Social Recovery · Pattern · EthSystems
image: https://original.es-internal.pages.dev/og.png
---

[Skip to content](#main-content) 

#### Works best when

* The signing key can be lost or compromised independently of the account contract
* Holder has durable out-of-band trust relationships (devices, hardware wallets, institutions, email or SMS services)
* A rotation window of hours to weeks is acceptable

#### Avoid when

* Holder cannot nominate independent guardians they trust more than a plausible attacker
* Recovery must finalize without a cancellation window
* Guardian set cannot be kept current

### I2I vs I2U — context differences

Between institutions, guardians are typically other institutions (custodians, partners, regulators) acting under contractual SLAs and formal escalation procedures. Mutual audit logs and legal recourse bound the risk of guardian collusion or coercion.

For end users, guardians are typically friends, family, or hardware devices. Setup quality depends on the user's social graph; social-engineering attacks on the guardian set become the dominant risk. Guardian freshness and rotation discipline are the user's own responsibility.

## Components

* Recoverable account: smart-contract wallet or identity anchor with an owner-rotation function gated on a quorum signature. ERC-4337 accounts and EIP-7702 delegated EOAs both fit.
* Guardian set: N guardians stored on-chain or as a Merkle commitment. Guardians can be EOAs, hardware wallets, institutional keys, an m-of-n Safe, or managed email and SMS attestation services.
* Threshold policy: M-of-N quorum, with M large enough to resist expected collusion.
* Timelock: cancelable security window between proposal and finalization.
* Optional ZK guardian proof: membership proof over a guardian commitment so the guardian set is not exposed on-chain. See [Verum Lotus](https://github.com/verumlotus/social-recovery-wallet).

## Protocol

1. user Register N guardians and threshold M on the account or identity anchor.
2. guardian On key loss, M guardians sign a recovery proposal naming the new owner key or new enrollment commitment.
3. contract Record the proposal and start the security window. The current owner, if reachable, can cancel. Deployed windows range from 36 hours ([Argent on-chain recovery](https://support.argent.xyz/hc/en-us/articles/360007338877-How-to-recover-my-wallet-with-guardians-onchain-complete-guide)) to 14 days ([Candide module default on Safe](https://safefoundation.org/blog/introducing-candides-social-recovery)).
4. contract After the window passes, anyone can execute the rotation; the new owner takes control and the prior signing key is revoked.
5. auditor The rotation event, guardian signatures, and new owner are logged. A rotation counter or nullifier prevents replay of the same proposal.

## Guarantees & threat model

* Recovery path with no issuer, custodian, or centralized service in the loop.
* Cancelable rotation: the timelock gives the holder a window to block unauthorized proposals if the original key is still reachable.
* Identity anchor variant: in the issuer-independent enrollment flow, guardians authorize rotation of the enrollment key bound to the on-chain commitment, not of a credential. See [Approach: Private Identity, Issuer-Independent Enrollment via Distributed OPRF](/approaches/approach-private-identity/#issuer-independent-enrollment-via-distributed-oprf).

## Trade-offs

* Guardian collusion. A compromised quorum can force a malicious rotation. The timelock and holder cancellation are the defenses.
* Stale sets. Guardian membership degrades if the holder does not keep it current. Lost or captured guardians reduce effective security without any on-chain signal.
* Privacy of the social graph. By default, the guardian set is visible on-chain. ZK-guardian variants hide identities until recovery, raising privacy toward `full` at the cost of circuit overhead.
* Timelock is a direct trade. Longer windows give stronger cancellation guarantees and worse recovery responsiveness. 36 hours favors live holders; 14 days favors defense against silent key theft.
* Anti-coercion for identity recovery is open. See [Resilient Identity Continuity open questions](/use-cases/resilient-identity-continuity/#6-open-questions).
* Post-quantum exposure. Guardian signatures inherit the exposure of their signing schemes. See [Post-Quantum Threats](/domains/post-quantum/).

## Example

A holder loses their phone. Three of five nominated guardians, two friends' wallets and one hardware wallet, sign an on-chain recovery proposal naming a new device key. A 48-hour timelock runs; no cancellation arrives. The account contract rotates the owner. Funds, permissions, and on-chain history are preserved. No service provider participated.

## See also

* [MPC Custody](/patterns/pattern-mpc-custody/): threshold-signing alternative for institutional custody, where recovery is a policy-engine decision rather than a guardian quorum.
* [Native Account Abstraction](/patterns/pattern-native-account-abstraction/): EIP-8141 validation frames let recovery logic live in the account itself.
* [Safe Proof Delegation](/patterns/pattern-safe-proof-delegation/): rotate authorization without moving funds.
* Implementations: [Argent / Ready](https://www.ready.co/), [Candide social recovery module for Safe](https://safefoundation.org/blog/introducing-candides-social-recovery), [zkEmail account recovery](https://prove.email/) (live on Safe and Clave mainnet).
* Prior art: [Vitalik on social recovery (2021)](https://vitalik.eth.limo/general/2021/01/11/recovery.html).

CROPS profile

Censorship-resistance: mediumOpen source: yesPrivacy: partialSecurity: medium

CRCensorship-resistancemedium

OSOpen sourceyes

PPrivacypartial

SSecuritymedium

#### Referenced by

approaches2
* [Private Identity](/approaches/approach-private-identity/)
* [White-Label Infrastructure Deployment](/approaches/approach-white-label-deployment/)
building blocks1
* [Forward-Secure Signatures](/patterns/pattern-forward-secure-signatures/)

×

```json
{"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://ethsystems.org/#organization","name":"EthSystems","url":"https://ethsystems.org/","logo":"https://ethsystems.org/icon-maskable.png","sameAs":["https://x.com/eth_systems","https://www.linkedin.com/company/ethsystems/","https://github.com/ethsystems"]},{"@type":"WebSite","@id":"https://ethsystems.org/#website","url":"https://ethsystems.org/","name":"EthSystems","publisher":{"@id":"https://ethsystems.org/#organization"}}]}
```