How Trust Stack works — Trust Stack Docs

Every value-bearing Trust Stack workflow follows the same lifecycle. The product keeps each phase visible so a user can tell the difference between a form submission, a wallet authorization, a finalized transaction, and an RPC-reconciled result.

1. Build a typed intent#

The form validates human input such as addresses, token amounts, UTC timestamps, URLs, and Merkle proofs. Every date and time is entered in UTC through the shared date-time picker: a calendar with year and month selectors plus a 24-hour time field, so the stored value does not depend on the browser's time zone. Decimal token amounts are converted to integer base units without JavaScript floating-point math. Review screens show the network, asset, recipient, amount, policy, and retained authority.

2. Re-read authoritative state#

When a workflow depends on an existing asset or position, the client reads it from Supra immediately before signing. This catches changed ownership, completed claims, expired windows, insufficient balances, and mismatched token metadata.

The dApp prepares a transaction request for chain ID 6 and passes it to StarKey. The wallet—not the API—owns the account and approval boundary. A disconnected wallet or wrong network stops the flow before signing.

4. Wait for finality#

The client submits through the wallet, polls the Supra receipt, and rejects failed VM execution. A submitted hash is not presented as a successful operation until the receipt finalizes successfully.

5. Reconcile the outcome#

Trust Stack parses the expected event type and compares its creator, beneficiary, asset, amount, schedule, and object address with the reviewed intent. State-aware flows then re-read the position and vault to confirm the expected transition.

Text

Form → validated intent → current Supra state → StarKey signature
     → finalized receipt → exact event match → resulting state/vault check

6. Index for discovery#

The Go indexer stores normalized event dimensions together with the original payload and the emission-proof fields returned by its configured Supra RPC. It checks that the returned event hash matches the returned proof leaf. This powers wallet position lists, filters, partner APIs, and public proofs. If the indexer is delayed or unavailable, on-chain authorization and claims still remain in Move.