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?

2 Answers 2


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.


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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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