Concepts
The data, authority, and completion model behind a safe Torq integration.
Torq integrations use the indexed API as the product-visible truth boundary. Your signer owns signing and submission; Torq never receives a private key, seed phrase, or reusable customer signing secret.
Core concepts
| Concept | Why it matters | Guide |
|---|---|---|
| Canonical state | Shared state becomes product-visible only after it is projected and persisted. | Canonical state and freshness |
| Network provenance | A prepared intent carries its own chain and governed deployment context. | Networks |
| Typed workflow | Actions are discriminated workflow types, not arbitrary contract calls. | Typed workflows |
| Resources | Markets, facilities, vaults, tranches, positions, and related records are read from the canonical API. | Resource APIs |
| Roles and scopes | A valid credential is necessary but never sufficient for an approved-role action. | Authentication and scopes |
Authority is evaluated at execution time
For a role-bound workflow, Torq checks the application scope, current wallet identity, selected chain, entity, canonical role state, and any required on-chain or timelock authority. A previously valid prepared workflow can become blocked if its snapshot expires or the relevant authority changes.
Amounts and time
Treat quantity fields as the exact format stated in the API schema. Do not introduce floating-point rounding between a displayed value, a workflow input, and a transaction intent. API timestamps are ISO 8601 strings; a timestamp shows observation or projection time, not necessarily finality.