Build an earn flow
Design a non-custodial deposit, position, redemption, and completion experience.
An earn flow takes a customer from vault selection to a canonical position without transferring signing authority to Torq. The current Developer Preview supports customer-owned wallet and custody integrations; it is not a Torq-hosted checkout page.
The flow
1. Select a vault
Read GET /v1/vaults and the related asset, market, tranche, eligibility, and freshness resources.
Show the customer the exact vault, loan asset, current terms, access state, and exit mechanics.
2. Establish wallet authority
Create a one-time wallet challenge with an origin-bound publishable key. The wallet signs the challenge and receives a short-lived opaque session. Never place a secret key, webhook secret, private key, seed phrase, or reusable signature in a browser bundle.
3. Prepare, simulate, and sign
Call POST /v1/workflows/prepare with the documented workflow type and base-10 integer inputs. Torq
returns exact transaction intents, not arbitrary target or calldata execution. Simulate every intent
and sign it with the customer-owned wallet, HSM, or MPC service.
4. Register and wait for canonical completion
Register each submitted hash at POST /v1/workflows/{requestId}/transactions. A mined receipt is not
completion. Continue until the workflow is final_success, then read the canonical position and
vault state.
5. Handle exits as a lifecycle
Redemption may be immediate, queued, restricted, or fulfilled by an authorized lender workflow.
Use the current vault exit terms and the documented role.lender.investorRequestRedeem and
role.lender.investorFulfillRedeem paths only where the approved application has the matching role
and scope. Do not promise instant liquidity from a successful request.
UX states to expose
| State | Product behavior |
|---|---|
prepared | Ask the external signer to review and simulate the exact intent. |
submitted | Show the transaction hash, but do not change financial balances. |
mined_unconfirmed | Keep the action pending while canonical confirmation and projection continue. |
final_success | Refresh and display the canonical position. |
blocked or failed | Show the stable error code and preserve the request ID for support. |
Use errors and retry behavior, events, and the SDK reference for the complete path.