Addressing State Archival Inconsistencies: Protocol Upgrade Vote Next Week

On October 9, SDF discovered a bug within Stellar's first of its kind state archival feature. Stellar's archival feature archives unused state for later restoration. The feature solves the blockchain scalability problem by preventing state bloat and keeping fees low. The bug, found in Whisk (Protocol 23) which the network upgraded to on September 3, 2025, resulted in outdated entries being archived and then restored incorrectly, producing state that did not match the canonical onchain history.

Once identified, teams immediately conducted an assessment, and made a proposal to update network settings to temporarily pause eviction of archived state, or the removal of unused data from active storage on the Stellar blockchain. Tier 1 validators voted to accept the change, which prevented additional writing of corrupted entries. On October 10, SDF put out a patch release of Stellar Core that blocked all transactions attempting to read or write values from corrupted entries, effectively quarantining the erroneous state. Within a few hours, all Tier-1 validators upgraded to that patch release.

To understand the scope of the impact, SDF analyzed and reviewed what happened onchain from when the bug was introduced to when validators picked up the patch release that quarantined it, and identified every protocol and asset contract that was affected. The bug impacted a limited subset of Stellar smart contract entries — 478, to be exact. Before the quarantine was put into place, 84 corrupted entries were restored and incorporated into the live ledger state and 77 of those entries were actually modified; the remaining 394 were not restored. No other ledger entries from the remaining ~47m were affected. Here is an example of how the bug functioned:

1. Entry E has balance of 10 at ledger n
2. E receives a payment of 15 at ledger n + 1, new balance is 25
3. E is “archived”, but outdated version n is archived with balance 10
4. E is later restored, but with outdated value n. Ledger records balance E as 10 instead of 25

A permanent fix will require a new protocol version, which will involve a validator vote to upgrade the network.

Over the past week, Tier 1 validators, impacted organizations, and community members were consulted to explore potential solutions. Informed by that feedback and analysis, a viable technical fix has been identified, and Tier 1 validators have expressed their intention to support it in an upcoming official network vote.

The proposed solution would return entries corrupted during the archival process to their pre-archival state, but only entries that were never restored after being archived. Since these entries were never observed by any transaction, reverting them poses minimal risk. This approach would fix the majority of impacted entries (394 out of 478). The small subset of entries not addressed by the protocol upgrade would be resolved on a case-by-case basis by the impacted organization. You can review the full technical details in the Core Advancement Proposal (CAP) that lays out the change with instructions on how to audit the proposed changes yourself.

Importantly, nothing is final until validators vote, which will happen next week. Only then will we know if this fix will be incorporated into the Stellar protocol. Because of the time-sensitive nature of this issue, we’ve placed this CAP in its final public comment period starting today, and it will remain in that state until the validator vote. We strongly encourage everyone in the ecosystem to review the proposal and provide feedback on the developer mailing list before the vote takes place.

* Monday October 20 – stable releases for Stellar Core, RPC, Horizon

* Tuesday October 21 17:00 UTC – Testnet upgrade

* Wednesday October 22 17:00 UTC – Mainnet upgrade vote. If ratified by validators, the network will upgrade immediately to Protocol 24. All infrastructure that does not run Protocol-24-compatible software will lose sync with the network.

It’s important that Stellar's transaction history remains immutable. The fix will realign internal databases with corrected values, but only for corrupted data that was never used or observed by any transactions. All transactions recorded on Stellar will remain in the permanent ledger exactly as they occurred. No transactions will be retroactively changed or removed. History remains immutable.