0x16d0682b16d0…16d06828
XRP Ledger Will Wipe Testnet and Devnet Data on Nov. 25
XRP Ledger will reset Testnet and Devnet on Nov. 25 after its only full-history Testnet server failed, wiping accounts, balances and escrows. Mainnet runs unchanged.

Outputs
XRP Ledger resets Testnet and Devnet on Nov. 25 after a server failure.
The reset erases accounts, transactions, balances, offers, AMMs, settings and escrows on both networks.
Mainnet is unaffected; URLs, Network ID and validator settings stay the same.
Testnet's only full history server failed and could not be recovered.
Server storage capacity will increase to reduce future reset frequency.
The XRP Ledger will reset its Testnet and Devnet environments on Nov. 25, erasing all stored data after the only full-history Testnet server failed and could not be recovered without rebuilding its environment. Mainnet, the production network, will continue running normally, and key connection details will remain unchanged.
The reset will clear accounts, transactions, balances, offers, automated market makers, settings, escrows and other ledger data from both testing networks. The XRP Ledger team attributed the decision to the loss of Testnet's sole full history server, which left operators no recovery path short of resetting the environment.
What stays intact after the reset?
Mainnet data is untouched by the operation. The URLs, Network ID and validator configurations that servers use to reach Testnet and Devnet will also stay the same, which limits the reconfiguration work operators face.
The two testing networks serve distinct roles. Testnet is designed to closely mirror Mainnet's amendment status, and the project will restore that alignment with Mainnet after the reset completes. Devnet functions as a preview environment for proposed and upcoming protocol features, so its cleared state will track future changes rather than production parity.
What must developers and server operators do?
The reset imposes concrete operational tasks on anyone building against either network:
- Developers who rely on stored data must recreate accounts, balances and other ledger objects from scratch.
- They must request fresh test XRP from the faucet to fund recreated accounts.
- Operators running xrpld servers connected to Testnet or Devnet should delete their local database data and restart their servers after the reset.
The project plans to increase Testnet's server storage capacity following the reset, aiming to reduce the frequency of future resets. Some data-retention limits will remain in place even after the upgrade, according to the announcement.
Why does the failure matter for tooling?
The loss of a single full history server exposes a structural fragility in the testing infrastructure: one machine held the complete record, and its failure forced an environment-wide wipe. That is a narrower failure mode than a validator outage, which the ledger's consensus design tolerates through redundancy. Developers who treat Testnet history as durable reference data now face a rebuild, though the fix — larger storage allocations — suggests the team expects longer retention windows going forward.
For teams with CI pipelines, faucets-dependent test suites or long-lived escrow simulations on either network, Nov. 25 marks a hard cutoff. Anything not recreated after the reset will simply not exist on the testing networks, and the project has signaled that periodic resets, while less frequent, remain part of Testnet's operating model.
via tokenpost.com (Source)
More from Tom Whitfield
Show full bio
News editor covering technology and product news in crypto and web3 industry at Mempool Brief.
893 articles