# Trust & custody model

This page states plainly what the platform holds and what it does not. If you
are evaluating an integration, read it before the endpoints.

## Order signing vs custody

The platform holds a **per-account, per-venue agent key** — AES-256-GCM
encrypted at rest, decrypted in-process only at signing time.

**The agent key can:** place, cancel, and modify orders on the venue, for the
one account it belongs to. These are exactly the powers a venue agent wallet or
API wallet is designed to delegate. So when you submit an intent, the order is
signed and dispatched server-side — no wallet popup per trade.

**The agent key cannot:** move funds off-venue. Venues release withdrawals only
to the user's signed-in main wallet, and the withdrawal signature must come
from that wallet, which the platform never holds. It also cannot register,
rotate, or revoke the agent on the user's behalf.

:::note[The custody boundary is the user's wallet]
Deposits, venue withdrawals, and agent authorisation all require the end user's
own wallet signature. The agent key shifts *order signing* off the wallet; it
does not shift custody. A partner integration — or even a fully compromised
backend — cannot perform a custody-moving action on a user's behalf.
:::

That is the reason partners integrate at the API layer: order flow is
API-driven and server-signed, while everything that moves money stays pinned to
the end user's own key.

## Prop firms: custody stays at your multisig

For an on-chain funded-trader program the same principle applies to the
operator:

- Your `PropInstance` contract is **owned by the multisig address you supply**
  at create time.
- Traders' challenge deposits go **straight to your instance**. The platform
  never takes custody of them.
- The deploy is broadcast with a gas-only platform deployer — it pays gas, it
  does not own the result.
- Approving a payout is an **authorisation**, not an on-chain send. You are the
  authoriser; settlement is dispatched against your instance.
- You never hold platform keys, and the platform never holds yours.

## Verify it rather than trust it

Every live firm publishes an on-chain proof page — treasury, collateral, ledger
totals, and a dollar-for-dollar reconciliation against the multisig, with no
login required. See [How verification works](https://docs.troncharts.xyz/docs/verify/how-it-works/) or go
straight to [Verify a firm](https://docs.troncharts.xyz/docs/verify/).

## Execution: routed vs internalised

One more thing worth stating openly, because it changes how you read a fill.
An order reaches the market one of two ways:

- **Routed** — the order is signed and dispatched to the named exchange.
  `venue` is that exchange, and `venueOrderId` / `venueTradeId` are the
  exchange's own identifiers.
- **Internalised** — the firm is the counterparty. The order is matched by the
  platform's own engine against a firm-canonical mark, and no order is placed
  at any exchange for it.

Internalised rows carry `venue: "paper"`. The sentinel means *matched by our
engine*, not *simulated money* — an internalised account settles real PnL. Which
mode applies is a property of the **account**, never of the venue string, so
discriminate on the account if you need to tell them apart. On an internalised
row the ids are minted by the platform: stable and safe as dedup keys, but they
resolve nowhere off-platform, so don't build exchange-side reconciliation on
them.