Canonical state and freshness
Understand Torq read ownership, freshness evidence, and post-transaction completion.
Torq integrations consume shared state through:
Chain -> Indexer -> Projector -> Postgres -> APIDo not reconstruct shared protocol state from RPC. The API returns freshness evidence including status, lag, block, projection time, snapshot time, and a reason when state is stale or missing.
Workflow lifecycle
| Status | Meaning |
|---|---|
prepared | Typed intents were built against a named canonical snapshot. |
submitted | Your signer submitted and registered the transaction. |
mined | The transaction is in a block; product state is not yet complete. |
indexed | The relevant chain events were consumed. |
persisted_visible | Canonical Postgres reads show the expected state. |
final_success | Every declared postcondition passed. |
failed | Execution, indexing, reorg handling, or canonical readback failed. |
Every prepared workflow includes a snapshot hash, expiry, simulation requirement, blocked reasons, and expected postconditions. Re-prepare after expiry or stale-state rejection.