Bake-off results — the raw data

Sequential testing isolates each candidate on a shared semi-prod host. No MEV; no validator keys. Execution clients (ELs) process transactions. Consensus clients (CLs) track the beacon chain. A shared JWT secret authenticates their connection.

All 12 pairs passed triage. Prysm’s el_offline checks EL reachability and Engine API authentication. False throughout means correct JWT wiring and EL payload validation. restErr counts brief beacon REST outages during heavy-client startup; see Resource contention.

• erigon — PASS; re-check in Stage B. Head froze at checkpoint slot 14615808 while sync_distance grew 71→97 over 5 min. el_offline=false throughout confirms Engine API reachability and authentication. Beacon-P2P backfill explains this benign warmup, rather than an EL handshake defect. Verify advancing head over Stage B’s longer window.
• reth alone needed EL installer fixes. It omitted --authrpc.jwtsecret for the shared secret from ensure_jwt_secret. Prysm used a non-shared auto-JWT: 401 errors froze head, with early el_offline=True. Two commits wired the shared JWT; el_offline flipped True→False. HTTP-RPC was also enabled on 127.0.0.1 for monitoring/consumers, matching other ELs.
• besu / nimbus_eth1 / ethrex passed cleanly without fixes. JWT wiring worked out of the box. ethrex finalized (finalizedEpoch=456756). nimbus_eth1 also syncs historical EL blocks from genesis in the background, independently of its immediately working Engine API.

Startup contention caused brief REST outages, without blocking checkpoint sync. Non-geth ELs and lodestar left Prysm’s beacon REST unavailable for 1–3 minutes (restErr above), then it recovered. CPU/IO competition with co-resident agents fits this shared-host behavior. This is the headline risk for Stage B: multi-day, IO-heavy syncs compete with co-resident workloads. Execution strategy must account for it when choosing sequential runs or small parallel batches.

Successful sync can still leave operational limits. besu risks stalled snap sync; ethrex has history and restart limits. reth/nimbus_eth1 exceeded the time cap; erigon deadlocked.

Stage B uses each EL’s most disk- and time-efficient available sync mode. We audited before starting slow full-sync runs to avoid accidental archive comparisons. geth’s --history.chain postmerge triggered the audit: it saves disk by pruning pre-merge block history. We verified it on the baseline, then checked every other EL.

All seven ELs now use disk-optimal sync settings. Six were already correct; only archive-by-default reth changed. Configuration comparisons are therefore equivalent. Sync time still differs: full-sync ELs execute all ~25M blocks, unlike geth’s snap baseline. Final footprint remains comparable.

Every candidate has a final verdict: synced, capped, or no-sync. Runs were sequential. Footprint means EL + CL datadir size, excluding secrets/validator material; capped and no-sync rows are partial.

Full post-merge history converges at ~1.0–1.2 TiB. History retention sets size across clients. ethrex and minimal-history nethermind are smaller only because they retain no history, not because they’re leaner. Choose on snap-sync speed and restart-resume; see recommendations.

nimbus_eth1

~40 GiB · partial · ~21.6%, full-sync-only

nethermind (minimal, default)

~265 GiB · synced · no history

ethrex

~475 GiB · synced · no history

reth

~980 GiB · partial · projected ~1.1–1.2 TiB

besu

~1080 GiB · synced

nethermind (full-history)

~1088 GiB · synced

geth

~1130 GiB · synced · baseline

erigon

~1210 GiB · no-sync · frozen partial

“Synced” and “settled” can have different sizes. nethermind’s pre-backfill ~251 GiB was not final. ethrex’s mid-climb ~467 GiB did not prove continuing growth. Both fresh and steady measurements appear below where available; missing phases are explicit.

nethermind

~251 GiB fresh → ~1,088 GiB steady (full-history)

ethrex

~286 GiB fresh → ~475 GiB steady (no-history plateau)

The same three CL tiers appear on every execution anchor. We held the EL constant and cycled CLs: ethrex first, already at tip, saving a multi-day re-sync; then geth and nethermind cross-checks. Each CL footprint is under ~1.1% of its anchor’s EL datadir. Engine API decoupling means anchor choice does not bias the comparison. Every EL datadir stayed untouched at tip; runs cycled only CL and validator keys.

All five CLs reached a fully validating head on every anchor, without crashes. Sync took ~22–23 min on ethrex, already at tip, versus ~6–10 min on fresh geth/nethermind. Time tracks anchor freshness, rather than CL choice, so footprint is the real differentiator. Figures below are decimal MB/GB.

Disk ranking, smallest → largest:

• Ethrex anchor: lighthouse (773 MB) < lodestar (868 MB) < grandine (~992 MB) < teku (2,161 MB) < nimbus (5,302 MB)
• Geth anchor: lodestar (185 MB) < lighthouse (542 MB) < grandine (~760 MB) < teku (977 MB) < nimbus (1,198 MB)
• Nethermind anchor: lodestar (186 MB) < lighthouse (492 MB) < grandine (~765 MB) < teku (875 MB) < nimbus (1,338 MB)

