Add 4337 Dependency section to the spec (#185)

Co-authored-by: Jay Paik <[email protected]>

standard/ERCs/erc-6900.md

@@ -486,6 +486,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 remove all hooks and SHOULD clear hook module states by calling `onUninstall` with the user-provided data for each hook, including both validation hooks and execution hooks, if specified by the user.
+  - The account MAY ignore the revert from `onUninstall` with try/catch depending on the design principle of the account.
 - The account MUST clear the configuration for the selectors that the validation function can validate.
 - The account SHOULD call `onUninstall` on the validation module to clean up state if specified by the user.
 - The account MUST emit `ValidationUninstalled` as defined in the interface for all uninstalled validation functions.
@@ -589,6 +590,14 @@ 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 accounts and modules to increase the velocity and security of the smart account ecosystem, and ultimately the wallet ecosystem. Currently, the standard prescribes ERC-4337 for one of its [modular account call flows](#overview). However, this does not dictate that ERC-6900 will continue to be tied to 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 account abstraction on rollups). Moreover, it is expected that ERC-4337 and its interfaces and contracts will continue to evolve until there is a protocol-level account abstraction.
+
+In the current state of the AA ecosystem, it is tough to predict the direction the builders and industry will take, so ERC-6900 will evolve together with the space's research, development, and adoption. The standard will do its best to address the objectives and create a secure foundation for modular accounts that may eventually be abstracted away from the infrastructure mechanism used.
+
 ### Community Consensus
 
 While this standard has largely been the result of collaboration among the coauthors, there have been noteworthy contributions from others in the community with respect to improvements, education, and experimentation. Thank you to the contributors: