--prune.mode blocks with --snap.keepblocks still prunes old block RPC access after snapshot sync

[dbu9]

Summary

I am running Erigon v3.4.4 on Ethereum mainnet with:

--prune.mode blocks
--prune.distance.blocks 0
--fcu.background.prune=false
--snap.keepblocks

According to erigon --help, --prune.mode blocks should keep all blocks but not historical state:

blocks: Keep all blocks but not the state history

However, after starting from a completely clean datadir, Erigon initially serves block 0x0, but after some time during snapshot sync / pruning, the same RPC call fails with:

old data not available due to pruning: requested block 0, history is available from block 25247999

This makes --prune.mode blocks unusable for applications that need historical block/transaction indexing, such as Blockbook.

Version

erigon version 3.4.4-5da2eae7
git_branch=release/3.4
git_tag=v3.4.4-dirty
git_commit=5da2eae7f6fc2ea7f296a5a960d262749f3546a4

Startup command

/opt/coins/nodes/ethereum/erigon \
  --chain mainnet \
  --snap.keepblocks \
  --db.size.limit 15TB \
  --db.pagesize 16KB \
  --prune.mode blocks \
  --prune.distance.blocks 0 \
  --fcu.background.prune=false \
  --externalcl \
  --nat none \
  --datadir /opt/coins/data/ethereum/backend/erigon \
  --port 38336 \
  --ws \
  --ws.port 8036 \
  --http \
  --http.port 8036 \
  --http.addr 127.0.0.1 \
  --http.corsdomain "*" \
  --http.vhosts "*" \
  --http.api "eth,net,web3,debug,txpool" \
  --authrpc.port 8536 \
  --private.api.addr "" \
  --torrent.port 8136 \
  --log.dir.path /opt/coins/data/ethereum/backend \
  --log.dir.prefix ethereum

The live process was verified from /proc/$pid/cmdline and contained the same flags.

Reproduction steps

1. Stop Erigon.
2. Empty the datadir completely:

find /opt/coins/data/ethereum/backend/erigon -mindepth 1 -maxdepth 1 -exec rm -rf -- {} +

3. Restore only jwt.hex.
4. Start Erigon with the command above.
5. Wait for snapshot download to begin.
6. Test block 0x0 repeatedly:

curl -s -X POST http://127.0.0.1:8036 \
  -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["0x0",false],"id":1}' | jq

Observed behavior

At first, block 0x0 is available:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "number": "0x0",
    "hash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3"
  }
}

Later, without changing flags or restarting with a different config, the same request fails:

old data not available due to pruning: requested block 0, history is available from block 25247999

The watchdog output:

=== Tue Jun 23 02:44:38 AM UTC 2026 ===
--- block 0 ---
0x0

=== Tue Jun 23 02:54:38 AM UTC 2026 ===
--- block 0 ---
0x0

=== Tue Jun 23 03:04:38 AM UTC 2026 ===
--- block 0 ---
old data not available due to pruning: requested block 0, history is available from block 25247999

Snapshot download log around the run

[Downloader] Syncing remaining snapshots time-left=1h10m32s time-elapsed=1m55s file-metadata=1719/1719 files=342/1719 data="2.71% - 45.5GB/1.6TB" hashing-rate=2.5GB/s webseed-download=238.8MB/s peer-download=157.2MB/s peers=85 conns=357

[Downloader] Syncing remaining snapshots time-left=1h3m9s time-elapsed=3m47s file-metadata=1719/1719 files=342/1719 data="5.40% - 90.9GB/1.6TB" hashing-rate=2.3GB/s webseed-download=185.3MB/s peer-download=245.5MB/s peers=124 conns=595

Expected behavior

With:

--prune.mode blocks
--prune.distance.blocks 0
--snap.keepblocks

Erigon should continue serving old historical blocks through eth_getBlockByNumber, including block 0x0.

I understand that historical state may be unavailable in blocks mode. That is expected. But historical block bodies / transactions should remain available if the mode description says “Keep all blocks but not the state history.”

Actual behavior

Historical block RPC access becomes unavailable and Erigon reports only a recent history boundary:

history is available from block 25247999

This looks like old block history is being pruned despite --prune.mode blocks.

Question

Is this expected behavior for --prune.mode blocks in Erigon v3.4.4?

If yes, what is the correct mode/flag combination for keeping all historical block bodies, transactions, receipts, and logs, but not full historical state?

If no, this appears to be a bug where blocks mode still prunes old block RPC access after snapshot sync/pruning.

Pruning:

