2

I saw quite a few smart contracts logging the current timestamp as part of their emitted events, e.g.:

event TokenLaunched (
    uint256 timestamp,
    uint256 id
);

function launchToken(uint256 id) external {
    _launchToken(id);
    emit TokenLaunched(block.timestamp, id);
}

Why do people do that, and would it be better to omit this? Especially since you can retrieve the timestamp using the block number with web3.

1

With web3.js, the block.timestamp is not included in the log object returned when listening to events. If someone wants to know the block.timestamp, they have to make another call to get it.

It's not much trouble to make that call, but if you really want to avoid it, embedding the block.timestamp in the event would work.

1

It depends on your needs but, personally, I don't think this is warranted for most use cases. the block timestamp is the same across all the events emitted in that block, so in your client app you can read that block's timestamp and you're good to go.

That is, not just the events emitted in your contracts but all the events emitted in all contracts which were touched by some transaction in that block.

1

This does not make any sense.

Any event emitted by Solidity includes the timestamp and block number implicitly. Adding it the second time just increases the cost of the transaction.

It is just poor programming. Please tell it to authors of these contracts that they unlikely know what they are doing.

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.