Cross-anchor verdict — the tiers reproduce, not an identical order:

• nimbus is the largest CL on all three anchors — the one ranking that holds without exception.
• {lodestar, lighthouse} are smallest on every anchor. lighthouse wins on ethrex; lodestar wins on geth/nethermind. Within-tier order depends on measurement time.
• {teku, grandine} form the middle tier. teku’s ~700 → 875 MB nethermind readings cross grandine’s ~765 MB. Taking the clean re-read as authoritative, grandine < teku holds on all three anchors. That pair’s order is measurement-sensitive, not a stable client property.
• Observation time affects absolute size. geth/nethermind sweeps measured minutes after checkpoint-sync; ethrex ran longer. Hence nimbus ~1.2–1.3 GB vs ~5.3 GB. Tiers hold; exact within-tier order does not.
• Three anchors reproduce three tiers: lightweight {lodestar, lighthouse}, mid {teku, grandine}, heavy {nimbus}. This supports EL/CL decoupling without an identical total order.

The tier story across anchors

Lodestar

~868 / 185 / 186 MB (ethrex / geth / nethermind anchor)

Lighthouse

~773 / 542 / 492 MB (ethrex / geth / nethermind anchor)

Grandine

~992 / 760 / 765 MB (ethrex / geth / nethermind anchor)

Teku

~2161 / 977 / 875 MB (ethrex / geth / nethermind anchor)

Nimbus

~5302 / 1198 / 1338 MB (ethrex / geth / nethermind anchor)

Live probes: 2026-07-29/30, our synced ethrex v22.0.0 node. Head advanced between probes.

Usable from the sync point onward. Earlier blocks are unavailable. The boundary is when you synced, rather than “wallet vs DeFi”.

Current-state DeFi reads work: swap quotes, balances, allowances, and pool state. Every frontend method tested at latest passed: eth_call, eth_getCode, eth_getStorageAt, eth_estimateGas, eth_getBalance, eth_getTransactionCount, eth_gasPrice, eth_feeHistory, eth_maxPriorityFeePerGas, web3_clientVersion, net_version. eth_sendRawTransaction exists and validates input: malformed input returned Invalid params: InvalidLength.

Every dapp read worked for a recent deployment. At head ~25,646,566, we tested a real contract-creation transaction 17 blocks back: block 25,646,549, tx 0xc909b51c…, contract 0x227efd38ef38a798ae5ec9af062c437ee4bbef35. eth_getCode returned 8,043 bytes of bytecode. eth_getStorageAt, eth_getTransactionByHash, eth_getTransactionReceipt, and eth_getLogs from deploy block to latest also worked.

ethrex can serve a dapp frontend for a contract deployed today, including current-state reads.

Every pre-merge probe returns null:

History starts exactly at the snap-sync pivot. pivot−1 (25,634,444) returned null; pivot+0 (25,634,445) was served. At this earlier probe, head ~25,639,228, the window held 4,783 blocks (~16h). It grows forward but never backfills.

Historical state is roughly the last ~128 blocks (~25 minutes). eth_call succeeds at head−100; head−500 fails: Vm execution error: DB error: state root missing for block N. Older “balance at block X” requests fail.

Consequently broken:

• Indexer/subgraph backfill
• Portfolio history
• Tax and accounting exports
• Historical charts
• "Show me my transaction from last month"
• Any analytics that replays past logs

eth_getLogs requires topics. Omitting it returns Expected parameter: topics is missing; geth treats it as optional. Conformant tooling can fail even inside ethrex’s served window.

The shipped nginx/Caddy RPC setup inherits these limits. geth with --history.chain postmerge serves post-merge history. ethrex handles current-state/wallet traffic but returns null/errors outside its history window. If exposing an endpoint is the goal, that’s an independent reason to prefer geth or nethermind. ethrex is not a drop-in public RPC for users expecting history.

ethrex’s ~470–476 GiB plateau is not a disk win. The ~600 GiB difference is history other clients retain. Footprint tracks retention.

geth and nethermind clear the durability bar. All 12 pairs installed, checkpoint-synced, and passed Stage A; full-history disk sizes converge. Restarts, upgrades, and weeks of uptime separate them. ELs carry the operational risk. CLs look solved only for measured sync and footprint; only prysm was restart-tested.

EL summary; CL guidance and caveats follow.

