Change ERC20 Transfer function to account for contract as sender

Question

I have a contract we will call A that uses the transfer function from an ERC20 contract we will call B through an interface. However, the transfer function will not work as expected because in the call from user -> A -> B the msg.sender is now the contract address of A and not the user's address anymore.

I can think of two immediate ways to solve this.

1. Pass the original msg.sender (user's address) as a param to the transfer function
2. Change msg.sender in contract B's transfer function to tx.origin

However both of these solutions modify the ERC20 token standard contract which I am not sure if that is good practice.

I can see how this could be a common issue devs run into. Should I implement one of the above solutions even though it changes the standard contract? If not, then how should I solve it?

Answer 1

The proper way to do this is with the approve and transferFrom workflow. The EOA would approve the contract to transfer the tokens, and then call the function on the contract which would use tranferFrom instead of transfer

Answer 2

This seems like the use of delegatecall() via a proxy pattern is what you're looking for.

With Delegate call, you pass along the original sender to the next contract. However, this can expose you to security risks to the calling contract. i.e. in your scenario contract B as you are exposing Contract A's storage to Contract B.

There are other posts that explain how to use such e.g. Difference between CALL, CALLCODE and DELEGATECALL

How does the delegatecall method work to call to another contract's method?

Great Blog: https://blog.gnosis.pm/solidity-delegateproxy-contracts-e09957d0f201