For ordinary users, “self-hosting” often implies mnemonic phrases, private keys, and irreversible operations; for finance, users expect email login, the ability to forget passwords, and account recovery services. On September 15th, Aave Labs made public the account architecture of Aave App, attempting to combine these two experiences: users only need an email address or mobile number along with a password to register, while at the underlying level, it relies on an encrypted key controlled by the user in conjunction with a smart contract account.
Aave describes this design as a solution that takes into account both control and usability. It indeed lowers the barrier to using traditional on-chain wallets, but it does not eliminate security trade-offs. Encrypted backups are stored on the Aave backend, biometric recovery involves CoinCover, and smart accounts are also granted limited permissions by Aave. Understanding what each of these components can do is more important than the label of “self-hosted” or not.
Signer is responsible for control rights; the password and device determine how to retrieve them.
Each Aave App user has an external account, which is commonly known as EOA. The official term for it is Signer. The private key is generated on the user's device and then encrypted using the user's password and email or mobile authentication credentials. The encrypted result is uploaded to the Aave backend for storage. When a user logs in from a different device, they need to pass a one-time verification code sent via email or mobile phone, followed by entering the correct password, in order to regain access to their Signer.
This design is different from embedded wallets that can be unlocked with just a SMS verification code. Even if an attacker manages to hijack the SIM card and obtain only the mobile phone number verification code, they still lack the password. Users can also add Passkey and require the use of additional one-time verification codes provided by verifiers such as Google Authenticator. According to this, accounts will not be compromised just because the SIM card is hijacked, but this does not mean that accounts are immune to all attacks. Phishing, device intrusion, weak passwords, and recovery processes remain risks.
When forgetting your password, Aave has designed two recovery paths. The first is device recovery: as long as the user still possesses a device they have used to log in to before, they can update their password using the encrypted materials saved in the device's secure area through methods such as Face ID. The second is an optional biometric recovery option, which is suitable for situations where neither the password nor the old device is available.
Biometric recovery is provided by CoinCover. During registration, users are required to scan their faces. The encryption backups related to the private keys are divided into two parts: one part is given to CoinCover and the other part to Aave. During recovery, CoinCover completes face matching through multiple verification providers and AI; Aave also requires a one-time verification code received by the user through authentication. Both parties then release their respective materials and re-establish access. This approach prevents any single party from holding all the backups, but users must also accept face data processing and reliance on third-party services. This feature is optional and not mandatory by default.
To restrict unauthorized withdrawals, users need to pre-approve the withdrawal destination in advance. New destinations must be confirmed through email or mobile phone verification codes. This whitelist approach can prevent the transfer of funds after some accounts are taken over, but its effectiveness depends on whether the authentication channels are secure, whether the reminders are timely, and whether users will mistakenly approve incorrect addresses on phishing pages.
Intelligent accounts are responsible for automation, and this also brings a set of authorizations that must be understood.
In addition to Signer, Aave App also deploys smart contract accounts for users. It utilizes Alchemy Modular Account and v2, and incorporates a custom ERC-6900 module. Smart accounts can have payments made on their behalf by the platform, multiple operations can be processed in batches, additional signatures may be required for sensitive actions, and they can also grant limited execution permissions to third parties.
These capabilities directly serve the goal of "using it just like finance App". For example, after a user deposits fiat currency from a bank, settlement may take several days. If the funds arrive but the user still has to reopen App and manually deposit the earnings into the treasury, there will be a disruption in the experience. Aave states that the user's smart account will be granted limited permissions by Aave, allowing it to move the stablecoins into the treasury, so that the funds can automatically start generating earnings once they arrive.
The key lies in "limited permissions." Smart accounts do not grant all operational rights to the platform; instead, they specify which assets can be manipulated, the destinations, and the actions that can be performed through modules. However, whether these restrictions are truly clear depends on the module code, the upgrade mechanism, the methods for revoking permissions, and the front-end presentation. Users should not only see "automatic profit generation" but also need to know who can initiate transactions, what the maximum limits are, when these limits can be revoked, and how to handle errors in the contracts.
Articles labeled with Aave only focus on the account level. This does not prove that other objectives such as fixed interest rates, balance protection, and instant zero-fee bank transactions have been fully achieved. The officials list these as “non-negotiable” features of products designed for public savings and plan to introduce them separately. To claim that these goals have already been realized would be an overestimation of the current maturity of these products.
From an industry perspective, this architecture indicates that the direction of wallet competition is changing. In the past, self-hosted products primarily marketed their “user-exclusive mnemonic phrases” as a selling point; now, account abstraction, Passkey, modular permissions, and shard recovery have broken down control into multiple verifiable components. Users may not necessarily need to see blockchain transactions, but they still need to understand recovery services, contract permissions, and the boundaries of hosting.
This is not about replacing the private key with an email address, but rather about hiding the private key behind a more familiar login process. The good outcome is that ordinary people can retain ultimate control over their on-chain accounts without having to manage a string of mnemonic phrases; however, the downside could be that the complexity is shifted from the users to the backend and smart contracts, making the risks less apparent. Making the underlying processes public (as with Aave) is a necessary step, but the next important step is to ensure that permissions, recovery conditions, and exit paths are also clearly presented in the product interface.
