ERC-7780 extends ERC-7579 smart account modules with three new types: Policies check what UserOperations can do, Signers validate signatures on hashes, and Stateless Validators verify signatures against calldata-provided data instead of stored configuration.
Composable validation logic is key to flexible smart accounts. Policies enable spending limits and action restrictions. Stateless validators let existing signature modules be reused across accounts without per-account storage setup, reducing gas and complexity.
This proposal introduces three new module types on top of the existing modules described in ERC-7579. The modules are policy, signer and stateless validator. None of these modules are required to be implemented by accounts, but accounts can choose to implement them or other modules can choose to make use of them for additional composability.
Policy modules can be used to check what a UserOperation or action is trying to achieve and determine if this is allowed. Signer modules can be used to validate signatures on provided hashes. Stateless validators are modules that are used to both validate signatures and compare them to a calldata-provided data blob which could, for example, include owners to check signatures against.
The modules introduced by this proposal aim to create more composability around signature and permission verification.
Policy and signer modules allow an account to make direct use of such a permissioning logic rather than relying on external modules to handle this. This has the upside of lower gas cost but the downside of less flexibility for users and developers that use the account.
Stateless validators enable further composability around signature validation logic. In many cases, it does not make sense to re-write signature validation for new validators, but instead to use the existing ones. However, this is usually not possible since the validators rely on a stored configuration indexed by the msg.sender, which is expected to be an account. Stateless validators solve this problem by not relying on state to compare signature verficiation against, but instead to compare it against a calldata-provided argument.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
This standard introduces three new module types on top of the existing modules introduced by ERC-7579:
Note: A single module can be of multiple types.
Policies MUST implement ERC-7579's IModule and the IPolicy interface and have module type id: 5.
Signers MUST implement the IModule and the ISigner interface and have module type id: 6.
Validators MUST implement the IStatelessValidator interface and have module type id: 7. It is RECOMMENDED that all Validators (module type id 1) also implement the Stateless Validator interface for additional composabillity.
TBD
No backward compatibility issues found.
TBD
Copyright and related rights waived via CC0.