2

Refer to the link below:

https://github.com/bokkypoobah/Tokens/blob/master/contracts/MyToken.sol

Line 62:

contract ApproveAndCallFallBack {
    function receiveApproval(address from, uint256 tokens, address token, bytes data) public;
}

And line 209:

ApproveAndCallFallBack(spender).receiveApproval(msg.sender, tokens, this, data);

If I understand correctly, line 209 is calling the default constructor of ApproveAndCallFallBack contract (which obviously does not exist), and call the receiveApproval() interface which is obviously not implemented here.

Anyone know how is this contract suppose to be used?

|improve this question
  • try to have a look here: ethereum.stackexchange.com/questions/36763/… – mirg Mar 19 '18 at 2:52
  • mirg, thanks for the comment, but this interface is not implemented at all. As far as I know, we can't add codes to the interface once contract is deployed right? – s k Mar 19 '18 at 3:13
  • For what I understand that's just an interface. So if the sender is actually a contract that implement the ApproveAndCallFallBack (and so will implement receiveApproval) that method will be called. – mirg Mar 19 '18 at 3:27
5

approveAndCall for exchanges

The approveAndCall / receiveApproval pattern is an old pattern used by exchanges to perform an atomic transfer of funds in a single step. This old method has mostly since been superseded by other standards, however it's still quite common in usage.

The idea is that an exchange wants to do 2 things.

  1. Buy tokens for you.
  2. Take your money.

Ideally the exchange wants to do these things together so that they don't get stuck holding tokens you can't pay for, or have you pay for tokens they can't retrieve and have to refund you.

The answer to this is to have a way they can call the transfer function and then do something on their side before completing the transfer, and if anything fails, the whole thing falls over and rolls back.

The typical workflow is:

  • they call approveAndCall in the token contract which verifies the transfer is possible.
  • the token contract calls them (or their surrogate contract) back via receiveApproval.
  • the receiveApproval function does the funds transfer (or other action) as required.
  • the token contract gets control back and performs the token transfer.
  • if any one thing fails, it all fails together and no cleanup is required.

However this can all now be accomplished via ERC223 using the tokenFallback() method, which also has the handy side effect of ensuring that your token doesn't get stuck in contracts that can't handle them.

|improve this answer
  • As far as I know this isn't limited to exchanges at all. Any contract can be implemented to 1.) (Do Something) for you 2.) Take your money (~tokens~ in this case, eth can be accepted natively with the payable modifier). Also, ERC223 at this point today represents one off a pattern, not an official standard. – Zach_is_my_name Dec 18 '18 at 4:41
  • Well you're right of course. A hammer can be used to juice an orange too, but if someone asks what a hammer is used for, the closest answer is probably for nailing things. – norganna Dec 18 '18 at 7:28
  • I like metaphors but I’m not grasping it here. I shared perspective, you have yours. Let’s let the people decide what they implement. We won’t settle that here – Zach_is_my_name Dec 18 '18 at 7:34
  • May I ask how receiveApproval() is being used if it is not implemented anywhere (see here too raw.githubusercontent.com/bokkypoobah/Tokens/master/contracts/…). I don't feel like that part of OP's question was answered – Zakoff May 26 at 12:28
  • When someone calls approveAndCall they will pass in a spender contract that implements receiveApproval. The example contract is not a spender so doesn't need to implement it. – norganna Aug 31 at 11:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.