Base chain migration guide: from OP Stack to base/base

TL;DR

• For node operators: Base V1 is the hard migration boundary. After activation, op-node + op-geth will no longer sync with the canonical chain. You must switch to base-consensus + base-reth-node. Sepolia activates 2026-04-20 at 18:00 UTC — mainnet date TBD.
• For app developers: Nothing breaks. Chain ID (8453), contract addresses, RPC methods, and EVM behaviour are unchanged. The optimism_* namespace remains fully supported.
• For DeFi / MEV teams: Flashblocks introduces 200ms sub-block ordering. Once a Flashblock is sealed its transaction order is final. Factor this into liquidation and arbitrage logic.
• For infrastructure providers: Sequencer, consensus client, and fault proof system are now consolidated into a single Reth-based binary from github.com/base/base. One release channel, one set of release notes.

What is Base?

➡️ If you are already familiar with the Base and it’s new architecture, skip to “What changes for node operators” section below for the step-by-step migration guide.

Base is an Ethereum Layer 2 network incubated by Coinbase. It was launched on Optimism‘s OP Stack and has since grown into the largest chain in the Superchain ecosystem by total value locked.

Base processes transactions off-chain and posts compressed calldata back to Ethereum for data availability. It uses optimistic rollup mechanics, with fraud proofs allowing any party to challenge invalid state transitions during a dispute window.

The network is EVM-equivalent. Smart contracts written in Solidity, developer tooling built for Ethereum mainnet, and standard JSON-RPC methods all work on Base without modification.

Why the migration happened

Base launched on the OP Stack because it offered a production-ready, well-audited foundation. The trade-off was coordination overhead from distributed ownership. Over time, Base grew into a diverse ecosystem. The code operating Base’s sequencer, consensus layer, and fault proof system was spread across repositories maintained by multiple teams, including Optimism, Flashbots, and Paradigm. Shipping a single feature required coordination across several external engineering teams and their release schedules. Hence, Base introduced a new unified stack.

Three specific objectives drove the migration decision:

Faster shipping cadence: The previous schedule supported three hard forks per year. The base/base architecture supports six, with smaller, tightly scoped upgrade batches. This reduces risk per upgrade and shortens the feedback loop between design and production deployment.

Reduced cognitive overhead: The protocol spec and codebase should be understandable by a single developer. Consolidating into base/base eliminates the need to cross-reference documentation across OP Stack, Flashbots’ builder infrastructure, and Paradigm’s Reth codebase separately.

Alignment with Ethereum roadmap: Base is positioned to deploy high-impact Ethereum Improvement Proposals like BAL (EIP-7928) ahead of L1 to generate data that informs the Ethereum roadmap. A consolidated codebase makes this faster to execute.

Architecture: before and after

Let’s compare the earlier architecture to better understand the changes introduced.

Before: Distributed multi-client architecture

Base previously ran as a composite system:

• Consensus client: op-node (maintained by OP Labs / Optimism)
• Execution client: op-geth (canonical OP Stack execution client) or op-reth
• Block building: Flashbots builder infrastructure
• Fault proofs: Optimism Cannon, coordinated with OP Labs
• Sequencer: Separate binary, maintained across multiple repositories

Each component had its own release cycle. Any upgrade to Base required coordination across Optimism, Flashbots, and in some cases Paradigm (for Reth-related changes). When a sequencer-level fix was needed, Base engineers had to coordinate with at least two external teams before shipping.

After: Unified base/base architecture

The base/base Stack: The unified repository lives at github.com/base/base.

The unified stack ships one official distribution per upgrade. One binary. One release channel. One set of release notes to track.

Core execution: Reth

The execution client is Reth, the Rust-based Ethereum client built by Paradigm. Base adopted Reth progressively in late 2024, migrating archive nodes first, then sequencer infrastructure.

Reth’s advantages for Base specifically:

