EIP-712 Standards Clarification (primaryType as DomainType)

Is there any reason why I couldn’t set the primaryType to the EIP712Domain type? It seems that would still be congruent to EIP712, but would allow me to specify the typing / data in the way I want, which is highly gas sensitive for deployment / verification (thus constructing only a single type and not 2 would be ideal). Yes, I have replay protection covered on all fronts.

The type data for a eth_signTypedDataV3 request to metamask would be as follows:

const typedData = {
  types: {
    EIP712Domain: [
      { name: "chainId", type: "uint256" },
      { name: "verifyingContract", type: "address" },
      { name: "nonce", type: "uint256" },
      { name: "destination", type: "address" },
      { name: "gasLimit", type: "uint256" },
      { name: "data", type: "bytes" },
  domain: {
    chainId: 1,
  primaryType: "EIP712Domain",
  message: {},

Can this be clarified @fulldecent @danfinlay?

I believe this to be standard, even if it’s a slight misuse of EIP712 intentions. I just don’t like being constrained to two hash productions if I don’t absolutely need it. And in this case, it would be great to get all the typed data work done in the domain than in the message / secondary data.

The change to the current EIP712 library would be as follows, as is extremely minimal:

1 Like

Thanks for posting, will try to look closer soon. To add context, you also sent me this example MultiSig wallet as part of your reason for wanting this to work:

This should be fine based on the standard as-written, and I also think this strategy can be a big win in certain contexts in terms of gas. Based on the PR, it looks like it can be implemented in a backwards-compatible manner with the existing implementation.

I can’t think of a reason why reducing hashing in this type of case would ever be detrimental.

Published as eth-sig-util@2.2.0