Solidity ERC20 – How to Approve and TransferFrom in a Contract

erc-20solidity

I have a contract with the following function:

function offerTokenTribute(address[] _tokenContractAddresses, uint256[] _tokenTributes) public {
  require(_tokenContractAddresses.length == _tokenTributes.length);

  Member storage member = members[msg.sender];
  member.approved = false; // should be already, but lets be safe

  for (uint8 i = 0; i < _tokenContractAddresses.length; i++) {
    ERC20 erc20 = ERC20(_tokenContractAddresses[i]);
    erc20.approve(this, _tokenTributes[i]);
    member.tokenTributeAddresses.push(_tokenContractAddresses[i]);
    member.tokenTributeAmounts.push(_tokenTributes[i]);
  }

  TokenTributeOffered(msg.sender, _tokenContractAddresses, _tokenTributes);
}

The problem is the erc20.approve function is not approving on behalf of the original msg.sender, it is changing msg.sender to the contract address (I verified this by checking allowances).

Is there any way to do this from my contract, or is the only solution to call the approval outside of my contract (non-ideal)?

Best Answer

No, there is no way around it.

It is a security feature, a contract cannot impersonate other account.

Related Solutions

Solidity – Handling Unimplemented Functions in Contracts

The problem is that totalSupply() implementation is missing. Seems like autogenerated getters do not count. So you need to explicitly create the function.

contract StandardToken is Token {
    uint256 _totalSupply;

    function totalSupply() constant returns (uint256 totalSupply) {
        totalSupply = _totalSupply;
    }
}

ERC-20 – Fixing Issues with Approve and TransferFrom for ERC20 Payments

If you are using someone else's ERC20 token, then you will not be able to do this. The approve function in a standard ERC20 contract is made to use the msg.sender which, as you have noticed, will take the form of the calling address (like a contract), rather than the root address which initiated a transaction.

This is actually a way to prevent from attacks against the token. Imagine you could build a contract which a user calls, that triggers another ERC20 token and make some sort of change on behalf of the user. You could then use this behavior in a malicious function, where you trick the user to call your contract function, and then you steal all of their coins.

Because the approve function is written the way it is, the only way a user could have their tokens manipulated with, is through explicit action by that user directly to the token contract that they know about.

The approve function is actually made exactly for your kind of scenario, where the user can "approve" your contract address to spend some amount of tokens, and then you can build functions which can call transferFrom() to then interact with those tokens.

Now, you can build your own ERC20 token, which would allow for this exploit by replacing msg.sender with tx.origin which is always the root caller of the transactions (always an EOA), but as I mentioned above, this would leave you vulnerable to other contracts exploiting your choice.

I hope this helps.

Best Answer

Related Solutions

Solidity – Handling Unimplemented Functions in Contracts

ERC-20 – Fixing Issues with Approve and TransferFrom for ERC20 Payments

Related Topic