Aller directement au contenu principal

Supported Chains, Node Types, and Pruning Policies

Mis à jour le
Sep 01, 2026

Présentation générale​

Blockchain networks rely on nodes to maintain the integrity and functionality of the network. Nodes perform essential tasks such as validating transactions, storing blockchain data, and facilitating data access for applications and users. Quicknode provides access to nodes on over 70 blockchains, including full and archive nodes, to accommodate various use cases and operational requirements.

This document explains the differences between full and archive nodes, their data storage, and pruning policies. It lists supported chains, networks, archive mode availability, and pruning policies for each.

What is a Full Node?​

A Full Node maintains the current state of the blockchain and validates all transactions and blocks according to the network's consensus rules. Full nodes store enough data to process new transactions and build the blockchain's latest state.

Key Features of Full Nodes:​


  • Current State Data: Full nodes maintain the most up-to-date blockchain state.
  • Transaction Validation: They verify transactions and blocks before adding them to the chain.
  • Storage Requirements: Full nodes are more storage-efficient compared to archive nodes, as they do not store all historical states. However, you can still verify historical states using block data.
  • Applications: Ideal for most blockchain interactions, such as querying balances, interacting with smart contracts, and sending transactions.

What is an Archive Node?​

An Archive Node stores the complete history of the blockchain, including all historical states of accounts and contracts. This allows archive nodes to answer queries related to past states of the blockchain, which full nodes cannot.

Key Features of Archive Nodes:​


  • Complete Data: Archive nodes retain the entire blockchain history, from the genesis block to the current state.
  • Advanced Querying: They support queries for any historical block, account, or contract state.
  • Storage Requirements: Due to the large volume of data stored, archive nodes require significantly more storage and computational resources.
  • Applications: Essential for analytics, blockchain explorers, debugging tools, and compliance requirements.

What is a Pruning Policy?​

A Pruning Policy defines how a node manages and retains blockchain data. Pruning is the process of removing older blockchain data to save storage space while retaining the data necessary for current operations.

Key Features of Pruning Policies:​


  • Reduced Storage: Pruned nodes discard historical data that is no longer needed for validation or current operations.
  • Efficiency: Pruning improves storage efficiency and reduces hardware requirements.
  • Limitations: Pruned nodes cannot provide access to historical states, making them unsuitable for applications requiring full blockchain history.
  • Variations Across Chains: The implementation of pruning policies varies across blockchain networks and can depend on the chain's design and specific use cases.

Supported Chains & Networks​

Below is a table that summarizes the availability of archive nodes and pruning policies across Quicknode's supported chains and networks.

