Reference architectures

Each architecture uses the same Torq truth boundary:

Chain -> Indexer -> Projector -> Postgres -> Torq API -> Your product

Your product may use RPC to simulate a prepared transaction, obtain a receipt, and submit through its own signer. It must not use RPC to reconstruct markets, vaults, positions, authority, or completion state for customer-visible decisions.

Issuer integration

Use the canonical asset, eligibility, NAV, and issuer resources for product-visible state. An approved issuer can prepare role.asset_issuer.assetSubmissionRequestCreate, which is a metadata-only workflow with a wallet-session and current issuer authority check. It reaches final_success only after the request is visible in the canonical submission queue.

Issuer back office -> server-held secret key -> typed workflow preparation
                         |                         |
                         v                         v
                  canonical API reads       canonical Postgres queue

Keep issuer administration and approval authority in the issuer's own service. Do not use an issuer integration to deploy shared markets: no public issuer workflow grants that capability.

Wallet integration

Use an origin-bound publishable key in the browser and create a one-time wallet challenge. The wallet signs that challenge, the API returns a short-lived opaque session, and the product passes that session only to endpoints that require the corresponding wallet scope. The transaction signer continues to live in the browser wallet or customer-owned custody system.

Browser -> publishable key + wallet challenge -> opaque wallet session
   |                                                       |
   +---- customer wallet signs prepared intent ------------+
                                                           v
                                           register hash -> canonical completion

Never ship a secret key, webhook secret, preview invitation, or customer signer secret to a browser bundle. A wallet signature authenticates the session; it is not a reusable credential and is never a substitute for a prepared workflow.

Exchange integration

An exchange generally combines anonymous resource discovery with server-side, scoped account reads, workflow tracking, and durable events. Store the latest event cursor only after your own database durably records the event. Deduplicate both eventId and deliveryId; retries are normal under the at-least-once contract.

Torq webhook -> exchange ingress -> raw-body signature verification -> durable inbox
                                                        |                 |
                                                        +---- 2xx <--------+
                                                                  |
                                                    reconcile through canonical API read

Do not credit a customer solely from a receipt or webhook. Reconcile the relevant canonical Torq resource and freshness evidence before presenting financial state.

Asset Manager integration

Asset Managers may receive an approved role workflow such as role.asset_manager.vaultDeploy. The API creates the exact active-V2 deployment intent after checking current entity permission, asset policy, manifest provenance, and read-model freshness. The Asset Manager's customer-owned signer simulates and submits that intent; Torq tracks the transaction and confirms the resulting canonical vault state.

Asset Manager console -> canonical validation -> prepared V2 deployment intent
         |                                                     |
         +---------------- customer-owned signer -------------+
                                                               v
                                        receipt evidence -> canonical vault readback

Shared-market creation is not part of this integration. Use the workflow guide for exact role restrictions and fail-closed behavior.

Choose the boundary first

Use a separate test application and test credentials for every integration. Production access is a reviewed approval path and is not inferred from a working Sepolia integration.