EIP-7947: Account Abstraction Recovery Interface (AARI)

[Arvolear]

Thanks for a comprehensive review. Appreciate it very much!

@SamWilsn

The name recoveryProviderExists is a bit odd, since the recovery provider exists regardless of whether it has been added to the account.

Agree. Renamed the function to recoveryProviderAdded.

@SamWilsn

Have you considered ERC-165?

Actually, I have thought about adding it to the recovery provider interface, but currently I see no obvious upside for this requirement. Wallets and dapps would probably support recovery providers on an individual integration basis. And adding ERC-165 to an account looks like unnecessary complexity.

@SamWilsn

Should this standard depend on ERC-173?

That’s a good question. Implicitly, the standard requires some kind of ownership, but I don’t want to restrict it solely to EIP-173. For example, a smart account may support some kind of 2FA or ZK2FA upon every execute action. In case of a private key compromise, a user could still recover the account ownership using EIP-7947. However, if an account inherited EIP-173, the transferOwnership function would not allow that, and a hacker would gain full control over the account.

@SamWilsn

In your motivation, you should explain why someone would want this standard over, say, setting the recovery provider as the owner (and having it proxy function calls). There’s probably an obvious downside, but it is the de facto approach that works today.

Extended the motivation section a bit.