How Torq works

Torq works because it separates the jobs that pool-first markets and isolated-market systems often blend together.

Capital commitment, borrower draw, valuation truth, policy change, wallet execution, indexing, and workspace visibility are distinct loops.

The operating sequence

Define facility
-> attach market relationship
-> govern oracle, NAV, Live-Feed, rate, and permissions
-> borrower draws under checks
-> chain event is indexed
-> projector updates canonical state
-> every workspace reads the same truth

Torq coordinates tokenized credit operations instead of only matching supply and borrow demand.

What is different about the operating loop

Aave-style pool action paths commonly begin with supplying to or borrowing from a liquidity pool. Morpho-style vault action paths commonly emphasize curated allocation and caps. Torq's operating sequence starts earlier and ends later: define the facility, attach the market execution component, check valuation and permissions, execute the action, then verify the projected product state.

Facility setup loop: define the facility before capital moves

1. A vault represents a bounded facility commitment.
2. Authority, asset scope, market relationship, and operating policy are made explicit.
3. NAV or Live-Feed visibility requirements are attached to the facility.
4. The operator workspace presents the facility as an accountable operating surface.

A vault is not a vague destination for capital. It is a governed boundary with responsibilities.

Policy control loop: rates and oracles are governed decisions

1. Interest-rate and oracle policy are treated as operating fields.
2. Changes are prepared through explicit action paths.
3. Authority is checked before execution.
4. The system records and refreshes the visible result through the persisted read model.

This is why rate policy is part of the product model. It changes borrower incentives, manager expectations, and operating review.

Data projection loop: visible truth is produced, not guessed

1. Indexers ingest chain events and snapshots.
2. Projectors derive deterministic current-state rows.
3. Postgres stores canonical application truth.
4. GraphQL/API serves the persisted read model.
5. Frontend pages render persisted state with freshness metadata.

This loop is what lets Torq tell the difference between transaction success and visible protocol state.

Operator execution loop: wallet success is not the finish line

1. The operator workspace reads namespace-aware persisted state.
2. The operator selects a mutation flow.
3. The app builds a wallet execution plan.
4. After write success, indexing is triggered immediately.
5. The workspace refreshes from persisted state.
6. The UI only shows completion when indexed truth is visible.

Product safety loop: actions have preconditions

Torq actions are not available just because a button exists. The product checks the relevant preconditions before execution and refreshes the displayed state after execution.

Examples:

• deposits depend on wallet, balance, allowance, vault capacity, and vault state
• tranche deposits depend on the active tranche configuration and tranche capacity
• borrows depend on collateral, oracle state, available partition liquidity, route preparation, and market state
• collateral withdrawals depend on borrower health after withdrawal
• operator actions depend on the connected role, permission, wallet, and target entity

This keeps Torq understandable as a product: users can see why an action is available, blocked, pending, or complete.