From c2c6d25556a1674d0e4114510fe09285832a4f55 Mon Sep 17 00:00:00 2001 From: Francis Li Date: Wed, 5 Aug 2026 16:54:20 -0700 Subject: [PATCH 1/6] Add Denim: 200ms section --- docs/AGENTS.md | 3 +- .../upgrades/denim/200ms-native-blocks.mdx | 165 ++++++++++++++++++ docs/docs.json | 6 + docs/llms-full.txt | 7 +- docs/llms.txt | 9 +- 5 files changed, 184 insertions(+), 6 deletions(-) create mode 100644 docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx diff --git a/docs/AGENTS.md b/docs/AGENTS.md index e4c635ced..d09c2de0b 100644 --- a/docs/AGENTS.md +++ b/docs/AGENTS.md @@ -49,7 +49,7 @@ npx skills add base/base-skills |apps:index |apps/builder-codes:agent-developers,app-developers,builder-codes,wallet-developers |apps/growth:rewards -|apps/guides:accept-b20-payments,migrate-to-standard-web-app +|apps/guides:accept-b20-payments,migrate-to-standard-web-app,verify-onchain |apps/quickstart:build-app,deploy-on-base |apps/resources:design-resources,templates |apps/technical-guides:base-notifications @@ -97,6 +97,7 @@ npx skills add base/base-skills |base-chain/specs/upgrades/canyon:overview |base-chain/specs/upgrades/cobalt:eip-8130 |base-chain/specs/upgrades/delta:overview,span-batches +|base-chain/specs/upgrades/denim:200ms-native-blocks |base-chain/specs/upgrades/ecotone:derivation,l1-attributes,overview |base-chain/specs/upgrades/fjord:derivation,exec-engine,overview,predeploys |base-chain/specs/upgrades/granite:derivation,exec-engine,overview diff --git a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx new file mode 100644 index 000000000..69eb226b2 --- /dev/null +++ b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx @@ -0,0 +1,165 @@ +--- +title: "200ms native blocks" +description: "Specification for Denim's canonical 200ms blocks, including BaseTime, derivation, validation, and RPC behavior." +--- + + +Denim is a tentative draft published to elicit feedback. The design is mostly finalized, but this is not a production specification and may change. Denim is not active on Base Sepolia or Base Mainnet; activation times and required client versions remain undecided. + + +## Summary + +Denim changes Base block production from one canonical block every two seconds to five complete canonical blocks per second. Each 200ms block has its own block number, hash, state root, receipts, forkchoice updates, and unsafe, safe, and finalized lifecycle. + +Denim replaces [Flashblocks](/base-chain/flashblocks/faq), which publish incremental pending-state updates for a single block. At activation, Base stops producing Flashblocks and instead produces a canonical block every 200ms. Applications using Flashblocks must migrate to canonical block and RPC streams. + +Denim keeps the Ethereum block header and its seconds-based `timestamp` unchanged. A BaseTime metadata deposit supplies the sub-second component. Together, these values identify a canonical block's full millisecond timestamp. + +## Tentative activation + +| Network | Activation timestamp | Required client versions | +| --- | --- | --- | +| `sepolia` | `TBD` | `TBD` | +| `mainnet` | `TBD` | `TBD` | + +No Denim activation has been scheduled. A later node upgrade guide will provide release and rollout instructions. + +## Execution + +### Full block timestamp + +Denim leaves `block.header.timestamp` as Unix time in whole seconds. For an activated block `b`, its full timestamp is: + +$$ +T_{ms}(b) = 1000 \times b.header.timestamp + b.tx[1].timestamp\_millis\_part +$$ + +The BaseTime deposit at `tx[1]` carries `timestamp_millis_part`. The only valid values are `0`, `200`, `400`, `600`, and `800`. Consecutive activated blocks satisfy: + +$$ +T_{ms}(child) = T_{ms}(parent) + 200 +$$ + +Blocks cannot skip slots. The seconds header and millisecond part must come from the same scheduled timestamp; wall-clock time controls when the sequencer starts a build, not the timestamp assigned to that block. EVM `block.timestamp` remains the whole-second header value. + +### BaseTime metadata deposit + +After activation, every block contains the canonical BaseTime update at `tx[1]`, immediately after the L1 information deposit at `tx[0]` and before user transactions. The deposit is bound to the current block number by source-hash domain `3`. + +| Field | Value | +| --- | --- | +| Transaction type | Deposit (`0x7e`) | +| Source hash | Domain `3`, bound to the current block number | +| From | `0xDeaDDEaDDeAdDeAdDEAdDEaddeAddEAdDEAd0001` | +| To | `0x4200000000000000000000000000000000000030` | +| Mint | `0` | +| Value | `0` | +| Gas limit | `1,000,000` | +| System transaction | `false` | +| Calldata | `setTimestampMillisPart(uint16)` with selector `0x86bdf394` and a 32-byte ABI-encoded millisecond part | + +Before activation, blocks must not contain this metadata transaction or the Engine millisecond field. After activation, implementations validate the transaction's position, source hash, sender, recipient, mint, value, gas limit, system flag, calldata shape, and lattice value. + +### BaseTime predeploy + +The initial design exposes the current block's millisecond part to contracts through a predeploy. + +| Property | Value | +| --- | --- | +| Proxy | `0x4200000000000000000000000000000000000030` | +| Implementation | `0xc0D3C0d3C0d3C0D3c0d3C0d3c0D3C0d3c0d30030` | +| Storage | `uint16` millisecond part in slot `0` | +| Setter | `setTimestampMillisPart(uint16)` | +| Millisecond-part getter | `timestampMillisPart()` | +| Full-timestamp getter | `timestampMs()` | + +Under the intended single-update behavior, the BaseTime deposit executes before user transactions, so successful user transactions in the same block can read the value written by `tx[1]`. Fresh chains install the linked predeploy in genesis. Existing chains retain a dormant reserved proxy before activation. + +Before activation, the transition does nothing. At activation, the execution transition checks the reserved proxy and canonical proxy admin, installs the implementation, and links the proxy before transactions execute. If governance has already changed the implementation link, the transition preserves that link rather than overwriting the governance upgrade. The current artifacts are pinned to `base/contracts` commit `4848ec70`; the normative Denim release remains undecided. + +### Engine payload compatibility + +Base payload attributes add the optional Engine field `timestampMillisPart`. Their forced transaction list contains the BaseTime deposit at `tx[1]`, and Engine validation requires the attribute to match its calldata. The resulting execution payload adds no separate millisecond field; its body commits the value through `tx[1]`. + +The payload ID includes `timestampMillisPart`, so builds that differ only in the millisecond part receive different IDs. When the field is absent, legacy payload-ID calculation remains unchanged. The field must be absent before activation and present with a valid lattice value after activation. + +All existing Engine timestamp fields remain seconds-based. + +### Validation + +Forkchoice-updated processing performs checks that do not require state access: activation-appropriate presence, valid range and lattice, and nondecreasing whole-second ordering. Same-second and next-second children can therefore pass this preliminary check; a child with an earlier header second cannot. + +The implemented post-execution path uses the actual parent header, parent BaseTime state, and child `tx[1]` to check parent-to-child progression. It does not yet explicitly compare the child BaseTime state with `tx[1]`. Coverage across historical, range, noncanonical-parent, and auxiliary import paths remains incomplete, so this specification does not define those paths as fully enforced. The intended behavior is to fail validation when required block, parent, or state data is missing rather than estimate the timestamp. + +## Derivation + +### Scheduled timestamps + +After activation, the derivation pipeline computes each block's timestamp from the Denim activation schedule and absolute L2 block number. It does not read the millisecond part from batch data or derive it from the local wall clock. The sequence is: + +`p (.000)` → `child (.200)` → `child (.400)` → `child (.600)` → `child (.800)` → `child (.000 in the next second)` + +The pipeline splits the scheduled timestamp into the seconds-based header timestamp and the BaseTime millisecond part, then reconstructs the BaseTime deposit at `tx[1]`. + +### Block lifecycle + +The sequencer builds and executes a complete block for every selected 200ms slot. Each block receives its own hash, state root, receipts, Engine payload, forkchoice update, and unsafe-to-safe-to-finalized lifecycle. + +The block begins with the L1 information deposit at `tx[0]` and the BaseTime metadata deposit at `tx[1]`. User transactions and other applicable transactions follow. The design intends the payload attribute, `tx[1]`, and the value written to the BaseTime predeploy to represent the same planned millisecond part. + +## RPC + +### Seconds compatibility + +Denim keeps the existing `timestamp` JSON-RPC field in Unix seconds. Engine timestamps, transaction-validity timestamps, `eth_call` timestamps, and EVM `block.timestamp` also remain seconds-based. RPC responses do not expose the internal `timestampMillisPart` field. + +After Denim activates, use canonical block responses and subscriptions such as `eth_subscribe("newHeads")` for sub-second updates. Flashblocks streams will stop. + +### Block and header timestamps + +The following responses add optional `timestampMs`, encoded as a JSON-RPC quantity containing the full Unix timestamp in milliseconds: + +- `eth_getBlockByHash` +- `eth_getBlockByNumber` +- `eth_getHeaderByHash` +- `eth_getHeaderByNumber` +- `eth_subscribe("newHeads")` + +For example, a block at 42.200 seconds has: + +| Field | Value | +| --- | --- | +| `timestamp` | `0x2a` | +| `timestampMs` | `0xa4d8` | + +Clients derive `timestampMs` from authenticated BaseTime metadata. They do not estimate it from the seconds field. If a historical block body or its BaseTime metadata has been pruned or is otherwise unavailable, the response omits `timestampMs`. + +### Transaction timestamps + +Mined transaction objects add optional `blockTimestampMs` for these methods: + +- `eth_getTransactionByHash` +- `eth_getTransactionByBlockHashAndIndex` +- `eth_getTransactionByBlockNumberAndIndex` + +Full transaction objects nested in block responses follow the same mined-transaction behavior. Pending transactions omit `blockTimestampMs` because they do not yet belong to a canonical block. + +### Log and receipt timestamps + +Mined log objects add optional `blockTimestampMs` when returned by: + +- `eth_getLogs` +- `eth_getFilterChanges` +- `eth_getFilterLogs` +- `eth_getTransactionReceipt` +- `eth_getBlockReceipts` +- `eth_subscribe("logs")` +- `eth_subscribe("transactionReceipts")` + +Receipts expose the field on their nested logs, not at the receipt's top level. A removed log retains its original block timestamp along with its original block provenance. If the originating block's authenticated BaseTime metadata is unavailable, the log omits the field rather than estimating it. + +As with block responses, pruned or unprovenanced transaction and log data omits `blockTimestampMs`. The fields are optional so pre-Denim history and clients without the required body data remain representable. + +### Tooling + +Foundry's `AnyRpcBlock` and `OtherFields` paths can preserve an unknown block-level `timestampMs`, while EVM execution continues to use seconds. Plain Alloy `AnyRpcHeader` drops unknown fields; consumers that need Denim timestamps can use `WithOtherFields` or a typed Base response. Locally mined Anvil blocks are not expected to produce BaseTime metadata in the initial rollout. diff --git a/docs/docs.json b/docs/docs.json index f6ddd67f2..7ab4bf30c 100644 --- a/docs/docs.json +++ b/docs/docs.json @@ -259,6 +259,12 @@ { "group": "Upgrades", "pages": [ + { + "group": "Denim", + "pages": [ + "base-chain/specs/upgrades/denim/200ms-native-blocks" + ] + }, { "group": "Cobalt", "pages": [ diff --git a/docs/llms-full.txt b/docs/llms-full.txt index a1c8c522f..7166735c6 100644 --- a/docs/llms-full.txt +++ b/docs/llms-full.txt @@ -102,7 +102,7 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Static Docs Files](https://docs.base.org/get-started/docs-llms): Use llms.txt and llms-full.txt to give AI assistants access to Base documentation. - [MCP Server](https://docs.base.org/get-started/docs-mcp): Connect your AI coding assistant to Base documentation using Model Context Protocol for real-time access. - [Get Funded](https://docs.base.org/get-started/get-funded): The Base ecosystem offers multiple funding pathways designed specifically for builders at every stage—from weekend experiments to full-scale ventures. -- [Launch a B20 Token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base by calling the B20 Factory precompile. +- [Launch a B20 token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base with one call to the B20 Factory precompile, with roles, supply caps, and compliance controls built in. - [Launch a Token](https://docs.base.org/get-started/launch-token) - [Learning Resources](https://docs.base.org/get-started/learning-resources): Find educational content for learning Solidity, Ethereum, and blockchain development - [Developer's Guide to Effective AI Prompting](https://docs.base.org/get-started/prompt-library): Learn practical AI prompting techniques to enhance your coding workflow and get better results from AI coding assistants. @@ -206,9 +206,11 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Execution Engine](https://docs.base.org/base-chain/specs/upgrades/azul/exec-engine): Execution engine changes in the Azul hardfork, including the EIP-7825 transaction gas limit cap and secp256r1 precompile cost updates. - [Node Upgrade Guide](https://docs.base.org/base-chain/specs/upgrades/azul/node-upgrade): Migrate your Base node to base-reth-node and base-consensus for Azul. - [Proof System](https://docs.base.org/base-chain/specs/upgrades/azul/proofs): Specification of the Azul multi-proof system, replacing the single output proposer with an AggregateVerifier contract for L2 checkpoint security. -- [B20 Native Token Standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): B20 is Base's native token standard - designed for stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. +- [B20 native token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): Learn how B20, Base's native token standard, serves stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. +- [B20 playground](https://docs.base.org/base-chain/specs/upgrades/beryl/b20-playground): Try B20's issuer flows in your browser: freeze-and-seize, payment memos, gasless approvals, and onchain corporate actions on Base. - [Native Account Abstraction](https://docs.base.org/base-chain/specs/upgrades/cobalt/eip-8130): Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays. - [Span-batches](https://docs.base.org/base-chain/specs/upgrades/delta/span-batches): Specification of span batches introduced in Delta, a new batch format that compresses sequences of L2 blocks for more efficient L1 data posting. +- [200ms native blocks](https://docs.base.org/base-chain/specs/upgrades/denim/200ms-native-blocks): Specification for Denim's canonical 200ms blocks, including BaseTime, derivation, validation, and RPC behavior. - [Derivation](https://docs.base.org/base-chain/specs/upgrades/ecotone/derivation): Derivation changes in the Ecotone upgrade, extending the retrieval stage to support EIP-4844 blobs as an additional data availability source. - [Ecotone L1 Attributes](https://docs.base.org/base-chain/specs/upgrades/ecotone/l1-attributes): L1 attributes transaction changes in the Ecotone upgrade, updating calldata format to support the new blob-based fee calculation model. - [Fjord L2 Chain Derivation Changes](https://docs.base.org/base-chain/specs/upgrades/fjord/derivation): Derivation changes in the Fjord upgrade, updating protocol parameters for max sequencer drift, channel bank size, and adding brotli compression support. @@ -369,6 +371,7 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Rewards](https://docs.base.org/apps/growth/rewards): Earn financial incentives for building high-quality Apps that drive user engagement and onchain transactions - [Accept B20 payments](https://docs.base.org/apps/guides/accept-b20-payments): Accept B20 token payments in your app and match each transaction to an order with onchain memos. - [Migrate to a Standard Web App](https://docs.base.org/apps/guides/migrate-to-standard-web-app): Migrate your Farcaster mini-app to work in the Base App. Covers replacing deprecated SDK methods, and registering on Base.dev. +- [Verify Users Onchain](https://docs.base.org/apps/guides/verify-onchain): Enforce Sybil resistance and policy gating inside any Base contract. Base Verify signs a short-lived verification your contract checks in the same transaction as a claim, deposit, or vote, so one real identity counts once and only wallets that meet your bar can participate. - [Build an app on Base](https://docs.base.org/apps/quickstart/build-app): A step-by-step guide to building a Next.js tally app on Base using wagmi and viem, with wallet connection, contract reads and writes, and batch transaction support. - [Deploy on Base](https://docs.base.org/apps/quickstart/deploy-on-base): Deploy a smart contract to Base Sepolia with Foundry. - [Add notifications](https://docs.base.org/apps/technical-guides/base-notifications): Send in-app notifications to your app's users through the Base Dashboard REST API. diff --git a/docs/llms.txt b/docs/llms.txt index 679a7cfb5..429361441 100644 --- a/docs/llms.txt +++ b/docs/llms.txt @@ -14,7 +14,7 @@ - [Static Docs Files](https://docs.base.org/get-started/docs-llms): Use llms.txt and llms-full.txt to give AI assistants access to Base documentation. - [MCP Server](https://docs.base.org/get-started/docs-mcp): Connect your AI coding assistant to Base documentation using Model Context Protocol for real-time access. - [Get Funded](https://docs.base.org/get-started/get-funded): The Base ecosystem offers multiple funding pathways designed specifically for builders at every stage—from weekend experiments to full-scale ventures. -- [Launch a B20 Token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base by calling the B20 Factory precompile. +- [Launch a B20 token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base with one call to the B20 Factory precompile, with roles, supply caps, and compliance controls built in. - [Launch a Token](https://docs.base.org/get-started/launch-token) - [Learning Resources](https://docs.base.org/get-started/learning-resources): Find educational content for learning Solidity, Ethereum, and blockchain development - [Developer's Guide to Effective AI Prompting](https://docs.base.org/get-started/prompt-library): Learn practical AI prompting techniques to enhance your coding workflow and get better results from AI coding assistants. @@ -84,7 +84,7 @@ - [Network Fees](https://docs.base.org/base-chain/network-information/network-fees): Documentation about network fees on Base. This page covers details of the two-component cost system involving L2 execution fees and L1 security fees, and offers insights on fee variations and cost-saving strategies. - [Throughput and Limits](https://docs.base.org/base-chain/network-information/throughput-and-limits): Gas limits and throughput-related network parameters on Base. - [Transaction Finality](https://docs.base.org/base-chain/network-information/transaction-finality): Detailed information about transaction finality on Base. -- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): This page outlines how Base transactions are ordered. +- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): Transactions are ordered based priority fee and arrival time, which determines which Flashblock they are included in. - [Troubleshooting Transactions](https://docs.base.org/base-chain/network-information/troubleshooting-transactions): Guide to diagnosing and resolving transaction issues on Base. - [Node Providers](https://docs.base.org/base-chain/node-operators/node-providers): Documentation for Node Providers for the Base network. Including details on their services, supported networks, and pricing plans. - [Node Performance](https://docs.base.org/base-chain/node-operators/performance-tuning): Hardware specifications, storage requirements, client recommendations, and configuration settings for running a performant Base node. @@ -118,9 +118,11 @@ - [Execution Engine](https://docs.base.org/base-chain/specs/upgrades/azul/exec-engine): Execution engine changes in the Azul hardfork, including the EIP-7825 transaction gas limit cap and secp256r1 precompile cost updates. - [Node Upgrade Guide](https://docs.base.org/base-chain/specs/upgrades/azul/node-upgrade): Migrate your Base node to base-reth-node and base-consensus for Azul. - [Proof System](https://docs.base.org/base-chain/specs/upgrades/azul/proofs): Specification of the Azul multi-proof system, replacing the single output proposer with an AggregateVerifier contract for L2 checkpoint security. -- [B20 Native Token Standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): B20 is Base's native token standard - designed for stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. +- [B20 native token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): Learn how B20, Base's native token standard, serves stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. +- [B20 playground](https://docs.base.org/base-chain/specs/upgrades/beryl/b20-playground): Try B20's issuer flows in your browser: freeze-and-seize, payment memos, gasless approvals, and onchain corporate actions on Base. - [Native Account Abstraction](https://docs.base.org/base-chain/specs/upgrades/cobalt/eip-8130): Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays. - [Span-batches](https://docs.base.org/base-chain/specs/upgrades/delta/span-batches): Specification of span batches introduced in Delta, a new batch format that compresses sequences of L2 blocks for more efficient L1 data posting. +- [200ms native blocks](https://docs.base.org/base-chain/specs/upgrades/denim/200ms-native-blocks): Specification for Denim's canonical 200ms blocks, including BaseTime, derivation, validation, and RPC behavior. - [Derivation](https://docs.base.org/base-chain/specs/upgrades/ecotone/derivation): Derivation changes in the Ecotone upgrade, extending the retrieval stage to support EIP-4844 blobs as an additional data availability source. - [Ecotone L1 Attributes](https://docs.base.org/base-chain/specs/upgrades/ecotone/l1-attributes): L1 attributes transaction changes in the Ecotone upgrade, updating calldata format to support the new blob-based fee calculation model. - [Fjord L2 Chain Derivation Changes](https://docs.base.org/base-chain/specs/upgrades/fjord/derivation): Derivation changes in the Fjord upgrade, updating protocol parameters for max sequencer drift, channel bank size, and adding brotli compression support. @@ -281,6 +283,7 @@ - [Rewards](https://docs.base.org/apps/growth/rewards): Earn financial incentives for building high-quality Apps that drive user engagement and onchain transactions - [Accept B20 payments](https://docs.base.org/apps/guides/accept-b20-payments): Accept B20 token payments in your app and match each transaction to an order with onchain memos. - [Migrate to a Standard Web App](https://docs.base.org/apps/guides/migrate-to-standard-web-app): Migrate your Farcaster mini-app to work in the Base App. Covers replacing deprecated SDK methods, and registering on Base.dev. +- [Verify Users Onchain](https://docs.base.org/apps/guides/verify-onchain): Enforce Sybil resistance and policy gating inside any Base contract. Base Verify signs a short-lived verification your contract checks in the same transaction as a claim, deposit, or vote, so one real identity counts once and only wallets that meet your bar can participate. - [Build an app on Base](https://docs.base.org/apps/quickstart/build-app): A step-by-step guide to building a Next.js tally app on Base using wagmi and viem, with wallet connection, contract reads and writes, and batch transaction support. - [Deploy on Base](https://docs.base.org/apps/quickstart/deploy-on-base): Deploy a smart contract to Base Sepolia with Foundry. - [Add notifications](https://docs.base.org/apps/technical-guides/base-notifications): Send in-app notifications to your app's users through the Base Dashboard REST API. From bd03ed3b76773a830666dfb72e951a3c6a178e51 Mon Sep 17 00:00:00 2001 From: Francis Li Date: Wed, 5 Aug 2026 17:01:57 -0700 Subject: [PATCH 2/6] docs: refine Denim native blocks spec Amp-Thread-ID: https://ampcode.com/threads/T-019fd2ba-ede5-767c-94c7-c47dc413f7be Co-authored-by: Amp --- docs/AGENTS.md | 2 +- .../upgrades/denim/200ms-native-blocks.mdx | 22 +++++++++++-------- docs/llms-full.txt | 6 ++--- docs/llms.txt | 8 +++---- 4 files changed, 19 insertions(+), 19 deletions(-) diff --git a/docs/AGENTS.md b/docs/AGENTS.md index d09c2de0b..97a90190a 100644 --- a/docs/AGENTS.md +++ b/docs/AGENTS.md @@ -49,7 +49,7 @@ npx skills add base/base-skills |apps:index |apps/builder-codes:agent-developers,app-developers,builder-codes,wallet-developers |apps/growth:rewards -|apps/guides:accept-b20-payments,migrate-to-standard-web-app,verify-onchain +|apps/guides:accept-b20-payments,migrate-to-standard-web-app |apps/quickstart:build-app,deploy-on-base |apps/resources:design-resources,templates |apps/technical-guides:base-notifications diff --git a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx index 69eb226b2..91c664d7d 100644 --- a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx +++ b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx @@ -11,7 +11,7 @@ Denim is a tentative draft published to elicit feedback. The design is mostly fi Denim changes Base block production from one canonical block every two seconds to five complete canonical blocks per second. Each 200ms block has its own block number, hash, state root, receipts, forkchoice updates, and unsafe, safe, and finalized lifecycle. -Denim replaces [Flashblocks](/base-chain/flashblocks/faq), which publish incremental pending-state updates for a single block. At activation, Base stops producing Flashblocks and instead produces a canonical block every 200ms. Applications using Flashblocks must migrate to canonical block and RPC streams. +Denim replaces [Flashblocks](/base-chain/flashblocks/faq), which publish incremental pending-state updates for a single block. As part of the Denim rollout, Base will stop producing Flashblocks and instead produce a canonical block every 200ms. Applications using Flashblocks must migrate to canonical block and RPC streams. Denim keeps the Ethereum block header and its seconds-based `timestamp` unchanged. A BaseTime metadata deposit supplies the sub-second component. Together, these values identify a canonical block's full millisecond timestamp. @@ -109,15 +109,19 @@ The block begins with the L1 information deposit at `tx[0]` and the BaseTime met ## RPC + +The RPC behavior below is planned for Denim and is not available on production endpoints. + + ### Seconds compatibility Denim keeps the existing `timestamp` JSON-RPC field in Unix seconds. Engine timestamps, transaction-validity timestamps, `eth_call` timestamps, and EVM `block.timestamp` also remain seconds-based. RPC responses do not expose the internal `timestampMillisPart` field. -After Denim activates, use canonical block responses and subscriptions such as `eth_subscribe("newHeads")` for sub-second updates. Flashblocks streams will stop. +After the Denim rollout, use canonical block responses and subscriptions such as `eth_subscribe("newHeads")` for sub-second updates. Flashblocks streams will stop. ### Block and header timestamps -The following responses add optional `timestampMs`, encoded as a JSON-RPC quantity containing the full Unix timestamp in milliseconds: +The following responses will add optional `timestampMs`, encoded as a JSON-RPC quantity containing the full Unix timestamp in milliseconds: - `eth_getBlockByHash` - `eth_getBlockByNumber` @@ -132,21 +136,21 @@ For example, a block at 42.200 seconds has: | `timestamp` | `0x2a` | | `timestampMs` | `0xa4d8` | -Clients derive `timestampMs` from authenticated BaseTime metadata. They do not estimate it from the seconds field. If a historical block body or its BaseTime metadata has been pruned or is otherwise unavailable, the response omits `timestampMs`. +Clients will derive `timestampMs` from authenticated BaseTime metadata rather than estimate it from the seconds field. If a historical block body or its BaseTime metadata has been pruned or is otherwise unavailable, the response will omit `timestampMs`. ### Transaction timestamps -Mined transaction objects add optional `blockTimestampMs` for these methods: +Mined transaction objects will add optional `blockTimestampMs` for these methods: - `eth_getTransactionByHash` - `eth_getTransactionByBlockHashAndIndex` - `eth_getTransactionByBlockNumberAndIndex` -Full transaction objects nested in block responses follow the same mined-transaction behavior. Pending transactions omit `blockTimestampMs` because they do not yet belong to a canonical block. +Full transaction objects nested in block responses will follow the same mined-transaction behavior. Pending transactions will omit `blockTimestampMs` because they do not yet belong to a canonical block. ### Log and receipt timestamps -Mined log objects add optional `blockTimestampMs` when returned by: +Mined log objects will add optional `blockTimestampMs` when returned by: - `eth_getLogs` - `eth_getFilterChanges` @@ -156,9 +160,9 @@ Mined log objects add optional `blockTimestampMs` when returned by: - `eth_subscribe("logs")` - `eth_subscribe("transactionReceipts")` -Receipts expose the field on their nested logs, not at the receipt's top level. A removed log retains its original block timestamp along with its original block provenance. If the originating block's authenticated BaseTime metadata is unavailable, the log omits the field rather than estimating it. +Receipts will expose the field on their nested logs, not at the receipt's top level. A removed log will retain its original block timestamp along with its original block provenance. If the originating block's authenticated BaseTime metadata is unavailable, the log will omit the field rather than estimate it. -As with block responses, pruned or unprovenanced transaction and log data omits `blockTimestampMs`. The fields are optional so pre-Denim history and clients without the required body data remain representable. +As with block responses, pruned or unprovenanced transaction and log data will omit `blockTimestampMs`. The fields are optional so pre-Denim history and clients without the required body data remain representable. ### Tooling diff --git a/docs/llms-full.txt b/docs/llms-full.txt index 7166735c6..b6e08c32a 100644 --- a/docs/llms-full.txt +++ b/docs/llms-full.txt @@ -102,7 +102,7 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Static Docs Files](https://docs.base.org/get-started/docs-llms): Use llms.txt and llms-full.txt to give AI assistants access to Base documentation. - [MCP Server](https://docs.base.org/get-started/docs-mcp): Connect your AI coding assistant to Base documentation using Model Context Protocol for real-time access. - [Get Funded](https://docs.base.org/get-started/get-funded): The Base ecosystem offers multiple funding pathways designed specifically for builders at every stage—from weekend experiments to full-scale ventures. -- [Launch a B20 token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base with one call to the B20 Factory precompile, with roles, supply caps, and compliance controls built in. +- [Launch a B20 Token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base by calling the B20 Factory precompile. - [Launch a Token](https://docs.base.org/get-started/launch-token) - [Learning Resources](https://docs.base.org/get-started/learning-resources): Find educational content for learning Solidity, Ethereum, and blockchain development - [Developer's Guide to Effective AI Prompting](https://docs.base.org/get-started/prompt-library): Learn practical AI prompting techniques to enhance your coding workflow and get better results from AI coding assistants. @@ -206,8 +206,7 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Execution Engine](https://docs.base.org/base-chain/specs/upgrades/azul/exec-engine): Execution engine changes in the Azul hardfork, including the EIP-7825 transaction gas limit cap and secp256r1 precompile cost updates. - [Node Upgrade Guide](https://docs.base.org/base-chain/specs/upgrades/azul/node-upgrade): Migrate your Base node to base-reth-node and base-consensus for Azul. - [Proof System](https://docs.base.org/base-chain/specs/upgrades/azul/proofs): Specification of the Azul multi-proof system, replacing the single output proposer with an AggregateVerifier contract for L2 checkpoint security. -- [B20 native token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): Learn how B20, Base's native token standard, serves stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. -- [B20 playground](https://docs.base.org/base-chain/specs/upgrades/beryl/b20-playground): Try B20's issuer flows in your browser: freeze-and-seize, payment memos, gasless approvals, and onchain corporate actions on Base. +- [B20 Native Token Standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): B20 is Base's native token standard - designed for stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. - [Native Account Abstraction](https://docs.base.org/base-chain/specs/upgrades/cobalt/eip-8130): Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays. - [Span-batches](https://docs.base.org/base-chain/specs/upgrades/delta/span-batches): Specification of span batches introduced in Delta, a new batch format that compresses sequences of L2 blocks for more efficient L1 data posting. - [200ms native blocks](https://docs.base.org/base-chain/specs/upgrades/denim/200ms-native-blocks): Specification for Denim's canonical 200ms blocks, including BaseTime, derivation, validation, and RPC behavior. @@ -371,7 +370,6 @@ const client = createPublicClient({ chain: base, transport: http() }) - [Rewards](https://docs.base.org/apps/growth/rewards): Earn financial incentives for building high-quality Apps that drive user engagement and onchain transactions - [Accept B20 payments](https://docs.base.org/apps/guides/accept-b20-payments): Accept B20 token payments in your app and match each transaction to an order with onchain memos. - [Migrate to a Standard Web App](https://docs.base.org/apps/guides/migrate-to-standard-web-app): Migrate your Farcaster mini-app to work in the Base App. Covers replacing deprecated SDK methods, and registering on Base.dev. -- [Verify Users Onchain](https://docs.base.org/apps/guides/verify-onchain): Enforce Sybil resistance and policy gating inside any Base contract. Base Verify signs a short-lived verification your contract checks in the same transaction as a claim, deposit, or vote, so one real identity counts once and only wallets that meet your bar can participate. - [Build an app on Base](https://docs.base.org/apps/quickstart/build-app): A step-by-step guide to building a Next.js tally app on Base using wagmi and viem, with wallet connection, contract reads and writes, and batch transaction support. - [Deploy on Base](https://docs.base.org/apps/quickstart/deploy-on-base): Deploy a smart contract to Base Sepolia with Foundry. - [Add notifications](https://docs.base.org/apps/technical-guides/base-notifications): Send in-app notifications to your app's users through the Base Dashboard REST API. diff --git a/docs/llms.txt b/docs/llms.txt index 429361441..cd3f8feec 100644 --- a/docs/llms.txt +++ b/docs/llms.txt @@ -14,7 +14,7 @@ - [Static Docs Files](https://docs.base.org/get-started/docs-llms): Use llms.txt and llms-full.txt to give AI assistants access to Base documentation. - [MCP Server](https://docs.base.org/get-started/docs-mcp): Connect your AI coding assistant to Base documentation using Model Context Protocol for real-time access. - [Get Funded](https://docs.base.org/get-started/get-funded): The Base ecosystem offers multiple funding pathways designed specifically for builders at every stage—from weekend experiments to full-scale ventures. -- [Launch a B20 token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base with one call to the B20 Factory precompile, with roles, supply caps, and compliance controls built in. +- [Launch a B20 Token](https://docs.base.org/get-started/launch-b20-token): Launch a B20 token on Base by calling the B20 Factory precompile. - [Launch a Token](https://docs.base.org/get-started/launch-token) - [Learning Resources](https://docs.base.org/get-started/learning-resources): Find educational content for learning Solidity, Ethereum, and blockchain development - [Developer's Guide to Effective AI Prompting](https://docs.base.org/get-started/prompt-library): Learn practical AI prompting techniques to enhance your coding workflow and get better results from AI coding assistants. @@ -84,7 +84,7 @@ - [Network Fees](https://docs.base.org/base-chain/network-information/network-fees): Documentation about network fees on Base. This page covers details of the two-component cost system involving L2 execution fees and L1 security fees, and offers insights on fee variations and cost-saving strategies. - [Throughput and Limits](https://docs.base.org/base-chain/network-information/throughput-and-limits): Gas limits and throughput-related network parameters on Base. - [Transaction Finality](https://docs.base.org/base-chain/network-information/transaction-finality): Detailed information about transaction finality on Base. -- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): Transactions are ordered based priority fee and arrival time, which determines which Flashblock they are included in. +- [Transaction Ordering](https://docs.base.org/base-chain/network-information/transaction-ordering): This page outlines how Base transactions are ordered. - [Troubleshooting Transactions](https://docs.base.org/base-chain/network-information/troubleshooting-transactions): Guide to diagnosing and resolving transaction issues on Base. - [Node Providers](https://docs.base.org/base-chain/node-operators/node-providers): Documentation for Node Providers for the Base network. Including details on their services, supported networks, and pricing plans. - [Node Performance](https://docs.base.org/base-chain/node-operators/performance-tuning): Hardware specifications, storage requirements, client recommendations, and configuration settings for running a performant Base node. @@ -118,8 +118,7 @@ - [Execution Engine](https://docs.base.org/base-chain/specs/upgrades/azul/exec-engine): Execution engine changes in the Azul hardfork, including the EIP-7825 transaction gas limit cap and secp256r1 precompile cost updates. - [Node Upgrade Guide](https://docs.base.org/base-chain/specs/upgrades/azul/node-upgrade): Migrate your Base node to base-reth-node and base-consensus for Azul. - [Proof System](https://docs.base.org/base-chain/specs/upgrades/azul/proofs): Specification of the Azul multi-proof system, replacing the single output proposer with an AggregateVerifier contract for L2 checkpoint security. -- [B20 native token standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): Learn how B20, Base's native token standard, serves stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. -- [B20 playground](https://docs.base.org/base-chain/specs/upgrades/beryl/b20-playground): Try B20's issuer flows in your browser: freeze-and-seize, payment memos, gasless approvals, and onchain corporate actions on Base. +- [B20 Native Token Standard](https://docs.base.org/base-chain/specs/upgrades/beryl/b20): B20 is Base's native token standard - designed for stablecoin issuers, real-world asset (RWA) and equity issuers, and long-tail token creators. - [Native Account Abstraction](https://docs.base.org/base-chain/specs/upgrades/cobalt/eip-8130): Build with native account abstraction on Base. EIP-8130 smart accounts send ordinary transactions, with no bundlers or relays. - [Span-batches](https://docs.base.org/base-chain/specs/upgrades/delta/span-batches): Specification of span batches introduced in Delta, a new batch format that compresses sequences of L2 blocks for more efficient L1 data posting. - [200ms native blocks](https://docs.base.org/base-chain/specs/upgrades/denim/200ms-native-blocks): Specification for Denim's canonical 200ms blocks, including BaseTime, derivation, validation, and RPC behavior. @@ -283,7 +282,6 @@ - [Rewards](https://docs.base.org/apps/growth/rewards): Earn financial incentives for building high-quality Apps that drive user engagement and onchain transactions - [Accept B20 payments](https://docs.base.org/apps/guides/accept-b20-payments): Accept B20 token payments in your app and match each transaction to an order with onchain memos. - [Migrate to a Standard Web App](https://docs.base.org/apps/guides/migrate-to-standard-web-app): Migrate your Farcaster mini-app to work in the Base App. Covers replacing deprecated SDK methods, and registering on Base.dev. -- [Verify Users Onchain](https://docs.base.org/apps/guides/verify-onchain): Enforce Sybil resistance and policy gating inside any Base contract. Base Verify signs a short-lived verification your contract checks in the same transaction as a claim, deposit, or vote, so one real identity counts once and only wallets that meet your bar can participate. - [Build an app on Base](https://docs.base.org/apps/quickstart/build-app): A step-by-step guide to building a Next.js tally app on Base using wagmi and viem, with wallet connection, contract reads and writes, and batch transaction support. - [Deploy on Base](https://docs.base.org/apps/quickstart/deploy-on-base): Deploy a smart contract to Base Sepolia with Foundry. - [Add notifications](https://docs.base.org/apps/technical-guides/base-notifications): Send in-app notifications to your app's users through the Base Dashboard REST API. From 71dc82a8448e09ce5e3d4a7a097dc671617c7141 Mon Sep 17 00:00:00 2001 From: Francis Li Date: Thu, 6 Aug 2026 08:27:02 -0700 Subject: [PATCH 3/6] docs: clarify BaseTime activation state Amp-Thread-ID: https://ampcode.com/threads/T-019fd2ba-ede5-767c-94c7-c47dc413f7be Co-authored-by: Amp --- .../base-chain/specs/upgrades/denim/200ms-native-blocks.mdx | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx index 91c664d7d..98af1ce31 100644 --- a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx +++ b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx @@ -73,9 +73,11 @@ The initial design exposes the current block's millisecond part to contracts thr | Millisecond-part getter | `timestampMillisPart()` | | Full-timestamp getter | `timestampMs()` | -Under the intended single-update behavior, the BaseTime deposit executes before user transactions, so successful user transactions in the same block can read the value written by `tx[1]`. Fresh chains install the linked predeploy in genesis. Existing chains retain a dormant reserved proxy before activation. +The BaseTime deposit executes before L1 user deposits, and user transactions, so all later transactions can read the updated value. -Before activation, the transition does nothing. At activation, the execution transition checks the reserved proxy and canonical proxy admin, installs the implementation, and links the proxy before transactions execute. If governance has already changed the implementation link, the transition preserves that link rather than overwriting the governance upgrade. The current artifacts are pinned to `base/contracts` commit `4848ec70`; the normative Denim release remains undecided. +Fresh chains install the linked BaseTime predeploy in genesis. On existing chains, the reserved address already contains the canonical proxy runtime and uses the Base ProxyAdmin, but its implementation slot is unset. Calls therefore revert until activation. + +At activation, before transaction execution, the protocol installs the canonical BaseTime implementation and links the existing proxy. It preserves the proxy admin and any implementation already set through governance. ### Engine payload compatibility From c506957d7a751bad8c65cd58d5e84a61a623439e Mon Sep 17 00:00:00 2001 From: Francis Li Date: Thu, 6 Aug 2026 08:35:04 -0700 Subject: [PATCH 4/6] docs: specify BaseTime engine attributes Amp-Thread-ID: https://ampcode.com/threads/T-019fd2ba-ede5-767c-94c7-c47dc413f7be Co-authored-by: Amp --- .../specs/upgrades/denim/200ms-native-blocks.mdx | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx index 98af1ce31..8d78eff9d 100644 --- a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx +++ b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx @@ -79,11 +79,17 @@ Fresh chains install the linked BaseTime predeploy in genesis. On existing chain At activation, before transaction execution, the protocol installs the canonical BaseTime implementation and links the existing proxy. It preserves the proxy admin and any implementation already set through governance. -### Engine payload compatibility +### Engine payload attributes -Base payload attributes add the optional Engine field `timestampMillisPart`. Their forced transaction list contains the BaseTime deposit at `tx[1]`, and Engine validation requires the attribute to match its calldata. The resulting execution payload adds no separate millisecond field; its body commits the value through `tx[1]`. +The Engine API uses `BasePayloadAttributes`, which flattens the standard `PayloadAttributes` fields alongside Base-specific fields. -The payload ID includes `timestampMillisPart`, so builds that differ only in the millisecond part receive different IDs. When the field is absent, legacy payload-ID calculation remains unchanged. The field must be absent before activation and present with a valid lattice value after activation. +For payloads at or after Denim activation, `BasePayloadAttributes.timestampMillisPart` **MUST** be present and equal `0`, `200`, `400`, `600`, or `800`. Before activation, it **MUST NOT** be present. + +`BasePayloadAttributes.transactions[1]` **MUST** contain the BaseTime metadata deposit. The deposit **MUST** be sent by the protocol depositor to the BaseTime predeploy, and its calldata **MUST** contain the canonical encoding of `setTimestampMillisPart(uint16)`. The encoded value **MUST** equal `timestampMillisPart`. + +An execution client **MUST** reject malformed `forkchoiceUpdated` payload attributes with JSON-RPC `Invalid params` (`-32602`). It **MUST** report an execution payload with a missing or invalid BaseTime deposit as invalid during `newPayload` validation. + +The payload ID includes `timestampMillisPart`, so builds that differ only in the millisecond part receive different IDs. When the field is absent, legacy payload-ID calculation remains unchanged. All existing Engine timestamp fields remain seconds-based. From aaec89bdccf1c6bacf192d815a1f44483da851a8 Mon Sep 17 00:00:00 2001 From: Francis Li Date: Thu, 6 Aug 2026 08:59:50 -0700 Subject: [PATCH 5/6] docs: clarify preliminary timestamp validation Amp-Thread-ID: https://ampcode.com/threads/T-019fd2ba-ede5-767c-94c7-c47dc413f7be Co-authored-by: Amp --- docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx index 8d78eff9d..2517aced7 100644 --- a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx +++ b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx @@ -95,7 +95,7 @@ All existing Engine timestamp fields remain seconds-based. ### Validation -Forkchoice-updated processing performs checks that do not require state access: activation-appropriate presence, valid range and lattice, and nondecreasing whole-second ordering. Same-second and next-second children can therefore pass this preliminary check; a child with an earlier header second cannot. +When processing `forkchoiceUpdated`, the execution client performs checks that do not require reading contract state. Before Denim, `timestampMillisPart` must be absent. After Denim, it must be present and equal `0`, `200`, `400`, `600`, or `800`. The block's whole-second timestamp must not be earlier than its parent's. Because block headers do not store milliseconds, the client checks exact 200ms progression after execution. The implemented post-execution path uses the actual parent header, parent BaseTime state, and child `tx[1]` to check parent-to-child progression. It does not yet explicitly compare the child BaseTime state with `tx[1]`. Coverage across historical, range, noncanonical-parent, and auxiliary import paths remains incomplete, so this specification does not define those paths as fully enforced. The intended behavior is to fail validation when required block, parent, or state data is missing rather than estimate the timestamp. From 58652693dad4b71613f41f34624aa13f3b64efdf Mon Sep 17 00:00:00 2001 From: Francis Li Date: Thu, 6 Aug 2026 09:35:07 -0700 Subject: [PATCH 6/6] docs: simplify BaseTime progression validation Amp-Thread-ID: https://ampcode.com/threads/T-019fd2ba-ede5-767c-94c7-c47dc413f7be Co-authored-by: Amp --- docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx index 2517aced7..3f9a1acd9 100644 --- a/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx +++ b/docs/base-chain/specs/upgrades/denim/200ms-native-blocks.mdx @@ -97,7 +97,7 @@ All existing Engine timestamp fields remain seconds-based. When processing `forkchoiceUpdated`, the execution client performs checks that do not require reading contract state. Before Denim, `timestampMillisPart` must be absent. After Denim, it must be present and equal `0`, `200`, `400`, `600`, or `800`. The block's whole-second timestamp must not be earlier than its parent's. Because block headers do not store milliseconds, the client checks exact 200ms progression after execution. -The implemented post-execution path uses the actual parent header, parent BaseTime state, and child `tx[1]` to check parent-to-child progression. It does not yet explicitly compare the child BaseTime state with `tx[1]`. Coverage across historical, range, noncanonical-parent, and auxiliary import paths remains incomplete, so this specification does not define those paths as fully enforced. The intended behavior is to fail validation when required block, parent, or state data is missing rather than estimate the timestamp. +After execution, the client **MUST** verify that the block's full timestamp is exactly 200ms after its parent's. Blocks that do not satisfy this requirement are invalid. ## Derivation