405 txnum=3602879883 age=3s execution=129ms alloc=9.2GB sys=26.9GB
[DBUG] [06-23|12:46:50.400] [6/6 Finish] prune done                  in=5.287µs
[DBUG] [06-23|12:46:50.400] [5/6 TxLookup] prune done                in=3.207µs
[DBUG] [06-23|12:46:50.403] [4/6 Execution] prune done               in=2.519084ms
[DBUG] [06-23|12:46:50.403] [3/6 Senders] prune done                 in=2.717µs
[DBUG] [06-23|12:46:50.403] [2/6 BlockHashes] prune done             in=1.475µs
[DBUG] [06-23|12:46:50.403] [1/6 OtterSync] prune done               in=13.966µs
[INFO] [06-23|12:46:50.404] Timings: Forkchoice Prune                prune=3ms initialCycle=false alloc=9.2GB sys=26.9GB
[DBUG] [06-23|12:46:59.817] Execution ForkValidator.ValidatePayload  foundCanonical=true currentHash=0xf48e433871cedb8976c98cc7a75e3f734c165b38568059ad3bd65d745ddcbe59 unwindPoint=25380405
[DBUG] [06-23|12:46:59.818] [warmBody] TX worker finished            worker=4 txns=21 elapsed=996.511µs
[DBUG] [06-23|12:46:59.818] [warmBody] TX worker finished            worker=1 txns=21 elapsed=1.343188ms
[DBUG] [06-23|12:46:59.818] [warmBody] TX worker finished            worker=6 txns=21 elapsed=1.221089ms
[DBUG] [06-23|12:46:59.819] [warmBody] TX worker finished            worker=2 txns=21 elapsed=1.294011ms
[DBUG] [06-23|12:46:59.819] [warmBody] TX worker finished            worker=0 txns=21 elapsed=1.73928ms
[DBUG] [06-23|12:46:59.819] [warmBody] TX worker finished            worker=5 txns=21 elapsed=1.56527ms
[DBUG] [06-23|12:46:59.819] [warmBody] TX worker finished            worker=7 txns=19 elapsed=1.855022ms
[DBUG] [06-23|12:46:59.819] [warmBody] TX worker finished            worker=3 txns=21 elapsed=1.664522ms
[DBUG] [06-23|12:46:59.820] [4/5 Senders] Recovery done              from=25380406 to=25380406 blocks=1 took=2.325409ms
[INFO] [06-23|12:47:00.208] head validated                           hash=0x77eb2720c37e6d52c7011a1da7f7c21b147b114d2023be77d608cf1952991577 number=25380406 age=1s execution=75ms mgas/s=111.97 avg mgas/s=127.85 alloc=9.3GB sys=26.9GB
[DBUG] [06-23|12:47:00.221] [2/6 BlockHashes] DONE                   in=3.146µs
[DBUG] [06-23|12:47:00.228] [3/6 Senders] Recovery done              from=25380406 to=25380406 blocks=1 took=6.226533ms
[DBUG] [06-23|12:47:00.228] [3/6 Senders] DONE                       in=6.294371ms
[DBUG] [06-23|12:47:00.228] [4/6 Execution] DONE                     in=114.557µs
[INFO] [06-23|12:47:00.228] [snapshots] holding state collation at block snapshot boundary step=9222 stepEndTxNum="3602734375 (step 9223)" blockSnapshotsTxNum="3602701138 (step 9222)"
[DBUG] [06-23|12:47:00.242] [5/6 TxLookup] DONE                      in=13.913929ms
[DBUG] [06-23|12:47:00.242] [6/6 Finish] DONE                        in=14.286µs
[DBUG] [06-23|12:47:00.242] head updated                             hash=0x77eb2720c37e6d52c7011a1da7f7c21b147b114d2023be77d608cf1952991577 number=25380406 txnum=3602880051 age=1s execution=75ms alloc=9.3GB sys=26.9GB
[DBUG] [06-23|12:47:00.507] [6/6 Finish] prune done                  in=6.788µs
[DBUG] [06-23|12:47:00.507] [5/6 TxLookup] prune done                in=3.779µs
[DBUG] [06-23|12:47:00.509] [4/6 Execution] prune done               in=2.532506ms
[DBUG] [06-23|12:47:00.509] [3/6 Senders] prune done                 in=2.935µs
[DBUG] [06-23|12:47:00.509] [2/6 BlockHashes] prune done             in=1.377µs
[DBUG] [06-23|12:47:00.509] [1/6 OtterSync] prune done               in=17.78µs
[INFO] [06-23|12:47:00.510] Timings: Forkchoice Prune                prune=3ms initialCycle=false alloc=9.3GB sys=26.9GB

[dbu9]

Additional version testing results.

I tested several Erigon versions with the same goal: keep historical block RPC access in --prune.mode blocks while avoiding archive mode.

Common flags used for the 3.4.x tests:

--snap.keepblocks
--prune.mode blocks
--prune.distance.blocks 0
--fcu.background.prune=false

Datadir was cleaned between tests.

v3.3.10

This is the version bundled with the Blockbook Ethereum backend:

