From d356fa6106a4de1c193bc0913be8a1aace180842 Mon Sep 17 00:00:00 2001 From: howydev <132113803+howydev@users.noreply.github.com> Date: Tue, 3 Sep 2024 16:39:36 -0400 Subject: [PATCH 1/5] chore: loosen requirement for IAccountExecute --- standard/ERCs/erc-6900.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/standard/ERCs/erc-6900.md b/standard/ERCs/erc-6900.md index dc9f4353..f8a6cb34 100644 --- a/standard/ERCs/erc-6900.md +++ b/standard/ERCs/erc-6900.md @@ -64,12 +64,13 @@ Each step is modular, supporting different implementations, that allows for open **Modular Smart Contract Accounts** **MUST** implement -- `IAccount.sol` and `IAccountExecute.sol` from [ERC-4337](./eip-4337.md). +- `IAccount.sol` from [ERC-4337](./eip-4337.md). - `IModularAccount.sol` to support module management and usage, and account identification. - The function `isValidSignature` from [ERC-1271](./eip-1271.md) **Modular Smart Contract Accounts** **MAY** implement +- `IAccountExecute.sol` from [ERC-4337](./eip-4337.md) as a way to pass state from the validation phase of a user operation to the execution phase. - `IModularAccountView.sol` to support visibility in account states on-chain. - [ERC-165](./eip-165.md) for interfaces installed from modules. From 42de32c844ad1c88991fc92adef0e6f20e481a3f Mon Sep 17 00:00:00 2001 From: howydev <132113803+howydev@users.noreply.github.com> Date: Thu, 5 Sep 2024 15:14:31 -0400 Subject: [PATCH 2/5] chore: update executeUserOp expected behavior --- standard/ERCs/erc-6900.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/standard/ERCs/erc-6900.md b/standard/ERCs/erc-6900.md index f8a6cb34..b253ceee 100644 --- a/standard/ERCs/erc-6900.md +++ b/standard/ERCs/erc-6900.md @@ -64,13 +64,12 @@ Each step is modular, supporting different implementations, that allows for open **Modular Smart Contract Accounts** **MUST** implement -- `IAccount.sol` from [ERC-4337](./eip-4337.md). +- `IAccount.sol` and `IAccountExecute.sol` from [ERC-4337](./eip-4337.md). - `IModularAccount.sol` to support module management and usage, and account identification. - The function `isValidSignature` from [ERC-1271](./eip-1271.md) **Modular Smart Contract Accounts** **MAY** implement -- `IAccountExecute.sol` from [ERC-4337](./eip-4337.md) as a way to pass state from the validation phase of a user operation to the execution phase. - `IModularAccountView.sol` to support visibility in account states on-chain. - [ERC-165](./eip-165.md) for interfaces installed from modules. @@ -445,7 +444,7 @@ interface IExecutionHookModule is IModule { /// be more than one. /// @param sender The caller address. /// @param value The call value. - /// @param data The calldata sent. + /// @param data The calldata sent. For `executeUserOp` calls on the account, hook modules would receive the full msg.data. /// @return Context to pass to a post execution hook, if present. An empty bytes array MAY be returned. function preExecutionHook(uint32 entityId, address sender, uint256 value, bytes calldata data) external @@ -541,7 +540,7 @@ If the selector being checked is `execute` or `executeBatch`, the modular accoun Installed validations have two flag variables indicating what they may be used for. If a validation is attempted to be used for user op validation and the flag `isUserOpValidation` is set to false, validation MUST revert. If the validation is attempted to be used for signature validation and the flag `isSignatureValidation` is set to false, validation MUST revert. -#### Direct Call Validation. +#### Direct Call Validation If a validation function is installed with the entity ID of `0xffffffff`, it may be used as direct call validation. This occurs when a module or other address calls a function on the modular account, without wrapping its call in the dispatcher function `executeWithAuthorization` to use as a selection mechanism for a runtime validation function. From 57e46563af88f67494925e79831a8d05aeb1e929 Mon Sep 17 00:00:00 2001 From: howydev <132113803+howydev@users.noreply.github.com> Date: Thu, 5 Sep 2024 15:34:35 -0400 Subject: [PATCH 3/5] chore: add hook data format --- standard/ERCs/erc-6900.md | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/standard/ERCs/erc-6900.md b/standard/ERCs/erc-6900.md index b253ceee..f5eed8c9 100644 --- a/standard/ERCs/erc-6900.md +++ b/standard/ERCs/erc-6900.md @@ -444,7 +444,7 @@ interface IExecutionHookModule is IModule { /// be more than one. /// @param sender The caller address. /// @param value The call value. - /// @param data The calldata sent. For `executeUserOp` calls on the account, hook modules would receive the full msg.data. + /// @param data The calldata sent. For `executeUserOp` calls, hook modules should receive the full msg.data. /// @return Context to pass to a post execution hook, if present. An empty bytes array MAY be returned. function preExecutionHook(uint32 entityId, address sender, uint256 value, bytes calldata data) external @@ -512,7 +512,17 @@ During execution uninstallation, the account MUST correctly clear flags and othe - the account SHOULD call `onUnInstall` on the execution module to initialize the states and track call success if required by user. - the account MUST emit `ExecutionUninstalled` as defined in the interface for all uninstalled executions. -### Hook Execution Order +### Hooks + +#### Execution Hooks Data Format + +For accounts that implement execution hooks, accounts **MUST** conform to these execution hook formats: +1. For `executeUserOp` calls, for execution hooks associated with a validator, accounts **MUST** send the full `msg.data`, including the `executeUserOp` selector. +2. For `executeUserOp` calls, for execution hooks associated with a selector, accounts **MUST** send `PackedUserOperation.callData` for `executeUserOp` calls, excluding `executeUserOp.selector` and the rest of the `PackedUserOperation`. +3. For `executeWithAuthorization` calls, for all execution hooks, accounts **MUST** send the inner `data`. +4. For all other calls, for execution hooks associated with a selector, accounts **MUST** send over `msg.data`. + +#### Hook Execution Order It is RECOMMENDED that an account implementer runs hooks in first installed first executed order. However, an account MAY implement a different execution order. From eb1b63de41f31592c5a8c470f29b6fad3f9ce0d7 Mon Sep 17 00:00:00 2001 From: howydev <132113803+howydev@users.noreply.github.com> Date: Thu, 5 Sep 2024 17:09:42 -0400 Subject: [PATCH 4/5] cleanup: remove bolding from MUSTs --- standard/ERCs/erc-6900.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/standard/ERCs/erc-6900.md b/standard/ERCs/erc-6900.md index f5eed8c9..f51b93e3 100644 --- a/standard/ERCs/erc-6900.md +++ b/standard/ERCs/erc-6900.md @@ -516,11 +516,11 @@ During execution uninstallation, the account MUST correctly clear flags and othe #### Execution Hooks Data Format -For accounts that implement execution hooks, accounts **MUST** conform to these execution hook formats: -1. For `executeUserOp` calls, for execution hooks associated with a validator, accounts **MUST** send the full `msg.data`, including the `executeUserOp` selector. -2. For `executeUserOp` calls, for execution hooks associated with a selector, accounts **MUST** send `PackedUserOperation.callData` for `executeUserOp` calls, excluding `executeUserOp.selector` and the rest of the `PackedUserOperation`. -3. For `executeWithAuthorization` calls, for all execution hooks, accounts **MUST** send the inner `data`. -4. For all other calls, for execution hooks associated with a selector, accounts **MUST** send over `msg.data`. +For accounts that implement execution hooks, accounts MUST conform to these execution hook formats: +1. For `executeUserOp` calls, for execution hooks associated with a validator, accounts MUST send the full `msg.data`, including the `executeUserOp` selector. +2. For `executeUserOp` calls, for execution hooks associated with a selector, accounts MUST send `PackedUserOperation.callData` for `executeUserOp` calls, excluding `executeUserOp.selector` and the rest of the `PackedUserOperation`. +3. For `executeWithAuthorization` calls, for all execution hooks, accounts MUST send the inner `data`. +4. For all other calls, for execution hooks associated with a selector, accounts MUST send over `msg.data`. #### Hook Execution Order From cf0285ab7d054dd526d2252642a994f73a98230c Mon Sep 17 00:00:00 2001 From: howydev <132113803+howydev@users.noreply.github.com> Date: Thu, 5 Sep 2024 17:13:12 -0400 Subject: [PATCH 5/5] fix: readd lost commit --- standard/ERCs/erc-6900.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/standard/ERCs/erc-6900.md b/standard/ERCs/erc-6900.md index f51b93e3..cf480c3c 100644 --- a/standard/ERCs/erc-6900.md +++ b/standard/ERCs/erc-6900.md @@ -517,7 +517,7 @@ During execution uninstallation, the account MUST correctly clear flags and othe #### Execution Hooks Data Format For accounts that implement execution hooks, accounts MUST conform to these execution hook formats: -1. For `executeUserOp` calls, for execution hooks associated with a validator, accounts MUST send the full `msg.data`, including the `executeUserOp` selector. +1. For `executeUserOp` calls, for execution hooks associated with a validation function, accounts MUST send the full `msg.data`, including the `executeUserOp` selector. 2. For `executeUserOp` calls, for execution hooks associated with a selector, accounts MUST send `PackedUserOperation.callData` for `executeUserOp` calls, excluding `executeUserOp.selector` and the rest of the `PackedUserOperation`. 3. For `executeWithAuthorization` calls, for all execution hooks, accounts MUST send the inner `data`. 4. For all other calls, for execution hooks associated with a selector, accounts MUST send over `msg.data`.