Are events in Ethereum Tokens worth it?

Question

QUESTION:

Is it worth it to have events in your token? Each transaction usually has the event inside it meaning more gas is spent for the users (which is bad). I don't have a full picture of all the good events bring to the picture so it's hard for me to decide whether to include them in tokens I code.

---

ELABORATING:

After a lot of digging, I came to understand that events (such as those in the ERC-20 token standard) are just logs that provide an easier way for Apps to check what is happening with your token, but don't provide any functionality in terms of making the token work. For instance, here is a subset of code from the ERC-20 Token Standard:

function transfer(address _to, uint _value) returns (bool success);
event Transfer(address indexed _from, address indexed _to, uint _value);

First line is the declaration of the transfer function, while the second is the declaration of the Transfer event. In terms of transactions, the ERC-20 token does just fine without a Transfer event. So why should events even be included if they add gas costs to each transaction? I don't know what the good sides are of having events, and if they outweigh the bad sides, which is why I pose this question.

Answer 1

It's a pretty good default setting to use event logs to create an audit trail such that the entire state history of the contract could, in theory, be reconstructed with nothing but the source code and event logs.

Event logs are useful for clients (current and future) and they are very cheap. In my opinion, it's better to err on the side of completeness and include comprehensive event logs that chronicle every important state change.

Obviously, if one wants to conform to a standard and the standard includes event logs, then personal preference is moot and the event log is a must for a compliant implementation.

Hope it helps.

Answer 2

It's the standard

From a functionality standpoint there's no reason why you need to call the transfer function. I mean the net result is the same regardless of if you call it or not, so if all you want to do is keep a ledger balance of allocations in your contract, there's absolutely no reason for you to emit the events except for one very important one.

It's the standard.

If you don't emit an event every time a transfer occurs, then you're not implementing an ERC20 standard token.

What you're implementing could be said to be like an ERC20 token, but it would affect your ability to get listed as an ERC20 token on an exchange, to get tracked as an ERC20 token by blockchain sites etc.

You see those sites expect your token to act a certain way. They expect to be able to listen on a global level at Transfer events to see when to update balances etc.

Without this functionality, they would need to know your ABI and interpret your function calls, to have to call your balanceOf function for every single possible address, or interpret your contract to work out how your contract keeps track of balances in variables.

And sure, most contracts keep balances in a mapping(address=>uint), but this isn't necessarily the case. Maybe they could keep track of all the calls to transfer(), but again this isn't the only way that contracts can modify balances.