Market health settings

Torq is a facility-health operating system.

Health is not background risk. It is a control surface.

A facility is healthy only when these remain legible:

• the bounded credit commitment
• vault authority
• asset policy
• oracle, NAV, and Live-Feed state
• interest-rate model
• liquidation path
• stakeholder action path

At a glance: the fields that define the category shift

Protocol security is visible before risk drifts into the market

Torq's differentiation starts below the interface. The protocol and operating layer are designed to make risk signals visible before they become hidden market drift.

Key fields include:

• NAV cadence: whether report-based valuation updates are timely enough for the market's risk posture
• Live-Feed cadence: whether market-feed updates are current enough for tokenized assets that need live pricing
• oracle skew: whether price paths or timing relationships are drifting in a risk-increasing way
• supply deltas: whether asset supply changes could make old NAV data unsafe
• token screening: whether a token has transfer fees, rebasing behavior, hooks, blacklists, paused states, proxy/admin risks, or other behavior that affects market safety
• freshness and degraded-state handling: whether a stale or uncertain state blocks, warns, or route into a protective action path
• signed NAV quorum: whether enough authorized reporters approved a valuation update
• freshness profiles: whether the asset's reporting cadence matches the active oracle profile
• source tier: whether a Live-Feed asset uses an approved provider, reference, cadence, and safety profile
• conservative pricing: whether the safer lower value governs when spot and NAV disagree

Torq makes asset and valuation risk visible before it becomes hidden market drift.

Facility draws replace unmanaged market pushes

The core mental model is a draw model.

A vault is the capital boundary for a governed facility. It defines:

• how capital can be made available
• which market relationship it can support
• which policy has to be satisfied before credit moves

Capital does not bypass vault authority as an unmanaged market push.

This creates a cleaner operating model:

1. the vault defines the facility commitment
2. attachment config defines which market execution component can use that commitment
3. policy defines when the facility can be used
4. borrowers draw under explicit collateral, oracle, nonce, epoch, and recipient checks
5. the vault enforces partition reserve, draw caps, rolling-window limits, and capital envelopes
6. the system indexes the result
7. every stakeholder reads the same persisted truth

This is a different product shape from pooled participation.

The current market and vault path makes this concrete:

• the market checks borrower access, wallet policy, vault attachment, oracle version, risk epoch, and collateral health before a borrow can increase exposure
• the vault checks partition status, borrow freeze, nonce, deadline, oracle freshness, recipient policy, queued-exit reserve, available reserve, per-transaction draw limit, rolling-window draw limit, and capital envelope before delivering loan assets
• if any of those checks fail, the draw fails closed instead of silently becoming a different kind of market action

Core distinction: Torq markets are controlled draw engines inside governed facilities.

Vault exits are queued, explicit, and tranche-aware

Vault liquidity management is one of Torq's biggest differences.

The V2 vault path supports request-based redemptions:

• immediate liquidity can be delivered
• unmet claims become queued requests
• the vault tracks queue head and tail
• out-of-order fulfillment is rejected
• queued-exit cash is isolated
• reserve can be earmarked from attached market partitions

This matters because a stressed vault cannot become an invisible speed contest.

Torq also supports optional Senior/Junior vault mode. In tranche mode:

• Senior and Junior assets and shares are accounted separately
• Senior target yield and junior loss absorption are represented in tranche NAV sync
• minimum junior subordination can be enforced
• tranche share tokens can be unrestricted, policy-controlled, or non-transferable
• stress, impairment, and wind-down states can change deposit and withdrawal behavior
• closed withdrawal epochs can prioritize Senior claims before Junior claims under non-normal states

One credit-line system can express different risk appetites without forcing every lender into the same bucket.

Rate policy changes through governed paths

Torq makes rates legible as operating policy.

Different asset categories can require different rate logic. A liquid exchange-traded token, a permissioned asset, a yield-bearing asset, a NAV-reported asset, a Live-Feed asset, and a volatile collateral asset do not create the same risk surface.

The operating model supports:

• category-specific rate curves
• utilization-aware behavior
• risk-sensitive adjustments
• authorized policy changes
• clear visibility into which model applies and why
• post-change verification through the indexed read model

The rate is not a label. It is how the facility expresses credit policy.

The current shared-market contracts support a richer policy surface than a single static rate:

• approved IRM deployment through a canonical factory
• adaptive curves with target utilization and bounded rate-at-target movement
• staged adaptive curves with soft, stress, and emergency utilization response bands
• governed IRM transitions with start, abort, and finalize paths
• emergency IRM override with optional borrow freeze and review timestamp
• aggregate utilization snapshots across attached vault partitions
• stepped reserve-factor policy at utilization thresholds
• lender-floor policy
• minimum protocol-spread policy

