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-user, per-venue agent key — AES-256-GCM encrypted at rest, decrypted in-process only at signing time. One row per user per venue, not one per account: the key is approved by the user’s wallet, and a user’s accounts all sit behind that one wallet, so they share it.

The agent key can: place, cancel, and modify orders on the venue, for the accounts of the user 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.

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 or go straight to Verify a firm.

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: "internal", and the account stays kind: "live". Both of those are deliberate, and the distinction is the one that matters most on this page:

	venue: "paper"	venue: "internal"
Account kind	paper	live
The money	Simulated	Real — settles real PnL
Matched by	Our engine	Our engine

The two ride the same matching engine, which is exactly why they do not share a sentinel. Every query that partitions the book by venue — exposure pivots, the liquidation and funding sweeps, the demo reset — keys off the literal paper, so putting real-money rows under it would sweep them into the demo bucket.

So: do not read venue: "paper" as “internalised”. It means simulated. If you need to tell an internalised account apart, the discriminator is a property of the account — a live account whose prop attempt carries the mirror_synthetic execution mode — never the venue string alone.

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.