What Erigon3 Is Doing After Startup

When an Erigon3 node starts, a running process is only the first signal. The node enters a staged synchronization workflow: it downloads or uses snapshots, prepares history data, executes blocks, computes trie-related data, maintains P2P peers, and, on Polygon, keeps pulling Heimdall-side data.

So the right way to read Erigon3 logs is to look across subsystems, not to stare at one log line in isolation. A common example is:

[4/6 Execution][agg] computing trie progress=159.82k/1.92M

This can look like the node is stuck at computing trie. In practice, it means the node is doing aggregation and trie work inside the Execution stage. If progress keeps moving and P2P, Heimdall, and memory signals are still healthy, this line alone is not enough to call the node broken.

Terms used here

Term	Meaning
Staged sync	Erigon’s synchronization model that splits work into stages such as headers, bodies, execution, and index generation.
Snapshot	Immutable data files Erigon can download or reuse instead of rebuilding all history from live peers.
Execution	The stage that replays blocks and updates state according to chain rules.
Trie	State data structure used to verify and access account/storage state. Trie-related work can be expensive.
P2P peer	Another node connected through the peer-to-peer network. Peers provide blocks and network data.
Heimdall	Polygon’s checkpoint/consensus-side service that Bor/Erigon uses for Polygon-specific data.

Confirm the key defaults first

One major difference between Erigon3 and Erigon2 is the default node mode. The official README says Erigon3 defaults to a Full Node. If you need an Archive Node, you must explicitly set --prune.mode=archive. For a small-disk validator scenario, minimal is another option. This setting should not be changed casually after the first startup ^[1].

Before reading startup logs, confirm three things:

Whether the node is meant to run as full, archive, or minimal.
Whether the data directory is being initialized for the first time.
Whether the target chain is correct.

For Polygon Mainnet, the chain parameter is:

--chain=bor-mainnet

If the node is intended to serve as a Polygon archive node, --prune.mode=archive should be present from the first startup, not added after the node has already synced for a while.

What happens inside datadir

Much of Erigon3 startup is about preparing and maintaining the data directory. The official README describes the structure roughly like this ^[2]:

datadir
  chaindata
  snapshots
    domain
    history
    idx
    accessor
  txpool
  nodes
  temp

You can read these directories by responsibility:

Path	Purpose
`chaindata`	Recent latest state, recent history, and recent blocks.
`snapshots/domain`	Immutable snapshot data related to latest state.
`snapshots/history`	Historical values.
`snapshots/idx`	Inverted indices for logs, traces, and historical queries.
`snapshots/accessor`	Accessors for random reads over history.
`txpool`	Pending transaction data, usually safe to delete.
`nodes`	P2P peer data, usually safe to delete.
`temp`	External sorting buffer for data larger than memory; cleaned at startup.

This explains why startup can produce heavy disk and memory pressure. Erigon3 is downloading blocks while it prepares state, history, indices, and temporary sort data.

Why Erigon3 is not replaying everything from zero

Erigon3 initial sync is not the old model of executing every block from genesis to the chain head. The official README says Erigon3 downloads most of the Latest State and History during initial sync. Compared with Erigon2, much more data is stored in immutable files, also described as segments or snapshots ^[3].

That changes how operators should reason about progress:

Sync speed cannot be understood only as “which block is currently executing.”
Snapshot download, validation, and index generation are part of startup.
chaindata is not the only home for historical data; much of it lives under snapshots.
Restarting usually does not lose too much stage progress because Erigon3 limits the block count processed by each sync loop by default ^[3].

So high disk IO, rising memory, or a slow Execution stage early in startup does not automatically mean the node is misconfigured.

The main line of Staged Sync

Erigon’s Staged Sync documentation explains why synchronization is split into stages: stage boundaries make the work easier to optimize, analyze, and debug than mixing every task concurrently ^[4].

The early stages described by the documentation include:

Stage	Responsibility
Stage 1: Headers	Pull block headers from peers, decode them, and write them to the database.
Stage 2: Block Hashes	Write the block hash to block number mapping from headers.
Stage 3: Bodies	Download, validate, compress, and write block bodies.
Execution / Trie	Execute blocks, process state changes, and compute trie or aggregation data.

This log line:

[4/6 Execution][agg] computing trie

means the node has reached the Execution line of work and is computing state-related data. The agg marker means this work includes aggregation structures and trie work, not plain transaction execution alone. For archive nodes or nodes with heavy historical query requirements, this stage can be expensive by design.

How to read real startup logs

The referenced log fragment contains several signal types. They should be read together.

The first signal is Execution progress:

[4/6 Execution][agg] computing trie progress=159.82k/1.92M
[4/6 Execution][agg] computing trie progress=780.65k/1.92M

The key point is that progress is increasing. Even if it is slow, the Execution stage is not fully stopped.

The second signal is P2P:

[p2p] GoodPeers eth68=66 eth69=66

The node has stable usable peers. When sync is slow but peer count looks healthy, P2P is not the first thing to blame.

The third signal is the Polygon Heimdall scraper:

[bor.heimdall] scraper progress name=milestones
[bor.heimdall] scraper progress name=checkpoints
[bor.heimdall] scraper progress name=spans

Polygon nodes need Bor and Heimdall-side data. If milestones, checkpoints, and spans keep advancing, Heimdall scraping is still working.

The fourth signal is bridge events:

[bridge] fetched new events periodic progress count=1

Bridge event fetching is still alive. Not every Polygon-related scraper has stopped.

The fifth signal is memory:

[mem] memory stats Rss=101.3GB Pss=101.3GB alloc=24.9GB sys=64.0GB

Separate Go runtime alloc and sys from process RSS. Erigon3 can show high RSS during snapshot, index, and Execution work. Operationally, the important questions are whether RSS keeps approaching the machine limit, whether swap is involved, and whether progress stops at the same time.

The logs may also show Heimdall 503 responses:

service unavailable: url='https://heimdall-api.polygon.technology/...', status=503

This has to be judged over time. If scraper progress appears again later, this is more likely a transient remote Heimdall API issue than a local Erigon failure.

Do not misjudge before startup settles

Erigon3 health should not be judged from one line. A better check combines these signals:

Signal	Healthy pattern
Execution	`progress` keeps increasing, even slowly.
P2P	`GoodPeers` stays at a reasonable count.
Heimdall	`milestones`, `checkpoints`, and `spans` continue to progress.
bridge	Event fetching does not remain fully stopped for a long time.
memory	RSS is high but does not keep hitting the machine limit or rely on swap for long periods.
disk IO	IO continues without long-term 100% await or queue saturation.

The node enters troubleshooting territory when several signals degrade together:

Execution progress stops completely for a long time.
P2P peers disappear or stay very low.
Heimdall API errors keep repeating with no later progress.
RSS keeps approaching the machine limit and swap rises.
Disk latency is extremely high and Execution barely moves.

computing trie alone does not indicate failure. Treat it as healthy work while Execution continues to advance and P2P, Heimdall, memory, and disk IO remain stable.