DocumentationSafety, permissions, and fields
Safety beyond a market parameter
Torq's safety model is not limited to collateral thresholds or vault curation caps. Those kinds of fields are important, but Torq also treats role authority, stale-state visibility, post-write projection, incident protection, and workspace-specific recovery as product fields.
Torq treats safety as part of the product experience.
Users should not have to guess whether an action is available, who can perform it, or whether the displayed state is current enough to rely on. Torq exposes permissions, freshness, unavailable field reasons, wallet execution, and post-write visibility as product concepts.
Product safety model
Controlled credit workflows need visible permissions and completion
role + wallet + entity
NAV + Live-Feed + oracle status
wallet plan + action review
indexed state + workspace refresh
Permissioned actions
Torq separates product labels from actual authority. A workspace such as Asset Manager, NAV Reporter, or Asset Issuer is an interface. The action still depends on the specific role, wallet, entity, vault, market, or permission behind it.
Users should expect sensitive actions to show:
- what entity is being changed
- which wallet or role is expected
- whether the action is direct, permissioned, or delayed by a governed path
- what state must refresh after execution
Stale and unavailable field reasons
Torq can block or constrain risk-increasing actions when the operating state is not acceptable. Examples include stale oracle data, stale NAV or Live-Feed inputs, blocked market state, insufficient capacity, missing permissions, unsafe collateral health, or unavailable route inputs.
Unavailable field reasons are not just errors. They are product signals that explain why an action should not continue until the relevant condition is repaired.
Wallet execution and completion
A wallet confirmation means a transaction was submitted or confirmed onchain. In Torq, the product also waits for the affected state to become visible through the indexed read model where the action path requires it.
That distinction matters for deposits, exits, borrows, repayments, collateral changes, vault settings, and valuation updates.
Product safety model
Torq's product safety model combines:
- scoped workspace access
- role-aware action planning
- explicit wallet execution
- indexed post-write refresh
- NAV, Live-Feed, and oracle freshness visibility
- vault, market, asset, and role availability fields
- clear separation between coordination messages and protocol state
The goal is practical: users should know what they can do, why they can do it, and when the result is actually visible in the application.