How Trust Stack works

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

3. Sign in the wallet

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.

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.