Build an earn agent
Compose discovery, suitability, explanation, portfolio, and redemption experiences from Torq investor resources.
Recommended product flow
Build an earn copilot as a sequence of evidence-backed tools, not one unconstrained prompt.
| Step | Torq resources | AI responsibility |
|---|---|---|
| Discover | assets, vaults, markets, funds, partner programs | Filter and explain available products |
| Qualify | eligibility, networks, deployments, share mobility | Exclude unavailable wallets, networks, and paths |
| Compare | vault details, allocations, liquidity, fees, NAV reports, oracles | Explain yield drivers, liquidity, exposures, fees, and evidence age |
| Personalize | vaultHolderPerformanceCurrent, positions, activity, messaging | Use the selected vault holder record for vault value and performance; keep market-position context separate and summarize only the authenticated wallet's state |
| Act | typed workflow prepare API | Propose an exact action after explicit approval |
| Complete | workflow and transaction tracking | Wait for canonical final_success and explain blocked states |
| Monitor stress | positions, vault activity, liquidation-recovery, events | Explain only canonical impairment and recovery evidence |
| Review recovery | fund detail, holdings, subscriptions, investor status | Present an eligible open fund as a separate decision, never as compensation |
| Reconcile recovery | original vault state plus optional fund state | Keep both positions separate through proceeds, claims, and final state |
Complete credit lifecycle rule
Every Earn agent must follow the complete credit lifecycle,
including the possibility that an open position becomes affected. Retrieve
GET /v1/liquidation-recovery, the original vault activity, GET /v1/funds/{resourceId}, and
GET /v1/funds/{resourceId}/holdings before explaining an optional recovery opportunity.
An affected position does not automatically make the wallet eligible, compensate the customer,
subscribe the wallet, or create a fund claim. The model must describe Distressed Recovery Fund
participation as a separate capital allocation, require explicit customer approval, and preserve
the customer-controlled signer. If the approved investor fund-action executor is unavailable, the
only valid action result is capability_not_ready; the agent must not invent target or calldata.
Wallets, neobanks, and exchanges
Use Torq resources to add institutional-grade earn discovery, deposits, position reporting, redemptions, and status messaging to an existing account experience. Keep your customer identity, consent, suitability, and custody controls outside the model. Never let one user's retrieved context enter another user's answer.
Asset managers and financial service providers
Use the same read model to explain assets, vault strategy, allocations, liquidity, fee economics, NAV evidence, and recovery state. Approved-role workflows may be prepared only when the authenticated role, application scopes, current chain, and current resource state allow them.
Yield aggregators
Use partner programs and wrappers to present eligible Torq opportunities, explain the integrator's fee economics, and route through the approved partner path. Compare the true user outcome after all visible fees. Do not claim a cheaper result unless current fee data proves it.
A useful answer contract
Every recommendation should return:
{
"answer": "Plain-language recommendation or refusal",
"evidence": [
{ "resource": "vault", "id": "...", "freshnessBlock": "..." },
{ "resource": "liquidity", "id": "...", "freshnessBlock": "..." }
],
"risks": ["liquidity", "credit", "oracle freshness", "redemption timing"],
"assumptions": [],
"missingData": [],
"proposedWorkflow": null,
"requiresApproval": false
}If missingData is non-empty for a decision-critical field, refuse to recommend an action.
Product-visible truth
Use canonical Postgres/API state for vaults, markets, funds, vault holder performance, market positions, eligibility, fees, allocations, liquidity, and completion. RPC is restricted to signing-time simulation, submission, and receipt observation through the approved signer boundary.