Recovery Request

A Recovery Request initiates a mandatory security delay (e.g., 24-72 hours) before the recovery action is executed. This cooling-off period prevents unauthorized access by:

• Allowing the legitimate account owner to cancel the request if it was fraudulent.
• Giving other guardians time to detect and veto a malicious attempt.
• Serving as a critical final defense against social engineering or key compromise.

Recovery typically requires a cryptographic threshold of approvals from a pre-defined set of guardians. For example, a 3-of-5 scheme where three guardians must sign the request. This ensures:

• Decentralized trust: No single guardian holds unilateral power.
• Redundancy: The failure or compromise of one guardian does not lock the user out.
• Social consensus: Mimics real-world notarization or family recovery processes.

The ultimate goal of the request is to reassign signing authority from the lost or compromised key to a new, secure cryptographic key pair. This is executed by the smart contract wallet, which updates its internal owner mapping. The process atomically:

1. Verifies the guardian signatures meet the threshold.
2. Waits for the security delay to expire.
3. Permanently sets the new public key as the account's controller.

Every Recovery Request is a public transaction on the blockchain, creating an immutable audit log. This transparency provides:

• Verifiability: Anyone can audit the guardian set, thresholds, and request status.
• Security through visibility: Unusual recovery activity is publicly detectable.
• Non-repudiation: Guardians cannot deny their participation, as signatures are on-chain.

At any point before the security delay expires, the current valid signer for the account can cancel the pending Recovery Request. This is a crucial user protection feature that:

• Renders a malicious or mistaken request inert.
• Empowers the user as the ultimate authority over their account's recovery state.
• Operates as a simple transaction calling a cancelRecovery function on the wallet contract.

The initial on-chain transaction that initiates the recovery process. It is a structured proposal containing:

• New Signer Set: The cryptographic addresses proposed to replace the lost or compromised signers.
• Execution Delay: A mandatory waiting period (e.g., 7 days) that allows existing signers to veto the request.
• Proposer: The address (often a Guardian) that submits the request, which can be a trusted third-party service, a hardware device, or another smart contract.

Guardians are pre-authorized entities (e.g., other wallets, trusted contacts, or services) that can propose a recovery. Crucially, the existing signers of the wallet retain veto power during the execution delay. This creates a security checkpoint, preventing unilateral takeovers. The process is trust-minimized: guardians propose, but only the legitimate owner can cancel by vetoing with their existing keys.

A critical security parameter that enforces a mandatory waiting period between a recovery request being proposed and its execution. This timelock period (often 1-2 weeks) provides a final recourse for the legitimate account owner to detect and cancel a malicious recovery attempt using their existing signer keys. It is the primary defense against attacks on the recovery mechanism itself.

Two primary models for structuring recovery requests:

• Social Recovery: Relies on a decentralized set of off-chain guardians (friends, devices) who cryptographically sign approvals. Popularized by wallets like Argent.
• Multi-Sig Recovery: Uses an on-chain multi-signature smart contract as the guardian. Recovery requires a threshold of signatures (e.g., 3-of-5) from a pre-defined committee, making the process fully transparent and on-chain.

Every recovery request emits standardized events on the blockchain (e.g., RecoveryRequested, RecoveryExecuted, RecoveryCanceled). This allows:

• Wallets & Dashboards to display clear recovery status updates to users.
• Monitoring Services to alert users of pending actions.
• Analytics to track recovery mechanism usage and security. The transparency of these logs is fundamental to user awareness and system auditability.

Recovery requests are a core feature of ERC-4337 Account Abstraction and smart contract wallets. The recovery logic is embedded within the wallet's smart account code, allowing for:

• Customizable recovery rules and guardian sets.
• Gas sponsorship for recovery transactions by paymasters.
• Batch execution of recovery alongside other operations. This integration moves recovery from a centralized, custodial process to a programmable, non-custodial feature.

A Recovery Request is a formal, on-chain proposal to change the signing authority of a smart account (like an ERC-4337 wallet). It is initiated by a user or a designated guardian and requires a predefined consensus (e.g., a majority of guardians) to execute. This process moves control from a potentially lost private key to a new, secure one.

