ERC-8010: Pre-delegated Signature Verification

ERCs
1

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.

4 Likes
2

ERC-6492 places the marker at the end of the signature, could this be done with this ERC as well? It would allow the verification procedure to check for markers in a single place.

It looks like this scheme only enables off-chain verification, right?

If the user delegated to a contract in the past and then redelegated to another contract, signatures for the first delegation should probably be invalidated. I donā€™t think Step 2 correctly handles this. What would handle it is to check the account nonce.

1 Like
3

ERC-6492 places the marker at the end of the signature, could this be done with this ERC as well? It would allow the verification procedure to check for markers in a single place.

Yes, fair. I updated the spec accordingly.

It looks like this scheme only enables off-chain verification, right?

For now, yes. Unfortunately, it is not very trivial (or possible?) to do this onchain right now.

If the user delegated to a contract in the past and then redelegated to another contract, signatures for the first delegation should probably be invalidated. I donā€™t think Step 2 correctly handles this. What would handle it is to check the account nonce.

Will amend!

1 Like
4

I propose that we find a way to develop this ERC into a replacement / successor of ERC-6492.

hereā€™s why

  • 6492 defines the verification order, which is important for correctly verifying signatures
  • 6492 defines an easy way to verify all types of signatures
  • the flow and principle of operation is almost the same

The first two traits make life significantly easier for devs.

You could argue that having this implemented correctly in viem is sufficient and dev ergonomics shouldnā€™t be that important, but this is not the case

Additionally, I could argue that introducing a third EIP into this mix will just make many good-intentioned devs who are trying to keep up with the AA ecosystem just rage quit on signature verification. In other words, mixing 6492 and 8010 verification will be at best slightly annoying, at worst quite the mess (I know in theory you just have to check magics, in practice you branch off code that might already be very branch-y).
A very concrete example of this confusion: when reading 8010, thereā€™s some ambiguity of when 6492 need to be performed: part of the ERC states clearly that it should be done if MAGIC is not found, but thereā€™s no explicit instruction/consensus of which ERC should apply itā€™s logic first, furthermore in most practical cases you might be tempted to identify the type of the account first, which is a can of worms in itself. Two ERCs simply adds way too much ambiguity to order.

Already in touch with @jxom about this

Sidenote: I was originally doubting the value of 7702 counterfactual verification altogether, before I remembered about PREP, which introduces a very valid reason for this to exist.

5

On second thought, I think the best approach is to reference the 6492 algorithm in this ERC for all signatures that are NOT 7702 counterfactual signatures

This way, the flow is very clear, and we donā€™t have the same information across multiple ERCs

6

Amended the ERC to your recommendations!

7

thanks for proposing

similar concern about about stale nonce but not sure I see a way around it currently.

@jxom can we validate chain_id to prevent cross-chain replay

8

The node would validate chain_id on the eth_call authlist, no?