An initial proposal, as seen in the original testnet4 PR, suggested a fix to the timewarp problem by allowing a 2-hour leeway for block timestamp verification. This approach aimed to prevent a scenario where a single miner could unduly influence the blockchain's time by mining the last block of a period with a future timestamp. The idea was that the next block, marking the start of a new period, could validate against the miner's "wall clock" time, thereby circumventing potential manipulation.

However, this original proposition was later revised. After discussions, notably mentioned in BIPs PR 1658, the consensus moved towards tightening the leeway from 2 hours to just 10 minutes, as detailed in PR 30647. This decision was underpinned by concerns over the broader window potentially offering slight chances for inflation manipulation. Furthermore, it was acknowledged that since Bitcoin Core had been modified not to create block templates with invalid timestamps (as per PR 30681), the necessity for a 2-hour leeway was largely mitigated. The reduction to a 10-minute window also serves a secondary purpose: it allows for a controlled environment on the test network to uncover any unforeseen compatibility issues that might arise from stricter timestamp requirements, thus ensuring a more robust implementation of timewarp fixes across the network.