# GSN with ERC20 Compliant Smart Contract

**URL:** <https://forum.openzeppelin.com/t/gsn-with-erc20-compliant-smart-contract/1921>\
**Category:** SDK\
**Tags:** erc20\
**Created:** [December 11, 2019, 5:25am UTC](https://forum.openzeppelin.com/t/gsn-with-erc20-compliant-smart-contract/1921 "2019-12-11T05:25:37Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![sirphemmiey](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/sirphemmiey/32/1479_2.png) [@sirphemmiey](https://forum.openzeppelin.com/u/sirphemmiey)\
**Post date:** [December 11, 2019, 5:25am UTC](https://forum.openzeppelin.com/t/gsn-with-erc20-compliant-smart-contract/1921/1 "2019-12-11T05:25:37Z")

</div>

I am trying to transfer ERC20 tokens from one address to another address with no ether via OpenZeppelin GSN.

**💻 Environment**  
“@openzeppelin/gsn-provider”: “^0.1.9”,  
“@openzeppelin/gsn-helpers”: “^0.2.1”,

**📝Details**  
I’m following the tutorial here: [https://docs.openzeppelin.com/sdk/2.5/gsn-dapp](https://docs.openzeppelin.com/sdk/2.5/gsn-dapp). And I have successfully done everything required (though locally on Ganache). But i’m facing a problem. I am building an ERC20 compliant smart contract. And i need to call `approve()` before calling `transferFrom()` but if I call the `approve()` function it returns "Error: Could not get relay hub address from recipient at ". And i guess the reason is because the ERC20 token is not configured to accept relayed calls. But i can’t call the `transferFrom()` function because it will revert. Please, how do i go about this problem with GSN?

Note: For now (development phase), i am developing both the ERC20 token and contract transferring the token. But in production, i would use ERC20 tokens already deployed.

**🔢 Code to reproduce**  
Implement ERC20 compliant smart contract that transfers tokens from an address to another address with `transferFrom`

---

<div class="post-metadata">

**Author:** ![abcoathup](https://sea2.discourse-cdn.com/flex022/user_avatar/forum.openzeppelin.com/abcoathup/32/415_2.png) [@abcoathup](https://forum.openzeppelin.com/u/abcoathup)\
**Post date:** [December 12, 2019, 12:44am UTC](https://forum.openzeppelin.com/t/gsn-with-erc20-compliant-smart-contract/1921/2 "2019-12-12T00:44:39Z")

</div>

Hi @sirphemmiey,

Welcome to the community forum 👋 Thanks for posting your question here.

The issue is that the ERC20 token is not GSN enabled.

To use an ERC20 token with a contract receiving tokens requires two transactions:

1. **Approve** : The user calls [`approve`](https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#IERC20-approve-address-uint256-) to set an allowance for the ERC20 token to use with the contract receiving tokens. (or use [`increaseAllowance`](https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#ERC20-increaseAllowance-address-uint256-))
2. **Transfer From** : The user calls the contract which then calls the ERC20 token [`transferFrom`](https://docs.openzeppelin.com/contracts/2.x/api/token/erc20#IERC20-transferFrom-address-address-uint256-) function to transfer an amount of ERC20 token to the contract receiving tokens.

If only the contract is GSN enabled, then users would still need to have Ether to call `approve` to set an allowance.

Otherwise for users not to require Ether, both the ERC20 token and the contract receiving tokens would both need to be GSN enabled. This would still require two transactions.

Is there a specific ERC20 token that you are looking at?  
How will your users obtain the ERC20 tokens?

One potential solution (depending on the token and how they obtain it) could be:

> [@How to use the GSN with DAI?](https://forum.openzeppelin.com/t/how-to-use-the-gsn-with-dai/1331/4):
>
> 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 …