From ed922e4455c1b6a52312d66da9c644b51866da59 Mon Sep 17 00:00:00 2001 From: Francis Li Date: Thu, 10 Sep 2026 10:18:59 -0700 Subject: [PATCH] docs(denim): warn about block-number-based contract logic under 200ms blocks Add a Block-Number-Based Contract Logic section to the 200ms Native Blocks page: block.number advances 10x faster in wall-clock time while block.timestamp stays seconds-based, so block-count timelocks, vesting, rate limits, deadlines, block-based governance windows, and TWAP history depth are affected. Align the activation text with the Denim overview's October 2026 planning window. Amp-Thread-ID: https://ampcode.com/threads/T-01a08c4c-75d9-753e-92fa-d96799d82ff0 Co-authored-by: Amp --- docs/upgrades/denim/200ms-blocks.mdx | 36 ++++++++++++++++++++++++---- 1 file changed, 32 insertions(+), 4 deletions(-) diff --git a/docs/upgrades/denim/200ms-blocks.mdx b/docs/upgrades/denim/200ms-blocks.mdx index 6b0f542d3..c04b58722 100644 --- a/docs/upgrades/denim/200ms-blocks.mdx +++ b/docs/upgrades/denim/200ms-blocks.mdx @@ -7,7 +7,9 @@ tag: "Vibenet" 200ms native blocks are live on [Vibenet](/build-on-base/test-on-vibenet) for experimental developer testing. This deployment may change, and you should not rely on it for production decisions. -Denim is not active on Base Sepolia or Base Mainnet; activation times and required client versions remain undecided. +Denim is targeting Base Sepolia and Base Mainnet in October 2026; exact activation times and required client versions remain undecided. + +Denim changes how fast `block.number` advances. If your contracts measure time in blocks, read [Block-Number-Based Contract Logic](#block-number-based-contract-logic) before activation. ## Summary @@ -27,10 +29,36 @@ If your application uses Flashblocks, see [Migrate From Flashblocks](/upgrades/d | Network | Status | Activation timestamp | Required client versions | | --- | --- | --- | --- | | `vibenet` | Live for experimental testing | — | — | -| `sepolia` | Not active | `TBD` | `TBD` | -| `mainnet` | Not active | `TBD` | `TBD` | +| `sepolia` | Planning for October 2026 | `TBD` | `TBD` | +| `mainnet` | Planning for October 2026 | `TBD` | `TBD` | + +Base Sepolia and Base Mainnet activation timestamps have not been scheduled. This page will list the activation timestamps and required client versions once they are set. + +## Block-Number-Based Contract Logic + + +Denim moves Base from one block every two seconds to five blocks per second. `block.number` advances ten times faster in wall-clock time, while `block.timestamp` still advances in whole seconds. Any contract or offchain system that treats a block count as a duration will see that duration shrink to one tenth of its intended length after activation. Block-count constants baked into immutable or non-upgradeable contracts cannot be retuned after activation. + + +Audit your contracts for logic that converts block counts to time before Denim activates: + +| Pattern | Effect after Denim | +| --- | --- | +| Timelocks, cooldowns, and exit delays measured as `block.number - start >= N` | Elapse in one tenth of the intended wall-clock time. | +| Vesting, emission, or difficulty schedules measured in blocks | Complete or retarget ten times faster in wall-clock time. | +| Per-block rate limits or caps that reset when `block.number` changes | Reset five times per second instead of once every two seconds, raising the effective per-second limit ten times. | +| Deadlines set as `expirationBlock = block.number + N` | Expire in one tenth of the intended wall-clock time. | +| Governance voting delay and voting period in blocks, including `ERC20Votes` with the default block-number `clock()` | Voting windows shrink ten times. Stored checkpoints stay correct. | +| Uniswap V3 style TWAP oracles | TWAP values stay correct because accumulators are second-weighted. A fixed observation cardinality covers roughly half as much wall-clock history, so long `observe()` lookbacks revert with `OLD` sooner. | + +Logic that measures time with `block.timestamp` is unaffected. + +To prepare: -Base Sepolia and Base Mainnet activation have not been scheduled. +- Replace block-count durations with `block.timestamp` comparisons where you can redeploy or upgrade. +- Where a block count is governance-tunable, plan to divide it by ten at activation. +- Where a block count is immutable and cannot be changed, assess the impact and plan a migration before activation. +- Test the changed behavior on [Vibenet](/build-on-base/test-on-vibenet), which already produces 200ms blocks. ## Execution