• Disk usage grows at a fraction of the rate of op-geth (Geth archive nodes were projected to hit 30TB NVMe limits around May 2025 at prior growth rates; Reth’s storage model extends that timeline to the mid-2030s)
• Block building performance is measurably faster, enabling the safe increase to 150 Mgas/s
• The modular ExEx (Execution Extension) system allows Base to deploy custom extensions without modifying core client code

Paradigm released Reth 2.0 in Q1 2026, achieving 1.7 Gigagas/s performance with a disk footprint of approximately 240 GB. Base’s production infrastructure uses op-reth, the OP Stack-compatible fork.

Consensus: op-node derived

The consensus client is derived from op-node but will be maintained entirely within base/base going forward. Bug fixes and protocol updates flow from the Base Engineering Team rather than OP Labs.

Fault proofs

The current system uses optimistic proofs. Base V1 will replace this with TEE (Trusted Execution Environment) and ZK proofs, enabling faster finality. The Kona fault proof program, a Reth-based implementation built by OP Labs, will replace the existing Cannon-based system after the Base V1 upgrade.

Flashblocks: The Performance Layer

Flashblocks is a preconfirmation system developed by Flashbots and deployed on Base. Rather than waiting for a 2-second block, the sequencer issues sub-blocks every 200 milliseconds.

• Block Structure: Flashblocks are partial blocks with committed transactions. Multiple Flashblocks form a final block.
• Transaction Signal: Transactions appear once executed by the builder. Apps receive inclusion signals in ~200ms.
• Transaction Ordering: Ordering is fixed per Flashblock, late transactions cannot modify already emitted Flashblocks.
• Reorg Handling: Flashblocks are not final, apps reading Flashblock state before finalization need to handle potential state rollbacks.
• Gas Constraints: Large transactions exceeding ~10% gas limit are delayed, they are included in later Flashblocks.
• RPC Compatibility: Works with standard Ethereum JSON-RPC : Use "pending" to access Flashblock state.

curl -X POST <YOUR_CHAINSTACK_BASE_RPC_URL> \\
-H "Content-Type: application/json" \\
-d '{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "eth_getBlockByNumber",
  "params": ["pending", false]
}'

• Fallback: Flashblocks maintains 99.9% uptime. If the infrastructure goes offline, the network automatically falls back to standard ~2-second block times

📖 Flashblocks is not exclusive to Base — to understand how it works across all supported chains, see What are Flashblocks?

Superchain cross-chain messaging

Before the migration, Base operated as part of a tightly integrated OP Stack ecosystem alongside chains like Optimism, sharing a common execution framework and cross-chain messaging layer. Superchain interoperability was being built around standardized messaging contracts like L2ToL2CrossDomainMessenger and CrossL2Inbox, with the goal of letting OP Stack chains pass messages directly without routing through Ethereum L1. It is worth noting that native Superchain interoperability was still rolling out iteratively at the time Base announced its migration. It was not yet a fully deployed production feature on Base when the announcement landed.

Nothing changes immediately for developers or users. Base will remain compatible with the OP Stack specification including continued support for existing RPCs, and will continue upstreaming bug fixes and coordinating security disclosures to help keep the broader Superchain ecosystem safe. The divergence is forward-looking: as base/base evolves its own upgrade cycle, consensus client, and proof systems independently of OP Labs, Base will gradually move outside the native Superchain interop cluster. Over time, this may affect access to emerging OP Stack interop features like SuperchainERC20, while current functionality remains intact. The separation is technical, not adversarial and Base will continue working with Optimism as a client of OP Enterprise for mission-critical support.

Hard fork roadmap

Base published its hard fork schedule publicly for the next several months:

Base V1 is the critical migration boundary for node operators:

