---
eip: 8010
title: Pre-delegated Signature Verification
description: Enables ERC-1271 signature verification for accounts that intend to delegate via EIP-7702, whilst falling back to ERC-6492 verification.
author: Jake Moxey (@jxom), howydev (@howydev), Tanishk Goyal (@legion2002), Ivo Georgiev (@Ivshti)
discussions-to: https://ethereum-magicians.org/t/new-erc-signature-verification-for-pre-delegated-accounts/25201
status: Draft
type: Standards Track
category: ERC
created: 2025-08-21
requires: 1271, 6492, 7702
---

# 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](./eip-7702.md) before onchain delegation occurs. The standard introduces a detectable signature wrapper containing an [EIP-7702](./eip-7702.md) authorization and initialization data, allowing verifiers to simulate the delegation and validate signatures through [ERC-1271](./eip-1271.md) in a single atomic operation, whilst falling back to [ERC-6492](./eip-6492.md) 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](./eip-1271.md) infrastructure, including Create2-based predeployed verification ([ERC-6492](./eip-6492.md))

## 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:

```solidity
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](./eip-6492.md) verification procedure, and return the result.
        - This will handle predeployed CREATE2, [ERC-1271](./eip-1271.md), 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](./eip-1271.md) 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](./eip-1271.md) `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](./eip-1271.md) `isValidSignature` as-is for whatever reason.

## Test Cases

TBD

## Security Considerations

TBD

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).