1

I'm wondering when you should consider that a transfer of ERC-20 tokens is confirmed. At the beginning I thought that just making sure the transaction calling transfer is confirmed successfully was enough, but then I started to think that maybe I should wait for the Transfer event instead.

I've seen that most tokens out there just emit the Transfer event right there inside of the transfer function. However let's suppose the following contract:

  • User A calls the transfer function to transfer tokens to address B
  • The transfer function sends an event to ask for validation of user B
  • The transfer function will be completed at this point, but tokens haven't been transferred yet and the Transfer event is not triggered either
  • Someone validates user B and calls another function in the contract that completes the initial transaction (tokens are moved)
  • The Transfer event is triggered now, indicating that the transfer has been completed

In this case, the correct thing to do would be to wait for the Transfer event to confirm a transaction of tokens, because just waiting for the confirmation of the transaction calling the transfer function is not enough.

However I'm not sure if that's what ERC-20 specification says and what most tools that work with ERC-20 tokens expect. So my questions is if it is fine to create a token where the confirmation of the transfer is done when the Transfer event is triggered instead of when the transaction to call transfer is confirmed.

1

The transaction that calls transfer and the Transfer event happen at the same time. Transactions are atomic, meaning things that happen in it happen, from an external application's context, at once or not at all. So you can either listen for the event or for the transaction's confirmation, it's up to you.

  • In the sample I wrote above that's not the case. I will make it more explicit. – dgaviola May 7 '18 at 19:35
  • I would say that that sample would be implemented poorly. You should instead use the approve/transferFrom portion of the ERC20 standard. transfer should cause a Transfer event unless it fails, in which case it reverts instead of succeeding. – flygoing May 7 '18 at 19:37
  • 1
    Yep, according the spec the Transfer event MUST be triggered in the transfer function, so I think you are correct. – dgaviola May 8 '18 at 13:55
1

The token is confirmed when Transfer is triggered.

However you need to take account the probabilistic finality of proof-of-work blockchain. If you can scan the latest (local) block it might be a minor fork due to miners racing for it. Wait at least some 10-20 blocks for the final settlement under the normal conditions.

  • 1
    I looked around a bit more and found this wiki: github.com/ethereum/EIPs/blob/master/EIPS/eip-20.md#transfer. If you look in the description of the transfer function, it says that it MUST trigger the Transfer event, so I think if the transaction for transfer call is successful (waiting for enough blocks confirmations) then we can consider the transaction confirmed, even without checking the Transfer event. – dgaviola May 8 '18 at 13:54
  • @dgaviola yes, but if you're doing something off-chain (e.g. crediting their account on a centralized exchange with the balance), then you should wait for some number of blocks to be sure it's unlikely to be reverted – flygoing May 8 '18 at 14:01
  • Right, but then it won't be a correct implementation of the ERC-20 spec, so I think I should avoid doing that. – dgaviola May 8 '18 at 14:14
  • Transfer events are for off-chain purposes only as smart contracts cannot access the event log in any case :) – Mikko Ohtamaa May 8 '18 at 16:07

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.