In a standalone blockchain, nodes will not only check the execution of extrinsics, they will also check the inherent data for consistency with the real world.

In the case of a parachain, the parachain nodes do these checks as well. Do the relay chain validators who execute the parachain block, also check the parachain's timestamp inherent?. I could imagine them checking it either for consistency with the real world, like the parachain nodes themselves do) or for consistency with the relay parent block.

I know this used to happen in the CheckInherents section of the register_validate_block! macro. But it seems that was removed in https://github.com/paritytech/cumulus/pull/2658

I understand that the consensus related checks now have a new dedicated hook, but what about timestamp? Is it still checked?

(And a secondary question, why do the docs I linked still show the CheckInherents? even though it was removed?)

1 Answer 1


AFAIR, validators don't care about parachain timestamps anymore. They just convert the relay parent block number into an approximate timestamp and use that when validating parachain blocks.

The decision was made to add CheckInherents logic back after removing it. This was done for backwards compatibility, though parachain teams are encouraged to avoid using it.

  • This seems like a security problem to me if I'm understanding correctly. Normal blockchains rely on their own validators/miners to check the timestamp offchain and then it is trustworthy in the runtime. For parachains, how can they ensure that the validators don't accept a block with an invalid timestamp? Looking from another perspective, is there any way for a parachain to have a secure timestamp inherent? Or is it better for parachains not to have a timestamp inherent, and instead rely on the relay parent's time? Nov 20, 2023 at 21:19
  • The optimal implementation for parachains at this point is to use the relay parent's time. Cumulus consensus was already changed to make this the case. A parachain can still use its inherent for business logic, though there isn't a good reason to do so anymore AFAIK. It appears that validators still check the accuracy of timestamps against some maximum drift in check_inherent of substrate/frame/timestamp/src/lib.rs. So it shouldn't be a security risk, as validators would reject blocks with logic based on invalid timestamps. Nov 21, 2023 at 23:39

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.