chore: migrate base specs

docs/base-chain/llms-full.txt

@@ -59,6 +59,44 @@
 - [Wallet Developers](https://docs.base.org/apps/builder-codes/wallet-developers.md) — Builder Codes for wallet developers
 - [Agent Developers](https://docs.base.org/apps/builder-codes/agent-developers.md) — Attribute AI agent transactions to your identity on Base
 
+### Protocol Specs
+- [Specification Index](https://docs.base.org/base-chain/specs/index.md) — Entry point for the full Base Chain protocol specification
+- [Protocol Overview](https://docs.base.org/base-chain/specs/protocol/overview.md) — Architecture tour: sequencer, batcher, derivation, proofs, and bridge
+- [Batcher](https://docs.base.org/base-chain/specs/protocol/batcher.md) — How sequencer data is posted to L1 as channel frames and batches
+- [Derivation](https://docs.base.org/base-chain/specs/protocol/consensus/derivation.md) — Deterministic L2 block derivation from L1 data and sequencer batches
+- [P2P Network](https://docs.base.org/base-chain/specs/protocol/consensus/p2p.md) — Rollup node peer discovery, gossip, and unsafe block propagation
+- [Rollup Node RPC](https://docs.base.org/base-chain/specs/protocol/consensus/rpc.md) — optimism_outputAtBlock and rollup node RPC interface
+- [Execution Engine](https://docs.base.org/base-chain/specs/protocol/execution/index.md) — EIP-1559 parameters, fee vaults, and Engine API behavior
+- [Predeploys](https://docs.base.org/base-chain/specs/protocol/execution/evm/predeploys.md) — System contracts at predetermined genesis addresses
+- [Precompiles](https://docs.base.org/base-chain/specs/protocol/execution/evm/precompiles.md) — Native EVM implementations at predefined addresses
+- [Preinstalls](https://docs.base.org/base-chain/specs/protocol/execution/evm/preinstalls.md) — Utility contracts deployed in genesis state
+- [Bridges](https://docs.base.org/base-chain/specs/protocol/bridging/bridges.md) — Standard bridge for ETH and ERC20 cross-domain transfers
+- [Deposits](https://docs.base.org/base-chain/specs/protocol/bridging/deposits.md) — L1-to-L2 deposit transaction mechanism
+- [Withdrawals](https://docs.base.org/base-chain/specs/protocol/bridging/withdrawals.md) — L2-to-L1 withdrawal and proof mechanism
+- [Messengers](https://docs.base.org/base-chain/specs/protocol/bridging/messengers.md) — Cross-domain messenger API for arbitrary message passing
+- [Fault Proof System](https://docs.base.org/base-chain/specs/protocol/fault-proof/index.md) — Program, VM, and dispute game overview
+- [Cannon FPVM](https://docs.base.org/base-chain/specs/protocol/fault-proof/cannon-fault-proof-vm.md) — Multithreaded Cannon virtual machine specification
+- [Proposer](https://docs.base.org/base-chain/specs/protocol/fault-proof/proposer.md) — L2 output root publication to L1
+- [Fault Dispute Game](https://docs.base.org/base-chain/specs/protocol/fault-proof/stage-one/fault-dispute-game.md) — Bisection-based dispute resolution protocol
+- [Honest Challenger](https://docs.base.org/base-chain/specs/protocol/fault-proof/stage-one/honest-challenger-fdg.md) — Correct challenger behavior in the dispute game
+- [Bond Incentives](https://docs.base.org/base-chain/specs/protocol/fault-proof/stage-one/bond-incentives.md) — Financial incentives enforcing honest participation
+- [OptimismPortal](https://docs.base.org/base-chain/specs/protocol/fault-proof/stage-one/optimism-portal.md) — Primary L1 interface for deposits and withdrawals
+- [Bridge Integration](https://docs.base.org/base-chain/specs/protocol/fault-proof/stage-one/bridge-integration.md) — Dispute-game-based withdrawal path
+- [Glossary](https://docs.base.org/base-chain/specs/reference/glossary.md) — Protocol terminology and definitions
+- [Configurability](https://docs.base.org/base-chain/specs/reference/configurability.md) — All configurable protocol parameters
+
+### Protocol Specs — Upgrades
+- [Jovian](https://docs.base.org/base-chain/specs/upgrades/jovian/overview.md) — Minimum base fee and DA footprint gas scalar
+- [Isthmus](https://docs.base.org/base-chain/specs/upgrades/isthmus/overview.md) — Pectra EIPs and operator fee mechanism
+- [Holocene](https://docs.base.org/base-chain/specs/upgrades/holocene/overview.md) — Dynamic EIP-1559 parameters and stricter derivation rules
+- [Granite](https://docs.base.org/base-chain/specs/upgrades/granite/overview.md) — bn256Pairing restrictions and channel timeout changes
+- [Fjord](https://docs.base.org/base-chain/specs/upgrades/fjord/overview.md) — FastLZ fee estimation, RIP-7212 precompile, brotli compression
+- [Ecotone](https://docs.base.org/base-chain/specs/upgrades/ecotone/overview.md) — EIP-4844 blob DA and Dencun integration
+- [Delta](https://docs.base.org/base-chain/specs/upgrades/delta/overview.md) — Span batches for efficient L1 data posting
+- [Canyon](https://docs.base.org/base-chain/specs/upgrades/canyon/overview.md) — Ethereum Shanghai EIPs (EIP-3651, EIP-3855, EIP-3860)
+- [Azul](https://docs.base.org/base-chain/specs/upgrades/azul/overview.md) — Osaka EVM support and multi-proof system
+- [Pectra Blob Schedule](https://docs.base.org/base-chain/specs/upgrades/pectra-blob-schedule/overview.md) — Optional delay of Ethereum blob count schedule changes
+
 ### Security
 - [Security Council](https://docs.base.org/base-chain/security/security-council.md) — Security governance
 - [Avoid Malicious Flags](https://docs.base.org/base-chain/security/avoid-malicious-flags.md) — App‑blocklist

docs/base-chain/llms.txt

@@ -33,6 +33,29 @@
 - [Performance Tuning](https://docs.base.org/base-chain/node-operators/performance-tuning.md) — Optimize node performance
 - [Node Providers](https://docs.base.org/base-chain/node-operators/node-providers.md) — RPC node providers for Base
 
+## Protocol Specs
+- [Overview](https://docs.base.org/base-chain/specs/index.md) — Full Base Chain protocol specification index
+- [Protocol Overview](https://docs.base.org/base-chain/specs/protocol/overview.md) — High-level tour of protocol components and user flows
+- [Derivation](https://docs.base.org/base-chain/specs/protocol/consensus/derivation.md) — How L2 blocks are deterministically derived from L1 data
+- [Execution Engine](https://docs.base.org/base-chain/specs/protocol/execution/index.md) — L2 execution engine configuration and Engine API usage
+- [Deposits](https://docs.base.org/base-chain/specs/protocol/bridging/deposits.md) — L1-to-L2 deposit transaction specification
+- [Withdrawals](https://docs.base.org/base-chain/specs/protocol/bridging/withdrawals.md) — L2-to-L1 withdrawal specification
+- [Fault Proof System](https://docs.base.org/base-chain/specs/protocol/fault-proof/index.md) — Fault proof program, VM, and dispute game
+- [Fault Dispute Game](https://docs.base.org/base-chain/specs/protocol/fault-proof/stage-one/fault-dispute-game.md) — Bisection-based dispute resolution protocol
+- [Predeploys](https://docs.base.org/base-chain/specs/protocol/execution/evm/predeploys.md) — System contracts at predetermined addresses
+- [Glossary](https://docs.base.org/base-chain/specs/reference/glossary.md) — Protocol terminology and definitions
+- [Configurability](https://docs.base.org/base-chain/specs/reference/configurability.md) — Consensus, policy, admin, and sequencer parameters
+
+### Upgrade Specs
+- [Jovian](https://docs.base.org/base-chain/specs/upgrades/jovian/overview.md) — Configurable minimum base fee and DA footprint scalar
+- [Isthmus](https://docs.base.org/base-chain/specs/upgrades/isthmus/overview.md) — Pectra EIPs and operator fee mechanism
+- [Holocene](https://docs.base.org/base-chain/specs/upgrades/holocene/overview.md) — Dynamic EIP-1559 parameters and stricter derivation rules
+- [Granite](https://docs.base.org/base-chain/specs/upgrades/granite/overview.md) — bn256Pairing precompile restrictions and channel timeout changes
+- [Fjord](https://docs.base.org/base-chain/specs/upgrades/fjord/overview.md) — FastLZ L1 fee estimation and brotli channel compression
+- [Ecotone](https://docs.base.org/base-chain/specs/upgrades/ecotone/overview.md) — EIP-4844 blob support and Dencun integration
+- [Delta](https://docs.base.org/base-chain/specs/upgrades/delta/overview.md) — Span batches for compressed L1 data posting
+- [Azul](https://docs.base.org/base-chain/specs/upgrades/azul/overview.md) — Osaka EVM support and multi-proof system
+
 ## Security
 - [Report a Vulnerability](https://docs.base.org/base-chain/security/report-vulnerability.md) — Security contact and disclosure
 - [Security Council](https://docs.base.org/base-chain/security/security-council.md) — Governance and process overview

docs/base-chain/node-operators/base-v1-upgrade.mdx

@@ -9,7 +9,7 @@ Base Azul is an upgrade that introduces Osaka features on Base and TEE/ZK proof
 
 Only `base-reth-node` (EL) and `base-consensus` (CL) support Azul. **Nodes running `op-node`, `op-geth`, `op-reth`, `nethermind`, or `kona` will not support the network upgrade and must be migrated before activation.**
 
-For full details on what's included, see the [Azul specification](https://specs.base.org/upgrades/azul/overview).
+For full details on what's included, see the [Azul specification](/base-chain/specs/upgrades/azul/overview).
 
 ## Activation Timeline
 

docs/base-chain/specs/bcps/bcp-0000.mdx

@@ -0,0 +1,103 @@
+---
+title: "BCP-0000: BCP Process"
+description: "BCP-0000 defines the Base Change Proposal process, establishing the template and standards for proposing, reviewing, and accepting protocol changes."
+---
+
+## Abstract
+
+BCP-0000 defines the Base Change Proposal (BCP) process — the mechanism by which changes to the Base
+Chain protocol are proposed, reviewed, and accepted. A BCP is a design document providing a
+complete specification of a proposed change, serving as the source of truth for implementation.
+
+## Motivation
+
+Base Chain needs a transparent, structured process for evolving its protocol. Without a formal
+process, changes risk being underdocumented, inconsistently reviewed, or difficult to track across
+stakeholders. BCPs provide a single canonical artifact per change: a self-contained specification
+that captures the what, why, and how, from initial proposal through final acceptance.
+
+---
+
+# Specification
+
+## BCP Types
+
+There are two types of BCPs:
+
+- **Standards Track** — describes a change to the Base Chain protocol itself: execution rules,
+  consensus, bridging, fault proofs, or other on-chain behavior. Most BCPs are Standards Track.
+- **Meta** — describes a change to the BCP process or introduces governance around how the
+  protocol is evolved. BCP-0000 is a Meta BCP.
+
+## BCP Statuses
+
+A BCP moves through the following statuses over its lifetime:
+
+```
+Draft → Review → Accepted → Final
+                └→ Rejected
+       └→ Withdrawn
+```
+
+| Status | Description |
+| ------ | ----------- |
+| **Draft** | The BCP is being authored and is not yet ready for formal review. |
+| **Review** | The BCP is complete and open for community and core team feedback. |
+| **Accepted** | The BCP has been approved and is scheduled for implementation. |
+| **Final** | The BCP has been implemented and deployed to mainnet. |
+| **Rejected** | The BCP was reviewed and not accepted. |
+| **Withdrawn** | The author(s) withdrew the BCP before a decision was reached. |
+| **Deprecated** | A previously Final BCP has been superseded by a later BCP. |
+
+## BCP Numbering
+
+BCPs are assigned a number at the time of their first Draft commit. Numbers are assigned
+sequentially starting from 1 (BCP-0001). The number is permanent and is never reused, even if the
+BCP is rejected or withdrawn. BCP-0000 is reserved for this process document.
+
+## BCP Format
+
+Each BCP is a Markdown file stored at `docs/specs/pages/bcps/bcp-{NNNN}.md` in the
+[base repository](https://github.com/base/base). It must begin with the title as an H1
+heading followed by the body sections below.
+
+### Required Sections
+
+**Abstract** — A 2–4 sentence high-level summary of the proposed change.
+
+**Motivation** — An explanation of the problem this BCP solves and why the proposed approach was
+chosen over alternatives. Include links to prerequisite specs or relevant context.
+
+**Specification** — A complete description of the change: state transitions, data structures,
+encodings, interface definitions, and any invariants that must hold. The specification must be
+precise enough for an independent engineer to implement and test without inferring details.
+
+**Invariants** (if applicable) — Explicit invariants that must always hold after the change is
+applied, and critical cases the test suite must cover.
+
+### Optional Sections
+
+Additional sections (e.g. **Security Considerations**, **Backwards Compatibility**,
+**Reference Implementation**) may be added as needed.
+
+## Process
+
+1. **Draft** — An author opens a PR to the base repository adding a new BCP file. The PR
+   description should link to any relevant prior discussion.
+2. **Review** — The PR is marked ready for review. Core team members and community stakeholders
+   review the specification for correctness, completeness, and alignment with Base's design goals.
+3. **Accepted / Rejected** — The core team makes a final decision. If accepted, the BCP is merged
+   and assigned a Final status once the implementation ships to mainnet. If rejected, the BCP is
+   merged with Rejected status and a brief rationale added to the BCP.
+4. **Final** — The BCP is updated to Final status when its implementation is deployed to mainnet.
+
+## BCP Index
+
+The [BCPs index page](./index) lists all BCPs with their current status. Authors are
+responsible for keeping their BCP's status up to date as it progresses.
+
+# Invariants
+
+- Every BCP has a unique, permanent number.
+- Every BCP that reaches Final status has a corresponding implementation deployed to mainnet.
+- A Deprecated BCP must reference the superseding BCP.

docs/base-chain/specs/bcps/index.mdx

@@ -0,0 +1,11 @@
+---
+title: "Base Change Proposals (BCPs)"
+description: "Index of Base Chain Proposals (BCPs) — design documents describing proposed changes to the Base Chain protocol."
+---
+
+BCPs are design documents that describe changes to the Base Chain protocol. Each BCP provides a
+complete specification that serves as the source of truth for implementation.
+
+---
+
+- [BCP-0000: BCP Template and Purpose](/base-chain/specs/bcps/bcp-0000)

docs/base-chain/specs/overview.mdx

@@ -0,0 +1,27 @@
+---
+title: "Overview"
+description: "Technical specification of the Base Chain protocol, covering block derivation, execution, transaction propagation, and state verification."
+---
+
+This specification defines the Base Chain protocol: how nodes derive and execute blocks, how
+transactions are propagated, and how state transitions are verified. It covers core protocol rules,
+execution behavior, and proving.
+
+## Design Goals
+
+Our aim is to design a protocol specification that is:
+
+- **Opinionated:** Simplicity through deliberate design choices. We identify the best solution and
+  commit to it.
+- **Maximally Simple:** By focusing on just what Base needs, we radically simplify the stack. The
+  protocol spec and codebase should be understandable by a single developer.
+- **Fast Cycles:** We ship upgrades frequently rather than batching risk into infrequent large ones.
+  We target six smaller, tightly scoped hard forks per year on a regular cadence, with fortnightly
+  releases.
+- **Ethereum Aligned:** Base wins when Ethereum wins. We accelerate deployment of high-impact
+  changes ahead of L1 to provide data that informs the Ethereum roadmap.
+
+## Lineage
+
+Base Chain inherits Ethereum's EVM semantics, transaction rules, and L1-anchored security. It was
+originally built on the [OP Stack](https://specs.optimism.io). After the Jovian Hardfork, Base Chain follows this specification.