Is it possible to add a custom parameter in the erc20 transfer function without breaking the erc20 standard?
What I want to do is have off-chain whitelist base on the signatures, I would like users to pass signature with their transfer calls which then will be verified and allow or disallow transfer, however, I do not want to break erc20 standard as I want my erc20 contract to be supported by all the modern wallets
Hi @Damian_Klepacki,
Welcome to the community 
.
If your token transfer function definition is different from the ERC20 standard then existing wallets won’t be able to transfer your token, though they could still display token balances. Your users would then need to use dapps/wallets that did support the signed transfer to transfer your token.
For an on-chain whitelist, you could look at using Role Based Access Control specifically WhitelistedRole.
You could look at using ERC777 where send includes data that can be used in send or receive hooks.
Perhaps someone else in the community can recommend how to do an off chain whitelist for token transfer.
Indeed, this custom transfer functionality would not be ERC20 compliant and wallets wouldn’t be able to work with it. Think about it this way: wallets don’t have a “signature” field in the UI for ERC20 transfers, so users wouldn’t even be able to input the signature.
The only way I see of doing an ERC20 compliant “offchain” whitelist is to require users to submit the signature in a separate transaction to have their account whitelisted. From then on, as far as their account is concerned, the ERC20 token will act compliantly. However, if it’s each transfer rather than account that needs to be whitelisted, this will not work.
I don’t see a way to do a fully offchain whitelist for ERC20 transfers that does not require a pre-transfer transaction. If there is a way, it will be a very clever one.
It’s worth noting though that many wallets can actually work with arbitrary contract ABIs, and they can create a basic UI with input fields, such that if your contract has a custom transfer function with an extra signature field they would be able to use it. Although this is probably going to be a mediocre user experience.
Thank you guys for this amazing replays. I will dig a bit dipper and post a potential solution here. I was also consider using oracle to contact external database and see if transfer to address is white listed or not, but I never worked with orackles and I’m not sure if its possible to cover the cost of calling orackle from gas fee that user is sending with the transfer request.
Hi @Damian_Klepacki,
How did you get on with your investigation?
We decided to go with onchain whitelist system, we have a whitelist contract which has add/get/delete functions, and each erc20 is creating instance of this contract to access the whitelist, the reason we want it to have it off chain is because 1) to make it cheap to add/delete/get customers to whitelist. 2) we will have multiple erc20 contracts and they all needed to share the same whitelist.
The solution is not perfect as we need to add customers to the whitelist ourselves which cost us gas. We will look into off-chain whitelist once the cost of adding to the whitelist will be too much to handle.
Hi @Damian_Klepacki,
So it sounds like you will have a single white list contract that each ERC20 can check.
You could potentially sign a message off chain that users then provide to add themselves to the onchain white list so that the users are paying the cost of white listing.
We could do this as well, the problem is that there will be multiple users (admins) using the white-list, and they will add/delete people from it as well. If we require signature to this it will be very centralised around us