Corrections, reorgs and finality

An event records an observation. Later evidence can change its assessment without deleting the earlier notification from delivered history.

An execution in an orphaned block

1. Apply fill.execution for occurrence A.
2. Receive canonicality.changed marking A orphaned.
3. Update the canonical projection of A and its executions, preserving observation history.
4. If the transaction is included in block B, process its new occurrence separately.

Revert is different: the transaction failed within its block and creates no executions. transaction.reverted is not a synonym for reorg. depth_confirmed is also distinct from chain_finalized.

Corrections can retain the event type

Later evidence can refine an execution’s relation to an intent. The event type remains fill.execution, with a new revision and correctionOf. Compare identities and assessments, not only eventType. Do not add each updated amount to volume.

Filtered subscriptions

Necessary invalidations can arrive even when the requested stage list excludes the correction stage. This keeps an accepted projection from retaining a known invalid fact while respecting its entitlement.

If the correction target is absent locally, record the correction without inventing an execution or applying an absent effect. A limited filter or late start can explain the absence. Resolve an incomplete local state through agreed replay or operator assistance.

Deduplicate notifications and finish correction processing before ACKing the covering checkpoint. See processing, event reference and recovery.