Versioning Corrections to Blockchain Data
Correct decoded or classified blockchain records with explicit versions, preserving raw evidence and allowing consumers to distinguish a revision from a new event.
Overview
When translating these concepts into an integration, keep the scope described by the wallet history api with the result. The examples in wallet transaction history and smart contract event logs show how the same distinction affects neighbouring data questions.
A parser fix can change a derived record without creating a new blockchain event. Consumers need a way to recognise that revision so they do not count the corrected record as additional activity.
Separate event identity and revision
Keep a stable evidence identity and an interpretation version or revision marker. Record which fields changed and why. A reorganisation invalidation differs from a metadata correction or a new classification rule. These cases can share an update mechanism while retaining distinct reasons and effective evidence.
Worked example: one transfer, corrected amount
A record was displayed with the wrong decimal scale. The correction retains the same event identity, changes the derived display amount and increments the interpretation version. A consumer updates the existing derived row. Inserting a second transfer would double-count the same underlying evidence.
Plan consumer compatibility
Document whether delivery is append-only revisions, replacement snapshots or explicit change events. Test an older client that does not know a new optional field. Preserve previous revisions where audit requirements justify it. A backfill should identify corrections and avoid generating fresh business actions such as duplicate payment fulfilment merely because the parser was improved.
A practical acceptance test
Send an original interpretation and a corrected revision under the same evidence identity. The consumer should update its derived row and retain the revision reason, not count another transfer. Repeat the correction notification and verify idempotency. Business fulfilment tied to the original payment must not run again merely because its descriptive fields were corrected.
Questions about the topic
Frequently asked questions
Is a corrected interpretation a new transaction?
No. It is a revision linked to existing evidence.
Should every correction trigger fulfilment again?
No. Business side effects must remain idempotent across revisions.
Standards & technical documentation