• Initiation: Triggered via a specific smart contract function call.
• Consensus: Uses multi-signature schemes or decentralized oracle networks for approval.
• Execution: Once validated, the account's entry point updates its ownership.

Recovery typically relies on a guardian system—a trusted set of entities (individuals, devices, or other contracts) authorized to approve requests. Standards define how these guardians are set, removed, and their voting power.

• Social Recovery: Friends or family act as guardians (e.g., early Ethereum Name Service designs).
• Decentralized Guardians: Services like Safe{Wallet}'s RecoveryHub or Etherscan's Permissionless Recovery act as neutral, incentivized networks.
• Threshold Schemes: Requires M-of-N guardians to sign, preventing single points of failure.

The ERC-4337 standard for account abstraction formalizes recovery as a primary use case. Smart accounts have built-in logic for managing recovery modules.

• Recovery Modules: Plug-in contracts that handle request logic, separate from core account functions.
• UserOperations: Recovery actions are bundled as UserOperations and submitted by bundlers to the network.
• Standardization: Efforts like ERC-6900 (Modular Account Interface) aim to create interoperable recovery plugins across different wallet providers.

To prevent malicious takeovers, recovery implementations include critical security timers and challenges.

• Security Period: A mandatory waiting window (e.g., 24-72 hours) between request initiation and execution, allowing the original owner to cancel if the request is fraudulent.
• Challenge Mechanisms: During the delay, anyone can submit proof (e.g., a recent valid signature from the old key) to veto the request.
• Graceful Degradation: Some systems increase the delay period if guardian turnover is high, adding an extra layer of security.

Several major wallet and infrastructure providers have live recovery systems.

• Safe{Wallet}: Uses a modular RecoveryHub where users can add/remove guardians and set policies.
• Etherscan Permissionless Recovery: A decentralized service where staked, anonymous "keepers" vote on recovery requests for a fee.
• Coinbase Smart Wallet: Integrates social recovery flows, allowing recovery via email or trusted contacts.
• ZeroDev & Stackup: ERC-4337 SDKs that provide built-in recovery module templates for developers.

Understanding recovery requires familiarity with adjacent standards and mechanisms.

• Account Abstraction (AA): The overarching paradigm enabling programmable recovery logic in smart accounts.
• Multi-signature (Multisig): A foundational technology where multiple signatures are needed, often used in guardian setups.
• Session Keys: Temporary signing keys that reduce risk; loss of a session key does not require a full recovery.
• Fallback Handlers: Designated contracts that can execute specific actions if the primary account is non-responsive, sometimes used in recovery flows.

A recovery request is a formal, on-chain proposal to change the signers or guardians of a wallet, initiated when a user loses access to their primary keys. The process typically involves:

• Initiation: The user (recoverer) submits a request, often with a time-delay (e.g., 1-7 days).
• Approval: A predefined majority of guardians or co-signers must approve the request.
• Execution: After the time-delay, the request executes, transferring control to new keys. This delay is a critical security feature, providing a window to cancel fraudulent requests.

The security of a recovery request hinges entirely on the integrity of the guardians. Key considerations include:

• Sybil Resistance: Guardians should be distinct, trusted entities (e.g., family, friends, hardware devices) not controlled by a single party.
• Social Engineering: Guardians are prime targets for phishing or coercion attacks to approve malicious requests.
• Decentralization of Trust: Using a diverse set of guardians (personal contacts, institutional services) reduces correlated failure risk. Avoid selecting guardians all from the same social circle or platform.

The mandatory time-delay (or waiting period) between request and execution is the primary defense against unauthorized recovery. It serves two purposes:

• Fraud Detection: Gives the legitimate owner time to discover and cancel a malicious request initiated by a compromised guardian set.
• Coercion Resistance: Provides a window where a user under duress can alert their network or let the delay expire. The length of the delay is a trade-off between security and convenience; longer delays (e.g., 1 week) are more secure but slower for legitimate recoveries.

