A block count is not a duration. The same block count does not preserve the same elapsed time across chains: a 20-block cooldown that equals roughly 40 seconds at a 2,000 ms nominal block time equals about 2 seconds where nominal block time is 100 ms. Code that stores retry, backoff, or cooldown windows only in blocks therefore changes behavior when block times differ. The morpho-org/morpho-bots issue #4 reports block-denominated backoff and settled cooldown values on a fast chain with roughly 103 ms blocks; that report is the motivation here, not an independent verification.
The table is a hypothetical conversion for a 40-second intent, not a measurement or a promise about any chain's real block rate.
| Nominal block time | Blocks = ceil(40,000 ms / block time) | Result |
|---|---|---|
| 2,000 ms | ceil(20.0) | 20 |
| 100 ms | ceil(400.0) | 400 |
| 103 ms | ceil(388.35) | 389 |
Ceiling means rounding up: 389 blocks at 103 ms represent 40,067 ms, not exactly 40,000 ms. At 2,000 ms and 100 ms the division happens to be exact.
Three practical checks:
- Poll against an elapsed clock. Keep retry decisions in milliseconds from a monotonic elapsed-time source, then convert only for display or where a block boundary is genuinely required. This does not replace chain-state checks and does not by itself address reorgs, nonces, or finality.
- Separate backoff from head and cooldown responsibilities. Backoff answers "when should this attempt run again?" Head lag and settled cooldown answer "what chain state do we trust?" Do not let one block counter own both questions; changing a timer cannot repair a stale read.
- Exercise fast, slow, paused, and jumpy clocks. Test with nominal block times below and above the default, with head progression halted, and with irregular jumps. Keep an explicit manual environment override so an operator can pin behavior during an incident instead of editing defaults.
Even with those checks, block conversion remains an approximation. A chain pause, a change in block time, or bursty production makes a block-denominated duration an estimate, not a real-time guarantee. Rounding up reduces undershoot but cannot enforce a deadline.
For provider-selection context, see the BlockVectra RPC provider guide. This is a BlockVectra engineering note and an AI-assisted draft. A different provider does not correct a unit error in application timers.
Top comments (0)