The precise facility position: Torq is designed for governed, category-aware rate operation.

Liquidations are controlled recovery action paths

Liquidation is facility hygiene.

Torq's facility-health model makes liquidation operations explicit:

• liquidator workspaces for candidate discovery
• oracle health and stale-state visibility before action
• collateral and debt context for stressed positions
• flexible liquidation bonuses for different assets, stress states, and recovery needs
• protective or emergency paths when normal pricing is degraded
• settlement visibility after execution
• post-write confirmation through the canonical read model

Flexible liquidation bonuses matter because recovery situations are not equal:

• some assets are easy to absorb
• some need stronger incentives
• some markets need containment before stress spreads

Torq treats these as operating fields, not hidden constants.

The contract path also treats liquidation as a bounded settlement action path:

• the market validates close factor, liquidation bonus, collateral support, oracle version, risk epoch, config version, sync state, deadline, and borrower health
• liquidation can be blocked by partition regime, liquidation freeze, stale oracle state, or missing protective recovery price
• the settlement path can be direct transfer, qualified-recipient transfer, redemption claim, protocol backstop, or manual workout
• protocol spread, lender interest, principal, collateral seized, residual bad debt, and liquidation claim state are reconciled explicitly

That is a stronger diligence story than "there is a liquidation button." It is a controlled recovery machine with visible preconditions.

Action fields protect the credit boundary

Action fields are how a credit ecosystem preserves discipline.

Multiple fields can exist at the same time:

• vault fields: whether a facility commitment can be used
• market fields: whether a market can accept risk-increasing action
• role fields: who can prepare, approve, or execute a action path
• asset fields: whether a token class is permitted for a specific use
• oracle fields: whether price state is fresh enough
• NAV fields: whether report-based valuation inputs are current enough
• Live-Feed fields: whether provider, source tier, cadence, and relay state are acceptable
• execution fields: whether wallet, chain, account, and namespace state match the intended action
• post-write fields: whether the indexed system of record has caught up

The product makes every boundary visible.

Automatic stop conditions matter as much as allowed paths. TORQ Protocol's current contracts expose runtime and partition states such as Normal, CashOnly, Frozen, Impaired, RepayOnly, Soft Freeze, Hard Freeze, Stale, and Degraded. Risk-increasing paths can stop when:

• NAV supply-delta state is soft or hard frozen
• Live-Feed state is stale, misconfigured, or outside the expected cadence
• collateral and loan oracle timestamps are skewed
• oracle version or valuation-as-of data is invalid
• the partition risk epoch is stale
• an authorized protocol control declares the market hard-unsafe
• emergency IRM is active with borrow freeze
• the vault or market has borrow, allocate, deallocate, redeem, collateral-withdraw, or liquidation freeze active

The commercial point is simple: Torq does not need to pretend every state is actionable. Some states are explicitly non-actionable until the operating truth is repaired.

Asset types are handled through policy

Torq's ecosystem is designed for the tokenized economy: open tokens, permissioned assets, yield-bearing assets, NAV-reported assets, and Live-Feed assets.

Permissioned assets need access rules, transfer restrictions, and issuer coordination. Non-permissioned assets still need oracle, volatility, and liquidity policy. Yield-bearing assets introduce rate, NAV, accounting, and redemption behavior. Live-Feed assets need provider, reference, source-tier, cadence, relay, and safety-profile fields.

The market-health posture is:

• screen the token
• classify the behavior
• attach the right oracle, NAV, Live-Feed, and rate policy
• block unsafe paths
• expose the state to the right workspace
• verify updates through indexed truth

That is how Torq can support more asset types without pretending all assets behave the same.

Ecosystem workspaces share one truth path

The fields only matter if the right people can use them.

Torq is differentiated because every stakeholder has a workspace:

• asset managers govern facilities and balance-sheet commitments
• asset issuers coordinate asset policy, token screening, and distribution readiness
• NAV and feed reporters maintain valuation lineage and freshness
• partners coordinate partner demand without taking protocol authority
• liquidators keep stressed markets resolvable
• lenders inspect facility exposure and market state
• borrowers understand terms, availability, and unavailable field reasons

All of those workspaces operate over one canonical truth path:

Chain -> Indexer -> Projector -> Postgres -> API -> Frontend

That is the ecosystem position: many roles, one facility operating system, no local truth inventions.

Product boundaries