Torq Documentation

Launch and operate an institutional Torq Earn vault through governed, canonical workflows.

Build an asset-manager control plane for creating and operating investor-facing Torq Earn products. This guide covers the public asset-manager and vault-owner workflow boundary only; it never exposes protocol-wide administration.

Private Preview. Vault launch, market attachment, allocation, fee, and liquidity scopes require explicit product and role approval. The docs do not grant those authorities.

Managed Earn

Launch, attach, allocate, and operate governed vaults

01Launch

Deploy an approved vault from an explicit configuration.

02Attach

Connect eligible markets under vault authority.

03Allocate

Set bounded market allocations and liquidity policy.

04Operate

Track fees, liquidity, activity, and canonical completion.

01Product service

Vault configuration and investor-facing disclosures.

02Policy engine

Market admission, caps, fees, and authority checks.

03Role signer

Asset-manager wallet, HSM, or MPC execution.

04Portfolio view

Allocations, liquidity, fees, positions, and activity.

What you will build

Vault-product configuration and launch flow using role.asset_manager.vaultDeploy.
Market-attachment, allocation, liquidity, and fee operations through approved vault roles.
Complete investor product data: assets, markets, vaults, tranches, funds, positions, and activity.
Review, authorization, customer-owned signer, transaction registration, canonical completion, and audit evidence.
Investor-facing product feed that updates only after canonical state becomes visible.

Prerequisites

Torq Developer Preview organization and applications, approved asset-manager and vault authority, allowed products and chains, secret key, webhook endpoint, and test wallets.
Product mandate, vault terms, eligible markets, limits, fees, liquidity policy, disclosures, and a decision process for every governed change.
Asset-manager wallet, HSM, or MPC configured as the customer-owned signer for approved roles.
Durable request store, event inbox, audit log, state reconciliation, and separation of proposer, reviewer, signer, and operational observer where your policy requires it.

Project files

Use the full request boundary in examples/developer-platform/earn-program-reference:

src/torq-api.mjs       # scoped server and wallet-session calls
src/catalog.mjs        # exact investor-facing product/read model
src/workflows.mjs      # proposal, preparation, simulation, registration
src/webhooks.mjs       # signed event inbox boundary
src/use-cases.mjs      # approved asset-manager workflow profile

Recommended application structure:

product-config/        # mandate, terms, fees, limits, market candidates
governed-actions/      # typed proposals and four-eyes review
signer/                # role wallet, HSM, or MPC adapter
torq-workflows/        # prepare/register/final_success state machine
portfolio-read-model/  # vault, allocations, liquidity, fees, activity
investor-feed/         # approved product-facing canonical view
audit-and-events/      # immutable decision and signed delivery evidence

Complete data contract

Operating view	Operations
Asset and market universe	`GET /v1/assets`, `GET /v1/markets`, `GET /v1/assets/{resourceId}`, `GET /v1/markets/{resourceId}`
Vault state	`GET /v1/vaults`, `GET /v1/vaults/{resourceId}`, `GET /v1/tranches`, `GET /v1/funds`
Portfolio controls	`GET /v1/vaults/{resourceId}/allocations`, `GET /v1/vaults/{resourceId}/liquidity`, `GET /v1/fees`
Investor and lifecycle	`GET /v1/vaults/{resourceId}/share-mobility`, `GET /v1/positions`, `GET /v1/eligibility`, `GET /v1/activity`
Governed writes	`POST /v1/workflows/prepare`, `POST /v1/workflows/{requestId}/transactions`, `GET /v1/workflows/{requestId}`

Complete credit lifecycle

Design and operate products against the same complete credit lifecycle that distributors expose to investors:

Lifecycle responsibility	Asset-manager implementation
Deposit and tranche selection	Publish accurate share-class, allocation, fee, liquidity, redemption, and eligibility terms for the distributor experience.
Position, yield, and liquidity	Keep server GraphQL `vaultHolderPerformanceCurrent`, vault, allocation, activity, fee, and `GET /v1/vaults/{resourceId}/liquidity` current and explain blocked states.
Redemption and claimable cash	Operate allocation and liquidity without obscuring queued obligations or customer claim state.
Impairment monitoring	Use `GET /v1/liquidation-recovery`, `GET /v1/vaults/{resourceId}/activity`, and `GET /v1/events` to publish canonical stress and recovery context.
Recovery opportunity	Where an approved recovery fund exists, expose `GET /v1/funds`, `GET /v1/funds/{resourceId}`, and `GET /v1/funds/{resourceId}/holdings` terms without promising an outcome.
Investor decision	A fund subscription remains a separate capital allocation requiring wallet eligibility and explicit customer approval; an affected vault position does not automatically create a fund claim.
Availability	Distributor-side subscription, idle-redemption, and claim execution require the approved Preview executor. Otherwise the customer action is `capability_not_ready`.
Final reconciliation	Maintain exact vault, loss, recovery-cash, fund, epoch, side-pocket, sale, proceeds, and claim evidence through canonical `POST /graphql` and resource rereads.

