Self-custody
Why your funds never touch our servers, and the wallet boundaries that make that true.
Self-custody means one thing here: we cannot move your money, because we never hold the keys that would let us. This page explains how that holds up, from the login screen down to the exact thing our server is allowed to sign.
What it means for you
When you sign in, you are not creating an account on our servers in the usual sense. You authenticate with a wallet through Privy. That wallet stays under your control the whole time. Your trading collateral lives on your own wallet at the exchange, not in a balance we keep for you. There is no "deposit to our platform" step, because there is no platform balance.
There is exactly one wallet we provision for you, called the Agent Wallet. It is your wallet — it appears in your Privy account and you own it outright. Its only job is to pay for AI trade suggestions. It holds a small amount of USDC for that purpose and nothing else. It never holds trading collateral, and it can never send money anywhere except the one AI provider you approve, up to a cap and an expiry date you set.
So there are two promises, and both are enforced by design rather than by policy:
- We cannot touch your trading funds. They are on your wallet at the venue, signed by your keys.
- The Agent Wallet can only spend on AI calls, only to the approved recipient, only up to your cap, only until your expiry.
How sign-in works
Authentication runs through Privy in local-storage session mode. You can sign in two ways, and the difference matters for what gets signed where:
- An external wallet, like MetaMask, that you already control. You linked it; you sign with it.
- An embedded wallet that Privy provisions for you on email or passkey login. The private key is held by Privy in a way that never exposes it to our servers or our frontend.
Either way, we never see your wallet's private key, and your identity across the app is just your Privy login.
The server never trusts the client's word on identity
Every request to our server proves who you are with a fresh, verified Privy login. The acting user always comes from that verified proof, never from anything the browser claims about itself.
The Agent Wallet, and why it is safe
The Agent Wallet is a Privy embedded wallet, one per user, that belongs to you. We provision it the first time you use the AI features; it then appears in your Privy account, and you can export its private key at any time — see Wallet management. The private key stays inside Privy's signing system. Our server holds a narrow signing permission on it: it can trigger only the one scoped payment you approved, and it cannot read the key, export it, or sign anything outside that scope.
That scope is the important part. When you turn on paid AI suggestions, you grant a delegation: a scoped, revocable permission for our server to trigger payments from your Agent Wallet without asking you to sign every single call. The permission is deliberately tiny:
- Only USDC payments. There is no free-form transfer — paying for an AI suggestion is the only thing it can do.
- Only the one AI provider you approve. Any other recipient is rejected.
- Only up to a cap you choose. That is the total it may ever spend.
- Only until an expiry you choose. After that date, the permission is dead.
You can revoke it at any time. Even while it is active, think about the worst case: if our server's delegated signer were fully compromised, the attacker could send your Agent Wallet's USDC to the one approved AI provider, up to your cap, until your expiry. They could not reach your trading collateral (it is on a different wallet entirely), and they could not redirect funds to themselves (the recipient is fixed). That bounded blast radius is the whole point of the design.
Where signing happens, and where it does not
The cleanest way to understand self-custody here is to look at who signs each kind of action. Notice that our server only appears on one row, and only for a single, scoped action.
| Action | Signed by | Where | Key held by |
|---|---|---|---|
| Approve a Hyperliquid agent / builder fee | your master wallet | in your browser | you |
| Place or cancel an order | your wallet at the venue | in your browser | you |
| Move funds between spot and perp | your master wallet | in your browser | you |
| Pay an AI provider (USDC authorization) | the delegated signer | on our server, via Privy | Privy, scoped to your delegation |
Order flow and fund movement never go through our backend. Your browser talks straight to the venue and signs with your keys. The only thing our server signs is a USDC payment authorization to the approved AI provider, and only because you granted a scoped delegation that says it may.
Funding a venue, the first time
Trading at a real venue like Hyperliquid needs a one-time readiness flow we call Venue Onboarding. It is client-side and it is signed by you. For Hyperliquid it is an ordered set of steps: a first deposit, then approving an agent wallet for signing, then approving the builder fee. Each approval is a separate action you sign with your own wallet.
Two of those steps protect signing and routing setup, so they re-derive live from the chain and can reopen if you tear the setup down (for example, if you revoke the agent). That is correct behaviour: you genuinely cannot route orders without that setup in place. The first deposit, by contrast, is a one-time milestone. Withdrawing all your funds later does not reopen it, because "have you ever funded this account" and "can this account trade right now" are two different questions. The second one, called Tradeable Funds, is a live check at the order button, not part of onboarding.