From 4a6de2ec330f1b39e7aa5a832619c085ce36865c Mon Sep 17 00:00:00 2001 From: Jay Paik Date: Wed, 20 Sep 2023 09:03:47 -0400 Subject: [PATCH] [ALC-2] add comment explaining contract owner limitations for user operation validation --- src/LightAccount.sol | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/src/LightAccount.sol b/src/LightAccount.sol index 719912c..3b0324c 100644 --- a/src/LightAccount.sol +++ b/src/LightAccount.sol @@ -32,6 +32,15 @@ import {CustomSlotInitializable} from "./CustomSlotInitializable.sol"; * exposing its own `isValidSignature` method. This only works when the owner of * LightAccount also support ERC-1271. * + * ERC-4337's bundler validation rules limit the types of contracts that can be + * used as owners to validate user operation signatures. For example, the + * contract's `isValidSignature` function may not use any forbidden opcodes + * such as `TIMESTAMP` or `NUMBER`, and the contract may not be an ERC-1967 + * proxy as it accesses a constant implementation slot not associated with + * the account, violating storage access rules. This also means that the + * owner of a LightAccount may not be another LightAccount if you want to send + * user operations through a bundler. + * * 4. Event `SimpleAccountInitialized` renamed to `LightAccountInitialized`. */ contract LightAccount is BaseAccount, TokenCallbackHandler, UUPSUpgradeable, CustomSlotInitializable, IERC1271 {