Replies: 1 comment 1 reply
-
If I understand correctly, I think the issue being addressed by that is that there could be multiple “things” a single signer could want to sign, and the goal is to make sure you don’t sign a payload for one purpose that is then used for another. Imagine if there were two methods, ApproveTransfer(address spender, address spendee) and AllowMint(address minter, address token). I won’t want approving a transfer to bestow minting right, when submitted to a the contract via a “permit” style method. If I understand correctly? Does that make sense? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi Richard @ricmoo
This question is not about ethers, but I have asked this at many places and didn't get an answer at all and I am dying of curiosity. I'd appreciate so much if you have some opinion on this as I really love your explanations and your dedications. Thank you for that.
In EIP712, there's a TYPE_HASH that we sign including other data. For example:
The above works great, but what's the rationale of even using BID_TYPE_HASH ? To ask it in better words, what if EIP suggested to do:
What could go wrong now ? Domain Separator already distinguishes dapps, so isn't that enough ? Can you provide an example where this suggested code breaks and defeats the use-case ? Note that I understand metamask's and ether's
eth_signTypedData
signs the message including typehash, but why ?Beta Was this translation helpful? Give feedback.
All reactions