diff --git a/src/interfaces/IExecutionModule.sol b/src/interfaces/IExecutionModule.sol
index 6edb3498..267daf4d 100644
--- a/src/interfaces/IExecutionModule.sol
+++ b/src/interfaces/IExecutionModule.sol
@@ -4,7 +4,6 @@ pragma solidity ^0.8.25;
 import {IModule} from "./IModule.sol";
 
 struct ManifestExecutionFunction {
-    // TODO(erc6900 spec): These fields can be packed into a single word
     // The selector to install
     bytes4 executionSelector;
     // If true, the function won't need runtime validation, and can be called by anyone.
@@ -14,7 +13,6 @@ struct ManifestExecutionFunction {
 }
 
 struct ManifestExecutionHook {
-    // TODO(erc6900 spec): These fields can be packed into a single word
     bytes4 executionSelector;
     uint32 entityId;
     bool isPreHook;
diff --git a/src/modules/validation/SingleSignerValidationModule.sol b/src/modules/validation/SingleSignerValidationModule.sol
index a750f4d6..ce18ec3a 100644
--- a/src/modules/validation/SingleSignerValidationModule.sol
+++ b/src/modules/validation/SingleSignerValidationModule.sol
@@ -50,9 +50,8 @@ contract SingleSignerValidationModule is ISingleSignerValidationModule, ReplaySa
 
     /// @inheritdoc IModule
     function onUninstall(bytes calldata data) external override {
-        // ToDo: what does it mean in the world of composable validation world to uninstall one type of validation
-        // We can either get rid of all SingleSigner signers. What about the nested ones?
-        _transferSigner(abi.decode(data, (uint32)), address(0));
+        uint32 entityId = abi.decode(data, (uint32));
+        _transferSigner(entityId, address(0));
     }
 
     /// @inheritdoc IValidationModule
diff --git a/standard/ERCs/erc-6900.md b/standard/ERCs/erc-6900.md
index 85ef43f5..d0720db9 100644
--- a/standard/ERCs/erc-6900.md
+++ b/standard/ERCs/erc-6900.md
@@ -64,8 +64,7 @@ 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).
-- `IAccountExecute.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)
 
@@ -78,7 +77,7 @@ Each step is modular, supporting different implementations, that allows for open
 
 - `IModule.sol` described below and implement ERC-165 for `IModule`.
 
-**Modules** **May** implement one of the following module types
+**Modules** **MAY** implement any of the following module types
 
 - `IValidationModule` to support validations for account.
 - `IValidationHookModule` to support hooks for validations.
@@ -411,8 +410,7 @@ interface IValidationHookModule is IModule {
     /// @param signature The signature of the message.
     function preSignatureValidationHook(uint32 entityId, address sender, bytes32 hash, bytes calldata signature)
         external
-        view
-        returns (bytes4);
+        view;
 }
 ```
 
@@ -532,7 +530,7 @@ During execution uninstallation, the account MUST correctly clear flags and othe
 
 Modular accounts support three different calls flows for validation: user op validation, runtime validation, and signature validation. User op validation happens within the account's implementation of the function `validateUserOp`, defined in the ERC-4337 interface `IAccount`. Runtime validation happens through the dispatcher function `executeWithAuthorization`, or when using direct call validation. Signature validation happens within the account's implementation of the function `isValidSignature`, defined in ERC-1271.
 
-For each of these validation types, an account implementation may specify its own format for selecting which validation function to use, as well as any per-hook data for validation hooks.
+For each of these validation types, an account implementation MAY specify its own format for selecting which validation function to use, as well as any per-hook data for validation hooks.
 
 Within the implementation of each type of validation function, the modular account MUST check that the provided validation function applies to the given function selector intended to be run. Then, the account MUST execute all validation hooks of the corresponding type associated with the validation function in use. These hooks MUST be executed in the order specified during installation. After the execution of validation hooks, the account MUST invoke the validation function of the corresponding type. If any validation hooks or the validation function revert, the account MUST revert. It SHOULD include the module's revert data within its revert data.
 
@@ -588,7 +586,9 @@ This proposal includes several interfaces that build on ERC-4337. First, we stan
 
 ## Backwards Compatibility
 
-TODO
+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.
+
+The standard also allows for flexibility in account implementations, including accounts that have certain features implemented without modules, so usage of modules may be gradually introduced.
 
 ## Reference Implementation