Node types
Frost nodes differ along two independent axes: what role they play in consensus, and how much history they retain. A node picks one of each.
Validator
Section titled “Validator”Participates in consensus. A validator’s frost-node process runs three
components — a consensus authority, an execution driver, and an ingress — and
drives a separate execution-layer process over the Engine API.
It proposes and signs consensus blocks, drives its execution layer over the
forced-transaction Engine API, and accepts user submissions. Validators are the
only nodes that can accept eth_sendRawTransaction. They also serve the
observer stream followers subscribe to and, when configured, the checkpoint
bootstrap endpoints a joining node uses.
Membership is by committee. See Keys and committee.
Follower
Section titled “Follower”Does not participate in consensus. A follower streams the committed order from a validator’s observer endpoint and drives its own execution layer to the identical chain.
The observer stream is allowlisted: a validator only completes the handshake
for a follower whose ML-DSA-65 network key is on its observer_allowlist, and
the consensus snapshot a joining follower restores requires the fleet’s bearer
token. Following the public fleet therefore means being admitted by its
operators. On a network you run yourself, you control both.
It produces byte-identical blocks and state roots, so it is a fully verifying node — it simply has no vote. Followers are the right choice for serving RPC, running an explorer or indexer, or independently checking what the validators agreed.
Followers cannot accept transaction submissions.
History tiers
Section titled “History tiers”Post-quantum signatures make storage a first-order cost — a frame transaction is about 90% signature bytes — so no node holds everything, and the fleet deliberately holds different amounts. Names follow Ethereum’s where the concept matches.
| Tier | Holds | Closest Ethereum equivalent |
|---|---|---|
| pruned | Full header chain back to genesis, a rolling recent-block window of bodies and receipts, and current state. | Full node with EIP-4444 history expiry. |
| tx-history | Full header chain, signature-stripped transaction bodies, receipts and the txid index back to genesis — all provable — plus current state. Witness sidecars pruned below a rolling window. On frost-reth the stripped bodies live in a compressed store, so the tier is markedly smaller than on 8141-geth. | No equivalent. This tier exists because of witness segregation. |
| full-history | Everything, including ML-DSA signature sidecars, plus current state. | Full node. |
| state-archive | All historical state — eth_call and storage queries at any height. |
Archive node. |
The tx-history tier is the interesting one and is Frost’s own contribution.
Because each block header commits to a strippedTransactionsRoot, a node can
discard multi-kilobyte witnesses and still serve every historical transaction
with a proof. You lose the signature bytes, not the ability to prove what
happened. See Witness segregation.
What is live today. No node in the fleet keeps full witnesses. The
exporting host runs tx-history with a long sidecar window whose pruning is
gated on verified upload to the cold archive; complete history lives in that
archive and in an archive node restored from it. A fresh node joins on the
pruned tier through checkpoint bootstrap — its snap-sync pivot becomes its
history cutoff — and can restore deeper history from the archive with
frost-archiver restore-el. The tx-history and full-history tiers need bodies
back to genesis, which only an archive restore now provides.
Ask any node what it holds:
curl -s <node-rpc> -H 'content-type: application/json' \ --data '{"jsonrpc":"2.0","id":1,"method":"frost_historyStatus","params":[]}'Retention windows
Section titled “Retention windows”State and history are pruned on independent windows, because they grow differently — history grows unconditionally and linearly, state only on net-new accounts and storage slots. The bulk post-quantum cost is history.
Execution layer. --frost.history.retention W sets the block window, and
each client refuses to start below its floor. On 8141-geth the floor is the
freezer’s immutability threshold (FullImmutabilityThreshold, 90,000 blocks):
if the freeze boundary ever lagged the head, that many blocks would be held back
in the key-value store, and a window at least that large keeps the degraded case
no worse than the normal one. On frost-reth the floor is reth’s own unwind-safe
prune distance, re-derived for reth’s storage layout.
A separate sidecar window prunes witness bytes only. A sidecar can never outlive its block body, so where both are set the shorter one wins — and the tx-history tier is precisely “the sidecar knob alone”.
Consensus layer. consensus_retention prunes the consensus store below a
window of commits. Three further mechanisms bound it. A byte clamp
(max_bytes) raises the prune floor when the retained window’s live bytes
exceed a budget — block bytes scale with load, so a commit count sized for
ordinary traffic can fill a disk during a campaign. Under the clamp sits a
commit floor (min_commits) that it may never cut past, so a node absent
for less than that re-joins by commit sync. And a disk guard
(disk_reserve_bytes): when free space on the store’s filesystem falls below
the reserve, the commit floor collapses to the recovery replay reach and the
node prunes to the byte floor, loudly, so the disk survives.
One thing is never pruned: the commit spine, the hash-linked record running back to genesis. It is roughly 1% of the consensus layer by volume — a few hundred bytes per commit instead of tens of kilobytes of signed DAG blocks — so keeping all of it is cheap, and it is what makes everything else verifiable.
Pruning is also clamped by runtime floors: consumer progress, the latest certified checkpoint, the durable-execution floor, and the verified-upload floor on hosts that export to archive. The pruner never cuts past any of them — the disk guard included.
Cold archive
Section titled “Cold archive”Beyond the node tiers, certified consensus segments and full-witness block groups are exported to S3-compatible object storage. Data is hash-verified against the chain’s own commitments before anything may be pruned locally.
The storage is treated as untrusted: a provider that corrupts or loses data is detected rather than believed. A state-archive node is rebuilt from this export by replaying full-witness blocks in archive mode.
Choosing
Section titled “Choosing”| You want to | Run |
|---|---|
| Participate in consensus | Validator, pruned — joined by checkpoint bootstrap |
| Serve RPC to an application | Follower, pruned |
| Verify the chain independently, cheaply | Follower, pruned |
Run an explorer or indexer, or answer historical eth_call |
An archive node restored from the cold archive with frost-archiver restore-el |
A new node reaches the pruned tier from the network and the archive tiers from the cold archive; there is no live peer to sync a tx-history or full-history node from.
A follower gives you full verification without committee membership, and is the right default for anyone who wants their own trustworthy view of the chain.