From beeb9cad41c2d6568079774dcfeb43632da1cb09 Mon Sep 17 00:00:00 2001 From: PowerStream3604 <63450340+PowerStream3604@users.noreply.github.com> Date: Wed, 25 Sep 2024 23:08:00 +0700 Subject: [PATCH 1/2] feat: add 4337 dependency to spec --- standard/ERCs/erc-6900.md | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff --git a/standard/ERCs/erc-6900.md b/standard/ERCs/erc-6900.md index c400df5a..1e74df29 100644 --- a/standard/ERCs/erc-6900.md +++ b/standard/ERCs/erc-6900.md @@ -586,6 +586,19 @@ ERC-4337 compatible accounts must implement the `IAccount` interface, which cons This proposal includes several interfaces that build on ERC-4337. First, we standardize a set of modular functions that allow smart contract developers greater flexibility in bundling validation, execution, and hook logic. We also propose interfaces that provide methods for querying execution functions, validation functions, and hooks on a modular account. The rest of the interfaces describe a module's methods for exposing its modular functions and desired configuration, and the modular account's methods for installing and removing modules and allowing execution across modules and external addresses. +### ERC 4337 Dependency + +ERC 6900's main objective is to create a secure and interoperable foundation through modular modules to increase the velocity and security of the Smart Account ecosystem and ultimately the wallet ecosystem. +Currently, the ERC 6900 standard enforces the ERC 4337 for the validation and execution, however, this does not dictate that ERC 6900 will continue to be tied to the ERC 4337. +It is likely that smart account builders will want to develop modular accounts that do not use ERC 4337 in the future, e.g., Native AA on rollups. +Moreover, it is expected that the version of EntryPoint contract will continue to evolve until there is a protocol-level account abstraction. + +ERC 6900, having the objective to provide the secure foundation for modular smart account layer, does not try to be tied with a specific version of continuously evolving EntryPoint and AA architecture but rather position to function as a modular layer encompassing them. + +To be in line with this, identical behavior and functions will exist for EntryPoint v6 with `UserOperation` and will continue to exist when a new EntryPoint version comes out with a different UserOp structure. + +ERC 6900 could evolve with ERC 4337 becoming an extension through a separate ERC for 6900 if more builders build on a new architecture, but in its current state, it enforces ERC 4337 within the standard, considering that the vast majority of smart accounts utilize ERC 4337. + ## Backwards Compatibility Existing accounts that are deployed as proxies may have the ability to upgrade account implementations to one that supports this standard for modularity. Depending on implementation logic, existing modules may be wrapped in an adapter contract to adhere to the standard. From d68a8322dcaf8dc27b489e783388ea60d3256394 Mon Sep 17 00:00:00 2001 From: PowerStream3604 <63450340+PowerStream3604@users.noreply.github.com> Date: Wed, 25 Sep 2024 23:14:46 +0700 Subject: [PATCH 2/2] chore: add line and format ERC name --- standard/ERCs/erc-6900.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/standard/ERCs/erc-6900.md b/standard/ERCs/erc-6900.md index 1e74df29..cd38e5a9 100644 --- a/standard/ERCs/erc-6900.md +++ b/standard/ERCs/erc-6900.md @@ -484,6 +484,7 @@ During validation uninstallation, the account MUST correctly clear flags and oth - the account MUST clear all flags for the validation function, like `isGlobal`, `isSignatureValidation`, and `isUserOpValidation`. - the account MUST remomve all hooks and SHOULD clear hook module states by calling `onUninstall` with the user-provided data for each hook, including both pre validation hooks and execution hooks, if required by user. + - the account MAY ignore the revert from `onUninstall` with try/catch depending on the design principle of the account. - the account MUST remove all selectors that the validation function can validate. - the account MUST emit `ValidationUninstalled` as defined in the interface for all uninstalled validations. @@ -588,16 +589,16 @@ This proposal includes several interfaces that build on ERC-4337. First, we stan ### ERC 4337 Dependency -ERC 6900's main objective is to create a secure and interoperable foundation through modular modules to increase the velocity and security of the Smart Account ecosystem and ultimately the wallet ecosystem. -Currently, the ERC 6900 standard enforces the ERC 4337 for the validation and execution, however, this does not dictate that ERC 6900 will continue to be tied to the ERC 4337. -It is likely that smart account builders will want to develop modular accounts that do not use ERC 4337 in the future, e.g., Native AA on rollups. +ERC-6900's main objective is to create a secure and interoperable foundation through modular modules to increase the velocity and security of the Smart Account ecosystem and ultimately the wallet ecosystem. +Currently, the ERC-6900 standard enforces the ERC-4337 for the validation and execution, however, this does not dictate that ERC-6900 will continue to be tied to the ERC-4337. +It is likely that smart account builders will want to develop modular accounts that do not use ERC-4337 in the future, e.g., Native AA on rollups. Moreover, it is expected that the version of EntryPoint contract will continue to evolve until there is a protocol-level account abstraction. -ERC 6900, having the objective to provide the secure foundation for modular smart account layer, does not try to be tied with a specific version of continuously evolving EntryPoint and AA architecture but rather position to function as a modular layer encompassing them. +ERC-6900, having the objective to provide the secure foundation for modular smart account layer, does not try to be tied with a specific version of continuously evolving EntryPoint and AA architecture but rather position to function as a modular layer encompassing them. To be in line with this, identical behavior and functions will exist for EntryPoint v6 with `UserOperation` and will continue to exist when a new EntryPoint version comes out with a different UserOp structure. -ERC 6900 could evolve with ERC 4337 becoming an extension through a separate ERC for 6900 if more builders build on a new architecture, but in its current state, it enforces ERC 4337 within the standard, considering that the vast majority of smart accounts utilize ERC 4337. +ERC-6900 could evolve with ERC-4337 becoming an extension through a separate ERC for ERC-6900 if more builders build on a new architecture, but in its current state, it enforces ERC-4337 within the standard, considering that the vast majority of smart accounts utilize ERC-4337. ## Backwards Compatibility