This page hasn't been translated yet. Showing English version.

Security and Custody

Who can sign what at TRUE: non-custodial wallets, a trade-only delegate that cannot withdraw, and the review gate on the way out.

The one question worth answering

Every security page is really answering the same question: who can move my money?

At TRUE the answer is you. Not as a slogan, as an architecture. The platform holds no key that can withdraw your funds, and that is not a policy we could quietly change next quarter, it is what the keys are scoped to do.

Wallets

Sign in with email, a social account, or by connecting a Solana wallet you already hold. Wallet infrastructure is provided by Dynamic, who handle key generation and the embedded wallet for users who do not arrive with one.

  • You hold the key. An embedded wallet is yours; TRUE cannot reconstruct it and cannot sign with it.
  • Connected wallets are untouched. If you arrive with Phantom or another wallet, TRUE only ever asks it to sign.
  • Signing sessions expire. An idle session stops being able to sign and the app asks you to re-authorise. That is the intended behaviour, not a fault.

TRUE is evaluating Privy as an additional wallet provider. Nothing about the custody model changes if that lands: the user holds the key in both cases.

The delegate, and what it cannot do

Trading on the perps venue happens fast and often, and asking you to sign a wallet prompt for every order would make the product unusable. So your venue account has a delegate signer that the platform holds, scoped to trading.

That delegate can place and cancel orders. It cannot withdraw. There is no code path, no admin tool and no support procedure that turns a trade delegate into a withdrawal. Getting money off the venue requires a signature from you.

This is the line that matters

If TRUE were compromised tomorrow, an attacker holding every delegate we have could trade your account. They could not send your funds anywhere. The withdrawal signature is not ours to give.

Sub-accounts

An Autopilot deck and a copy wallet are separate venue accounts with their own margin, so a strategy going wrong is bounded by what you funded it with.

Withdrawing from a sub-account is two hops: venue to that book’s own on-chain wallet, then that wallet to your main wallet. The second hop is signed by you. Money sitting between the hops is on a wallet you own, which is why it is never lost even when it is briefly not where you expected it. Every funded book appears in your balances, so no account is invisible.

Withdrawals

Withdrawals go through a review gate. Most clear automatically and land in minutes. Some are held for a human look.

We publish that the gate exists and roughly what it weighs: how new the account is, how many withdrawals it has made recently, the size, and whether the destination has a history with us. We do not publish the thresholds. A published threshold is a number to structure around, and the people who would structure around it are exactly who the gate is for.

A held withdrawal is not a lost withdrawal. It is reviewed and then approved or refused, and you are told which.

API credentials

  • Keys are shown once and stored as a hash. Nobody at TRUE can read your key back to you, support included.
  • Keys expire, 90 days by default.
  • Keys can be pinned to IP addresses. This is the control that still works after a key leaks, and it is why we built it: a rate limit slows a thief down, an allowlist stops them.
  • Changing an allowlist costs an emailed code, because widening one is exactly what an attacker with your session would want to do.
  • Trading keys are bound to a wallet and every order must carry that wallet’s signature. Our gateway can refuse an order. It cannot forge one.

Details on Authentication and Rate Limits.

AI, and the limits on it

TRUE is full of AI: chat, agents, market making, support. None of it can spend your money on its own.

  • An assistant with trade:execute can propose an order, not place one. Execution requires your approval inside an authenticated session.
  • Leveraged orders never auto-approve. There is no setting that turns that off.
  • Agents trade from their own funded deck, not from your main balance, so their worst case is bounded by what you gave them.

Venue risk controls

The perps venue has brakes that can be pulled without a deploy: price bands on placement and on fills, a halt when an oracle goes stale, self-trade prevention, per-market halts, per-account freezes, and a hard stop on the settlement path. They exist because we needed them once and would rather never need them again.

Their thresholds are not published, and neither is which ones are armed right now. That is a deliberate choice: publishing them converts a safety net into a specification for getting close to it without tripping it.

Automated checks

Jobs run on a schedule against the systems that hold money, and they check the boring invariants that quietly stop being true: that balances reconcile against the chain, that payouts recorded as sent actually left a wallet, that positions and ledgers agree, that no account’s books drift from its on-chain reality. When one disagrees, a human is paged rather than a dashboard being updated.

What they check we will describe. The exact checks and the alerting thresholds we will not, for the same reason as the risk controls.

Reporting something

Found a vulnerability, or think an account has been compromised? Contact support from inside the app. Include what you observed and how to reproduce it, and never include a raw key: TRUE will never ask for one, and anybody who does is phishing you.

See also

Last updated: