An Archived Dusk Event Can Describe a State Change That Never Happened
A backend can read an event from Dusk’s finalized archive and still make the wrong financial decision.
Since Boreas became active on mainnet at restart block 4,414,095, Dusk deliberately retains reverted contract events in archive data with a reverted marker. Those events are historical evidence that execution produced them—not proof that their state effects survived.
Post-Boreas, reverted events are excluded from the canonical block bloom, and reverted stake events do not update provisioner state.
That distinction matters wherever events become database mutations. An indexer that treats “event exists” as “operation succeeded” can credit a deposit, record a payout, or trigger downstream logic for state the chain rolled back.
Dusk’s own Moonlight deposit guidance makes the rule explicit: a direct deposit is accepted only when the transfer event matches the expected operation and event.reverted === false.
So finalization answers one question: is this archived history settled? It does not erase the need to interpret what that history says.
For Dusk integrations after Boreas, reverted is not metadata to ignore. It is part of the acceptance condition separating historical execution evidence from canonical state.
@Dusk $DUSK #dusk
A backend can read an event from Dusk’s finalized archive and still make the wrong financial decision.
Since Boreas became active on mainnet at restart block 4,414,095, Dusk deliberately retains reverted contract events in archive data with a reverted marker. Those events are historical evidence that execution produced them—not proof that their state effects survived.
Post-Boreas, reverted events are excluded from the canonical block bloom, and reverted stake events do not update provisioner state.
That distinction matters wherever events become database mutations. An indexer that treats “event exists” as “operation succeeded” can credit a deposit, record a payout, or trigger downstream logic for state the chain rolled back.
Dusk’s own Moonlight deposit guidance makes the rule explicit: a direct deposit is accepted only when the transfer event matches the expected operation and event.reverted === false.
So finalization answers one question: is this archived history settled? It does not erase the need to interpret what that history says.
For Dusk integrations after Boreas, reverted is not metadata to ignore. It is part of the acceptance condition separating historical execution evidence from canonical state.
@Dusk $DUSK #dusk
