My contract has data that is only for front-ends to read (the contract will never need to reference it again).

Is there any reason to write that data to the blockchain, or can Events just be emitted with the relevant information? So that front-ends can just scan the logs.

Emitting Events is apparently much cheaper than storing on-chain data, so sticking with Events is enticing.

Is speed an issue? How efficiently can web3 scan all blocks looking for Events, compared to reading from a contract? What other considerations are there?

2 Answers 2


Events are actually a form of saving data in the network, one that is cheap. The only reason to not to use events logs instead of saving data in the storage of a contract is if another contract will need that data or if not having the data in the storage of the contract force users to trust the backend system that process the data. Other than that, I will go for events.

In terms of speed or performance reading the logs, given the structure of the blocks, searching is very efficient.

Hope this helps.


Events will emit when and only that particular action occurs, not like it scans all the previous blocks and act accordingly unless you added that logic in between.

It is not a recommended practice to do unrealistic looping on the block data from solidity.

As the language constraints it is the one way for getting something out of smart contract for free and in realtime, so do your optimisation to make it effective.

  • I see. I meant that my front-end could scan the logs for data, rather than reading from the contract data. Those are the two options I'm weighing. Dec 10, 2017 at 4:03

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.