ChaîneRéseauArchivesPruning Policy
0gGalileo TestnetOuiAucun
0gMainnetOuiAucun
AbstractTestnetOuiAucun
AbstractMainnetOuiAucun
AleoMainnetOuiAucun
AptosTestnetOuiAucun
AptosMainnetOuiAucun
ArcTestnetOuiAucun
ArbitrumSepoliaOuiAucun
ArbitrumMainnetOuiAucun
ArbitrumMainnetOuiAucun
AvalancheFuji TestnetOuiAucun
AvalancheMainnetOuiAucun
AultMainnetOuiAucun
AultTestnetOuiAucun
B3SepoliaNon128 blocks of state history
B3MainnetNon128 blocks of state history
BaseSepoliaOuiAucun
BaseMainnetOuiAucun
BerachainBepolia TestnetOuiAucun
BerachainMainnetOuiAucun
BitcoinTestnetNonPruning disabled
BitcoinMainnetNonPruning disabled
BitcoinTestnetOuiAucun
BitcoinMainnetOuiAucun
BlastSepoliaOuiAucun
BlastMainnetOuiAucun
BNBTestnetOuiAucun
BNBMainnetOuiAucun
CelestiaMainnetOuiAucun
CelestiaMocha TestnetNonpruning-keep-recent = "362880"
CeloMainnetOuiAucun
CosmosMainnetOuiData available starting from cosmoshub-4 (block height 5200791); no support for cosmoshub-1/2/3
CyberSepoliaOuiAucun
CyberMainnetOuiAucun
DogeTestnetOuiAucun
DogeMainnetOuiAucun
EthereumSepoliaOuiAucun
EthereumMainnetOuiAucun
EthereumHoodiOuiAucun
FantomMainnetOuiAucun
FlareCoston2 TestnetOuiAucun
FlareMainnetOuiAucun
FlowTestnetNonRoot of current spork (epoch)
FlowMainnetNonRoot of current spork (epoch)
FluentMainnetOuiAucun
FluentTestnetOuiAucun
FraxtalMainnetOuiAucun
FuelSepoliaOuiAucun
FuelMainnetOuiAucun
GIWASepoliaOuiAucun
GravityMainnetOuiAucun
GravityAlpha MainnetOuiAucun
GnosisMainnetOuiAucun
HemiTestnetOuiAucun
HemiMainnetOuiAucun
HederaTestnetOuiAucun
HyperliquidMainnetOui/evm → Recent data only; older blocks are periodically pruned (~12 hours retention)
/nanoreth → Full historical archive with tracing support
/hypercore → HyperCore exchange layer for historical trading data, order book updates, and exchange events
Learn more about Hyperliquid endpoints here
HederaMainnetOuiAucun
ImmutableTestnetOuiAucun
ImmutableMainnetOuiAucun
InkSepoliaOuiAucun
InkMainnetOuiAucun
JOCMainnetOuiAucun
InjectiveTestnetNonpruning-keep-recent = "1832727" and pruning-interval = "16"
InjectiveMainnetNonpruning-keep-recent = "1832727" and pruning-interval = "16"
KaiaKairos TestnetOuiAucun
KatanaMainnetOuiAucun
KaiaMainnetOuiAucun
LineaMainnetOuiAucun
LiskMainnetOuiAucun
LitecoinMainnetOuiAucun
LitecoinTestnetOuiAucun
MantleSepoliaOuiAucun
MantleMainnetOuiAucun
MegaETHMainnetNonBlock and transaction data retained indefinitely. Receipt data retained ~15 days in database but also persisted in static files. Historical state queries (eth_call, eth_getBalance at past blocks) limited to ~15-day / 1,296,064-block pruning window. En savoir plus
MocaTestnetNonpruning-keep-recent = "550000" and pruning-interval = "16"
ModeMainnetOuiAucun
MonadTestnetOuiOver 40,000 recent blocks available
MonadMainnetOuiOver 40,000 recent blocks available
MorphHoodiOuiAucun
MorphMainnetOuiAucun
NEARTestnetOuiAucun
NEARMainnetOuiAucun
OptimismSepoliaOuiAucun
OptimismMainnetOuiAucun
OsmosisMainnetOuiAucun
PeaqMainnetOuiAucun
PlasmaTestnetOuiAucun
PlasmaMainnetOuiAucun
PolkadotMainnetOuiAucun
PolygonTestnet AmoyOuiAucun
PolygonMainnetOuiAucun
RobinhoodMainnetOuiAucun
RobinhoodTestnetOuiAucun
SaharaTestnetOuiAucun
ScrollMainnetOuiAucun
SeiAtlantic TestnetNon3240000 blocks
SeiPacific MainnetOuiAucun
SolanaDevnetNon6578505 slots
SolanaTestnetNon10964176 slots
SolanaMainnetOuiAucun
SolanaAlpenglow TestnetNonbest-effort — not guaranteed. History may reset to near-zero after node maintenance/upgrades or the cluster's periodic re-genesis.
SoneiumMainnetOuiAucun
SonicMainnetOuiAucun
StacksTestnetOuiAucun
StacksMainnetOuiAucun
StarknetSepoliaOuiAucun
StarknetMainnetOuiAucun
StellarTestnetNonHorizon: ~1.43M ledgers (~90 days) & Stellar RPC: 17280 ledgers (~1 days)
StellarMainnetNonHorizon: ~1.5M ledgers (~90 days) & Stellar RPC: 120,960 ledgers (~7 days)
DATAAeneid TestnetOuiAucun
DATAMainnetOuiAucun
SuiMainnetYes (gRPC only)Full nodes: 14 epochs. Older data automatically routed to archive nodes
SuiTestnetNonFull nodes: 14 epochs
TempoMainnetOuiAucun
TempoTestnetOuiAucun
TRONNile TestnetOuiAucun
TRONMainnetOuiAucun
TONMainnetOuiAucun
UnichainSepoliaOuiAucun
UnichainMainnetOuiAucun
VanaMokshaOuiAucun
VanaMainnetOuiAucun
World ChainSepoliaOuiAucun
World ChainMainnetOuiAucun
X LayerMainnetOuiAucun
X LayerTestnetOuiAucun
XRP LedgerTestnetOuiFull history after recent network reset
XRP LedgerMainnetOuiStarts from ledger 32570 (Genesis)
XRPL EVMTestnetOuiAucun
XRPL EVMMainnetOuiAucun
ZcashMainnetNonPruning disabled
ZcashTestnetNonPruning disabled
ZKSyncSepoliaOuiAucun
ZKSyncMainnetOuiAucun
ZoraMainnetOuiAucun
Dernière mise à jour sur