Event reconciliation

Trust Stack does not equate receipt.status === success with product success. A transaction may execute successfully while calling the wrong function, emitting an unexpected entity, or producing an outcome that does not match the user's reviewed intent.

Client-side reconciliation#

For each workflow, the parser:

1. selects the exact event type at the approved package and module;
2. rejects missing, duplicate, malformed, or ambiguous events;
3. canonicalizes addresses and parses integers without precision loss;
4. compares every security-relevant field with the intent snapshot;
5. returns a typed result only after all comparisons pass.

For custody flows, the client then reads the object and vault. Examples include checking that a new lock owns the funded amount, a claim is terminal, a Digital Asset's owner changed to the beneficiary, or a cancelled stream's vault equals its accrued, unclaimed beneficiary balance.

Indexer-side reconciliation#

The indexer validates the fixed event schema and cross-checks the event hash against the emission-proof leaf returned in the same configured RPC response before writing a record. This is strict application-level reconciliation of provider-returned fields, not independent verification of Merkle inclusion, an authenticated block root, or consensus finality. The original payload and normalized search dimensions remain linked to the event hash.

Failure handling#

If submission has a transaction hash but reconciliation fails:

• do not ask the user to blindly resubmit;
• show the hash and explain that outcome verification is incomplete;
• inspect the receipt in SupraScan;
• read current state by the intended object address;
• determine whether the operation finalized before constructing a recovery or retry.

This avoids duplicate value movement after a UI, RPC, or indexer error.