Stellar events: retroactive events

When Protocol 23 rolls out later this year, CAP-67 won’t just start emitting events for new ledgers. It can also generate events for past ledgers if configured to do so. That means any provider who wants a truly complete unified events stream must re-ingest full history with two new core flags enabled.

This is an atypical protocol upgrade: P23 has the ability to emit new event data in the TransactionMeta for past ledgers. If your service or tooling stores full Stellar history for end-users, be it wallets, exchanges, analytics platforms or custom indexers, you’ll need to opt in; otherwise you’ll miss all the classic operation movements that happened before P23.

configs to support two new flags. By default, both flags are off. Operators must explicitly opt in:

yaml

```

# in your stellar-core.cfg or stellar-core.conf

# add classic operations into the unified stream

EMIT_CLASSIC_EVENTS: true

# generate new events for all historical ledgers

BACKFILL_STELLAR_ASSET_EVENTS: true

```

• EMIT_CLASSIC_EVENTS
  When true, two new types of events are emitted: fee events and classic-operation token movements (payments, path payments, clawbacks, etc). The fee event covers all transaction fees charged, including Soroban transactions and refunds. No fee events are emitted unless this flag is set, not even for Soroban transactions.These events will be added to the event stream going forward (from P23 upgrade onward).
• BACKFILL_STELLAR_ASSET_EVENTS
  When true, Core will emit new events for all past ledgers (genesis → present), allowing you to fill any gaps in your historical event feed. The operator will need to trigger the backfill; the flag just allows core to create new data for past ledgers.

Note: Protocol 23 introduces a new version of TransactionMeta XDR, TransactionMetaV4. If you operate an RPC node, Horizon or Galexie, support for the new meta version will be included with the protocol upgrade.

Your Three Upgrade Paths

Note: Option 3 unlocks the ability to accurately compute account balances, circulating supply, and other token analytics, but it requires full-history re-ingestion.

Benefits

• Complete analytics: historical balances, supply metrics, audit trails
• Uniform API: one event schema for every token movement, past and future
• Better UX: wallets, exchanges and dApps all get a consistent history

Costs / Trade-offs

• Growth in DB size: Stellar RPC with EMIT_CLASSIC_EVENTS=true saw a DB size increase by ~2.5 GB per day. For RPCs with a 7-day retention window, this is ~10% increase in size
• Growth in Analytics Storage: Full events storage uncompressed is ~7TB
• CPU and RAM performance hits are negligible and will not require resizing infrastructure components

1. Review your user base: if you serve wallets, exchanges, dApps, or analytics platforms that track token flows, supporting a full history of Classic Events is strongly recommended.
2. Update your Core/Galaxie/RPC P23-compatible node images to configure these flags.
3. Plan a full‐history re-ingestion if you need complete past data.

That way, your unified events feed will truly cover every mint, transfer, burn and clawback operation, even the pre-P23 classic operations.

For more on CAP-67’s overall design see Stellar Events: Track All the Things, and for full P23 release details, check out the Protocol 23 Announcement and corresponding Upgrade Guide.