EIP-712: eth_signTypedData as a standard for machine-verifiable and human-readable typed data signing


For on-going discussion and feedback for EIP712.

Draft is available here

Left old, new right


Just a minor point that should probably be cleaned up.

In the draft spec…


DATA: Signature. As in eth_sign it is a hex encoded 129 byte array starting with 0x. It encodes the r, s and v parameters from appendix F of the yellow paper in big-endian format. Bytes 0…64 contain the r parameter, bytes 64…128 the s parameter and the last byte the v parameter. Note that the v parameter includes the chain id as specified in EIP-155.

But EIP-155 Chain IDs can be larger than a byte (elsewhere in the spec it is encoded as uint256).

Clients probably should not rely on a fixed length response of 129 bytes. Perhaps “a hex encoded byte array of at least 129 bytes…”


This is copied almost verbatim from the official Ethereum JSON RPC. Personally, I think packing the three values into a hex string is a bad idea and I would rather have a structure with v, r, s attributes.

Given the elsewhere mentioned confusion about v,r,s vs. r,s,v order and the above mentioned assumptions on the size of v I’m inclined to go for the object approach instead of packed binary.

What do you think?


I agree that it’d probably be clearer to return a JSON object. Labeled fields eliminate a lot of ambiguity.

If you don’t do this, you’ll have to keep it in r,s,v order given the variable length of v. (And that’s a bit weird, since transactions are signed in v,r,s order.)