Hi,
I am working on a new ERC-20 token. I would like to make the token smart contract future proof, so that it would work in the future with different gasless tx systems. What would be your recommendation here to go forward? Should I need to implement GSN support directly in the token contract or do you advise against this - what are the strategies here?
I also opened an ethereum.stackexchange.com question on this if somebody wants to have their 100 rep bounty: https://ethereum.stackexchange.com/questions/80112/gasless-transaction-and-easy-approval-integrated-to-an-erc-20-token
1 Like
Hi @miohtama,
I am not sure how future proof you can make your token (without making it upgradeable), though it is definitely worth looking at whether enabling GSN for your token meets the needs of your intended use case.
As an ERC20 you need to consider the approve and transferFrom pattern. As well as making your token GSN enabled, any contracts that your token holders interact with using their tokens that you want them to use without having Ether will also need to be GSN enabled.
I would start with looking at the documentation: Sending Gasless Transactions.
You would need to make your token a GSNRecipient and have a GSN Strategy (decide which relayed calls you want to pay for).
I would suggest looking at GSNRecipientSignature as this offers a lot of flexibility. If you used this strategy, you may want to add functionality to allow you to change the trusted signer if you needed.
There would be some extra overhead on deployment, and I assume a small amount on checking msgSender (https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v3.0.0-beta.0/contracts/GSN/GSNRecipient.sol#L88).
You could check these overheads.
Overall, I think making your token GSN enabled is worth considering to have the option of allowing transactions via the GSN. I assume that other meta transaction solutions wouldn’t be incompatible (though you would want to check),
You may want to look at creating an ERC777 token (no need to do approve and transferFrom in two separate transactions). See the documentation for details: https://docs.openzeppelin.com/contracts/2.x/tokens#ERC777
Something else to consider, OpenZeppelin Contracts 3.0 is in beta and uses Solidity 0.6. OpenZeppelin Contracts 2.5 uses Solidity 0.5.
I would also look at other meta-transaction schemes, including smart contract accounts, though it really depends on your use case of how your token holders use your token.
Hi @miohtama,
Did the above answer your question? Let me know if you need any more information?
Hi @abcoathup,
Indeed it did.
I think this time I will refrain to add GSN network functionality, as it might delay our plans too late. I was hoping for a ready made example. However, making the contract upgradeable is something I am considering now.
1 Like
I might also stick for Solidity 0.5 for now as it is more battle proven.
1 Like
Hi @miohtama,
When thinking about making your contract upgradeable, governance of the upgrade process is important. Making sure that it is clear to your users under what circumstances the smart contract can be upgraded.
I suggest having a look at: Governance for Smart Contract Upgrades
If I use a proxy contract for upgrades, does the proxy contract itself needs any special support for GSN? Or is GSN transparent regardless of the first point of contact contract and I can upgrade later for GSN support?
Just making sure not digging myself a hole here 
1 Like
Hi @miohtama,
The proxy contract doesn’t need any support for GSN (See How Upgrades Work).
The issue with enabling GSN on the token during an upgrade would be ensuring that we didn’t change the order which state variables are declared. (See Modifying Your Contracts). This would need appropriate testing prior to upgrading.
Ok. I understand this risk. Thank you for super good feedback as always.
1 Like