Update ERC-7913: Move to Final

ERCS/erc-7913.md

@@ -4,8 +4,7 @@ title: Signature Verifiers
 description: Interface for the verification of signatures by address-less keys
 author: Hadrien Croubois (@Amxx), Ernesto García (@ernestognw), Francisco Giordano (@frangio), Aryeh Greenberg (@arr00)
 discussions-to: https://ethereum-magicians.org/t/erc-7913-key-verifiers/23262
-status: Last Call
-last-call-deadline: 2025-08-12
+status: Final
 type: Standards Track
 category: ERC
 created: 2025-03-21
@@ -23,9 +22,9 @@ With the development of account abstraction, there is an increasing need for non
 
 All these signature mechanisms have one thing in common: they do not have a canonical ethereum address to represent them onchain. While users could deploy ERC-1271 compatible contracts for each key individually, this would be cumbersome and expensive. As account abstraction tries to separate account addresses (that hold assets) from the key that controls them, giving fixed on-chain addresses to keys (and possibly sending assets to these addresses by mistake) is not the right approach. Instead, using a small number of verifier contracts that can process signatures in a standard way, and having the accounts rely on these verifiers, feels like the correct approach. This has the advantage that once the verifier is deployed, any key can be represented using a `(verifier, key)` pair without requiring any setup cost.
 
-The `(verifier, key)` pairs can be given permission to control a smart account, perform social recovery, or do any other operation without ever having a dedicated on-chain address. Systems that want to adopt this approach need to transition away from the model were signers are identified by their address to a new model where signers may not have an address, and are identified by a `bytes` object.
+The `(verifier, key)` pairs can be given permission to control a smart account, perform social recovery, or do any other operation without ever having a dedicated on-chain address. Systems that want to adopt this approach need to transition away from the model where signers are identified by their address to a new model where signers may not have an address, and are identified by a `bytes` object.
 
-This definition is backward compatible with EOA and ERC-1271 contract: in that case, we use the address of the identity (EOA or contract) as the verifier and the key is empty.
+This definition is backward compatible with EOA and ERC-1271 contracts: in that case, we use the address of the identity (EOA or contract) as the verifier and the key is empty.
 
 ## Specification
 
@@ -81,7 +80,7 @@ Given a signer `signer`, a message hash `hash`, and a signature `sign`, verifica
 
 ## Reference Implementation
 
-In solidity, signature verification COULD be implemented in the following library:
+In solidity, signature verification could be implemented in the following library:
 
 ```solidity
 import {SignatureChecker} from '@openzeppelin/contracts/utils/cryptography/SignatureChecker.sol';
@@ -106,9 +105,9 @@ library SignatureCheckerExtended {
 
 ## Security Considerations
 
-Signer may be used for anything from smart account session key (with a short lifetime of a few hours/days) to social recovery "guardians" that may only be used several years after they are setup. In order to ensure that these signers remain valid "in perpetuity", the verifier contract SHOULD be trustless. This means that the verifiers SHOULD not be upgradeable contracts.
+Signer may be used for anything from smart account session key (with a short lifetime of a few hours/days) to social recovery "guardians" that may only be used several years after they are setup. In order to ensure that these signers remain valid "in perpetuity", the verifier contract should be trustless. This means that the verifiers should not be upgradeable contracts.
 
-Verifiers SHOULD also not depend on any value that can be modified after deployment. In solidity terms, the `verify` function SHOULD be pure. Any parameters that are involved in signature verification SHOULD either be part of the key, or part of immutable code of the verifier. Using `immutable` variable (in solidity) would be safe. The stateless aspect of the verifier also ensure compliance (of the verifier) with [ERC-7562](./eip-7562.md) scope rules.
+Verifiers should also not depend on any value that can be modified after deployment. In solidity terms, the `verify` function should be pure. Any parameters that are involved in signature verification should either be part of the key, or part of immutable code of the verifier. Using `immutable` variable (in solidity) would be safe. The stateless aspect of the verifier also ensure compliance (of the verifier) with [ERC-7562](./eip-7562.md) scope rules.
 
 ## Copyright