Action Paths

A Torq action path is the full path from intent to verified product state. A wallet transaction, by itself, is not the whole action path.

Why the action path is longer than one transaction

In pool-first lending, a user often thinks in single actions: supply, borrow, repay, withdraw, or liquidate. In vault-curation systems, a user may also think about allocation and caps. Torq keeps those actions, but it wraps them in credit-line operations: role check, entity scope, valuation freshness, route preparation, wallet or metadata execution, indexing, projection, and workspace verification.

Universal sequence

sequenceDiagram
  participant User
  participant Workspace
  participant Wallet
  participant Chain
  participant Indexer
  participant Postgres
  participant API
  User->>Workspace: Choose action and enter inputs
  Workspace->>API: Read persisted current state
  Workspace->>Workspace: Check role, entity, route, freshness
  alt Wallet write required
    Workspace->>Wallet: Request signature or transaction
    Wallet->>Chain: Submit transaction
    Chain-->>Workspace: Transaction hash or receipt
  else Metadata-only update
    Workspace->>API: Persist metadata change
  end
  Workspace->>Indexer: Trigger focused refresh where supported
  Indexer->>Postgres: Project current state
  Workspace->>API: Reread persisted result
  API-->>Workspace: Updated, pending, blocked, or failed state

Create

Examples: create asset submission, create asset manager, create market, create oracle, create IRM, deploy vault, create partner context.

1. User opens the relevant workspace.
2. User enters identity, metadata, addresses, and policy fields.
3. Workspace checks required fields and permissions.
4. The action follows a metadata-only, direct wallet, direct-or-timelock, or timelock route.
5. The affected inventory refreshes from persisted state.

Common mistake: treating an asset submission as a listed asset. Submission creates review state; it does not automatically create protocol listing authority.

Edit

Examples: update asset policy, update vault settings, change fee collector, change market access, update roles, update oracle metadata.

1. User opens the current entity.
2. Workspace compares intended state with persisted current state.
3. No-op writes can be skipped when execution-time checks permit.
4. Required writes are grouped only when the wallet and action semantics allow it.
5. The result is visible only after projection.

Delete or revoke

Examples: remove a permission user, revoke a role, cancel a timelock action, disable or unlist an entity where supported.

1. User selects the existing grant, role, or pending action.
2. Workspace checks whether removal is direct, timelocked, or blocked.
3. User confirms the consequence.
4. State refresh confirms the removal or cancellation.

Risk: delete-like actions can remove recovery authority. Operators need to check that a replacement role or recovery route exists before removing critical power.

Approve

Examples: approve a token allowance, approve a vault market, approve a permission template, approve or route a governed action.

1. User reviews the approval target.
2. Workspace checks current allowance or approval state.
3. If approval is needed, the wallet flow requests the minimum required confirmation.
4. The next action path step uses the approved state.

Allocate

Examples: allocate vault capacity, enable or disable market allocation, set routing, configure partner channel state.

1. Asset manager or allocator reviews vault and market state.
2. Workspace checks vault capacity, market approval, route, and permission.
3. Allocation update executes through configured route.
4. Vault and market rows refresh.

Redeem

1. Lender opens vault detail.
2. Lender selects redeem or exit request.
3. Workspace checks share state, tranche state, queue state, and vault liquidity.
4. User signs the required request or claim.
5. Redemption queue and position state refresh.

Borrow

1. Borrower opens market detail.
2. Workspace prepares the borrower route.
3. Collateral, risk epoch, oracle version, nonce, deadline, and partition state are checked.
4. Borrower signs the borrow transaction.
5. Borrower debt and vault partition state refresh.

Repay

1. Borrower opens market detail.
2. Workspace reads projected borrower debt.
3. Repay input is prepared from canonical debt and checkpoint data.
4. Borrower signs repay transaction.
5. Debt, fees, and position health refresh.

Liquidate

1. Liquidator opens the liquidator workspace.
2. Workspace checks borrower health, oracle state, close factor, liquidation bonus, freeze state, and deadline.
3. Liquidator executes bounded recovery.
4. Borrower debt, collateral settlement, and recovery state refresh.

Manage

Manage action paths cover Protocol Manager, Asset Manager, Asset Issuer, NAV Reporter, and workspace messages. They follow the same pattern: inspect persisted state, choose entity, prepare action, execute, refresh, and verify.

Govern

Governed action paths include timelock queue, execute, cancel, finalize, emergency recover critical role, oracle transition, IRM transition, and permission changes.

Sensitive changes can require delay. Emergency actions can be direct when they reduce risk or restore critical authority, but they still need the configured role and route.

For reviewers

Action Path coverage maps to apps/web/config/functionRegistry.json, apps/web/src/walletFlow/**, apps/web/src/actionEngine/**, tracked mutation APIs, and active V2 contracts. The action path names on this page match the requested quality gate list.