Accounting
Torq accounting model, state ownership, reconciliation, invariants, value flows, and failure handling.
Torq accounting explains where value is, who owns the state, which movements are allowed, and how the product reconciles after a write.
The active accounting model is V2 only. It follows the same truth path as the rest of the product:
Chain -> Indexer -> Projector -> Postgres -> API -> FrontendAccounting flow
Value movement is tracked by custody, capacity, debt, fees, redemption, and recovery state
Investor assets enter the vault boundary.
Vault capacity becomes available to approved markets.
Borrower draws from an attached credit facility.
Principal and fee components return through the market path.
Exit requests and claims move through queue-aware settlement.
Liquidation or loss recovery resolves stressed state.
Accounting context
Aave-style accounting often centers on pool supply, borrow balances, collateral, interest, and liquidations. Morpho-style vault accounting also includes vault assets, adapters, caps, allocation, and reporting. Torq accounting is organized around governed facilities: vault custody, market capacity, borrower partition debt, collateral, fee realization, redemption queues, tranches, recovery, and post-write reconciliation.
Accounting model
| Area | Plain meaning | Torq model |
|---|---|---|
| Custody | Where assets are held. | Vault and market contracts own value-moving state; Postgres records projected application truth. |
| Capacity | How much credit can be used. | Facility commitments, vault commitments, and market partitions determine available draw capacity. |
| Debt | What the borrower owes. | Borrower debt is projected from active shared-market state and repay events. |
| Collateral | What secures the borrow. | Collateral deposits and withdrawals are tracked by market and borrower partition. |
| Fees | Who earns or collects fees. | Vault fees, spread fees, reserve factors, fee collectors, and protocol fee paths are explicit. |
| Redemption | How lenders exit. | Queue and claim state determine redemption status. |
| Recovery | How stressed positions are resolved. | Liquidation and loss recovery update partition-local state. |
Torq accounting is not a spreadsheet attached to the app. It is a set of invariants and projected records that the app must reread before calling work complete.
State ownership
| State | Owner |
|---|---|
| Value-moving balances | Active V2 contracts. |
| Application-visible current state | Domain projectors and Postgres current tables. |
| API responses | GraphQL and operator APIs reading Postgres. |
| Frontend display | Workspaces consuming API state. |
| Accounting evidence | Accounting inventory, invariants, replay, reconciliation, and proof artifacts. |
Reconciliation
Reconciliation means comparing the expected accounting result with the observed projected result.
The minimum product standard is:
- Transaction or persisted write completes.
- Affected entity is indexed.
- Projector updates current-state rows.
- API returns the updated persisted state.
- Workspace displays the updated state.
- Any mismatch remains visible as pending, stale, blocked, or failed.
Invariants
| Invariant family | Plain meaning |
|---|---|
| Global | Totals should reconcile across custody and projected state. |
| Custody | Assets should not disappear between vault, market, borrower, and settlement paths. |
| Capacity | Borrow capacity should match vault and market constraints. |
| Debt | Borrower debt should not be locally invented by the frontend. |
| Collateral | Collateral should support debt under configured safety rules. |
| Fee | Fee realization should be explicit and traceable. |
| Redeem | Queue and claim state should explain exit availability. |
| Tranche | Senior/Junior share accounting should remain separated where active. |
| Liquidation | Recovery should stay bounded and partition-local. |
| NAV | Valuation-sensitive state should respect freshness and report fields. |
| Indexing | Application truth should come through projector-owned state. |
| UI | Screens should not replace stale state with local guesses. |
Value flows
| Flow | What changes |
|---|---|
| Deposit | Lender assets move into vault custody and position state updates after projection. |
| Allocate | Vault capacity becomes available to a configured market. |
| Borrow | Loan assets move to borrower and debt increases. |
| Repay | Debt decreases and fee components are realized according to active rules. |
| Redeem | Share or claim state changes according to queue and vault liquidity. |
| Liquidate | Debt and collateral settle through bounded recovery logic. |
| Fee collect | Protocol or vault fee balances move to configured recipient paths. |
Failure handling
| Failure | Accounting handling |
|---|---|
| Wallet failure | No completed value movement is assumed. |
| Partial projection | Product state remains pending or stale. |
| Oracle stale | Risk-increasing accounting moves can be blocked. |
| Fee mismatch | Reconciliation should fail until the projected fee path matches expected state. |
| Queue mismatch | Redemption state should remain unresolved until current rows reconcile. |
For reviewers
Accounting evidence is in docs/accounting/accounting-inventory.md,
docs/accounting/accounting-invariants.md, docs/accounting/accounting-inventory.json,
docs/accounting/transition-mutation-matrix.json, docs/accounting/replay-and-reconciliation-rules.json,
and the active V2 contract inventory.