• Prior to V1, full backward compatibility with the previous execution specification is maintained
• After activation, legacy op-node + op-geth nodes will no longer remain compatible with the canonical chain
• Restricts supported node software to base-consensus and base-reth-node only
• Introduces multi-proof system using TEE and ZK components alongside optimistic assumptions for faster withdrawals and a path toward stronger decentralization
• Simplifies Flashblocks websocket format to improve consistency and reduce integration complexity
• Aligns Base with Ethereum Fusaka upgrade for improved data availability and rollup scalability. Learn more about the Fusaka upgrade.

⚠️ Mainnet activation is currently TBD, while Sepolia activation is scheduled for 2026-04-20 18:00:00 UTC.

Base V2

• Block Access Lists for block-level state access optimization
• New transaction types for improved execution efficiency and UX
• Reduced execution overhead under high network load
• No changes to EVM semantics

Base V3

• Support for Ethereum Glamsterdam upgrade
• Opcode repricing aligned with upstream EVM changes
• Base fee mechanism adjustments for improved fee market stability
• Continued alignment with Ethereum execution-layer roadmap

What changes for node operators

This section covers the migration steps for teams running Base nodes.

Current state (before Base V1):

Nodes running op-node (consensus) + op-geth or op-reth (execution) continue to function normally. Base remains fully compatible with the OP Stack specification.

After Base V1:

After Base V1, the following components are no longer supported for canonical sync:

• op-node
• op-geth
• standalone OP Stack op-reth
• Nethermind-based configurations

Nodes using these clients will diverge after the upgrade boundary.

ℹ️ Checkout the official announcement : https://blog.base.dev/next-chapter-for-base-chain-1

Required node stack

Migration steps

From OP Reth → base-reth-node

If you are already running OP Reth via base/node, update to the latest version and your node will automatically use base-reth-node. Your existing ./reth-data directory is fully compatible. No re-sync or snapshot restore is needed.

Stop existing node

Shutdown all running services before migration begins

docker compose down

Update Base node repository

Pull the latest Base node configuration

git pull origin main
cd base/node

Verify sync

Confirm the node is running the Base stack correctly:

web3_clientVersion

Should include base in the version string (e.g. reth/v1.11.3-.../base/v0.7.0)

Migrating from another client

op-geth and nethermind are no longer supported. You must start fresh with base-reth-node.

Stop existing node

Shutdown all running services before migration begins

docker compose down

Update Base node repository

Pull the latest Base node configuration

git pull origin main
cd base/node

Remove deprecated execution state (if required)

If you are running op-geth or Nethermind, you must reset execution data.

rm-rf ./geth-data
rm-rf ./nethermind-data

Edit your .env.mainnet or .env.sepolia file to match your configuration preferences.

Bootstrap from a Reth snapshot to avoid a full sync.

Start your node

docker compose up

Migrating Consensus Layer

Replace op-node with base-consensus by updating your environment configuration. Set in .env file:

USE_BASE_CONSENSUS=true

Update .env file from OP_NODE_* → BASE_NODE_*

Restart your node

docker compose up

Verify

Check consensus logs:

docker compose logs -f node

Confirm sync status: optimism_syncStatus continues to work.

ℹ️ See the following document for detailed migration instructions and all new environment variables: https://docs.base.org/base-chain/node-operators/base-v1-upgrade

What changes for developers

For teams building applications on Base, not operating nodes:

• Nothing changes immediately: Contract addresses remain the same. Chain ID (8453) remains the same. All existing RPC endpoints continue to function. EVM behavior is identical.
• What gets better: The faster upgrade cadence means features move from proposal to production faster. The proof system upgrade in V1 (Optimistic → TEE/ZK) will enable faster withdrawal finality. Current optimistic fraud proof windows require a 7-day challenge period before L1 finalization; TEE/ZK proofs compress this significantly.
• Transaction ordering changes with Flashblocks: For protocols that depend on block-level ordering guarantees (MEV strategies, liquidation bots, arbitrage), the 200ms Flashblock window introduces a time-based ordering constraint. Once a Flashblock is sealed, its transaction ordering is final within that window.
• Smart contract deployments: No redeployments required. Existing contract addresses, ABIs, and event signatures are unaffected.

