# Edge Cases

Handling Edge Cases

**Blocks with Identical Timestamps**

**Blocks with Identical Timestamps**

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:

### Problem

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.

### Solution

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:

**Optimization**

**Optimization**

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:

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

**Special Consideration**

**Special Consideration**

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 updated