When should a protocol should emit an event?

Question

I understand that a protocol can emit events for any of the following reasons:

1. Make it easier to do a data migration in the future (ie, copy-pasting storage mappings is much easier with events)
2. Store data that a smart contract doesn't need to access in a cheaper location than storage
3. Allowing indexing services to index such data
4. Allow front ends to listen for updates

But, is there a hard-and-fast rule for exactly when you should emit an event?

Answer 1

Yes, those are the main reasons for emitting an event. But one more thing is that contracts cannot read event data which makes it a bit more secure than the return statement as we can also return as a response to the front-end. But, on the contrary, events are costlier than return statements, so one might want to rethink if events are essential.

As for hard and fast rules, there isn't one and it's totally up to the developers what they facilitate but emitting an event is considered more organised code.

Answer 2

The rule of thumb at the moment is that if you're going to change storage, emit an event.