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.