The ability to cancel a recovery request is as important as initiating one. Users must:

• Actively Monitor: Use blockchain explorers or alert services to detect unauthorized recovery requests against their wallet address.
• Maintain a Secure Cancel Key: Retain access to at least one key (even a less-secure one) with cancellation privileges during the delay period.
• Understand Revocation Rules: Know if cancellation requires a single key or a guardian vote. A system where any guardian can cancel may be vulnerable to denial-of-service attacks against legitimate recovery.

Recovery systems introduce new phishing vectors. Attackers may:

• Impersonate wallet interfaces to trick users into initiating recovery to attacker-controlled addresses.
• Pose as legitimate guardians via email or SMS, sending fake approval links to capture signatures.
• Create fake "recovery services" that require users to surrender guardian details. Defense: Never share recovery secrets or guardian addresses. Always verify transaction details (especially new wallet addresses) on-chain before signing. Use dedicated communication channels with guardians.

Recovery requests are often part of inheritance planning. This requires special consideration:

• Documentation: Securely store instructions for heirs on how to initiate recovery, including guardian contacts and steps, without exposing private keys.
• Guardian Longevity: Choose guardians who will be available and identifiable years later. Consider institutional or professional co-signers for very long-term plans.
• Legal Wills: The recovery mechanism should be referenced in a legal will, but the cryptographic details (guardian addresses) should be kept separate from the public document to prevent targeted attacks.

A wallet security model where asset recovery is managed by a trusted group of individuals or entities, rather than a single private key. When a user initiates a Recovery Request, a predefined majority of their Guardians must approve it to execute the wallet migration.

• Decentralizes Trust: Eliminates single points of failure.
• User-Controlled: Users select their own guardians (friends, family, institutions).
• Common Implementations: Used by Smart Contract Wallets like Safe (formerly Gnosis Safe) and Argent.

A trusted entity (person, device, or institution) authorized to approve a Recovery Request for a user's wallet. Guardians hold a cryptographic key or sign transactions to facilitate the recovery process.

• Multi-Signature Logic: Recovery typically requires a threshold (e.g., 3 out of 5) of guardian approvals.
• Types: Can include other wallet addresses, hardware security modules, or dedicated guardian services.
• Security Role: Acts as a failsafe against lost seed phrases or stolen devices.

A non-custodial wallet where user assets and logic are managed by an on-chain smart contract, enabling advanced features like Recovery Requests. Unlike Externally Owned Accounts (EOAs), these wallets use programmable rules for transaction validation.

• Enables Recovery: The smart contract codifies the guardian structure and recovery logic.
• Account Abstraction: Pioneered by ERC-4337, allowing gas sponsorship and batched transactions.
• Examples: Safe, Argent, and Etherspot wallets.

A mnemonic phrase (typically 12 or 24 words) that generates the master private keys for a traditional wallet. Loss or compromise of this phrase often triggers the need for a Recovery Request in more advanced wallet systems.

• Single Point of Failure: In basic wallets, losing the seed phrase means permanent loss of funds.
• Contrast with Social Recovery: Social recovery systems are designed to mitigate this risk.
• Backup Essential: Should always be stored securely and offline.

A security scheme that requires multiple private keys to authorize a transaction. The guardian approval process for a Recovery Request is a specific application of multisig logic.

• Threshold Signatures: M-of-N signatures are required (e.g., 2-of-3).
• Beyond Recovery: Also used for corporate treasuries, DAO vaults, and escrow.
• On-Chain vs Off-Chain: Signatures can be aggregated on-chain (Smart Contract) or off-chain (like Schnorr signatures).

An Ethereum standard that allows wallets to be programmable smart contracts (called Account Abstraction), separating the logic of transaction validation from the concept of a private key. This is the foundational technology enabling native Recovery Requests without protocol-level changes.

• User Operations: Bundles transactions and enables social recovery as a built-in feature.
• Paymaster Support: Allows third parties to pay gas fees on a user's behalf.
• Future-Proofing: Paves the way for more sophisticated authentication and recovery mechanisms.