Architecture

The Platform API is the integrator surface. Behind it, one unified balance and one execution engine handle Trade, Transfer, Lend, Borrow, and Checkout through a single order.

One Balance

Users see one spendable portfolio balance. Torque aggregates holdings across chains behind the scenes; depositable assets (including yield-bearing forms) count toward parent buckets such as ETH or BTC. Routing is automatic; integrators and end users never pick a source chain.

What the user sees

One portfolio balance

One spendable amount per action

Ownership layer

Live portfolio total

Unified balance for MAX and spend

Execution readiness

Can this action route now

Multi-step plan when needed

Inventory layer (hidden)

Per-chain holdings

Where tokens sit today

Torque ledger

Balance buckets (available / reserved)

Order lifecycle

What the user sees

One portfolio balanceOne spendable amount per action

Ownership layer

Live portfolio totalUnified balance for MAX and spend

Execution readiness

Can this action route nowMulti-step plan when needed

Inventory layer (hidden)

Per-chain holdingsWhere tokens sit today

Torque ledger

Balance buckets (available / reserved)Order lifecycle

Indexers and observers feed ownership. Users never pick a chain.

Order Execution

Direct when one pocket can fund the action; orchestrated when balance is split across chains or forms.

Money surfaces

TradeLend & BorrowTransfer & CheckoutAssistant

Quote and execution engine

Preview quote and receive amountSubmit frozen order

Direct path

Single routed transaction

Portfolio plan

ConsolidateSwap / bridgeDeFi delegate

One user-facing order

Single order ID and timelineSettlement legs behind the scenes

Balance lifecycle

Lock spendable balanceSend onchain txConfirm and debitRelease on failure

Onchain execution

Smart walletRouting and DeFi partners

Path	When	What Happens
Direct	One pocket holds enough to fund the action	Single routed transaction
Orchestrated	Balance is unified but split across chains or forms	Consolidate, then swap, bridge, or DeFi delegate legs

Maps to the API Lifecycle

The engine above powers the READ → DECIDE → EXECUTE contract documented for integrators. See Introduction for the lifecycle diagram and below for wallet_order schema and intent types.