erigon version 3.3.10-e7de183d

Result: it does not reach the later pruning problem because it gets stuck during OtterSync/snapshot download around:

file-metadata=293/309
files=293/309
data=13.4GB
webseed-download=0B/s
peer-download=0B/s
hashing-rate=0B/s
time-left=∞

Restarting did not resolve it.

v3.3.8

I also tested v3.3.8.

Result: same general failure pattern as v3.3.10. It gets stuck around the same OtterSync point:

file-metadata=293/309
files=293/309
data=13.4GB
webseed-download=0B/s
peer-download=0B/s
hashing-rate=0B/s
time-left=∞

So the 3.3.x line appears to have an old snapshot/OtterSync availability problem in this setup.

v3.4.0

erigon/v3.4.0-ab501fc7/linux-amd64/go1.25.9

This version downloads snapshots successfully. It passes the old 3.3.x stuck point and completes remaining snapshot download.

During/after snapshot download, old block RPC access initially works:

0        -> 0x0
1        -> 0x1
1000000  -> 0xf4240
10000000 -> 0x989680
15537393 -> 0xed14f1
20000000 -> 0x1312d00

But later, without changing flags, historical block RPC access disappears:

0        -> old data not available due to pruning: requested block 0, history is available from block 25270999
1        -> old data not available due to pruning: requested block 1, history is available from block 25270999
1000000  -> old data not available due to pruning: requested block 1000000, history is available from block 25270999
10000000 -> old data not available due to pruning: requested block 10000000, history is available from block 25270999
15537393 -> old data not available due to pruning: requested block 15537393, history is available from block 25270999
20000000 -> old data not available due to pruning: requested block 20000000, history is available from block 25270999

So v3.4.0 behaves like v3.4.4: it downloads snapshots successfully, but old block history becomes unavailable later despite --prune.mode blocks.

v3.4.4

erigon version 3.4.4-5da2eae7

Same basic result as v3.4.0.

With a clean datadir and the flags:

--snap.keepblocks
--prune.mode blocks
--prune.distance.blocks 0
--fcu.background.prune=false

block 0x0 is initially available, but later RPC returns:

old data not available due to pruning: requested block 0, history is available from block 25247999

or a similar recent boundary.

Summary

Test matrix:

v3.3.10 -> stuck during OtterSync around 293/309, 13.4GB
v3.3.8  -> stuck during OtterSync around 293/309, 13.4GB
v3.4.0  -> downloads successfully, then old block RPC history is pruned/unavailable
v3.4.4  -> downloads successfully, then old block RPC history is pruned/unavailable

This makes --prune.mode blocks unusable for a full historical block/transaction indexer such as Blockbook in these tested versions.

The key question remains:

Is there a supported Erigon mode/flag combination that keeps all historical block bodies/transactions/receipts/logs available through RPC, but does not keep full historical state?

Based on the help text:

blocks: Keep all blocks but not the state history

I expected old eth_getBlockByNumber requests to keep working in --prune.mode blocks, but in 3.4.x they stop working after later sync/pruning activity.

[Sahil-4555]

The root cause is identified and a fix is submitted in PR #21984.

The issue is in the RPC layer, not in pruning or snapshots. Uncle endpoints (eth_getUncleByBlockNumberAndIndex, eth_getUncleByBlockHashAndIndex, eth_getUncleCountByBlockNumber, eth_getUncleCountByBlockHash) were using checkPruneHistory, which gates on state history availability (p.History). In --prune.mode blocks, state history is pruned but block data is set to KeepAllBlocksPruneMode - so all blocks are physically present. The function was rejecting valid requests by comparing against the wrong pruning boundary.

The fix replaces checkPruneHistory with checkPruneBlocks (which gates on p.Blocks) in these 4 uncle endpoints, aligning them with the block and transaction endpoints in eth_block.go and eth_txs.go that were already corrected.

Details in the PR description.

[VBulikov]

yperbasis added Imp1 as Importance

[Metavcl]

For operators, I think a small RPC acceptance script would be very useful here.

After snapshot sync / pruning, the script could sample genesis, mid-history, and recent blocks, then verify eth_getBlockByNumber, tx lookup, receipts, logs, and the uncle endpoints against the expected pruning mode. That would catch cases where data is physically present but the RPC layer rejects it with the wrong history boundary.

I’d keep trace_* checks separate though. In --prune.mode blocks, historical state is not expected to be retained, so trace capability should probably be treated as an archive-mode requirement, not part of the blocks-mode contract.

For production backfill/indexing systems, it also helps to compare the same checks against a known-good archive RPC, for example BlockPI, so operators can quickly distinguish an Erigon RPC-layer issue from real missing history while upgrading to the fixed release.

[yperbasis]

Thank you @Metavcl. I've created a follow-up issue #22260.