Canonical read model

Torq's canonical read model is the product rule for application-visible protocol state.

Torq does not let each workspace reconstruct its own version of market truth. Shared protocol state has one path from chain to application.

One-line rule

Shared protocol state should be read from the same indexed application truth path in every workspace.

Why Torq avoids page-level truth

The comparison is not about whether another protocol has data tools. The Torq-specific rule is that investor, borrower, operator, and admin screens should not reconstruct shared protocol truth in the browser. That rule is central because Torq action paths depend on post-write verification and role workspaces agreeing on the same credit-line state.

Authority path

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

Every shared protocol field needs:

• one source class
• one canonical owning table
• one owning projector
• explicit freshness metadata
• a clear frontend consumer path

What users should expect

• tables, charts, badges, balances, queue state, market state, and role state should agree across workspaces
• wallet success and application-visible completion can be separate steps
• stale, pending, blocked, or degraded state should remain visible instead of being silently replaced
• shared protocol data should not change just because one page locally guessed a value

Where live RPC is allowed

Live wallet reads are still useful for execution-time needs such as wallet balances, allowances, gas estimation, simulation, pending transaction status, and setup checks. They are not the product source for shared market, vault, role, or accounting state.

Why this matters to sophisticated partners

The model reduces integration ambiguity.

A partner consuming Torq data gets clear answers:

• which path owns the value
• whether it represents persisted projected state
• whether the state is fresh, stale, pending, or blocked
• why a workspace can or cannot act on it