Security and decentralization

Base is a Stage 1 decentralized rollup. Upgrade authorization is enforced via a Security Council multisig, and state validity is enforced through permissionless fault proofs.

Protocol upgrades require approval from a 12-member Security Council multisig (Coinbase + 11 independent entities). Execution requires a ≥9-of-12 threshold (75%).

The Base Security Council currently includes members from organizations like Aerodrome, Moonwell, Blackbird, ChainSafe, and Talent Protocol, among others. Each member operates an independent key used for protocol upgrade and governance signing.

Stage 1 properties:

• Permissionless fault proofs enabled
• Fraud proofs allow any actor to challenge invalid state transitions during the dispute window
• Upgrade execution requires 9-of-12 signatures
• No single entity has unilateral upgrade authority
• Separation between execution operation and upgrade authorization

The Security Council composition replaces a prior external governance dependency with an independent signer, preserving the 12-member structure and 9-of-12 threshold while maintaining quorum integrity and reducing reliance on external coordination.

Council responsibilities include protocol upgrade signing, key rotation approvals, signer replacement, key custody security, and liveness verification. Key compromise or loss is handled through coordinated rotation procedures that preserve quorum requirements without disrupting upgrade authority.

Base is a transitional system targeting Stage 2, where upgrade authority is constrained by on-chain verifiable fault proofs and a multi-proof validation system (optimistic + TEE + ZK). Base V1 introduces early components of this model by integrating hybrid proving infrastructure, reducing reliance on social coordination for correctness.

Key resources for node operators and builders

Core Infrastructure

• base/base (GitHub): Unified stack repository. The canonical source for Base binary releases post-V1.
• base/node (GitHub): Node configuration repository. Docker configurations for Reth, Geth, and Nethermind.
• Base Documentation: Official developer documentation.

EVM Tooling

• Foundry: Smart contract development framework. Works with Base without modification.
• Wagmi: React hooks for Ethereum. Supported and actively contributed to by Base Engineering.
• viem: TypeScript interface for Ethereum. Base is a built-in chain definition.
• Hardhat: Ethereum development environment. Full Base compatibility.

Flashblocks

• Flashblocks Demo: Live testnet demo of Flashblocks latency.
• Flashblocks Docs: Integration guide for apps, wallets, and indexers.
• transaction-latency tester (GitHub): Tool for benchmarking transaction inclusion times with and without Flashblocks.

Conclusion

The base/base migration resolves a structural tension that had been building since Base’s launch: a chain with the largest TVL in the Superchain was still dependent on external teams to ship protocol changes. base/base eliminates that dependency.

The EVM semantics, chain ID, contract addresses, and JSON-RPC interface are unchanged. But the infrastructure beneath them is now Base’s to control — and to upgrade six times a year instead of three.

What this means by audience:

• Node operators: Base V1 on Sepolia activates 2026-04-20 at 18:00 UTC. Test your migration from op-node + op-geth to base-consensus + base-reth-node on Sepolia now. Mainnet date is TBD — watch the base/base release channel.
• App developers: No action required in this phase. Watch for withdrawal finality improvements in V1 and Block Access Lists in V2.
• DeFi / MEV teams: Review your ordering assumptions against Flashblocks’ 200ms sub-block windows.
• Managed infrastructure users: Chainstack’s Base nodes are already on the base/base stack. No migration steps required on your end.

Running your own Base node? If the migration overhead isn’t worth it for your team, Chainstack offers managed Base nodes with no infra management required.

FAQ

Related Reading

• Flashblocks on Base: 200ms preconfirmations for lightning-fast UX
• How to get a Base public RPC endpoint
• Best Ethereum RPC providers in 2026
• Base: Deploy an ERC-721 contract with Hardhat
• Best Base RPC providers for onchain applications in 2026