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.

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

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. 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 lists all BCPs with their current status. Authors are responsible for keeping their BCP's status up to date as it progresses.

• 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.