TORQ
TORQ explains governed credit operations for digital and tokenized assets.
- 03 OCT 2026
- 5 min read
When is a credit action complete?
A wallet receipt proves an execution event, but a business workflow needs the new facility state to reach the product. Trace the steps from chain confirmation to a visible record.
A wallet can report that a transaction was submitted or mined while the application's loan, vault, or permission view still shows the previous state. The right user message depends on which stage has been verified.
TORQ uses the chain as root truth and a projected Postgres model as canonical application truth. Its completion rule follows the relevant event through the indexer, projector, API, and workspace.
Six states that should remain distinct.
1. Submitted.
The wallet or signer sent a transaction. It may still revert, be replaced, or remain pending.
2. Confirmed.
The chain includes a successful transaction and receipt. This establishes the onchain result for that transaction.
3. Indexed.
The indexer observes the relevant chain event in the configured namespace and network.
4. Projected.
A projector applies the event to the correct entity and business-state record.
5. Persisted and returned.
Postgres stores the updated row and the API returns it for the relevant identity and scope.
6. Visible.
The workspace reloads or refreshes and displays the new canonical state to the authorized user.
A draw awaiting indexing.
Suppose a borrow transaction succeeds on the configured chain. The receipt records execution, but the borrower workspace still shows the prior debt amount because the event has not yet been projected.
Showing a completed loan update at that point would be premature.
The interface should keep the action in a pending-update state, retain the receipt for diagnosis, and reread the canonical API.
Once the correct loan and facility records appear for the same network and entity, the workspace can show completion.
If projection fails, an operator needs a recoverable exception path rather than a second blind borrow attempt.
The same principle applies to a permission change or vault setting: the user needs the resulting governed state, not only proof that a wallet signed something.
What an integrator should record.
- The intended action, chain ID, transaction hash, and entity or facility identity.
- The receipt status and the exact event or state change expected from the action.
- The indexer and API readback that proves the expected record reached the correct namespace.
- A reload test and a recovery path for missing, delayed, or contradictory state.
- Keep only the minimum data needed for diagnosis. Never log reusable credentials or private signing material.
