> ## Documentation Index
> Fetch the complete documentation index at: https://docs.novacula.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Base

> Two-role (base-reth-node + base-consensus) OP-Stack L2 anchored on Ethereum, with required L1 endpoints

Base is an OP-Stack L2 anchored on Ethereum. Every Base node runs two processes: a **base-reth-node** execution layer and a **base-consensus** rollup client. They talk to each other over a JWT-secured Engine API that the platform manages — you never set it. Sequencer URL and P2P peers are baked in per network, but the **L1 endpoints** base-consensus derives the rollup from are **yours to provide** — there is no public default (see [L1 endpoints](#l1-endpoints-required)).

Base runs either way on a bare-metal Agent — as `systemd` services or as Docker containers — and as pods on a [Kubernetes Operator](/recipes/provision-on-kubernetes) executor. Both clients ship as binaries and as images, so you pick the **Runtime** in the wizard's **Target** step (defaults to **Systemd**). See [Runtime](/docs/nodes/deploy-a-node#runtime-agent-only).

## Networks and resources

| Network   | Sequencer RPC                        |
| --------- | ------------------------------------ |
| `mainnet` | `https://mainnet-sequencer.base.org` |
| `sepolia` | `https://sepolia-sequencer.base.org` |

Base offers a single node type, `full`. The deploy wizard pre-fills resource and disk defaults per network and role:

| Network   | Process        | CPU | Memory | Disk   |
| --------- | -------------- | --- | ------ | ------ |
| `mainnet` | base-reth-node | 8   | 32Gi   | 2048Gi |
| `mainnet` | base-consensus | 2   | 8Gi    | 20Gi   |
| `sepolia` | base-reth-node | 4   | 16Gi   | 512Gi  |
| `sepolia` | base-consensus | 1   | 4Gi    | 10Gi   |

## Clients

| Role        | Client             | Versions |
| ----------- | ------------------ | -------- |
| `execution` | **base-reth-node** | `1.3.1`  |
| `rollup`    | **base-consensus** | `1.3.1`  |

One pinned client per role today. The deploy wizard offers exactly the client and version the executor declares.

## Ports

| Name            | Port    | Owner                    |
| --------------- | ------- | ------------------------ |
| EL RPC (HTTP)   | `8545`  | base-reth-node           |
| Engine API      | `8551`  | base-reth-node (private) |
| EL metrics      | `6060`  | base-reth-node           |
| EL P2P          | `30303` | base-reth-node (TCP/UDP) |
| EL discovery v5 | `9200`  | base-reth-node (UDP)     |
| Rollup RPC      | `9545`  | base-consensus           |
| Rollup metrics  | `7300`  | base-consensus           |
| Rollup P2P      | `9222`  | base-consensus (TCP/UDP) |

The execution client answers the node's primary RPC. The rollup RPC is a control-plane endpoint used by the platform's health probe.

## L1 endpoints (required)

base-consensus derives the L2 chain from Ethereum L1 — it does **not** sync purely from L2 peers. Unlike some rollups, Novacula supplies **no public L1 fallback** for Base: you must point the node at an Ethereum L1 yourself. A Base node needs two L1 endpoints:

* **Ethereum execution RPC** (`l1`) — the L1 blocks the rollup reads.
* **Ethereum beacon REST** (`l1beacon`) — the L1 consensus data, including blob data.

You supply both in the deploy wizard's **Connections** step, and change them later on the node's **Connections** tab. In this release the L1 endpoints are entered as **external URLs** — each must work without a password or API key. The beacon endpoint must come from a consensus client that keeps every blob — on Lighthouse that's `--supernode` or `--semi-supernode`; a beacon node running without one of them can't feed the L2. An Ethereum node you deploy on Novacula gets that flag when you pick the `blob-serving` node type in the wizard; expose its execution RPC and beacon API (without RPC-key auth) and enter those URLs.

See [Connections](/docs/nodes/deploy-a-node#connections) for the step, and [Edit connections](/docs/nodes/edit-configuration#edit-connections) for changing them after deploy.

<Warning>
  A Base node is only as reliable as the L1 behind it. If base-consensus stops making progress, the L1 endpoints are the first thing to suspect — a rate-limited or lagging L1 stalls the rollup even when the node itself is healthy. Prefer an Ethereum node you control over a shared public endpoint for a production Base node.
</Warning>

The related client flags (`--l1-eth-rpc`, `--l1-beacon`, and the Engine API wiring) are managed by the platform.

## Config overrides

Base exposes no config override surface: the platform manages both clients' flags — the P2P peers, the Engine API, and the L1 endpoints above — so a Base node is configured entirely by the choices you make in the wizard. See [Edit a running node](/docs/nodes/edit-configuration) for what can change after deploy.

## Sync

base-consensus fetches batches from L1 and base-reth-node applies them through the Engine API. The execution client **bootstraps from a snapshot** on its first start instead of syncing from genesis, which cuts initial sync time; the download runs once per data directory, so a node whose data directory has already been bootstrapped skips the step. A healthy, reachable L1 endpoint is the gating factor for progress after that — if base-consensus can't reach L1, it can't advance.

## Monitoring

Status, height, peers, sync progress, and disk combine both processes' readings — see [Node monitoring](/docs/nodes/monitoring). Sync progress reflects the execution layer's real position, so a node whose base-reth-node is still behind is not reported as fully synced.

The node's **Overview** tab shows each observed L1 endpoint — its URL, its last check time, and its sync percentage, height, and lag when the upstream reports them. The **Connections** tab is where you change the endpoints.

## Common patterns

* **RPC provider for Base mainnet** — point the node at your own Ethereum L1, then serve the node's HTTP RPC to your apps.