By Nimbus Team in News — Mar 2, 2026

The Nimbus Unified Client

Back to the Good Old Days of Running Ethereum

There was a time—the pre-Merge days—when running Ethereum felt refreshingly simple. You ran one client, one process, one database. Back then, you didn’t need to worry about lining up JWT secrets or timing races between processes.

Post-Merge, correctness demanded modularity: execution client, consensus client, and often an external validator client. Three moving parts, three failure domains, and a lot of glue.

Most of us have since experienced the joy of 3 a.m. debugging sessions, trying to figure out, “Is my execution client talking to my beacon node?”

A simpler way to run Ethereum with Nimbus

Nimbus is a unified client which is created as a single binary prototype that unites Ethereum into one process, one binary, one data directory—while remaining fully post-Merge correct. It’s not for nostalgia’s sake: it’s about reclaiming operational simplicity without sacrificing performance, correctness, or modern Ethereum features.

It shows that Ethereum is fundamentally one system, and Nimbus, with its unified client, completes that vision.

What is the Nimbus unified client?

Nimbus is a unified Ethereum client where:

The execution chain and beacon chain run inside the same process
They share a database, services, and configuration
All functionality from nimbus_execution_client and nimbus_beacon_node is available via a single nimbus command

Conceptually, the execution client and beacon node behave like libraries embedded in one program. Practically, this means One binary. One process. One data directory. One node.

Why this matters

1. Ridiculously easy to run

Don’t need to handle:
- JWT secrets
- Port juggling
- Cross-client startup ordering
- Mysterious EL ↔ CL failures
Instead just run

./nimbus

3. Smaller databases by design

Separate EL/CL setups often duplicate:
- Block data
- Metadata
- Indices
Nimbus as a single binary uses one shared data directory, reducing total storage overhead.

4. DevP2P is optional - With the right trade-offs

Block building comes first:
- When running a validator, block production typically relies on external block builders.
- In this model, a local execution-layer mempool is not required for block production.
- This makes it possible to run the execution layer with reduced or no devp2p participation once reasonably synced.
Works beyond validation - wallet and privacy use cases:
- Devp2p-less sync is also useful when running a node as a wallet / Web3 backend.
- Nimbus will still maintain access to the public mempool for transactions.
- This is one more use case for Nimbus Single Binary: privacy-focused users running a node at home without validating.
- Chain state can be queried locally without relying on third-party RPC providers.
How syncing works in this mode:
- Execution blocks can be sourced from the consensus layer (beacon node), which already stores these blocks.
- If the execution layer temporarily falls out of sync, it can recover directly from the CL database.
This is ideal for:
- Validators using external block builders
- Privacy-focused wallet / Web3 backends
- Research nodes
- Low-maintenance home setups

Syncing Ethereum with Nimbus

# Step 1: Grab a recent consensus checkpoint
./nimbus trustedNodeSync \
  --trusted-node-url=http://testing.mainnet.beacon-api.nimbus.team/ \
  --backfill=false

# Step 2: Start the node
./nimbus

What happens:

Consensus starts from a trusted checkpoint
Execution syncs via P2P
Both chains run in the same process
Disk requirement: ~500 GB (Realistically, buy a 2–4 TB SSD and forget about it.)

If you want to try it out on testnet then just add:

./nimbus --network=hoodi

Using the node:

Once running, Nimbus unified client can act as everything:

Web3 / wallet backend

./nimbus --rpc

Beacon API (for validators)

./nimbus --rest

Metrics

./nimbus --metrics

Or just enable everything

./nimbus --rpc --rest --metrics

One node which:

Wallets connect to via JSON-RPC
Validators connect to via Beacon REST
Is monitored via Prometheus

Running validators inside the same node

You can also run validators inside Nimbus itself—no external validator client required.

Import your validator keys and you’re done:

One binary
One process
One data directory
One operational surface

Why this feels special

If you ran Ethereum before the Merge, you probably remember how natural it felt. You ran one client and you were done. One process, one set of logs, one clear mental model: this machine is an Ethereum node. Things were simpler conceptually and operationally.

