Architecture

Torq is organized around governed credit facilities and clear authority boundaries.

Torq does not ask the frontend to behave like a protocol analyst, NAV engine, Live-Feed relay, risk engine, and operator console at the same time. Each layer has a job. Each shared protocol field has an authority path.

flowchart LR
  Chain["V2 protocol contracts"] --> Indexer["Indexer ingestion"]
  Indexer --> Projectors["Domain projectors"]
  Projectors --> Postgres["Canonical Postgres read model"]
  Postgres --> API["GraphQL and operator APIs"]
  API --> Frontend["Operator and user workspaces"]
  Frontend --> Wallet["Wallet execution"]
  Wallet --> Chain

Protocol layer: V2 shared markets and multi-vault facilities

The active runtime is the V2 shared-market and multi-vault architecture. It owns value-moving state, permissioned transitions, fee realization, oracle policy, and vault/market authority separation.

Why this architecture matters

Aave and Morpho have their own contract, vault, oracle, and governance architectures. Torq's architecture is described here through the active V2 shared-market and multi-vault kernel plus a strict application truth path. The practical difference is that Torq separates facility authority, borrower execution, projection, API serving, and workspace display into distinct layers.

Key product difference:

• vaults define governed facility commitments
• markets execute draws from attached vault partitions
• oracle, Live-Feed, and IRM changes move through governed paths
• unsafe or stale conditions can block risk-increasing actions

Indexer and projector layer: application truth is projected

The data platform turns chain state into deterministic application truth. Projectors own derived state, not GraphQL resolvers and not frontend pages.

This is what makes Torq more than a UI over contracts. The product can prove what the system saw, when it saw it, and which persisted state each workspace is using.

API layer: serve truth, do not invent it

GraphQL and operator APIs serve persisted state. They do not become alternate truth sources for canonical protocol fields.

Frontend layer: workspaces consume authority

Frontend workspaces consume the API/read model. Live RPC is restricted to bounded cases such as wallet balances, allowances, simulation, gas estimation, execution-time revalidation, and approved preflight probes.

Workspace layer: keep the system explainable

The architecture is designed so each user sees the right operating surface:

• investors see vaults, tranches, positions, queues, and activity
• borrowers see markets, collateral, routes, repayments, and market state
• asset managers see vault programs, credit facilities, assets, rates, partners, and roles
• issuers see submissions, controlled assets, NAV reports, and messages
• NAV and feed reporters see valuation action paths and freshness context
• operators see protocol inventory, permissions, policy, and controlled action flows

The result is an architecture built around one facility truth: protocol state is projected once and then surfaced through role-specific workspaces.