docs(rpc): document planned denim millisecond timestamp fields

[youssefea]

What changed? Why?

Adds a "Denim Millisecond Timestamps" section to the eth_getBlockByNumber and eth_getBlockReceipts API reference pages. It documents the planned optional block-level timestampMs field and the optional blockTimestampMs field on mined logs nested in receipts. Both sections say the behavior is planned for Denim and is not available on production endpoints, and both link to the RPC section of the 200ms Blocks page.

This closes Base Knowledge Base gap gap-20260930-timestampms-blocktimestampms-fields-absent-json: "After Denim's 200ms blocks, which JSON-RPC responses expose millisecond-precision block time: do eth_getBlockByNumber or eth_getBlockReceipts return a millisecond timestamp, and what are the field names?"

• Gaps log: https://bdocs.cbhq.net/d/base-knowledge-gaps-log
• Linear: DEVREL-859

Notes to reviewers

Primary sources for each fact:

• timestampMs is optional, is a JSON-RPC quantity holding the full Unix timestamp in milliseconds, and is added to eth_getBlockByNumber. timestamp stays in seconds. The field is omitted when the block body or its BaseTime metadata is pruned or otherwise unavailable. Source: docs/upgrades/denim/200ms-blocks.mdx, RPC section ("Seconds compatibility", "Block and header timestamps").
• eth_getBlockReceipts exposes optional blockTimestampMs on nested mined logs, not at the receipt's top level. The field is omitted when the originating block's BaseTime metadata is unavailable. Source: docs/upgrades/denim/200ms-blocks.mdx, "Log and receipt timestamps".
• The behavior is not available on production endpoints. Source: the <Note> at the top of the RPC section in docs/upgrades/denim/200ms-blocks.mdx.

On purpose, no activation date is stated. The Denim overview and the migration guide currently use different schedule wording.

Owner confirmation needed before merge: the Denim 200ms Native Blocks / BaseTime protocol team should confirm that the field names, optionality, and omission conditions are still current, and that saying "not available on production endpoints" is still accurate.

This replaces the part of #2092 for this gap. #2092 did not change these two API reference files.

How has it been tested?

• node scripts/lint-mdx.js --files-from=<changed files>: 0 errors. The 4 codeblock/highlight warnings are on existing code blocks and were already there.
• node scripts/validate-docs-structure.js: 2 failures that already exist on master (the /upgrades/denim/eip-8130 redirect chain in docs.json). This PR does not change them.
• The new internal link /upgrades/denim/200ms-blocks#rpc points to a page in docs/docs.json that has a ## RPC heading.

Screenshots

N/A (text-only change)

Generated with Toshi

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated
base	🟢 Ready	View Preview	Oct 15, 2026, 3:02 PM

💡 Tip: Enable Automations to automatically generate PRs for you.

[cb-heimdall]

🟡 Heimdall Review Status

Requirement	Status	More Info
Reviews	🟡 0/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[linear]

DEVREL-859