ERC-8010: Pre-delegated Signature Verification

Pre-delegated Signature Verification

Abstract

This ERC defines a signature verification procedure that enables signature validation for accounts that intend to delegate via EIP-7702 before onchain delegation occurs. The standard introduces a detectable signature wrapper containing an EIP-7702 authorization and initialization data, allowing verifiers to simulate the delegation and validate signatures through ERC-1271 in a single atomic operation, whilst falling back to ERC-6492 verification if the signature is not wrapped.

Motivation

EIP-7702 enables EOAs to set code in their account, but signatures are often generated before onchain delegation occurs. Current verification methods cannot validate these pre-delegation signatures against the intended delegate logic.

This proposal addresses this limitation by:

• Standardizing a signature format that embeds delegation intent
• Defining a verification procedure that simulates delegation atomically
• Maintaining compatibility with existing ERC-1271 infrastructure, including Create2-based predeployed verification (ERC-6492)

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.

Signer Side (e.g. Wallets)

This ERC proposes that wallets can wrap signatures into a predelegate verification-compatible format that is constructed as follows:

wrapped_signature = signature 
    || context 
    || context.length 
    || MAGIC

MAGIC = 0x8010801080108010801080108010801080108010801080108010801080108010
context = abi.encode(authorization, init_to, init_data)
authorization = abi.encode(chain_id, address, nonce, y_parity, r, s)

Where:

• signature: The signature to be verified by the delegate's isValidSignature method
• MAGIC: Detection marker for EIP-7702 accounts
• authorization: Signed EIP-7702 authorization
• init_to: Optional address of the initializer. Can be the account itself, or an external initializer (e.g. account orchestrator)
• init_data: Optional initialization data to be executed before validation

Requirements

• Signers SHOULD NOT wrap signatures if the account has already been delegated.
• init_data MAY be empty if the account has no initialization data.
• If init_data is not empty, contracts MUST ensure that verification of init_data occurs on initialization.
• init_to MAY be empty if there is no init_data OR the initializer is the account itself

Verifier Side (e.g. Apps, Libraries,)

The verification procedure is performed by consumers of the account contract (e.g. applications, services, libraries, etc.).

Given inputs (account: address, digest: bytes32, wrapped_signature: bytes), verifiers MUST implement the following procedure (pseudocode):

1. Check if wrapped_signature ends with MAGIC
2. If MAGIC is not found:
   1. MUST follow the ERC-6492 verification procedure, and return the result.
      • This will handle predeployed CREATE2, ERC-1271, and EOA signatures.
3. Otherwise:
   1. Parse the wrapped signature:
      1. length = wrapped_signature.length
      2. context_length = wrapped_signature[length-64:length-32]
      3. signature = wrapped_signature[0:length-64-context_length]
      4. (authorization, init_data, init_to) = abi.decode(wrapped_signature[length-64-context_length:length-64], (bytes, bytes, address))
      5. (chain_id, delegation, nonce, y_parity, r, s) = abi.decode(authorization, (uint256, address, uint256, uint8, bytes32, bytes32))
   2. If account.code == bytes.concat(hex"ef0100", delegation):
      1. Perform standard ERC-1271 verification: account.isValidSignature(digest, signature)
         • If success, return successfully.
         • If failure, attempt ecrecover verification.
   3. Perform a multicall to initialize the account and validate the signature:
      1. init_to.call(init_data)
      2. account.isValidSignature(digest, signature)
      3. Return the result of (b).

Requirements

• Verifiers MUST follow the verification procedure as specified
• Verifiers MAY use a (pre)deployed multicall contract or a deployless multicall mechanism.
• Verifiers MUST include an authorizationList parameter containing authorization (in the wrapped_signature) in the eth_call request for Step 3(iii).

Rationale

Offchain Verification

The procedure for 0x8010...8010 signatures is intended for offchain signature verification, as onchain contracts cannot apply a delegation in a transient or simulated manner.

Atomic Simulation Context

The design executes initialization and validation atomically (via a verifier or multicall contract) to ensure state changes from initialization are visible during validation. This mirrors the execution flow when a EIP-7702 delegation transaction includes authorization.

Backwards Compatibility

This ERC leaves the inner signature unaltered in the wrapped signature foramt, rather than ABI-encoding it. The assumption is that most ERC-1271 isValidSignature implementations rely on a static length for the signature, and will therefore parse the inner signature correctly when reading up to the defined context. This ensures wrapped signatures can still be validated if they are passed to ERC-1271 isValidSignature as-is for whatever reason.

Test Cases

TBD

Security Considerations

TBD

Copyright

Copyright and related rights waived via CC0.