First Flight #17: Dussehra

[H-7] The Dussehra protocol will be deployed, among others, to the zksync. However, ZkSync is currently transitioning to a new mechanism of calculating block.timestamp. This transition will likely continue into October. Zksync documentation notes that during this transition block.timestamp should not be used to calculate time.

Description: The documentation from zksync notes that (I added emphasis)

The block production rate and timestamp refresh time will be gradually increased during the catch up period.
If your project has critical logics that rely on the values returned from block.number, block.timestamp or blockhash you might face unexpected behaviour (e.g. reduced time for governance voting, spike in rewards etc.). These logics could include (non-exhaustive):

• [...]

• Relying on block.number to calculate when an auction ends or calculate time.

• [...]

Additionally, please note that transient storage (and related Opcodes TLOAD and TSTORE) are not supported in zkSync. See the the official documentation: https://www.rollup.codes/zksync-era Both of these are used in the OpenZeppelin v5 that is imported in RamNFT.sol. It does not seem to create an issue at the moment (as ERC721 remains unused in RamNFT) but could become a problem as the protocol is adapted prior to deployment.

Impact: Currently, and into October, block.timestamp on zkSync cannot be used to calculate time or date. It breaks the core functionality of the contract on this chain.

Recommended Mitigation: Either completely change the functionality of the protocol, in order for it not to depend on block.timestamp for its functionality, or do not deploy to zksync.