Reconciling Stellar Events

The Whisk protocol release launched Stellar Events (specified by CAP-67), which allowed everyone to easily track all token movements across the Stellar network. The recent state archival issue caused some Stellar Events to be omitted when they should have been emitted in the network’s ledger metadata.

Stellar Core v24.1.0, which was released on 11/11/2025, will guarantee that anyone replaying the history of the network from genesis will have a full and complete picture of all token movements that happened on the network, fulfilling the original promise of Stellar Events. However, operators that were already live and operational when the issue was present on the network missed these events between Protocol 23 (ledger sequence 58762517) and Protocol 24 (ledger sequence 59501299).

The recommendation varies depending on the specific infrastructure product that you run.

Galexie

Operators that host a Galexie Data Lake (S3 or GCS) should plan to re-export all ledgers that occurred between Protocols 23 and 24 in order to ensure that they have a complete history of all Stellar Events that occurred on the network.

The Galexie v24.1.0 release added a new replace feature in order to ease this process. It enables you to overwrite existing files in your data lake seamlessly and without downtime, like so:

$ galexie replace --start 58762517 --end 59501299

This job will take roughly 80 hours to run on the recommended hardware. It’s possible to parallelize this if you’d like to expedite the process.

Horizon

Operators hosting Horizon that set any of the following configuration values should consider ingesting history between Protocols 23 and 24 in order to ensure a complete history of all Stellar Events that occurred on the network.

• SKIP_TXMETA = false
• EMIT_CLASSIC_EVENTS = true
• BACKFILL_STELLAR_ASSET_EVENTS = true

Note that if you do not explicitly set either of these values in your configuration, then the default behavior is that you do not need to take any action.

Should you identify that you do need to reingest the history in your Horizon database, it can be done like so:

• Check HISTORY_RETENTION_COUNT to ensure that you’ll be at least retaining enough ledgers to reach back ledger sequence 58762517
• Stop your live Horizon instance; reingestion cannot be performed at the same time as live ingestion. For this reason, it is best to perform this process offline or on a standby/secondary instance.
• Perform the reingestion. If desired, this command can be parallelized.

$ stellar-horizon db reingest range 58762517 59501299

• Restart your live Horizon instance.

Stellar RPC

The default historical retention window for RPC is 7 days. As such, all Stellar Events that weren’t emitted in real-time have already occurred outside of RPC’s retention window. Therefore, it is not recommended that RPC operators take any action.

Providers may consider expanding their offering to include an archival RPC node, as the consumer demand to reingest historical data may increase given this issue.

If you’ve been consuming Stellar Events since the launch of Protocol 23, it is advised that you audit the list of ledger keys which were affected by the restoration bug. This list is relatively small, so there’s a good chance that even if you are consuming Stellar Events, you will still be unaffected by this issue.

Assuming you have determined that you do need to consume the Stellar Events related to the affected ledger keys, your remediation will depend on where you are consuming those events from. Regardless of the source, be sure to confirm with your infrastructure provider that they have already performed the necessary reingestion on their end.

Galexie

It is recommended that you re-download all historical ledger metadata between Protocols 23 and 24 and identify any events which were previously missed by your ingestion system.

Stellar RPC

RPC retains only 7 days of historical data, so all of the omitted events are already beyond the point in time that RPC would have available. There are a couple options to get historical data via RPC:

• Find an RPC provider that provides an archive RPC
• Run RPC locally and proxy it to a provider that exposes a public Data Lake

Using this archival RPC instance, pull historical ledger metadata between Protocols 23 and 24 and identify any events which were previously missed by your ingestion system. Note that historical support on archive RPC’s is limited to the getLedgers endpoint.

Horizon

No action is necessary, as Horizon does not expose Stellar Events in transaction meta by default.

If you have custom-configured a self-hosted Horizon instance to expose events with either of the two configurations noted above, then you should re-query for all ledger metadata between Protocols 23 and 24, via whichever endpoint you are currently fetching that data. Note that SDF Horizon (horizon.stellar.org) does not expose Stellar Events and thus will take no action as a result of this release.

Hubble

If you use or mirror the public BigQuery analytics dataset, you will need to reprocess any analytics pipelines containing data from Protocol 23 to Protocol 24. SDF will reingest and overwrite the data in Hubble; downstream consumers will be responsible for reconciling their own downstream pipelines from BigQuery.

Reach out on the Hubble Discord with any questions or concerns.

Third Party Indexers or Analytics Providers

Reach out directly to your providers to get a timeline of the availability of the complete data set. They will be following remediation steps recommended by SDF for operators (above) and thus may need some time before data is available for consumption by their customers.