Do not use asset-manager authority to enroll investors or sign for them. Product operation and the customer-controlled investor decision remain separate authority paths.

Build the integration

1. Model the product constitution

Represent the product mandate, asset, vault type, eligible market set, allocation bounds, liquidity requirements, share mobility, fee schedule, decision authority, and investor disclosures as reviewed configuration. Do not derive intended economics only from current contract values.

2. Provision scoped applications and roles

Use separate test and production applications and keys. Map each Torq role wallet to the exact organization, vault, environment, and allowed workflows. Never share an asset-manager secret with an investor client or use one signer for unrelated vaults without an explicit policy.

3. Load and validate market candidates

Read asset/market detail, activity, vault state, allocations, liquidity, fees, eligibility, and freshness through src/catalog.mjs. Apply the product constitution to canonical data. Keep a reviewable explanation for accepted and rejected market candidates.

4. Launch the vault

Create a typed role.asset_manager.vaultDeploy proposal containing every documented configuration field. Show the expected product, authority, asset, terms, fees, and dependencies. Obtain independent review where required, then call POST /v1/workflows/prepare with a stable idempotency key.

5. Review and sign exact launch transactions

Require preflight passed. Persist the request, snapshot, transaction intent set, expiry, and review decision. The signer revalidates chain, targets, values, order, configuration digest, and role scope, simulates required calls, and submits only exact prepared transactions.

6. Confirm canonical vault creation

Register each hash at POST /v1/workflows/{requestId}/transactions, wait for transaction and GET /v1/workflows/{requestId} final_success, then reread the new vault resource. Do not publish the product merely because deployment returned a receipt.

7. Attach approved markets

Prepare role.vault_owner.attachMarketToVault for each approved relationship. Bind the selected vault, market, configuration, authority, and current snapshot. Sign, register, wait for canonical success, then reread vault detail, allocations, liquidity, and market state.

8. Set and maintain allocations

Use role.vault_owner.vaultAllocate or the approved allocator workflow. Validate allocation totals, per-market bounds, liquidity needs, current attachment, and current product state. Keep proposed and current allocations visible together. Reconcile the canonical allocation rows after final_success.

9. Configure fees and product settings

Use the documented vaultFeeConfigUpdate and supported vault settings workflows only. Make the single-recipient semantics, rates, beneficiaries, effective state, and unrelated protected fields explicit. Reject invalid zero-recipient/rate combinations and differing nonzero curator recipients before preparation. Reread fee and vault state after completion.

10. Operate and publish the product

Serve investors only from canonical assets, markets, vaults, allocations, liquidity, fees, activity, eligibility, and share-mobility state. Signed events trigger a reread and investor-feed update. Keep stale, blocked, paused, recovery, and low-liquidity states visible and fail closed on new actions.

11. Audit every change

Persist proposer, reviewer, signer, role, product configuration, request ID, exact prepared intents, transaction hashes, canonical outcome, affected resource versions, and remediation. Do not log API secrets, wallet proofs, HSM material, or unnecessary investor data.

Release tests

A launch with wrong role, chain, asset, configuration, or expired plan is rejected.
Attachment cannot target an unapproved or stale market.
Allocation rejects unattached markets, wrong totals, wrong vault, and changed snapshot.
Fee configuration rejects invalid recipient/rate combinations and preserves unrelated fields.
Receipt/event without canonical post-state never reaches application completion.
Reorg and replay demote affected workflow state and force resource reconciliation.
Investor feed never exposes role-only actions or protocol-wide administrative data.

Production checklist

Product constitution and every authority boundary have named owners and reviewers.
Test/production applications, keys, signers, queues, and databases are isolated.
Every proposal is built from current canonical resource state.
The customer-owned signer binds exact workflow, role, chain, target, configuration, and expiry.
Launch, attach, allocation, and fee actions wait for final_success and resource reread.
Investor views expose full product data but no protocol-wide administrative surface.
Signed events are deduplicated and treated as reconciliation triggers.
Negative, reorg, idempotency, frame-condition, and recovery tests pass on Sepolia.
Private Preview access and production responsibilities are documented.

Run node --test examples/developer-platform/earn-program-reference/test/*.test.mjs, then use vault economics, workflow reference, and complete APIs.

Asset managers