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 is empty.

Indexer-side reconciliation

The indexer independently validates the fixed event schema and Supra emission proof before writing a record. 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.