MrChico

Thanks @maurelian, added a comment about the approval front running attack. @nipol The `deadline` parameter is a way to mitigate the [free option](https://blog.althea.net/the-free-option-problem/) that the relaying party gets when receiving...

Actually @maurelian I was just made aware of the [xDai staking token implementation of `permit`](https://etherscan.io/address/0x0Ae055097C6d159879521C384F1D2123D1f195e6#code) which I think does what exactly what you are alluding to here. It shares the...

> We can't show you the "Free Options" article every time ask for a signature. If we cannot effectively explain deadline to the signer and Tx Relayer, uint256(-1) will be...

@axic I'm planning on mentioning the Stake-flavored implementation under "backwards compatibility", making that, the dai and chai implementations all belong to this " semi-compatible" class, but keep the specification as...

> > The standard ERC-20 race condition for approvals applies to permit as well. > > Why not take the opportunity to fix this? Otherwise, we might end up with...

> I'd also consider changing its name to something else, since `nonces` is quite generic and non-descript. Do you have a suggestion?

Keep in mind that a change in this name would make this etc incompatible with Uniswap v2 (and even more incompatible with dai and chai)

Its okay for nonces to be generic, in some cases it can be an advantage. The erc doesn't specify other methods can't use `nonces` for other purpose

But most of the time, this doesn't seem like a particularly important concern

> I think it would be useful to have a function that let smart contract know if the permit call will succeed if executed. > For example, when a contract...