You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
EIP-712 does not currently specify how the inputs to the eth_signTypedData JSON-PRC method should be encoded. For example, it doesn't say whether to encode boolean values as true and false, or 0, and 1, or as the strings "true" and "false". Different assumptions have been made about how to interpret inputs between eth_signTypedData implementations, leading to incompatible implementations with no clear "correct" answer for how input data should be interpreted.
It seems clear to me that EIP-712 should be amended to include guidance on the expected input encoding. But in the meantime, we should at least be clear about what our expectations are in this library, so that users don't get a different encoding than they expect. We should clearly document our expectations, eliminate any potential ambiguity about how to interpret inputs, and include validation to help users correctly format their inputs wherever possible.
These changes may not be possible with existing signTypedData versions, so these improvements will be made solely on signTypedData_v5 (at least for now).
The text was updated successfully, but these errors were encountered:
EIP-712 does not currently specify how the inputs to the
eth_signTypedData
JSON-PRC method should be encoded. For example, it doesn't say whether to encodeboolean
values astrue
andfalse
, or0
, and1
, or as the strings"true"
and"false"
. Different assumptions have been made about how to interpret inputs betweeneth_signTypedData
implementations, leading to incompatible implementations with no clear "correct" answer for how input data should be interpreted.It seems clear to me that EIP-712 should be amended to include guidance on the expected input encoding. But in the meantime, we should at least be clear about what our expectations are in this library, so that users don't get a different encoding than they expect. We should clearly document our expectations, eliminate any potential ambiguity about how to interpret inputs, and include validation to help users correctly format their inputs wherever possible.
These changes may not be possible with existing
signTypedData
versions, so these improvements will be made solely onsignTypedData_v5
(at least for now).The text was updated successfully, but these errors were encountered: