XGRChain v2.1.0 introduces State Growth Control, an optional node-level capability designed to reduce the long-term accumulation of obsolete historical EVM state while a node remains online.
The feature is implemented as an Online State Trie Sweeper. When enabled, it can reclaim unreachable historical trie and contract-code data without changing the current canonical chain state used for execution and consensus.
Why state growth matters for long-running nodes
Blockchain scalability is not only a question of transactions per second. Infrastructure also has to remain practical after a network has been operating for years.
Without a retention policy, historical versions of EVM state can continue to accumulate locally. For validator and infrastructure operators, that can translate into steadily increasing storage requirements even when much of that historical state is no longer required for normal validation of the current chain.
XGRChain v2.1.0 addresses that operational problem at the node level. Operators can decide whether a node should retain archive-style historical state or use a bounded retention policy suited to normal validator and infrastructure operation.
Online State Trie Sweeping
When State Growth Control is enabled, the node periodically works from a configurable recent range of canonical state roots.
The sweeper identifies trie nodes and contract code that remain reachable from the retained roots and can reclaim data that is no longer reachable.
The process is designed for live operation. A node can perform sweep cycles while remaining online, and the implementation performs a strict post-sweep integrity check against a freshly captured canonical state root.
State Growth Control is disabled by default and configured independently on each node. Operators decide whether to enable it and how much historical state their node should retain.
No consensus change and no hardfork
State Growth Control is a local storage policy rather than a protocol transition.
XGRChain v2.1.0 does not require a consensus fork, activation block, genesis replacement, transaction-format change, state-transition change, staking change or validator-set change for this feature.
Validator operators can therefore upgrade the node software and decide separately whether to enable the trie sweeper.
Nodes that require archive-style historical state can keep the sweeper disabled or configure a retention policy appropriate to that requirement.
Canonical history remains available
State Growth Control affects historical EVM state, not the canonical block history.
Reclaiming old trie state does not remove:
- canonical block headers
- canonical block bodies
- transactions
- receipts
- logs
The distinction is historical state access.
After sufficiently old trie state has been reclaimed, historical state-dependent RPC requests such as old balances, contract code, storage or historical eth_call execution are not guaranteed to remain locally available.
Operators that require arbitrary historical-state access should therefore retain an archive-oriented configuration.
Leaner validator infrastructure
For normal validator operation, this creates a path to lower long-term storage pressure without requiring every validator node to operate as a full archive node.
Archive nodes can continue to retain full historical state where that capability is actually required.
The retention policy remains an operator decision rather than a network-wide consensus rule.
Infrastructure scalability beyond TPS
XGRChain v2.1.0 was published as the current public node release on 28 August 2026.
State Growth Control and the Online State Trie Sweeper are part of that release baseline and are documented for validator, RPC and infrastructure operators.
The broader goal is straightforward: as XGRChain continues to run, node operation should remain sustainable not only in execution throughput, but also in the amount of historical state each operator is required to keep locally.
This is infrastructure scalability beyond TPS.