• History retention sets disk size. Full-history ELs converge at ~1.0–1.2 TiB: geth 1.13, nethermind ~1.06, besu 1.08, reth ~1.1–1.2 projected. Update 2026-08-03: nethermind ships minimal-history by default, staying at ~250–280 GiB, state only. Pre-sync blocks return null, like ethrex. For public RPC history, set NETHERMIND_FULL_HISTORY=true on a fresh datadir. Its no-history size beats ethrex’s ~470 GiB and reaches a floor geth cannot. Calling it “4× leaner than geth” would compare unlike history settings. With history retained, choose on snap speed and restart-resume.
• geth and nethermind both reached validating tip and resumed cleanly. They are the two most battle-tested codebases here, with comparable full-history disk (~1.06 vs ~1.13 TiB). geth offers the largest ecosystem, conservative default, and cleanest ~8h28m snap. nethermind offers diversity and compact flat-storage state. Every tested gap from 12 min to ~35h resumed through ordinary import, without re-snap or cliff. Either supports long-running operation.
• besu is a viable enterprise third. It fully validated; ~1.08 TiB is the same magnitude as geth/nethermind: comparable, not an outlier. A prolonged CL outage can age its snap pivot beyond servable state. The sync thread then dies, observed twice and unrecoverable. Keep the CL current; this is not a set-and-forget solo-staker choice.
• Each remaining EL missed a specific operational requirement:
  • ethrex syncs fastest (~2h16m), but 26-minute downtime stalled; 1.5–2h gaps triggered full re-snap. Its datadir settles at ~470–476 GiB, rather than growing unbounded. It is smaller only because it retains no history, not because it’s leaner. nethermind’s ~226–230 GiB state is smaller, though different encodings prevent a perfectly controlled comparison. Fast setup remains painful to operate without restart recovery. This young client moved v19.0.0 → v22.0.0 during the campaign and may improve.
  • reth, nimbus_eth1 cannot reach tip practically on this host: full-sync-only, no snap. This misses our snap-to-tip bar; it is not a universal client verdict. reth is widely run elsewhere.
  • erigon — deadlocked against checkpoint-synced prysm on this host (structural, reproducible), so no synced datadir.
• Stage-A note: geth, besu, nimbus_eth1, ethrex passed Stage A with zero installer changes and zero REST contention — the cleanest out-of-the-box ELs against Prysm.

Every swept CL worked: lighthouse, lodestar, grandine, teku, nimbus. All checkpoint-synced to validating head in ~22–23 min without crashes. Within measured sync/footprint, choose by size and preference; only prysm has resume evidence.

• Disk order (the only differentiator): on ethrex, lighthouse (~773 MB) < lodestar (~868 MB) < grandine (~992 MB with --prune-storage) < teku (~2,161 MB) < nimbus (~5,302 MB). Recommended: lighthouse, ~22-min checkpoint-sync, blob pruning enabled by default. lodestar is smaller on geth/nethermind, down to ~185 MB.
• Size teku’s JVM heap generously: undersizing caused GC pressure on co-resident services and invalidated the first run. Enable grandine --prune-storage, or every state is stored. nimbus is otherwise clean but heaviest, ~6.9× lighthouse.
• Keep the CL binary current. Stale prysm v7.1.5 stalled ~28h on a PeerDAS/data-column bug, aging out besu’s pivot. Binary freshness is an operational requirement.

Choose geth or nethermind for long-running EL operation; besu qualifies where operators keep the CL healthy. Any swept CL works on measured axes; lighthouse is the lean default. Initial speed and size alone do not prove durability across restarts and uptime. That deciding risk sits in the EL layer.

Verify EL progress and restart recovery, even when RPC answers. Dates and measured thresholds follow by theme.

Across six weeks and 12 pairs, sync speed and restart recovery separated clients. Disk size reflected history settings.

• Disk converges, it doesn’t rank: ~1.0–1.2 TiB for full-history ELs (geth 1.13, nethermind ~1.06, besu 1.08, reth ~1.1–1.2 projected). Minimal-history nethermind (~250–280 GiB default) and ethrex (~470–476 GiB plateau) are smaller because they retain no history, not because they’re leaner.
• Speed has a real order: ethrex (~2h16m) < geth (~8h28m) < nethermind (~14.5h) < besu (~19h18m). reth and nimbus_eth1 never reached tip in the 72h cap (full-sync-only), and erigon deadlocked entirely against a checkpoint-synced CL.
• Restart-resume decides. geth and nethermind imported missed blocks cleanly across tested gaps: 12 min up to ~52h/~35h. Neither re-snapped. ethrex stalled past ~25 min/~128 blocks; ~1.5–2h gaps triggered re-snap near scratch. besu’s snap sync deadlocks if a CL outage ages its pivot out of the ~128-block servable-state window.
• Pick geth or nethermind for long-running nodes; besu qualifies for enterprise operators keeping the CL current. Any swept CL works, with lighthouse the lean default. ethrex’s fastest cold sync cannot offset its restart cliff and missing history: watch, rather than deploy, today.

Read next

• Ethereum client bake-off
• How we tested with Claude
• The bake-off harness

Sources

• Raw results doc (CLIENT_BAKEOFF_RESULTS.md)