Question: `--full` snapshot preset selects `Since block 0` for transactions on Base mainnet (docs mention a 31-day retention window)

[alan-eth]

Hi team — first of all, thanks a lot for the detailed v1.2.0 release notes and the new download command. The modular snapshot selection is really nice to work with.

We're preparing the Storage V2 migration for a pruned (non-archive) Base mainnet node and ran into something we'd like to double-check before committing to a maintenance window. We may well be misreading this, so apologies in advance if we've misunderstood.

What the docs say

The snapshots page FAQ states:

Base's full snapshot uses a 31-day retention window, differing from Reth's standard 10,064-block preset.

Based on that, we planned to use --full and expected roughly a 31-day history window.

What we observed

Running base-reth-node download --chain base --full -y (v1.2.0, on a clean data directory), the command reports this selection plan:

INFO Loaded snapshot manifest block=48987727 chain_id=8453 storage_version=2 components=8
INFO Queued component for download component=State (mdbx)        archives=1  selection=All
INFO Queued component for download component=Headers             archives=98 selection=All
INFO Queued component for download component=Transactions        archives=98 selection=Since block 0
INFO Queued component for download component=Receipts            archives=1  selection=Last 10064 blocks
INFO Queued component for download component=Account Changesets  archives=1  selection=Last 10064 blocks
INFO Queued component for download component=Storage Changesets  archives=1  selection=Last 10064 blocks
INFO Downloading all archives archives=200 download_total=1725.22 GB output_total=3075.11 GB

So on Base mainnet, --full appears to select:

• Transactions: the entire history (Since block 0, all 98 archives, ~1.14 TB compressed)
• Receipts / Account Changesets / Storage Changesets: Last 10064 blocks (≈5.6 hours), which looks like exactly the Reth 10,064-block preset the docs say Base differs from

For comparison, an explicit component selection on the same snapshot:

$ base-reth-node download --chain base \
    --with-txs-distance 2678400 --with-receipts-distance 2678400 \
    --with-state-history-distance 2678400 -y

INFO Queued component for download component=Transactions        archives=6 selection=Last 2678400 blocks
INFO Queued component for download component=Receipts            archives=6 selection=Last 2678400 blocks
INFO Queued component for download component=Account Changesets  archives=6 selection=Last 2678400 blocks
INFO Queued component for download component=Storage Changesets  archives=6 selection=Last 2678400 blocks
INFO Downloading all archives archives=123 download_total=846.96 GB output_total=1426.52 GB

	--full	explicit --with-*-distance 2678400
archives	200	123
download	1725.22 GB	846.96 GB
extracted	3075.11 GB	1426.52 GB
transactions	all 98 archives	6 archives
receipts / changesets	1 archive (10,064 blocks)	6 archives

Our (possibly wrong) reading of why

Tracing through the code, full_selection_for_component() in Reth's download command resolves Transactions via full_bodies_history_use_pre_merge (default true), which maps to Since(<Paris activation block>). Base sets Paris to block 0:

// base/base: crates/execution/chainspec/src/spec.rs
// We set the paris upgrade for Base networks to zero
EthereumHardfork::Paris.boxed(),
ForkCondition::TTD { activation_block_number: 0, ... }

ForkCondition::block_number() returns Some(activation_block_number) for the TTD variant, so Since(0) ends up meaning "everything". That heuristic makes sense for L1 (skip pre-merge bodies), but on an L2 where Paris is pinned at 0 it seems to degenerate into "download the full transaction history".

Receipts / changesets fall back to Distance(MINIMUM_UNWIND_SAFE_DISTANCE) = 32 * 2 + 10_000 = 10,064.

Questions

1. Is the 31-day figure in the docs still accurate for v1.2.0's --full? Or does it describe the older V1 pruned snapshots rather than the new modular preset?
2. Is Transactions = Since block 0 intended for Base under --full, given Paris is pinned at block 0? If not intended, would a Base-specific override of the full-preset defaults make sense?
3. For full/pruned (non-archive) operators who want an N-day window, is explicit --with-*-distance the recommended approach going forward? We noticed two things worth confirming:
   • --with-senders has requires = with_txs, so it can't be combined with --with-txs-distance — is running without downloaded senders (recovering them from signatures at runtime) the expected setup?
   • Not selecting rocksdb_indices means the indices are rebuilt locally on first start. Is that the recommended path for pruned nodes, or is downloading them preferred when disk allows?

This matters a fair amount for us because --full would land ~3.0 TB (nearly filling our 4.5 TB data volume) while giving a shorter receipts/history window than our current pruned node, so we want to make sure we're choosing correctly before the mid-August deadline.

Thanks again for all the work on this — happy to provide more logs or test anything if it helps.

Environment

base/node       v1.2.0
base-reth-node  1.2.0
chain           base (mainnet)
manifest        https://mainnet-v2-snapshots.base.org/1784764806/manifest.json (block 48987727, storage_version 2, profile archive)
host            AWS EC2 i7ie.2xlarge, Amazon Linux 2023, Docker

---