ERC-7780: Validation Module Extension for ERC-7579

Introduces new smart account module types for signature validation and permissioning

Metadata

Status: DraftStandards Track: ERCCreated: 2024-10-01

Authors

zeroknots (@zeroknots), Konrad Kopp (@kopy-kat), Taek Lee (@leekt), Fil Makarov (@filmakarov)

Requires

EIP-7579

Links

GitHub page Discussion on Ethereum Magicians

Abstract

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.

Motivation

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.

Specification

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:

Policy (type id: 5)
Signer (type id: 6)
Stateless Validator (type id: 7)

Note: A single module can be of multiple types.

Policy

Policies MUST implement ERC-7579's IModule and the IPolicy interface and have module type id: 5.

Signer

Signers MUST implement the IModule and the ISigner interface and have module type id: 6.

Stateless Validator

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.

Rationale

TBD

Backwards Compatibility

No backward compatibility issues found.

Security Considerations

TBD