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
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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