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.

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: "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.