Concepts
Plain-language definitions for the core Torq concepts, entities, relationships, and terminology.
This page defines Torq terms before the manual uses them.
Torq is the credit facility operating system for tokenized assets. A facility is a bounded credit commitment with rules. In Torq, that relationship is represented by vault capital, markets as execution components, permissions, valuation data, exit state, recovery state, and post-write verification.
Relationship map
A Torq vault governs the line; an attached market lets a borrower draw
The bounded credit-line commitment and authority boundary.
The borrower-facing credit facility attached to vault capacity.
The borrower or market slice used to keep accounting local.
The role-specific screen that verifies the projected result.
A non-technical reader can think of Torq as a controlled facility desk: one team defines the facility, a borrower draws from it, valuation teams keep the data current, and the system only calls work complete after the shared records update.
Core mental model
| Concept | Plain meaning | In Torq |
|---|---|---|
| Facility | Bounded credit commitment | The operating object that connects vault capital, borrower draw rights, eligible collateral, valuation fields, exits, recovery, permissions, and canonical reporting. |
| Credit line | Permission to borrow under agreed rules | A facility-level draw relationship backed by a governed vault and market execution path. |
| Vault | The boundary that holds capital and rules | The facility capital commitment, capacity, tranches, fees, redemption queue, and authority surface. |
| Market | Borrower execution component | The place where collateral, debt, rates, oracle state, and borrower routes are resolved inside a facility. |
| Partition | A separated accounting slice | A borrower or market slice used to keep debt, capacity, and recovery local. |
| NAV | Net asset value | A reported valuation path for assets that need controlled valuation evidence. |
| Live-Feed | Fresh external price or market data | Oracle/feed input used for state that changes over time. |
| IRM | Interest rate model | The rule that defines how borrow rates respond to utilization or policy. |
| Permission | Who is allowed to do something | A role, wallet, entity, and action check before a action path can proceed. |
| Post-write verification | Proof that an action became visible in the product | Wallet success followed by indexing, projection, API refresh, and workspace reread. |
| Canonical read model | The single application truth path | Chain -> Indexer -> Projector -> Postgres -> API -> Frontend. |
System entities
| Entity | Product role | Related entities |
|---|---|---|
| Protocol | Shared runtime, permissions, registries, contracts, and global safety fields | Markets, vaults, roles, oracles, IRMs, timelocks. |
| Vault | Capital boundary and facility rules | Investors, asset managers, markets, tranches, redemption queues. |
| Market | Facility execution surface | Borrowers, collateral, loan assets, oracles, IRMs, liquidators. |
| Asset | Token or asset metadata used in a market or vault | Asset issuers, NAV reporters, market feeds, policy rows. |
| Oracle or NAV adapter | Valuation source | Markets, assets, NAV reporters, freshness fields. |
| Role | A job with scoped authority | Wallet, entity, permission template, action registry. |
| Workspace | A screen for a job | Investor, borrower, Protocol Manager, Asset Manager, Asset Issuer, NAV Reporter, Liquidator, Partner. |
Relationships between entities
- A vault defines the facility capital boundary.
- A market can be attached to the vault as the borrower execution component.
- A borrower route prepares the exact execution path for borrow and repay actions.
- Valuation data comes through NAV and Live-Feed paths.
- Permissions decide who can create, edit, approve, allocate, redeem, borrow, repay, liquidate, manage, or govern.
- The indexer and projectors update Postgres so every workspace sees the same persisted truth.
Glossary
| Term | Definition |
|---|---|
| Aave | A DeFi protocol whose public help docs describe supplying assets into liquidity pools and borrowing against collateral. |
| Allocation | Making vault capacity available to a market or route under configured rules. |
| Allowance | Wallet approval that lets a contract move a token amount for a transaction. |
| Asset issuer | The role that submits or maintains asset information and related NAV context. |
| Asset manager | The role that operates vault programs, assets, oracles, markets, IRMs, partners, and scoped roles. |
| Borrow | Drawing loan assets from an approved market route. |
| Canonical | The one source the product treats as authoritative for a field. |
| Collateral | Asset posted to support a borrow position. |
| Curator | Legacy-compatible label that routes to Asset Manager in the active app. |
| Draw | Plain-language word for a borrow from an approved credit line. |
| Faucet | Local or test environment tool for obtaining demo assets. |
| Facility | Governed operating object that binds vault capital, borrower draw rights, eligible collateral, valuation fields, exits, recovery, permissions, and canonical reporting. |
| Governance | Controlled process for changing permissions, contracts, policies, or sensitive settings. |
| Indexer | Service that observes chain and runtime events. |
| Liquidation | Bounded recovery action path for unhealthy borrower debt. |
| Market feed | External data source used to update price or market-state context. |
| Morpho | A DeFi protocol whose Vault V2 docs describe curated lending strategies, adapters, IDs, caps, and role separation. |
| NAV reporter | Role that submits valuation reports where configured. |
| Operator | Person or wallet performing a control-plane action. |
| Permission template | Reusable permission bundle for a role or action family. |
| Projector | Code that turns observed events into deterministic current-state rows. |
| Redeem | Request or claim assets back from a vault according to the redemption path. |
| Senior/Junior | Tranche labels used when a vault separates risk or claim priority into two share classes. |
| Timelock | Delay mechanism before a sensitive operation can execute. |
| Tranche | A class of vault participation with its own risk and redemption profile. |
| Wallet | User-controlled signing tool used to submit transactions. |
Why these terms matter
Aave's public help docs describe users supplying assets into liquidity pools and borrowing against collateral. Morpho's Vault V2 docs describe curated vault strategies with adapters, caps, and separate roles. Torq uses some familiar DeFi words, but the operating center is different: Torq is organized around governed facility work, role-specific operating action paths, canonical indexed truth, and post-write verification.
The practical difference is control. In Torq, the important question is not only "is there liquidity in a pool?" or "which market receives vault assets?" It is also "who fields the facility, which borrower can draw, which valuation path is trusted, which permission applies, and when did the product verify the result?"
For reviewers
The active source evidence is the V2 route map in apps/web/src/app/router.tsx, page surface registry
in apps/web/config/pageSurfaceRegistry.json, function registry in
apps/web/config/functionRegistry.json, role catalogs in apps/web/config/roleFunctionCatalog.json
and apps/web/config/roleFieldCatalog.json, and active contract inventory in
protocol/contracts/security/manifests/torq-v2-active-contract-inventory.json.