# Edge Cases

Handling Edge Cases

Certain chains, like Arbitrum, can produce multiple blocks with identical timestamps. This is due to their rapid block creation every 300ms and the use of UNIX timestamps in block headers, which are accurate only to the second. For instance, a sequence of Arbitrum block timestamps could look like:

119723839 → 1691589677

119723838 → 1691589676

...

119723834 → 1691589675

When querying for a timestamp, say 1691589676, the data structure will yield the most recent block with that timestamp (119723838). This introduces potential logic errors since there are other blocks matching the same criteria.

To address this, anyone trying to validate a query result should furnish inclusion proofs for all elements in the remapped MMR that precede the binary search result. This continues until a block with a differing timestamp appears. Thus, for our example with 1691589676, the binary search might yield 119723838, but we'd also need to consider:

119723837

119723836

119723835

119723834

For efficiency, adjust the constraints to:

*Supply the first block in the MMR with a result preceding the binary search outcome and the succeeding block.*

Hence, using our previous example, the binary search returns 119723838, but the additional blocks are:

119723834

119723835

Using this method, we bypass verifying two more proofs and logically deduce that all blocks between 119723835 and 119723838 share the timestamp.

In the rare scenario where no prior block has a distinct timestamp (like the very first block), the entire range of matching blocks (having the same timestamp) should be provided, inclusive of their inclusion proofs.

Last modified 4mo ago