The Merge, which separated execution and consensus, made Ethereum more robust and future-proof. But it also changed the day-to-day experience of running a node. Ethereum became something you had to assemble: two clients, JWT secrets, ports, startup order, and subtle coordination issues. These extra points of friction could push away beginners trying to run Ethereum.

The Nimbus unified client feels special because it removes that friction without undoing the Merge.

It brings back the “one node” model
You start Nimbus, and you’re running Ethereum. You don’t need to bother about anything else, i.e configuring a separate EL or CL client.
Post-Merge correct, pre-Merge simple
Execution and consensus are still cleanly separated internally, but that complexity no longer leaks into the operator experience.
Fewer moving parts, fewer failure modes
JWT setup and IPC issues fade into the background, becoming things of the past. Fewer moving parts mean fewer things that can go wrong, and fewer issues to debug.
A shared system, not duct tape
This works because Nimbus components are library-quality. The beacon node and execution client coexist naturally in one process, sharing data and services.
Lower barrier to running Ethereum
When running a node is one binary and one command, more people do it—validators, developers, researchers, and hobbyists alike.

Nimbus doesn’t try to rewind Ethereum’s evolution. It accepts the modern architecture and wraps it in a user experience that feels whole again. The unified client proves that Ethereum can be both powerful and simple to run.

MEV and external block building

One important piece that fits naturally into this model is MEV and external block building support. Since the execution layer in this setup can already operate with minimal or no devp2p connectivity once synced, relying on external builders is a logical next step.

By sourcing blocks from builders rather than a local mempool, the node avoids the need to maintain full EL p2p participation. This further simplifies networking, reduces resource usage, and aligns well with validator-centric and infrastructure-light deployments. In other words, the execution layer becomes more of a state transition and verification engine than a gossip-heavy network participant.

This also improves resilience. If the execution layer briefly falls out of sync, it can naturally recover using data available via the consensus layer database, without requiring a full re-sync or complex recovery logic. The consensus chain remains the source of truth, and the execution layer smoothly catches up from it.

Together, external block building and tighter CL→EL recovery strengthen the “no-p2p EL” model: fewer moving parts, faster recovery, and an even cleaner single-node experience, all while staying fully compatible with modern Ethereum and the MEV ecosystem.

Enabling external block building in the Nimbus unified client

Enabling external block building support in the Nimbus unified client is very simple – you just pass the following flag additionally:

./nimbus \
    --data-dir=<> \
    --payload-builder=true \
    --payload-builder-url=<your external builder url>

And that’s all it takes to add external block building support to your Nimbus unified client.

What about client modularity ?

With the Nimbus unified client in the picture, released as a single binary, will we continue to support running clients independently? The answer is YES.

You can easily attach an external validator to the Nimbus unified client by enabling the REST API with --rest flag and connecting your preferred external validator with it.

The Nimbus unified client provides a unique interface to run Nimbus Execution Client and Nimbus Consensus Client independently from the same binary interface.

Nimbus Execution Client

./nimbus executionClient --network=<>

Nimbus Consensus Client

./nimbus beaconNode --network=<>

This interface gives the optimal balance between ease of running a unified Ethereum node and flexibility for more advanced users.

What’s next? Light clients and even leaner nodes

One of the most exciting directions for the Nimbus unified client is the ability to swap out the full consensus node for a light client module inside the same binary, offering the leanest node possible.

For users who want a trustworthy, private, self-hosted node, running a full beacon node is often more than necessary. In these cases, a consensus light client can provide the guarantees needed to safely observe the chain, verify execution data, and power a local wallet or Web3 backend while consuming only a fraction of the bandwidth and storage.

In this model:

The light client replaces the full consensus node inside the same single-binary architecture.
Execution blocks are anchored to a consensus light client, which verifies finality and canonical chain selection.
Bandwidth usage drops dramatically, making home and low-connectivity setups far more practical.

Because Nimbus is already structured as composable components, this isn’t a separate product or special mode—it’s a natural extension of the same design philosophy. Over time, this will allow users to choose exactly how much of Ethereum they want to run, from a full validator all the way down to a lightweight, self-verifying observer.

In short, Nimbus is about making every valid way of running Ethereum simpler, leaner, and more accessible.