Reading Astar and Shiden Catch-up Logs Without Overreacting

Astar and Shiden catch-up logs are easy to misread. The node prints parachain progress and relaychain progress in the same stream, but those two parts do different work. During the first long sync, one side can look healthy while the other still looks strange.

The log line that causes the most anxiety is usually this one:

[Parachain] Syncing 240.0 bps, target=#15173806, best: #3057834, finalized #0
[Relaychain] Syncing 325.6 bps, target=#34075714, best: #6517931, finalized #6517760

finalized #0 on the parachain side looks bad. In early catch-up, it is not enough by itself to call the node broken. The better question is whether best keeps moving, whether peers stay connected, and whether the relaychain side keeps finalizing.

Terms used here

Term	Meaning
Parachain	A chain connected to a relay chain in the Polkadot ecosystem. Astar and Shiden are parachains.
Relaychain	The chain that provides shared consensus and finality for parachains.
Collator	A parachain node role that produces candidate blocks for the relaychain validators.
Archive node	A node that keeps historical state for old block, storage, and RPC queries.
Full node	A node that can follow the network but prunes old finalized data after a configured window.
Warp sync	A relaychain sync mode that prioritizes finality proofs and state so the relay side becomes usable faster.
Frontier	The Ethereum-compatible layer used by Substrate EVM chains for Ethereum-style RPC data.

Start from the official split: full node, collator, archive RPC

The Astar docs separate these roles. The full-node page says a full node prunes old finalized blocks by default and that operators who need old historical data should use an archive node instead ^[1].

The collator guide uses pruned settings such as --state-pruning 1000 and --blocks-pruning 1000, then tells operators to wait until the node is fully synchronized before moving to the next steps ^[2]. That is a collator-oriented setup, not an archive RPC endpoint.

For an archive RPC node, the node command reference switches to:

--state-pruning archive
--rpc-methods Safe
--sync warp

The same reference also notes that EVM RPC methods require an extra flag when those methods are needed ^[3]. That distinction matters. If the operational goal is historical RPC, a pruned collator command and an archive RPC command are different starting points.

What each log field tells you

For the catch-up line, read the fields in this order:

Field	Operational meaning
`Parachain`	The Astar or Shiden chain itself. This is the height most application-facing RPC users care about.
`Relaychain`	The relay network being followed under the parachain. It can sync and finalize at a different speed.
`bps`	Blocks per second for that part of the sync loop. It will fluctuate.
`target`	The head height the node currently believes it should reach.
`best`	The best block the node has imported locally.
`finalized`	The finalized block known to that side of the client. During catch-up it can lag badly.
`peers`	Connected peers. Non-zero peers do not guarantee speed, but zero peers is a real problem.

Healthy catch-up looks like movement, not perfection. If parachain best rises every sample and relaychain finalized rises too, the node is doing useful work even when parachain finalized is still #0.

Why `finalized #0` can stay there

Astar and Shiden finality comes through the relaychain. While a node is importing old parachain blocks quickly, the parachain log can keep printing an early finalized value. That is especially visible when the relaychain has already found finalized blocks but the parachain side is still rebuilding its view.

I treat finalized #0 as a warning only when it comes with other bad signals:

Situation	Decision
`best` rises, `target` rises slowly, peers stay connected	Keep observing.
relaychain `finalized` rises but parachain `finalized` stays `#0` during early catch-up	Usually still acceptable.
`best` stops for many samples while peers are low or zero	Investigate P2P, bootnodes, firewall, or client health.
`best` is near `target`, `eth_syncing` or Substrate sync says done, but parachain finality never moves	Investigate client state and version.

The first hour of a node is the wrong time to judge finality from one field. Look for trend.

Bootnodes help discovery; they do not import blocks for you

Bootnodes are useful when a node needs help finding peers. They are less useful once the node already has a stable peer set.

The practical rule:

Low or unstable peers -> check bootnodes, P2P port, listen address, firewall.
Stable peers but low bps -> look at CPU, disk I/O, memory, client version, and chain stage.

A node can have 15 peers and still import slowly. That is not a contradiction. Peer discovery and block execution are different bottlenecks.

Warp sync and snapshots

The snapshot page says database snapshots are generally discouraged and that syncing from scratch is the normal best practice. It also says archive snapshots are available for Astar and Shiden from a third-party provider, but those are archive snapshots and do not work for pruned nodes ^[4].

For the relaychain side, the same page points to --sync warp. The important detail is that this is about the relaychain path. Warp sync makes the relay side useful faster by prioritizing finality proofs and state. It does not remove the parachain database work.

There is also a GitHub issue worth remembering: Astar issue #1110 reported warp sync triggering OOM after state download in an older context ^[5]. That does not mean warp sync should never be used. It means memory should be watched during startup, especially after a client or dependency change.

Version choice is part of sync behavior

The Astar README explains a release-process change from v5.45.0: client releases and runtime releases are split ^[6]. For node operators, that makes floating latest a poor default. The client version is an operational input.

For v5.49.2, the release notes mark the upgrade priority as critical and include a fix for RPC node gap resync with slot-based Aura ^[7]. The linked PR #1638 says it bumps Polkadot SDK dependencies and fixes RPC node gap syncing ^[8].

That is the reason I prefer an explicit client tag over latest. If sync behavior changes, I want to know which binary changed.

The checks I would run

For a Docker-based node, I would avoid destructive commands and sample these first:

docker logs --tail=200 <container>
df -h /data
free -h
uptime

For RPC readiness:

curl -s http://127.0.0.1:9944 \
  -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"system_syncState","params":[]}'

For EVM RPC, only test it after the EVM RPC flag is enabled and the endpoint is intentionally exposed to the right network boundary. The official docs treat EVM RPC as opt-in, and public RPC should still be behind a deliberate access policy.

My operational read

When Astar or Shiden prints fast best movement, stable peers, and relaychain finalization, the node is catching up. finalized #0 on the parachain line is a thing to watch, not a reason to restart by itself.

I would intervene only when the trends change:

peer count collapses,
best stops moving,
disk or memory pressure appears,
RPC stays unavailable after the client has caught up,
or the node is on a client version known to have sync or RPC gaps.

Until then, the boring answer is the right one: keep the node running, keep metrics on it, and judge by progress over time.