Alchemy Light Account

The `LightAccount` wallet supports user operations validation by either EOA or [`ERC-1271`](https://eips.ethereum.org/EIPS/eip-1271) signature validation method. It is important to note that the ERC-1271 signature validation only works when the `owner` of the wallet supports `ERC-1271`. According to the `ERC-1271` standard: > `isValidSignature` can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc. Therefore, a contract that supports `ERC-1271` may read storage or the current blockchain state to determine the validity of a signature. However, the usage of `ERC-1271` for the validation of user operations may have specific limitations due to the restrictions of opcode banning and storage access outlined in the [`ERC-4337`](https://eips.ethereum.org/EIPS/eip-4337) standard. Specifically, during the validation phase, wallets are not allowed to use any forbidden opcodes, including `TIMESTAMP` and `NUMBER`. Additionally, storage access is restricted to self-storage or storage associated with the wallet's address. This restriction prevents `ERC-1967` proxies from being an owner of a `LightAccount`, as they access a constant implementation slot not associated with the wallet. These restrictions also mean that violating the storage access rule on the `owner` would lead to bundlers dropping the UserOps that are sent to the `owner`'s light account. While typically, this is recoverable by directly operating on the `owner` smart contract itself, it may not be the expected behavior. There is also the possibility of not being able to recover if the `owner` smart contract is not well designed. Furthermore, the `LightAccount.isValidSignature()` function cannot be used for user operation validation since `LightAccount` is deployed as an `ERC-1967` proxy and implements a customized storage slot pattern that triggers a storage access violation when the wallet attempts to read its `owner`.

In the `LightAccount` wallet, the `owner` can transfer their ownership to another address through the `transferOwnership()` function. This transfer of ownership can occur either directly or by `ERC-4337` user operations. However, the wallet can lose ownership if the `newOwner` address is accidentally provided as an uncontrollable address or a smart contract that does not support `ERC-1271`. As a result, all user operations to the wallet will fail during the validation phase, effectively making the wallet unusable.