Stage	Engine	Integrator Surface
READ	Unified portfolio and market context	GET /read/portfolio, portfolioData in Assistant context, Intelligence feeds
DECIDE	Intent resolution and draft wallet_order	Assistant functionResults, Checkout SDK session (merchant pay)
EXECUTE	Order commit, routing, settlement	POST /execute/** (on_chain) or torque-checkout SDK + webhooks (merchant)

Lifecycle

Financial Action = Intent + wallet_order

Intent is the user goal; wallet_order is what Torque commits.

Lifecycle Stages

Stage	Summary	Constraint
READ	State + intelligence	Read-only. No wallet_order produced.
DECIDE	Intent → executable plan	No settlement. Outputs draft wallet_order only.
EXECUTE	Final settlement	Commits wallet_order. Financial Action completes.

READ: Portfolio and market context → Intent
DECIDE: Assistant → functionResults (draft wallet_order)
EXECUTE: Actions settlement (on_chain or merchant)

Intent Types

Intent is the user goal. DECIDE resolves it; EXECUTE commits the matching wallet_order through Actions. The wallet_order channel selects on_chain vs merchant.

Intent	Description	DECIDE	EXECUTE Channel
swap	Exchange one asset for another	trade (functionResults may show swap_tokens)	on_chain
transfer	Send assets to a wallet or address (peer)	transfer (functionResults may show transfer_tokens)	on_chain
lend	Supply assets for yield	lend (functionResults may show lend_tokens)	on_chain
borrow	Borrow against collateral	borrow (functionResults may show borrow_tokens)	on_chain
pay	Settle a merchant order (buyer → merchant)	torque-checkout SDK (merchant server)	merchant

transfer → on_chain (wallet JWT); pay → merchant (business key). Same move-value, different auth.

Merchants: merchant + Checkout. Wallet/Assistant: on_chain.

Wallet Order

Draft in DECIDE (functionResults); committed in EXECUTE via Actions (on_chain or merchant).

Field	Description
intentType	swap \| transfer \| lend \| borrow \| pay
status	draft (DECIDE) → committed (EXECUTE)
channel	on_chain → POST /execute/**; merchant → torque-checkout SDK + order webhooks
requiresConfirmation	true for value-moving drafts from Assistant
transaction	Prepared tx body (on_chain channel) or checkout session (merchant)
chainId	Target chain for on_chain orders

// DECIDE output (draft wallet_order, on_chain)
{
  "toolName": "transfer_tokens",
  "result": {
    "success": true,
    "requiresConfirmation": true,
    "intentType": "transfer",
    "status": "draft",
    "channel": "on_chain",
    "chainId": 8453,
    "transaction": { ... }
  }
}

// pay: merchant channel; DECIDE via Checkout SDK (not Assistant)
{
  "intentType": "pay",
  "status": "draft",
  "channel": "merchant",
  "checkoutSession": { ... }
}

Execution Tiers

draft

DECIDE

wallet_order in functionResults; plan only, no settlement

committed

EXECUTE

wallet_order submitted; value moves or state changes

Actions Channels

EXECUTE is one surface (Actions) with two channels. Both finalize a wallet_order.

Surface	Channel	Routes	Auth
Actions	on_chain	POST /api/v1/execute/ (alias /actions/)	Smart Wallet JWT
Actions	merchant	torque-checkout SDK, POST /api/webhooks/order-update	sk_live_… + Business ID

Tool Name	EXECUTE Route	Channel
trade (alias swap_tokens)	POST /api/v1/execute/trades	on_chain
trade / swap_tokens (Solana)	POST /api/v1/execute/trades/solana	on_chain
transfer (alias transfer_tokens)	POST /api/v1/execute/transfers/evm	on_chain
transfer (alias transfer_tokens, Solana)	POST /api/v1/execute/transfers/solana	on_chain
lend (alias lend_tokens)	POST /api/v1/execute/lends/evm	on_chain
borrow (alias borrow_tokens)	POST /api/v1/execute/borrows/evm	on_chain
torque-checkout SDK (pay)	Checkout session + POST /api/webhooks/order-update	merchant

Boundary Rules

If it does not produce or contribute to a wallet_order, it is not part of EXECUTE.

Category	Examples	Why
READ-only responses	GET /intelligence/feed, GET /data/*, GET /wallet/me	Context only; no wallet_order
Assistant text-only replies	content without functionResults	Intent answered; no draft wallet_order
System metadata	GET /health, GET /capabilities, GET /openapi	Discovery, not execution
Rate tiles without commit	Opportunities GET without downstream EXECUTE	READ context, not a wallet_order

For Integrators

Unified portfolio READ, not per-chain pockets.
Third-party: business key for read/decide; user auth for execute.
EXECUTE commits wallet_order; routing stays inside Torque.
Trade, Transfer, Lend, Borrow, Checkout share one order lifecycle.
Merchant pay: Checkout SDK, not Assistant.

Next: Authentication, Execute, Checkout SDK, Assistant.

FAQ

How does one balance work across chains?

Torque aggregates holdings into product buckets (USD, ETH, BTC, equities). Portfolio READ returns one unified balance; execution may pull from multiple pockets and consolidate before the final leg.

When is execution direct vs orchestrated?

Direct when one pocket holds enough to fund the action in a single routed transaction. Orchestrated when balance is unified but split across chains or forms; Torque consolidates, then runs swap, bridge, or delegate legs as needed.

Do integrators expose per-chain balances?

No. Partner UI should show one balance line per product bucket or portfolio total. Per-chain inventory is internal routing detail.

What is wallet_order?

The executable unit Torque commits after DECIDE. It carries intent (swap, transfer, lend, borrow, pay) and routes through one order lifecycle. See Lifecycle for schema and intent types.

More general questions: Introduction FAQ.

Questions or corrections? hello@torque.fi

← Errors & Limits API Catalog →