Just wondering why the ERC20Permit contract hardcodes the EIP712 domainSeparator version to 1 instead of exposing that in the constructor along with name?
I guess it makes sense for a token contract to have only a single version 1. But what about an upgradeable ERC20 that implements ERC20Permit? If such a contract upgrades to another version, and the EIP712 version stays at 1, wouldn't that allow valid permit signatures from the previous version of the contract to be used in the upgraded version?
Hi, since the contracts library is not to perform upgrades there always will be just one version of every contract, so it makes sense to hardcode the "1", as you can see in the documentation on the EIP712 the way to upgrade the parameters if by performing an upgrade(using this library instead), because that's the kind of structure that would allow to have several versions of a contract.
1 Like
I think @sebastiantf's question is valid even if the contract is upgradeable.
I think we hardcoded version 1 to simplify use, but there may be cases where this isn't good enough. If so, please open an issue.
I think your post is missing the last part. But if I see where it's going, the EIP712 version doesn't need to be incremented when the contract is upgraded.
1 Like
Thanks for pointing that out. Apologies!
If such a contract upgrades to another version, and the EIP712 version stays at 1, wouldn't that allow valid permit signatures from the previous version of the contract to be used in the upgraded version?
I guess that's a very specific and uncommon requirement, but just wondering if that is a good enough use case. But I also realize from @JulissaDantes's comment that they're indeed only supposed to be / can be changed during an upgrade.
The reason I actually brought this up is I saw some contracts with EIP712 using specific versions like 1.0.0. So I was wondering how someone would do that with ERC20Permit. Version upgrades with smart contracts does seem to be breaking changes that often bump major versions, but what about minors or patches that are bug fixes or some internal logic change that doesn't really break the external API?
Apologies again for this long post 
PS: I couldn't find a way to edit the original post
You're right that if you want to invalidate permits on an upgrade you have no way to do that with our ERC20Permit contract. I can't imagine why you'd want to do that though? For other kinds of EIP-712 signatures it may make more sense.
I agree that the chances are slim. Just wanted to know the reason behind the hardcoded version, and bring about a discussion about letting the version changeable on ERC20Permit constructor.
If this gets enough support, happy to create an issue.