EIP-712 Standards Clarification (primaryType as DomainType)

EIPs
1

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,
    verifyingContract,
    nonce,
    destination,
    gasLimit,
    data,
  },
  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
2

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:

3

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.

4

Published as eth-sig-util@2.2.0