ERC-7947 Smart Account Recovery: Recovery Providers, Proofs, and Takeover Risk
ERC-7947 smart account recovery proposes a common interface for restoring access to smart accounts through one or more recovery providers when the normal access credential is lost or unavailable. Instead of forcing every wallet to invent an incompatible recovery API, ERC-7947 defines a shared mechanism around adding recovery providers, removing them, committing recovery data, submitting recovery proofs, and changing the account's access subject after successful verification. The same flexibility that can prevent permanent loss also creates one of the most powerful authorization surfaces in a smart wallet: a recovery path capable of replacing an owner, role, key, or other access-control subject can become a complete account takeover path if a malicious provider is added, a proof can be replayed, provider state is compromised, access-control checks are weak, or a user mistakes recovery enrollment for an ordinary wallet action.
TL;DR
- ERC-7947 is a Draft smart-account recovery interface, not a wallet connection, token allowance, or routine transaction standard.
- A supporting smart account can register multiple recovery providers and later use one of them to verify a recovery proof and update account access.
- The core recovery call is recoverAccess(subject, provider, proof). The account must verify that the provider is registered and update access only when the provider accepts the proof.
- Recovery providers maintain account-specific recovery data or commitments and must prevent recovery proofs from being reused, for example through nonce updates.
- ERC-7947 does not define one universal expiry, delay, guardian threshold, chain field, or recovery-proof format. Those controls depend on the provider and smart-account implementation.
- The largest takeover risk is enrolling or retaining a malicious recovery provider. The official security considerations explicitly warn that a provider accepting fake proofs can gain full account control.
The proposal defines a common Account Abstraction Recovery Interface rather than a finished wallet product or one mandatory recovery policy. Real security therefore depends on the smart account, provider contracts, recovery proof scheme, access-control design, upgrade model, user interface, and operational procedures surrounding the standard.
What ERC-7947 actually standardizes
Smart accounts can support features that traditional externally owned accounts cannot implement directly at the account layer.
They can use several signers.
They can enforce spending policies.
They can install authentication modules.
They can rotate keys.
They can recover from credential loss.
The recovery problem is especially important because an account can be technically secure against attackers while remaining unusable to its legitimate owner after a key, device, passkey, or other access credential is lost.
ERC-7947 proposes a common interface called the Account Abstraction Recovery Interface, or AARI.
Its central idea is that a smart account can register one or more external recovery providers.
Each provider can maintain recovery-specific information for that account.
If the user later needs to restore access, a valid proof is submitted through the registered provider.
If verification succeeds, the smart account changes the relevant access subject.
The proposal is intentionally generic.
A recovery proof could involve a zero-knowledge proof, a signature, an alternative secret, a two-factor recovery mechanism, or another provider-defined verification method.
The standard does not require every smart account to recover by replacing one EOA owner address.
The subject being recovered is represented as arbitrary bytes because modern smart accounts can be ownerless, role-based, modular, or controlled through structures that cannot be reduced to one address.
Recovery is not an ordinary wallet transaction
An ordinary transaction changes account or application state according to authority that already exists.
A recovery transaction can change who possesses that authority.
That difference changes the security consequences dramatically.
Suppose Alice owns a smart account containing $100,000 of assets.
A normal swap permission might allow a DEX to spend $500 of USDC.
A recovery provider capable of replacing Alice's access subject can potentially cause the account to recognize a completely different owner or access role.
If that happens incorrectly, every asset and every future account action can become exposed.
| Mechanism | Primary purpose | Typical authority | Main security question |
|---|---|---|---|
| Wallet connection | Expose selected account information and allow a DApp to request actions. | Usually no direct autonomous ownership replacement. | Which account and data are being exposed? |
| ERC-20 allowance | Authorize a spender to move a specific token under allowance rules. | Limited to the token contract and allowance semantics. | Which spender, token, and amount? |
| Permit2 authorization | Provide reusable token-spending permissions through Permit2 infrastructure. | Token-specific spending authority under the Permit2 model. | What spending authority remains active? |
| Ordinary transaction | Execute one state transition. | Effects defined by the specific call. | What will this transaction do now? |
| ERC-7947 recovery | Restore or replace account access using a registered recovery provider and proof. | Can potentially alter owner, signer, role, or another core access subject. | Who can prove recovery and what account authority changes afterward? |
This is why recovery enrollment should not look like a low-risk preference change.
Adding a provider can be equivalent to creating a second path to ultimate account control.
The two ERC-7947 interfaces
The proposal separates responsibilities between the smart account and recovery provider.
IAccountRecovery
The smart account manages which providers are trusted and applies an access change after successful provider verification.
IRecoveryProvider
The recovery provider stores account-specific recovery data and validates the proof presented during recovery.
This separation allows one wallet implementation to work with different provider designs.
A biometric recovery provider could use one proof system.
A zero-knowledge two-factor provider could use another.
A social-recovery-style provider could implement another validation method, provided it conforms to the required interface.
The account becomes a recovery-provider aggregator rather than permanently depending on one hardcoded recovery service.
The smart-account recovery interface
A smart account that supports ERC-7947 must expose several recovery functions and events.
The smart-account side is where provider trust becomes account authority.
The provider itself does not need to hold the user's private key.
It needs to satisfy the account's recovery pathway.
That can be equally powerful.
The recovery-provider interface
The provider has a separate lifecycle.
The provider should process the recoveryData supplied during enrollment and associate it with the smart account that called subscribe.
During recovery, the provider uses that stored or committed data to decide whether the supplied proof establishes the required recovery condition.
The ERC-7947 recovery authorization surface
Normal account control
The current owner, signer, passkey, role, or authorization module controls the smart account.
Recovery provider enrollment
The account adds a provider address and passes recoveryData to the provider's subscribe function.
Recovery commitment stored
The provider associates recovery information with the smart account for future verification.
Normal access is lost
The legitimate user can no longer authenticate through the primary access path.
Recovery proof is verified
recoverAccess uses a registered provider to verify proof against the account's recovery data.
Access is replaced and verified
The account changes its access subject, then the user verifies new control and cleans up residual risk.
Adding a recovery provider is a high-authority action
The official ERC states that addRecoveryProvider should be access controlled.
That recommendation is fundamental.
If arbitrary callers can add providers, an attacker can install their own recovery contract and later recover the account to an attacker-controlled subject.
The attack would not require stealing the original owner's private key.
The attacker would have created an alternate ownership path.
The provider address must be verified
ERC-7947 requires the account to reject the zero address.
That check prevents one invalid configuration.
It does not establish that a non-zero provider is trustworthy.
A malicious provider can exist at a valid contract address.
Provider enrollment should receive clear signing
A wallet should not show "Enable recovery" while hiding the actual provider.
The user needs to know that the transaction is creating a new path capable of changing account access.
TokenToolHub's Clear Signing in Crypto guide explains the broader principle: a wallet interface should translate contract calls into their real consequences rather than exposing only raw calldata or vague action labels.
Address substitution is a serious phishing vector
A legitimate wallet interface can intend to register Recovery Provider A.
A compromised frontend replaces the address with Provider B.
If the user signs without seeing or verifying the effective provider, the attacker has positioned a future takeover mechanism inside the account.
What recoveryData represents
When a provider is added, the smart account passes arbitrary recoveryData to the provider's subscribe function.
The proposal describes this data as something such as a commitment or zero-knowledge public output that can later help validate a recovery proof.
The exact format is provider-specific.
It may commit to an alternative secret
A user can enroll a secret separate from the normal private key.
Later, knowledge of that secret can be proven without necessarily publishing it directly.
It may commit to a more complex recovery condition
A provider could verify a zero-knowledge proof derived from several factors.
Another provider could implement a signature-based mechanism.
A future provider could use different cryptographic or identity-based evidence.
The data format must be interpreted only by its provider
A bytes value is not self-describing.
Two providers can interpret identical bytes differently.
Wallets and auditors should therefore treat the provider address and recoveryData as one configuration unit.
Recovery commitments can become long-lived secrets or identifiers
Recovery systems often depend on commitments designed to avoid exposing the underlying recovery secret.
The commitment can still have security implications.
Weak recovery secrets can be brute-forced
If recoveryData is a simple unsalted hash of a predictable phrase, publishing it on-chain or storing it in an accessible provider can allow attackers to test guesses offline.
The fact that a system calls something a commitment does not make the underlying secret high entropy.
Commitments can create correlation
If the same recovery commitment is reused across several smart accounts, observers may be able to infer that those accounts share a recovery relationship.
Changing the recovery secret should be possible
The ERC's rationale explicitly recognizes recommitment.
A user can unsubscribe and subscribe again with new recovery data, potentially through a multicall.
This allows a compromised or aging recovery secret to be replaced without necessarily replacing the provider itself.
Multiple recovery providers reduce one dependency but increase configuration complexity
One of ERC-7947's strongest design ideas is that a smart account can support multiple recovery providers.
The account does not have to depend permanently on one vendor.
A user could theoretically configure different recovery mechanisms and preserve more than one path back into the account.
This can reduce availability risk.
It can also increase takeover surface.
Availability improves
If Provider A disappears, Provider B may remain available.
If one recovery method depends on a lost device, another method may still work.
Takeover paths multiply
If any single provider can independently replace account access, compromising the weakest provider may be enough to take over the account.
Threshold behavior is not standardized by ERC-7947
The core interface does not require two of three providers, unanimous recovery, or any specific threshold.
A smart-account or provider design could add such policy, but users should not infer threshold security merely because several providers are registered.
What recoverAccess actually does
The core recovery function takes three arguments:
The smart account must first verify that the provider has previously been added.
It then calls the provider's recover function.
If proof verification succeeds, the smart account updates its access according to the subject supplied in the recovery call.
This architecture separates proof validation from account mutation.
The provider decides whether the proof satisfies its recovery rule.
The account decides how the recovered subject changes access.
The subject field is deliberately broader than an owner address
A traditional social recovery wallet is often described as replacing one owner address with another.
ERC-7947 avoids hardcoding that model.
The subject is arbitrary bytes.
This matters because smart accounts can use access structures such as:
- A single owner address.
- Several owner addresses.
- A passkey or WebAuthn credential.
- A validator module.
- A role identifier.
- A multisignature configuration.
- A session-independent root credential.
- A custom authentication object.
A recovery interface limited to address replacement would not work cleanly for every smart account.
Arbitrary bytes provide flexibility.
They also demand strict parsing.
Encoding ambiguity can become takeover risk
If the account interprets malformed subject bytes differently from the wallet interface, the user can approve one visible owner while the contract installs another access configuration.
Length and type assumptions need validation
A smart account expecting an encoded address should reject malformed subject lengths rather than truncating or coercing unexpected input.
Wallets should render subject meaning
Users should see "Recovery will set Owner to 0x..." rather than "subject: 0xa928..." when the wallet understands the account's access model.
Why the provider recover function uses object and proof
The provider interface names the first recovery value object rather than subject.
The proposal explicitly allows object and subject to differ.
This gives providers flexibility in how proof statements are formed.
For example, the smart account may ultimately install an encoded owner structure while the provider verifies a proof about an associated recovery object.
That flexibility is useful for zero-knowledge and custom authentication systems.
It can also create semantic mismatch if a provider verifies one statement while the account applies another unrelated access change.
A valid proof should never become a generic voucher that can be attached to an arbitrary replacement owner, role, or credential unless that is explicitly the intended security policy.
ERC-7947 does not prescribe one proof technology
The proof argument is arbitrary bytes.
The specification gives examples such as a zero-knowledge proof, zero-knowledge AI proof, signature, or another provider-defined recovery proof.
This intentionally avoids making one recovery technology mandatory.
Signature proof
A backup credential might sign a recovery statement.
The provider verifies the signature against enrolled recovery data.
Zero-knowledge proof
A user could prove knowledge of a recovery secret without revealing the secret directly.
Multi-factor proof
A provider can potentially require several factors and encode verification into one proof result.
Identity-oriented proof
A provider could incorporate another authentication model, though such a design would introduce additional trust, privacy, revocation, and availability questions.
The standard provides interoperability at the interface boundary.
It does not make every proof scheme equally secure.
Recovery proofs must not be reusable
ERC-7947 explicitly requires recovery providers to ensure that a proof cannot be reused.
The proposal gives nonce updates as an example mechanism.
This requirement is essential because recovery proofs can represent near-root authority.
Why proof replay is catastrophic
A legitimate user recovers Account A from old credential X to new credential Y.
An attacker records the proof from the public transaction.
If the same proof remains valid, the attacker could submit it again later.
Depending on what the proof binds, they may be able to trigger another access change.
Proofs should bind to the intended account
A proof valid for Account A should not automatically recover Account B merely because both use the same provider.
Proofs should bind to the intended new access object
A proof authorizing recovery to Alice's new owner credential should not be reusable to recover the account to Mallory.
Proofs should include freshness
Nonce, counter, nullifier, epoch, challenge, or another one-time mechanism can establish that an old proof is no longer acceptable.
Where chain scope fits into ERC-7947
Unlike some wallet RPC standards, ERC-7947 does not define a top-level chainId parameter in the recovery interface.
The recovery action occurs in the context of the smart account contract deployed on a specific chain.
That does not mean proof systems can ignore chain binding.
Cross-chain account addresses can match
The same deterministic smart-account address can exist on Ethereum, Base, Arbitrum, Optimism, Polygon, or another EVM chain.
Recovery commitments can be similar across networks
A wallet can intentionally use the same recovery setup for multiple chains.
A generic proof can become cross-chain reusable
If the provider accepts a proof that binds only to an account address and new owner but not the chain or provider context, a proof observed on one chain could potentially be meaningful on another deployment using the same configuration.
A robust provider should therefore define the exact domain of its proof carefully.
Depending on the scheme, useful bound values can include chain identifier, smart-account address, provider address, recovery object, nonce, proof purpose, and protocol version.
ERC-7947 does not define one universal recovery expiry
The proposal does not include a mandatory expiry timestamp in addRecoveryProvider, recoveryData, or recoverAccess.
That is a key difference from permission standards where authority may expire automatically after a specified time.
A registered recovery provider can potentially remain configured indefinitely until removed, depending on the smart-account design.
Long-lived recovery is often necessary
A recovery system that expires after 30 days would be useless if the user loses their key next year.
Recovery intentionally needs persistence.
Persistence creates stale-provider risk
A provider added three years ago might later be abandoned, upgraded, compromised, or acquired by another organization.
Provider-specific proofs can still expire
A provider can design challenges or signed recovery messages with timestamps, nonces, or short validity windows.
Wallets should periodically review long-lived providers
Recovery configuration should be treated like an emergency-access list, not something users configure once and never inspect again.
Removing a provider is the primary ERC-7947 revocation path
The smart-account interface includes removeRecoveryProvider.
The proposal says this function should be access controlled.
When called, the smart account must invoke unsubscribe on the provider.
The provider's unsubscribe implementation must delete all recovery data associated with the calling smart account.
This creates a clean conceptual revocation flow:
Revocation must change both sides
Removing the provider from the account prevents recoverAccess from accepting it as a registered provider.
Deleting provider-side recovery data reduces stale state and future confusion.
Wallet UI should confirm removal
Users should be able to verify that the provider no longer appears in the account's active recovery configuration.
Provider removal is not token approval revocation
If the same account also has ERC-20 allowances, Permit2 permissions, session keys, or other modules, removing a recovery provider does not remove those unrelated authorizations.
Changing recovery secrets without changing providers
ERC-7947's rationale describes an important maintenance workflow.
A user may want to recommit to new recovery data for security reasons.
Instead of replacing the entire provider, the account can unsubscribe and subscribe again with a new commitment.
Those operations can potentially be executed together through multicall.
Why recommit?
The recovery secret may have been exposed.
A backup authentication device may have been replaced.
A user may want stronger cryptographic parameters.
A recovery factor may no longer be trustworthy.
Atomic recommitment is preferable
If unsubscribe and subscribe occur in separate transactions, a temporary window can exist where no recovery configuration is available.
A batched or atomic update can reduce that gap where the smart-account architecture supports it safely.
The most direct takeover attack: malicious recovery-provider enrollment
The ERC's official security considerations explicitly warn about this scenario.
A user can be phished into adding a malicious recovery provider.
That provider can then accept a fake recovery proof.
The result can be full account control.
This is not a theoretical side issue.
It is the central risk created whenever recovery becomes programmable.
The attacker does not need the primary key after enrollment
The victim signs one provider-enrollment transaction while still in control.
The attacker waits.
Later, the malicious provider approves a fake proof and the account access is changed.
The attack can be delayed deliberately
An attacker can wait weeks before triggering recovery so the victim does not connect the takeover with the earlier configuration transaction.
The provider can imitate a legitimate recovery service
A phishing frontend can display the brand name of Provider A while inserting Provider B's contract address.
Wallets should identify provider contracts independently
Where reliable metadata is available, wallets should show provider identity, verified contract information, and warnings for unknown or newly deployed providers.
Access control on add and remove functions is not optional in practice
The specification uses SHOULD language for access control around provider addition and removal.
From a production security perspective, these functions are among the most sensitive operations in the account.
Unauthorized add is takeover preparation
An attacker installs a provider they control.
Unauthorized removal is recovery sabotage
An attacker removes legitimate providers, leaving the victim unable to recover after future credential loss.
Front-running can matter
If a user is attempting to replace a compromised provider, an attacker with another active authorization path might race the defensive transaction.
Role separation can help
Some smart accounts may choose stricter authentication for recovery configuration than for routine transactions.
Changing emergency ownership infrastructure deserves stronger confirmation than swapping a small token balance.
A legitimate provider can become compromised later
A provider can be honest when enrolled and unsafe years later.
Signing-key compromise
If provider verification depends on privileged keys, compromise can undermine recovery validation.
Smart-contract vulnerability
A bug in proof validation can allow false recoveries.
Upgrade compromise
An upgradeable provider can be changed to accept weaker evidence.
Governance compromise
An administrator, multisig, DAO, or service operator controlling provider upgrades can itself be attacked.
Availability failure
The provider can disappear, cease operating, or fail to process proofs when needed.
This is why multiple providers can improve resilience while also increasing the number of components that require ongoing review.
Upgradeable recovery providers deserve special scrutiny
A user can inspect Provider version 1 today and enroll it.
The provider later upgrades to version 2.
The user does not submit a new enrollment transaction.
The recovery logic controlling the user's account has nevertheless changed.
Upgrade authority should be visible
Who can replace the provider implementation?
Timelocks can improve reaction time
A delayed upgrade can give users time to remove the provider before new logic becomes active.
Emergency upgrades create a tradeoff
A provider may need to patch a critical vulnerability quickly.
Fast upgrades reduce response time but concentrate administrator power.
Immutable providers reduce upgrade risk but complicate fixes
No architecture eliminates every tradeoff.
Users need to know which tradeoff their recovery provider chose.
Smart-account upgrades can also change recovery semantics
The smart account itself can be modular or upgradeable.
An upgrade can change:
- How recovery providers are stored.
- How subject bytes are interpreted.
- Which provider contracts are recognized.
- How recoverAccess applies the new subject.
- Which access roles recovery can replace.
- Whether recovery requires additional delays or approvals.
An account upgrade that accidentally removes recovery safeguards can turn previously reasonable provider registrations into dangerous authority.
Recovery tests should therefore be part of every major account implementation upgrade.
ERC-7947 is broader than traditional social recovery
Social recovery commonly means a set of trusted guardians can collectively restore wallet access.
ERC-7947 does not require that model.
Its providers can implement social recovery, but they can also implement cryptographic recovery services that do not rely on named human guardians.
A provider can represent a guardian system
The provider's recover function can verify whether the required guardian approval threshold was reached.
A provider can represent a zero-knowledge secret
The user proves knowledge of an enrolled secret without asking friends or family.
A provider can represent two-factor recovery
The verification logic can combine recovery factors.
Multiple provider styles can coexist
One smart account could potentially register a zero-knowledge provider and a separate guardian-oriented provider as independent recovery options.
This composability is a major benefit of the interface.
It is also why wallets must identify the security model of each provider rather than showing every provider as the same generic "Recovery Method."
Human guardian recovery has its own takeover risks
If a provider implements social recovery, additional threats emerge.
Guardian collusion
Enough guardians intentionally cooperate to recover the account away from the legitimate user.
Guardian compromise
Attackers compromise enough guardian credentials to satisfy the threshold.
Guardian phishing
Guardians are tricked into approving a recovery request they believe belongs to the account owner.
Guardian loss
Too many guardians lose access, making legitimate recovery impossible.
Guardian privacy
Publicly identifiable guardian relationships can reveal social or organizational connections.
ERC-7947 itself does not prescribe how these issues must be solved because they belong to the provider's recovery scheme.
Zero-knowledge recovery solves some privacy problems but creates proof-system dependencies
Zero-knowledge recovery can allow a user to prove possession of recovery knowledge without exposing the secret itself.
This can be powerful.
It does not remove implementation risk.
Verifier correctness
A bug in the verifier can accept invalid proofs.
Circuit correctness
A valid proof can faithfully prove the wrong statement if the circuit does not encode the intended recovery condition.
Trusted-setup assumptions
Some proof systems have setup or parameter assumptions that must be handled correctly.
Nullifier or nonce handling
Replay prevention must survive even if the proof itself is cryptographically valid.
Recovery secret entropy
Zero knowledge hides a secret during proof generation but cannot transform an easily guessable secret into a strong one.
How an ERC-7947 takeover can unfold
Consider a smart account with $250,000 in assets.
The user receives a fake wallet-security alert.
The page claims that a new recovery provider must be activated to protect the account.
The user connects the wallet.
The site generates an addRecoveryProvider transaction.
The contract address belongs to the attacker.
The wallet displays an opaque call saying only "Contract Interaction."
The user signs.
No assets move.
The wallet balance remains unchanged.
The attacker waits three weeks.
The malicious provider then accepts a fake proof.
recoverAccess replaces the account's owner with the attacker's credential.
The AccessRecovered event is emitted.
The attacker now controls the smart account through legitimate contract state.
They can transfer assets without ever having stolen the victim's original private key.
Should smart-account recovery have a delay?
ERC-7947 does not mandate a recovery delay.
A smart account or provider can still implement one.
Whether a delay is appropriate depends on the threat model.
Immediate recovery improves availability
A legitimate user locked out of an account can restore access quickly.
Immediate recovery helps attackers too
If a provider or proof is compromised, an attacker can complete takeover before the original owner has time to react.
Delayed recovery creates a cancellation window
The existing owner can potentially cancel an unexpected recovery before access changes.
Delay can be dangerous after genuine credential loss
If the old key is compromised rather than merely lost, waiting several days gives the attacker holding the old key more time to drain funds.
A mature wallet may therefore use different recovery modes for loss and compromise rather than applying one universal delay.
Recovery events should trigger high-priority notifications
ERC-7947 defines explicit events for provider addition, provider removal, and recovered access.
These events create valuable monitoring hooks.
RecoveryProviderAdded
A wallet can alert the user immediately whenever a new provider appears.
RecoveryProviderRemoved
Unexpected removal can signal sabotage or compromised account authority.
AccessRecovered
This should be treated as a critical account-security event.
A user who did not initiate recovery needs to assume takeover until proven otherwise.
Out-of-band alerts are valuable
Notifications should not depend only on the smart account being accessible.
Email, push notification, a secondary device, or another independent alert channel can warn the user when their primary wallet is no longer under their control.
What should happen immediately after legitimate recovery
Successfully replacing account access is only the first part of incident recovery.
Verify new access
Confirm that the intended owner, signer, role, or authentication module is active.
Invalidate lost credentials
The old access subject should no longer retain authority unless the account intentionally uses multiple concurrent owners.
Review recovery providers
Remove providers or recovery data that became compromised during the incident.
Rotate recovery commitments
If the recovery secret was disclosed as part of the recovery process or compromise, recommit to fresh recovery data.
Review token approvals
The old owner or attacker may have created ERC-20 allowances before recovery.
TokenToolHub's Crypto Approval Risks guide explains why persistent spender authority can survive an account ownership change.
Review Permit2 state
Permit2 authorization can also remain after the account owner changes. The Permit2 and Allowances guide covers the additional approval layer that should be checked independently.
Recovery does not reverse an attack that already happened
A legitimate user can recover control after a key compromise.
The blockchain does not automatically reverse transactions executed before recovery.
Transferred assets remain transferred
Recovering the account does not return ETH or tokens already sent away.
Approvals can remain active
An attacker may have created allowances before losing control.
Loans and vault positions persist
The attacker could have borrowed, supplied collateral, opened derivatives, bridged assets, or entered staking positions.
Delegate or module changes may persist
Smart accounts can have additional authorization modules beyond the main recovered subject.
A post-recovery audit should therefore inspect the entire wallet state, not just confirm that the new owner can sign.
Decode recovery transactions independently
ERC-7947 recovery is observable on-chain.
That makes transaction analysis an important verification layer.
TokenToolHub's Transaction Decoder can help inspect the EVM transaction that added a provider, removed a provider, or executed recovery.
Provider enrollment review
Confirm the provider contract address passed to addRecoveryProvider.
Recovery data review
Inspect the encoded recoveryData where interpretation is possible.
Recovery call review
Confirm which provider was used and what subject bytes were passed to recoverAccess.
Event review
Look for RecoveryProviderAdded, RecoveryProviderRemoved, AccountSubscribed, AccountUnsubscribed, and AccessRecovered events.
Nested call review
Smart accounts may execute recovery configuration through multicall or modular account infrastructure, so the outer transaction alone may not reveal the full sequence.
Ownership recovery and spending approvals are separate layers
Imagine that an attacker controls a smart account for ten minutes.
They approve a malicious spender for unlimited USDC.
The legitimate user then successfully recovers the account.
The attacker no longer owns the smart account.
The malicious spender remains approved inside the USDC contract.
The spender can potentially use that allowance after recovery.
This is why incident recovery must be layered.
Recovery complements hardware protection rather than replacing it
Hardware wallets reduce the likelihood that a root signing key is extracted from an internet-connected machine.
A device such as Ledger can keep a primary signing credential isolated while a compatible smart-account architecture adds separate recovery mechanisms around it.
An air-gapped signing approach such as Keystone can similarly reduce direct exposure of a root credential.
Recovery providers solve a different problem.
Hardware protects the key you still possess.
Recovery helps when the normal access path is lost or must be replaced.
A hardware-protected owner can still be taken over if the user signs a malicious recovery-provider enrollment transaction.
Strong key custody does not make recovery configuration harmless.
Compromised frontend risk
A user can visit the correct wallet interface and still be exposed if the frontend is compromised.
The attacker can alter recovery parameters before the transaction reaches the wallet.
Provider substitution
The interface displays a trusted provider but transaction calldata contains another contract address.
RecoveryData substitution
The user intends to commit to their own recovery secret while the frontend inserts attacker-controlled commitment data.
Subject substitution
During legitimate recovery, the interface displays the user's new owner while recoverAccess receives an attacker-controlled subject.
Removal sabotage
A compromised interface can trick the user into removing safe recovery providers instead of adding one.
Clear signing is therefore particularly important for recovery transactions because the visible web interface cannot be treated as the ultimate source of truth.
Partial execution and recovery-state mismatch
Recovery workflows can involve several calls.
The exact atomicity depends on how the smart account and provider are implemented.
Provider added but UI state fails
The on-chain provider registration succeeds while the wallet interface reports an error.
The user retries and accidentally creates additional configuration.
Provider removal succeeds but re-enrollment fails
During recovery-secret rotation, unsubscribe succeeds in one transaction but the new subscribe transaction fails.
The account can temporarily lose that recovery path.
Access recovery succeeds but cleanup fails
The new owner is installed, but subsequent transactions intended to remove compromised modules or allowances revert.
Off-chain recovery service state can lag on-chain state
A provider's web dashboard can still display a subscription after the smart account has removed it.
Users should verify contract state rather than relying solely on service dashboards.
Recovery security includes availability, not only takeover resistance
A recovery system can fail safely against attackers while still failing the legitimate user.
Provider outage
The recovery provider is unavailable when the account owner loses access.
Lost recovery factor
The user loses the primary key and the recovery secret simultaneously.
Provider abandonment
The service shuts down years after enrollment.
Broken verifier after chain upgrade
A provider's implementation stops functioning correctly in the current environment.
Dependency on centralized infrastructure
The contract is available, but proof generation depends on a proprietary server that no longer operates.
Multiple recovery providers can improve availability if their failure modes are genuinely independent.
Recovery can expose highly sensitive identity relationships
Recovery mechanisms often connect information users intentionally keep separate.
Guardian relationships
Public guardian addresses can reveal social links.
Provider reuse
Using identical recoveryData across accounts can create correlations.
Identity provider linkage
A recovery provider using email, phone, government identity, biometric systems, or another off-chain account can link a pseudonymous wallet to real-world identity.
Recovery events are public
An AccessRecovered event can signal that the account underwent a security or access incident.
Privacy should therefore be considered during provider selection, not only after recovery happens.
What ERC-7947 deliberately does not standardize
The proposal defines interoperability boundaries without imposing one complete recovery policy.
| Security property | ERC-7947 position | Implementation question |
|---|---|---|
| Provider enrollment interface | Standardized. | Who is allowed to call it and what confirmation is required? |
| Provider removal interface | Standardized. | Can removal be delayed, blocked, or front-run? |
| Recovery proof format | Not standardized. | Signature, ZK proof, guardian threshold, identity proof, or another mechanism? |
| Universal expiry | Not defined. | Does the provider or proof scheme impose timing limits? |
| Mandatory recovery delay | Not defined. | Is recovery immediate or subject to a challenge window? |
| Guardian threshold | Not defined. | Can one provider recover alone, or does the account add another policy layer? |
| ChainId field | Not part of the core interface. | Does the proof itself bind to chain context where necessary? |
| Proof replay protection | Required. | Nonce, counter, nullifier, consumed proof hash, or another mechanism? |
| Recovered subject format | Arbitrary bytes. | How does the smart account interpret and validate it? |
| Multiple providers | Supported conceptually. | Are providers independent alternatives or combined through a threshold policy? |
How to evaluate a recovery provider
The provider is effectively part of the account's root-security perimeter.
Evaluation should therefore resemble infrastructure and security-module due diligence rather than ordinary DApp selection.
Proof statement
What exactly must be proven to authorize recovery?
Account binding
Can a proof for another account be reused?
Subject binding
Does the proof authorize the exact new credential being installed?
Replay protection
How does the provider make old proofs unusable?
Upgrade authority
Can provider logic change?
Administrator controls
Can an operator manually bypass normal proof verification?
Availability
Does legitimate recovery depend on centralized servers?
Privacy
What identity or guardian information becomes public or known to the provider?
Recovery-data rotation
Can the user replace compromised recovery data safely?
Removal
Can the account reliably unsubscribe and delete provider-side data?
Account-wide review after suspicious recovery activity
A recovery incident is rarely limited to the recoverAccess call.
An attacker who gained account access may have interacted with numerous protocols before the owner noticed.
A broader review should inspect:
- Recent asset transfers.
- New token approvals.
- Permit2 authorization.
- NFT operator approvals.
- New smart-account modules.
- Changed owners or validators.
- Borrowing positions.
- Vault deposits.
- Bridging activity.
- Unexpected counterparties.
TokenToolHub's Wallet Safety 101 provides a broader framework for wallet compartmentalization and incident hygiene, while transaction-by-transaction investigation can establish the actual sequence of changes.
Worked ERC-7947 recovery scenarios
Scenario 1: legitimate lost-key recovery
A user loses access to their primary hardware signer.
The smart account still has a trusted recovery provider registered.
The user generates the required recovery proof and specifies a new owner credential as the recovered subject.
recoverAccess confirms the provider is registered.
The provider validates the proof and invalidates its one-time recovery nonce.
The smart account installs the new owner.
The user verifies that the old signer is no longer active and rotates recovery data.
This is the intended availability benefit.
Scenario 2: malicious provider phishing
A fake support page tells the user that their wallet must be "secured."
The transaction actually calls addRecoveryProvider with an attacker contract.
The attacker waits until the user stops thinking about the configuration change.
The provider later accepts an arbitrary proof and recovers the account to the attacker.
No seed phrase theft was required.
Scenario 3: provider proof replay
A legitimate user recovers the account once.
The provider fails to consume a nonce or proof identifier.
The same proof remains valid.
An observer copies it from transaction calldata and resubmits it.
This violates the ERC's explicit anti-replay requirement and can turn public blockchain data into an account takeover tool.
Scenario 4: proof does not bind the new subject
A provider verifies only that the caller knows a recovery secret.
The proof does not commit to the new owner being installed.
A malicious transaction relay captures the valid proof and substitutes its own subject bytes.
If the account and provider do not bind proof authorization to the intended new subject, the attacker can redirect legitimate recovery.
Scenario 5: cross-chain recovery replay
The same smart-account address and recovery commitment exist on two EVM chains.
A provider proof is valid for Account A and NewOwner B but contains no chain-specific domain information.
The user recovers on one network.
An attacker attempts to reuse the proof on the second network.
Provider designs should evaluate whether chain binding is required for their threat model.
Scenario 6: old provider becomes compromised
A user registers a reputable provider in 2026.
They forget about it.
In 2029 the provider's upgrade administrator is compromised.
The attacker deploys verification logic that accepts invalid proofs.
Every account that retained the provider can become exposed.
Long-lived recovery infrastructure requires periodic review.
Scenario 7: malicious smart-account upgrade
The provider remains secure.
The account implementation is upgraded.
A bug causes recoverAccess to update the owner before checking whether the provider proof succeeded.
The provider is blamed initially, but the vulnerability exists inside the account integration.
Both sides of the interface are security critical.
Scenario 8: provider removal sabotage
An attacker gains temporary routine account authority but cannot immediately move a protected vault balance.
They remove every recovery provider first.
The victim later loses access to the compromised primary signer and discovers there is no remaining recovery path.
Unauthorized provider removal can be denial of recovery even without direct theft.
Scenario 9: recommitment failure
A user believes their recovery secret leaked.
They call unsubscribe in one transaction and plan to subscribe with fresh recovery data in a second.
The second transaction fails.
The account remains without that recovery provider until the user notices.
Atomic rotation can reduce this availability gap.
Scenario 10: stale provider dashboard
The user removes a provider on-chain.
The provider's web interface continues showing the account as protected because its indexer has not updated.
The user trusts the dashboard and assumes recovery remains available.
On-chain state should be treated as authoritative for whether the account considers the provider registered.
Scenario 11: recovered owner but malicious allowance remains
An attacker temporarily controls the smart account.
Before the owner recovers it, the attacker approves a spender for unlimited USDC.
The legitimate owner successfully uses ERC-7947 recovery.
The owner address is fixed.
The spender allowance remains.
Account recovery must be followed by approval review.
Scenario 12: guardian provider compromise
A social-recovery provider requires three of five guardian approvals.
An attacker compromises three guardians through phishing.
The provider correctly verifies the threshold according to its rules.
The smart account correctly accepts the provider.
Yet the attacker still takes over the account because the underlying guardian security failed.
Interface correctness cannot compensate for a weak recovery policy.
Scenario 13: low-entropy recovery secret
The user chooses a simple phrase as a recovery secret.
recoveryData contains a commitment derived directly from it.
An attacker enumerates common phrases offline until the commitment matches.
The zero-knowledge proof later protects the secret in transit, but the secret itself was already guessable.
Scenario 14: immediate malicious recovery
A provider is compromised at 09:00.
At 09:01 it accepts a false proof.
The account has no recovery delay or independent notification.
By 09:02 the attacker controls the account and transfers assets.
A delay could have created reaction time, although delay introduces its own tradeoffs when the old credential is compromised.
Scenario 15: recovery provider unavailable
The provider is perfectly secure but depends on a hosted proof-generation API.
The company shuts down.
The on-chain provider contract remains deployed but the user cannot generate the required proof.
Having a second independent provider can protect against this availability failure.
ERC-7947 recovery risk matrix
User checklist before enabling smart-account recovery
Before adding a recovery provider
- Confirm that the transaction is changing recovery configuration.
- Do not treat provider enrollment as a routine wallet connection.
- Verify the smart-account address being configured.
- Verify the network on which the recovery provider is being added.
- Verify the full recovery-provider contract address.
- Confirm the provider through an independent trusted source.
- Check whether the provider contract is upgradeable.
- Identify who controls provider upgrades.
- Understand what recoveryData represents.
- Avoid low-entropy recovery secrets.
- Avoid reusing the same recovery secret unnecessarily across accounts.
- Understand what proof will be required if normal access is lost.
- Confirm whether proof generation depends on a centralized service.
- Understand whether one provider alone can replace account access.
- Do not assume several registered providers create a threshold automatically.
- Check whether recovery is immediate or delayed.
- Confirm how you can remove the provider later.
- Confirm how recovery data can be rotated.
- Store recovery factors separately from the primary signing credential.
- Document the recovery procedure before an emergency happens.
- Test recovery with a low-value account before relying on it for significant funds.
- Periodically review active recovery providers.
- Remove providers that are no longer maintained or trusted.
- Monitor provider-addition and removal events.
- Treat an unexpected AccessRecovered event as a critical incident.
Smart-account and wallet-builder checklist
Recovery implementation controls
- Strongly access control addRecoveryProvider.
- Strongly access control removeRecoveryProvider.
- Reject address(0) provider registrations.
- Prevent duplicate provider states from creating ambiguous behavior.
- Call provider subscribe exactly as intended during enrollment.
- Verify successful subscription behavior where appropriate.
- Emit RecoveryProviderAdded for every successful provider addition.
- Call unsubscribe when a provider is removed.
- Ensure removed providers can no longer pass the account's provider-existence check.
- Emit RecoveryProviderRemoved reliably.
- Validate that recoverAccess uses only registered providers.
- Apply the new access subject only after proof verification succeeds.
- Validate subject encoding before mutating account access.
- Prevent malformed subject data from creating unexpected roles.
- Ensure proof authorization binds to the correct access transition.
- Consider account and chain domain separation in proof design.
- Ensure provider proofs cannot be reused.
- Test nonce, nullifier, or replay-consumption logic thoroughly.
- Test concurrent recovery attempts.
- Test recovery transactions racing with provider removal.
- Test recovery immediately before and after provider upgrades.
- Test account upgrades against existing provider registrations.
- Test ownerless and role-based subject encodings.
- Test multicall-based recovery-data rotation.
- Test partial rotation failure.
- Consider a recovery delay where appropriate for the threat model.
- Consider emergency cancellation mechanisms where practical.
- Provide out-of-band notifications for provider changes.
- Provide urgent notification for AccessRecovered.
- Expose active recovery providers in the wallet UI.
- Show provider contract identity rather than a generic recovery label.
- Show whether the provider is upgradeable.
- Make provider removal easy while the user still controls the account.
- Make recovery-data rotation understandable.
- Never describe recovery as removing every other wallet authorization.
- Guide users through post-recovery allowance and module review.
Recovery-provider builder checklist
Provider-side proof and state controls
- Associate recoveryData with the exact subscribing smart account.
- Do not allow one account's commitment to authorize another account unintentionally.
- Validate recoveryData format during subscription.
- Delete all account-associated recovery data during unsubscribe as required.
- Ensure unsubscribed accounts cannot recover through stale provider state.
- Define exactly what the recovery proof proves.
- Bind proofs to the relevant account.
- Bind proofs to the intended recovery object where required.
- Consider chain and provider-domain binding.
- Use strong anti-replay protection.
- Consume nonces, counters, nullifiers, or equivalent one-time state atomically.
- Reject already consumed proofs.
- Reject malformed proof encodings.
- Use appropriate cryptographic libraries and verifier implementations.
- Audit proof-verification logic independently.
- Test edge cases around proof length and parsing.
- Test replay attempts across accounts.
- Test replay attempts across networks where relevant.
- Protect provider upgrade authority.
- Document administrator powers.
- Provide users enough time to remove a provider before non-emergency upgrades where practical.
- Plan for provider deprecation.
- Provide a migration path before infrastructure shutdown.
- Minimize recovery-data leakage.
- Avoid requiring unnecessary personally identifiable information.
- Monitor abnormal recovery volume.
- Alert on repeated failed proof attempts where appropriate.
- Document whether recovery is immediate or delayed.
Incident response after suspicious recovery activity
Recovery incidents can move quickly because the attacker may be targeting root account access.
Verify current access
Determine whether the expected owner, signer, role, or module still controls the smart account.
Inspect recovery providers
Identify every registered provider and compare them with the intended configuration.
Remove malicious providers
If legitimate authority remains, remove unknown or compromised providers immediately.
Decode recent transactions
Review provider additions, removals, recovery calls, owner changes, module changes, transfers, and approvals.
Clean residual authority
Review ERC-20 allowances, Permit2, NFT operators, installed modules, delegates, and protocol positions.
Rebuild recovery safely
Rotate compromised recovery data and establish independent recovery paths only after the cause of the incident is understood.
Continuous recovery monitoring is worth the effort
Recovery configuration usually changes far less frequently than token balances.
That makes unexpected changes especially informative.
Provider-added alerts
Any new provider should trigger a high-priority notification.
Provider-removed alerts
Unexpected removal can mean the account's emergency path is being sabotaged.
Access-recovered alerts
This is one of the highest-severity smart-account events.
Provider upgrade alerts
If a trusted provider is upgradeable, changes to implementation or administrator configuration can affect every enrolled account.
RecoveryData rotation alerts
A recommitment should be expected and documented. An unexpected one can indicate compromise.
Multiple providers are valuable only when their failures are independent
A user may register three recovery providers and believe they have strong redundancy.
That conclusion can be false.
Same backend
Three provider contracts rely on one centralized API.
Same administrator
Three providers are upgradeable by the same multisig.
Same recovery secret
All providers ultimately rely on one backup phrase.
Same identity account
All recovery mechanisms depend on one email account.
The provider count is three.
The practical recovery dependency is one.
Redundancy should be evaluated by failure domain rather than raw provider count.
ERC-7947 fits the wider account-abstraction security model
The proposal is intended to work across account-abstraction designs rather than being tied to one wallet architecture.
Its rationale specifically discusses compatibility with account-abstraction directions including ERC-4337 smart accounts and EIP-7702-style account contractization.
The broad direction is important.
Ethereum account security is becoming programmable.
A wallet no longer has to choose between one permanent private key and irreversible loss.
Accounts can rotate credentials.
They can use multiple authenticators.
They can add emergency recovery.
They can separate routine and root authority.
They can potentially migrate to new cryptographic signature systems over time.
The Ethereum security roadmap increasingly treats flexible account authentication as part of long-term security planning, including the need for accounts to move toward different signature mechanisms as cryptographic requirements evolve.
Recovery is therefore not only a consumer convenience.
It is part of building accounts that can survive years of credential, device, and cryptographic change.
Recovery should be stronger than routine application access
Most wallet activity does not need root-level authority.
A user swaps tokens.
A user signs into a DApp.
A user claims a reward.
A user approves a limited token amount.
Recovery configuration is fundamentally different.
It determines who can regain ultimate control when the normal authentication mechanism fails.
That means wallets can justify stronger protections for provider changes:
- Hardware confirmation.
- Long-press or secondary confirmation.
- Clear provider identity.
- Out-of-band notification.
- Short configuration timelocks.
- Risk warnings for unknown contracts.
- Reauthentication through a root credential.
The goal is not to make recovery unusably difficult.
It is to make installation of a new root-access path visibly different from a normal DApp transaction.
Recovery design must balance two opposite failures
Wallet recovery has an unavoidable tension.
Recovery too difficult
The legitimate user loses a key and permanently loses the account because recovery is inaccessible, overcomplicated, or unavailable.
Recovery too easy
An attacker satisfies the recovery path more easily than they could compromise the original account credential.
A good recovery system must be easier for the legitimate owner than permanent seed loss while remaining harder for an attacker than compromising ordinary wallet activity.
That is a demanding design target.
Proof quality matters more than proof complexity
A sophisticated zero-knowledge recovery system can still be insecure.
A simple signature-based provider can still be secure for an appropriate use case.
The correct question is not whether the proof sounds advanced.
Ask what statement is actually being proven.
Who is the claimant?
What credential or secret establishes their recovery right?
Which account is being recovered?
Can proof valid for another account be reused?
What new subject is authorized?
Is the replacement signer included in the proof statement?
Is the proof fresh?
How is replay prevented?
Which provider and protocol version apply?
Can the same proof be interpreted differently by another contract?
Which chain is intended?
Could identical deployments make a proof meaningful elsewhere?
A proof system that answers those questions precisely is more valuable than complexity for its own sake.
Common ERC-7947 recovery misconceptions
ERC-7947 is a social recovery standard
It can support social recovery, but it is broader. Recovery providers can implement many different proof mechanisms.
The recovery provider owns my account
Not necessarily. The provider verifies recovery according to its scheme. However, a provider that can accept false proofs can effectively become a takeover path, so its security is still critical.
Adding several providers automatically requires several approvals
No. ERC-7947 supports multiple providers but does not mandate a threshold across them.
ERC-7947 has a built-in recovery timeout
No. The core interface does not define one universal expiry or recovery delay.
Recovery proofs are automatically chain-specific
No. Chain binding depends on the provider's proof design and smart-account context.
A proof can be reused if it is still cryptographically valid
No. The ERC explicitly requires providers to ensure that proofs cannot be reused.
Recovery only changes an EOA owner
No. The subject is arbitrary bytes to support different access-control structures.
Removing a provider is only a wallet UI preference
No. Provider removal is part of the on-chain recovery authority lifecycle and calls the provider's unsubscribe function.
unsubscribe can leave recoveryData behind
The provider interface requires unsubscribe to delete recovery data associated with the calling smart account.
Successful recovery makes the wallet clean again
No. Approvals, malicious modules, loans, transfers, or other state created before recovery can remain.
A hardware wallet makes malicious recovery impossible
No. A user can use a hardware signer to authorize a malicious provider-registration transaction.
A recovery provider is safe if its address is non-zero
No. The non-zero requirement only prevents an invalid address configuration. It does not prove contract safety.
The most complicated proof is always the safest
No. Security depends on what is proven, how replay is prevented, which account and subject are bound, and whether implementation assumptions are sound.
Recovery data should never change
No. The ERC rationale explicitly recognizes changing recovery commitments through unsubscribe and subscribe.
Provider events are just developer logs
No. They can serve as valuable wallet-security monitoring signals for unexpected configuration changes.
A practical ERC-7947 verification framework
Users and wallet teams can reduce the recovery problem to seven questions.
If any answer is unclear, recovery authority is not fully understood.
Which account?
Verify the exact smart account and chain.
Which provider?
Verify the actual contract address rather than a marketing name.
Which commitment?
Understand what recoveryData binds to and whether it exposes privacy or brute-force risk.
What proof?
Understand the recovery condition that must be satisfied.
What new access?
Understand exactly what subject recoverAccess will install.
How is replay prevented?
Look for nonce, counter, nullifier, or another robust one-time mechanism.
How is it revoked?
Confirm that the provider can be removed and unsubscribed before it becomes a problem.
Full post-recovery verification workflow
After recovering from lost or compromised access
- Confirm the expected new access subject is active.
- Confirm the old compromised subject cannot still authorize account actions.
- Review all registered recovery providers.
- Remove any provider that contributed to the compromise.
- Rotate recoveryData when the recovery factor may be exposed.
- Verify AccountUnsubscribed or equivalent provider state after removal.
- Review account implementation and validator modules.
- Check whether new owner or validator modules were installed.
- Review ERC-20 token approvals.
- Review Permit2 permissions.
- Review NFT operator approvals.
- Review DeFi lending positions.
- Review vault deposits and withdrawal rights.
- Review bridge transactions.
- Review recent counterparties.
- Decode suspicious transactions independently.
- Move assets if account integrity cannot be re-established confidently.
- Establish fresh recovery providers only after the compromise source is understood.
- Document the new recovery configuration.
- Test the new recovery process with minimal value where practical.
Why a common recovery interface matters
Without a shared recovery interface, every smart-account wallet can invent different function names, events, provider formats, and recovery tooling.
That fragmentation makes independent security software harder to build.
A common interface can improve:
- Wallet interoperability.
- Recovery-provider portability.
- Security monitoring.
- Provider marketplaces.
- Independent recovery dashboards.
- Smart-account migration tooling.
- On-chain event indexing.
- User choice between different recovery methods.
The proposal's motivation explicitly anticipates a future where smart accounts can aggregate several recovery providers and where different technologies, including zero-knowledge approaches, compete behind a common interface.
That is a useful direction.
Standardization does not eliminate provider risk.
It makes that risk easier to identify and reason about consistently.
A recovery-provider marketplace would need stronger security signals than a normal DApp directory
If ERC-7947 enables users to choose between many recovery providers, those providers are not equivalent to ordinary applications.
A DApp can usually be disconnected.
A recovery provider can potentially determine who controls the account during an emergency.
Useful provider-selection information would include:
- Provider contract address.
- Verification status.
- Audit history.
- Upgradeability.
- Administrator authority.
- Proof mechanism.
- Recovery delay.
- Replay protection.
- Service dependencies.
- Privacy model.
- Supported smart-account types.
- Provider deprecation policy.
- Incident history.
Popularity alone would not be sufficient evidence of safety.
The right mental model: recovery is a second root key implemented as policy
A traditional wallet has one obvious root secret: the private key or seed phrase.
A programmable recovery system distributes root authority differently.
The recovery provider may not literally possess a second private key.
It implements a rule that can create a replacement root credential when its proof condition is satisfied.
From the perspective of account takeover risk, that rule deserves the same caution as another master key.
The second sentence is why recovery security cannot be an afterthought.
Conclusion: recovery prevents permanent loss by creating another path to ultimate account authority
ERC-7947 smart account recovery addresses one of the hardest problems in self-custody.
A wallet can protect a private key perfectly and still fail the user if that key disappears forever.
Account abstraction allows Ethereum wallets to move beyond the irreversible "lose the key, lose the account" model.
ERC-7947 proposes a common recovery interface so smart accounts can register alternative recovery providers without requiring every provider and wallet to invent an incompatible integration.
The architecture is deliberately flexible.
A smart account manages trusted recovery providers.
Adding a provider sends provider-specific recoveryData to the provider's subscribe function.
The provider stores or processes that recovery commitment for the smart account.
If normal access later fails, recoverAccess receives a proposed new access subject, a registered provider, and an encoded recovery proof.
The smart account checks that the provider is authorized.
The provider validates the proof against the account's enrolled recovery data.
If verification succeeds, the account updates its access subject.
The account emits an AccessRecovered event.
That general flow is simple enough to support many recovery technologies.
The security implications are much deeper.
Every registered provider becomes part of the root-access perimeter.
If a provider accepts a fake proof, the smart account can follow the standard perfectly and still transfer control to an attacker.
If a user is phished into adding a malicious provider, the attacker can create a delayed takeover path without stealing the user's existing private key.
If proof replay is possible, a valid recovery transaction can become a reusable attack primitive.
If the proof does not bind to the intended replacement subject, a legitimate recovery can be redirected.
If provider state does not bind to the correct smart account, one account's recovery evidence can contaminate another.
If a provider is upgradeable, the logic users originally trusted can change years after enrollment.
If recovery depends on one centralized service, the user may discover during an emergency that their supposedly self-custodial recovery path cannot operate without that company.
The proposal therefore should not be interpreted as "recovery is secure because ERC-7947 is used."
The ERC standardizes interfaces.
Security depends on implementation and recovery policy.
The proposal's explicit requirement that recovery proofs cannot be reused is especially important.
Public blockchain transactions expose calldata.
A proof submitted once can be visible forever.
The provider must therefore consume a nonce, nullifier, counter, proof identifier, or equivalent state so the same proof cannot become a permanent recovery credential.
Recovery proof design should also establish exactly what is being authorized.
The account.
The intended new access subject.
The provider.
The recovery purpose.
Freshness.
And, where the architecture requires it, the chain and protocol domain.
The arbitrary bytes used for subject and proof make the interface flexible enough for ownerless and modular accounts.
That flexibility makes parsing and clear signing more important.
A user should never have to guess what a hexadecimal subject will become after recovery.
The wallet should render the actual effect:
Replace Owner A with Owner B.
Replace Passkey X with Passkey Y.
Install Validator Module Z.
Change recovery role to this credential.
The same principle applies when adding providers.
"Enable recovery" is not enough.
The wallet should make the provider contract and consequences clear because provider enrollment can create a new root-access path.
This is where TokenToolHub's Clear Signing in Crypto framework becomes directly relevant.
Recovery also does not exist in isolation from the rest of wallet security.
An attacker who temporarily controls an account can create token approvals before the owner recovers it.
They can establish Permit2 authority.
They can install modules.
They can borrow against assets.
They can bridge tokens.
They can transfer NFTs.
They can alter recovery providers themselves.
Regaining the owner role stops only the authority that the recovery change actually replaces.
It does not automatically clean every side effect left behind.
The Crypto Approval Risks guide provides the next layer for conventional spender authorization.
The Permit2 and Allowances guide covers separate Permit2 authority.
TokenToolHub's Transaction Decoder can help reconstruct provider addition, removal, recovery, transfers, approvals, multicalls, and other EVM actions surrounding a recovery incident.
And Wallet Safety 101 provides the broader operational framework for keeping routine credentials, high-value accounts, recovery factors, and DApp activity appropriately separated.
Users should also remember that more recovery providers do not automatically mean more security.
Three providers controlled by the same administrator are one failure domain.
Three providers using the same weak recovery secret are one failure domain.
Three providers relying on the same email account are one failure domain.
Real redundancy requires independent security assumptions.
The same logic applies to hardware custody.
Hardware protection and smart-account recovery are complementary.
The hardware signer reduces the chance of primary-key extraction.
The recovery mechanism reduces the chance of permanent loss when that primary access path fails.
Neither can safely replace understanding the other.
The best ERC-7947 configuration therefore does not maximize recovery convenience at any cost.
It creates an alternate access route whose proof is strong, whose provider is independently verifiable, whose state can be rotated, whose proofs cannot be replayed, whose access changes are clearly rendered, whose provider can be removed, and whose events are monitored continuously.
The standard's central security lesson can be reduced to one sentence:
That authority deserves the same level of scrutiny as the root credential it is designed to replace.
Verify the recovery transaction and the account state that remains afterward
After provider enrollment, removal, or access recovery, inspect the actual transaction, verify the effective owner or access subject, review persistent token approvals, and confirm that only intended recovery providers remain active.
FAQs
What is ERC-7947?
ERC-7947 is a Draft Ethereum Standards Track ERC defining a common Account Abstraction Recovery Interface for smart accounts and external recovery providers.
What problem does ERC-7947 solve?
It provides a common interface for smart accounts to add recovery providers, remove them, commit recovery data, verify recovery proofs, and update account access after the user's normal credential is lost or unavailable.
Is ERC-7947 finalized?
No. The official Ethereum Improvement Proposal currently lists ERC-7947 as Draft.
What is AARI?
AARI stands for Account Abstraction Recovery Interface, the recovery interface introduced by ERC-7947.
Is ERC-7947 only for social recovery wallets?
No. Social recovery can be implemented through a recovery provider, but the interface also supports other proof systems such as zero-knowledge recovery, signatures, alternative secrets, multi-factor designs, and other provider-defined mechanisms.
What is a recovery provider?
A recovery provider is a contract implementing the ERC-7947 recovery-provider interface. It stores or processes recovery data for subscribed smart accounts and verifies recovery proofs when those accounts need to restore access.
Can a smart account have several recovery providers?
Yes. The proposal is explicitly designed to allow multiple recovery providers to coexist.
Does having multiple providers automatically create a threshold?
No. ERC-7947 does not require two of three, three of five, or any other cross-provider threshold. A specific smart-account or provider design would need to implement that policy separately.
What does addRecoveryProvider do?
It adds a recovery provider to the smart account, rejects the zero address, and calls the provider's subscribe function with recoveryData.
Should addRecoveryProvider be access controlled?
Yes. The ERC says it should be access controlled. Unauthorized provider enrollment can create a future account takeover path.
Why is a malicious recovery provider dangerous?
A malicious provider can accept a fake recovery proof. If the smart account trusts that provider, the attacker may be able to cause account access to be replaced with an attacker-controlled subject.
Can phishing target recovery providers?
Yes. The ERC's security considerations explicitly warn that users can be phished into adding malicious recovery providers.
Does adding a recovery provider transfer my tokens?
Not necessarily. Provider enrollment changes account recovery configuration rather than inherently transferring assets, but it can create a powerful future path to account control.
What is recoveryData?
recoveryData is provider-specific information supplied during enrollment, such as a commitment, hash, zero-knowledge public output, or another value the provider later uses when validating a recovery proof.
Is recoveryData a private key?
Not necessarily. It is arbitrary provider-defined data and may represent a commitment rather than the secret itself.
Can recoveryData be changed?
Yes. The ERC rationale describes recommitting to fresh recovery data by unsubscribing and subscribing again, potentially in one multicall.
Why would I rotate recoveryData?
You might rotate it when a recovery secret may be exposed, a backup factor changes, stronger security parameters are available, or the previous recovery commitment should no longer be trusted.
What does recoverAccess do?
recoverAccess takes a new access subject, a registered recovery provider, and a proof. The account calls the provider to verify recovery and updates account access if verification succeeds.
What is the subject in ERC-7947?
The subject is arbitrary encoded data representing the account access state to be recovered, such as an owner address, signer, access-control role, validator configuration, or another account-specific subject.
Why is subject bytes instead of an address?
Smart accounts can use more complex access-control systems than one owner address. Arbitrary bytes allow the standard to support ownerless, modular, role-based, and other account designs.
What is the recovery proof?
The proof is provider-specific encoded evidence used to show that the recovery condition has been satisfied. It can represent a signature, zero-knowledge proof, multi-factor result, or another supported mechanism.
Does ERC-7947 require zero-knowledge proofs?
No. Zero-knowledge proofs are one possible recovery mechanism. The proof format is intentionally generic.
Can recovery proofs be replayed?
They must not be reusable. ERC-7947 explicitly requires providers to prevent proof reuse, for example by updating a nonce.
Why is proof replay dangerous?
A recovery proof may be visible in public transaction data. If it remains valid, an attacker could copy and resubmit it later.
Should a recovery proof bind to the account?
Yes. A robust proof design should prevent evidence generated for one smart account from being used to recover another account unintentionally.
Should recovery proof bind to the new owner?
Where the proof authorizes a specific replacement owner or access object, binding that object into the proof prevents a valid recovery from being redirected to an attacker-controlled subject.
Does ERC-7947 include chainId?
No top-level chainId field is defined in the core recovery functions. Provider implementations should consider chain or domain binding where cross-chain replay could be relevant.
Does ERC-7947 have a built-in expiry?
No. The core interface does not define one universal recovery expiry. Providers can implement their own timing or freshness rules.
Does ERC-7947 require a recovery delay?
No. A delay or challenge period can be added by a provider or smart-account implementation but is not mandated by the core ERC.
What are the benefits of a recovery delay?
A delay can give the legitimate owner time to cancel an unexpected recovery before account control changes.
What are the risks of a recovery delay?
If the original credential is compromised rather than merely lost, a long delay can give the attacker additional time to use the old authority.
How do I revoke a recovery provider?
The smart account calls removeRecoveryProvider, which must call the provider's unsubscribe function.
What must unsubscribe do?
The ERC requires the provider to delete all recovery data associated with the calling smart account.
Does removing a recovery provider revoke token approvals?
No. ERC-20 allowances, Permit2 permissions, NFT operator approvals, and other authorizations are separate account or contract state.
What event shows that account access was recovered?
The smart account must emit AccessRecovered whenever account access changes as a result of recovery.
What events show recovery provider changes?
The smart account emits RecoveryProviderAdded and RecoveryProviderRemoved, while providers emit AccountSubscribed and AccountUnsubscribed.
Should I monitor recovery events?
Yes. Unexpected provider addition, removal, or account recovery can indicate a critical wallet-security incident.
Can a recovery provider be upgradeable?
Yes, depending on its implementation. Upgradeability introduces governance and administrator risk because recovery logic can change after users enroll.
Can a smart-account upgrade affect ERC-7947 recovery?
Yes. An account upgrade can change provider storage, subject interpretation, access-control logic, or how successful recovery modifies account authority.
Does successful recovery undo attacker transactions?
No. Transactions already finalized remain effective. Recovery changes future account access but does not automatically reverse transfers, approvals, borrowing, bridging, or other completed actions.
Can token approvals survive account recovery?
Yes. ERC-20 allowances and other persistent authorizations exist independently of account ownership and should be reviewed after a recovery incident.
Can Permit2 permissions survive recovery?
Yes. Permit2 authorization is a separate permission layer and should be reviewed independently after account compromise or recovery.
Can hardware wallets work with smart-account recovery?
Yes. Hardware key protection and smart-account recovery solve different problems. Hardware protects a normal signing credential, while recovery provides an alternate access path if that credential is lost or must be replaced.
Does a hardware wallet protect me from malicious recovery providers?
Not automatically. A user can use a hardware device to authorize a malicious provider-enrollment transaction if the transaction is misunderstood.
What is the biggest ERC-7947 account takeover risk?
One of the largest risks is registering or retaining a provider that can accept false recovery proofs, because that provider can become an alternative path to root account control.
Are more recovery providers always safer?
No. More providers improve redundancy only when their security and availability failure modes are sufficiently independent. Each additional provider can also create another takeover path.
What should I check after legitimate recovery?
Verify the new access subject, invalidate compromised credentials, review recovery providers, rotate recovery data where necessary, inspect token approvals, review modules and protocol positions, and decode recent transactions.
Can ERC-7947 work with ERC-4337 smart accounts?
The ERC rationale is designed for broad account-abstraction compatibility and explicitly discusses working with account-abstraction approaches such as ERC-4337.
Can ERC-7947 work with EIP-7702 account designs?
The proposal's rationale also identifies EIP-7702 as an account model with which a compatible smart-account provider could support the recovery interface.
Is ERC-7947 backwards compatible?
The proposal states that it is fully backwards compatible because accounts adopt the recovery interface voluntarily.
What should a wallet display before adding a provider?
The wallet should make clear that the transaction is adding a recovery path, identify the smart account, network, provider contract, recovery implications, and any understood provider or upgrade risk.
What should a wallet display before recoverAccess?
The wallet should show which account is being recovered, which provider is being used, and what new owner, signer, role, or access subject will become effective if recovery succeeds.
What is the simplest ERC-7947 security rule?
Treat every recovery provider as part of your account's root-authority system and verify its address, proof model, replay protection, upgrade controls, removal path, and long-term availability accordingly.
References and further reading
These official Ethereum resources provide the primary specification and broader security context for ERC-7947 smart-account recovery.
- ERC-7947: Account Abstraction Recovery Interface
- Ethereum Improvement Proposals and ERC Standards
- Ethereum.org: A More Secure Ethereum
ERC-7947 remains a Draft proposal. The standard defines common recovery interfaces but does not prescribe one universal provider, proof system, delay, threshold, expiry policy, smart-account architecture, or operational recovery procedure. Actual account security depends on the specific account and provider implementations in use. This guide is educational security research and is not financial, legal, custody, or software-audit advice.
