Thanks guys for the awesome GSN project!
We have one problem though – how we can allow our users to execute operation approve() on the smart contract that we do not actually control/developed (DAI token for example)? Our dapp would use DAI as the currency and our smart contracts should be able to obtain DAI from the end user, but before we can collect any DAI user would need to approve() our smart contract. Any solution to this problem?
Thanks a lot!
Marcin
Hi @zduniak, welcome to the community 
I am not sure if there is a neat solution to this as I assume that the user would have needed Ether to obtain the DAI. Hopefully someone in the community may have an answer.
Certainly have a look here: https://docs.openzeppelin.com/contracts/2.x/gsn-bouncers
Although I don't think this solves your particular problem. Basically what you are asking, if I understand correctly is: a user already has interacted with a non-GSN enabled contract (IE: the ERC20 for DAI) and at this point, their DAI balance is associated with an address which is the "owner" of this DAI.
In this case, depending on what the DAI contract actually allows you to do, the user will still need to go through the steps to either move the DAI or whitelist your GSN enabled contract addresses. There might be some clever way around this- but I don't think so. The DAI contract won't move the DAI unless the address which owns it signs a transaction approving it.
There are some UX methods you could do to make this process simpler, but I don't think you can get away from the user signing this transaction. The upside is though, once they are in your "System" they won't have to worry about this anymore.
We've thought about this issue, and there are a couple solutions, but none are trivial.
From my understanding, it is possible to purchase DAI with fiat, and not have any Ether in that account (though this is weird - the DAI is essentially locked in that account until it gets funded, so I'm not sure how those services work).
What you could do is, instead, have the user transfer the tokens to a pre-computed address, where a contract account / identity contract will be deployed counterfactually (using create2). You can then set that contract to give allowance to your recipient and sidestep the issue that way. It's also possible to use some of this initial balance to pay for the deployment of the contract account itself, so there's no risk from the recipient side. The main issue with this setup is the need for the DAI to be sent to an address specified by your dapp.
This is quite complex and there are some tricky details involved; we'll probably have a more in-depth guide and tools to support this advanced use case in the near future. Stay tuned!
Hey! We built https://gdai.io on ETH Boston last weekend. You can now transfer DAI without having any ether on your wallet!
Feel free to give feedback!
Exciting stuff @deacix. Can you share any details regarding what is happening behind the scene?
Hello,
In this case, can we use https://github.com/ethereum/EIPs/issues/662 ?
This way we can execute the off-chain signed approve and transferFrom function and execute the DAI transfer on behalf our user, so he will not have to pay gas fee ?
What do you think ?
Hi @akersof,
Welcome to the community
Did any more happen with EIP-662, the last comment is over 18 months ago?
I can see in the comments for ERC-777 that operators were used instead of using provable meta-transactions.
What do you think are the benefits to use EIP-662 over GSN?
In any case, my understanding is that either a new flavour of DAI appears to be required (e.g. gDAI), or use some form of contract account / identity contract.
Interested to hear more opinions from the community on this.