Reference
Non-custodial by construction
The terminal holds no funds and has no account system. Where that boundary comes from, and what it does not buy you.
Pre-launch. Market data is live Hyperliquid mainnet. Order placement is not wired: the fills, position, PnL and volume shown here are simulated against the real price. Amber outline means simulated. What is built, in full.
The shape of it
Your private key never leaves your wallet. The terminal holds no funds, has no account system, takes no deposits and has no withdrawal feature. It is built to route orders to Hyperliquid against the account your own wallet already owns, and to hold nothing in between. There is nothing here to be custodian of.
What the terminal can do
- Read your wallet's public address, and which chain it is on.
- Ask your wallet for the two typed-data signatures described on The two signatures.
- Submit exactly those two approvals to Hyperliquid, and nothing else through that path.
- Generate and hold a trading key, encrypted, in your browser.
- Sign orders, cancels, modifications, leverage changes and isolated margin changes with that key.
- Read your account state from Hyperliquid: positions, open orders, fills, margin and funding.
What it cannot do
- Send any blockchain transaction. There is no transaction path in the product at all. Everything it asks your wallet for is a signature.
- Withdraw. The exchange client it uses exposes order placement, cancellation, modification, leverage and isolated margin, and nothing else. No withdraw, no transfer, no send.
- Take a deposit. The module for it exists and is deliberately not connected to anything. There is nowhere in the product to deposit into.
- Freeze, seize or reverse anything. There is no privileged action over your account, because there is no relationship with your account beyond a key you approved and can revoke.
Complete, and awkward: the signing library the terminal is built on does contain a builder for Hyperliquid's withdrawal action, unused, gated behind a flag that must be passed literally so that a withdrawal can never be constructed by a mistyped action name or a loop over action builders. Nothing in the app calls it. It would be wrong to say the code cannot express a withdrawal. It is right to say the product has no withdrawal feature.
Where the boundary actually comes from
Not from us.
Hyperliquid's withdraw and send actions carry no "from" field, so the account debited is whichever key signed the action. A trading key signing a withdrawal withdraws from its own empty account. That is structural, which is why it is trustworthy: not a permission we configured, and not one we could change.
What that does not buy you
A trading key can do more than trade. It can move collateral around inside your own account tree, including into a Hyperliquid vault where a hostile operator could trade it away, and it can open maximum-leverage positions and liquidate them deliberately. So the honest boundary is that it cannot move funds out of your control directly, but it can move them somewhere they can be destroyed, and it can destroy them in place.
What the restriction buys is that such an attack is loud, slow, visible on chain, needs market access and cannot be a single silent transfer. That is worth a lot and it is not the same as safe. Revoking is one signature and it is a real revoke, not a local delete.
What is kept in your browser
All of it is local. None of it is sent anywhere, there is no account behind any of it, and there is no server copy to ask us about.
Settings, progression, layout
| Key | What it holds |
|---|---|
ct.progression.v1 | XP, tier, volume and the running discount total |
ctm.alerts.v1 | Your alert definitions. Which have already fired is not kept |
ctm.chart.ind | Which chart indicators are switched on, and their periods |
ct-sn-muted | Whether sound is muted |
ct-sn-bed | Whether the ambient bed is on |
ctm.layout.v1 | Panel sizes, if you have dragged a divider |
The trading key
In IndexedDB, as AES-GCM-256 ciphertext, under a wrapping key the browser marks non-extractable. Your account address, the network and the expiry are bound into the encryption, so editing the stored record to extend the expiry or point it at another account makes the decryption fail. It does not quietly succeed. If your browser does not provide the cryptography or the database, the key is held in memory for the session and you are re-prompted on reload. There is no plaintext fallback.
Stated honestly, because it is worth knowing: an attacker already running code on this origin can open the same database and ask the browser to decrypt with the same handle. Against that adversary this is a speed bump and not a wall. What it does defeat is a copied storage file, a malicious extension reading text, and anything that reads storage without executing in the page.
If you arrived from a promoter link
Two keys, and that is the whole inventory:
| Key | What it holds |
|---|---|
ct.referral.touch.v1 | The first promoter code this browser ever arrived under, when, which parameter carried it, how many referred visits there have been, and up to eight later codes kept only for settling a dispute |
ct.referral.bindings.v1 | Wallet addresses that connected, and the code in force at that moment |
No page views, session ids, click paths, referrer headers, device fingerprint, IP address, user agent, or anything at all derived from your balances, positions or order flow. The layer contains no network call of any kind: no request, no beacon, no socket, no tracking pixel. The table leaves your browser only if a human exports it by hand.
Attribution is first-touch. The first code a browser arrives under
is the one it keeps, and a later link is recorded as evidence and changes
nothing. An address that connects with no code is not written down at all.
Codes are accepted as ?ref= or the short
?r=, and the parameter is stripped from the
address bar immediately after capture, so it does not get pasted into a
group chat or ride along into anything that records a page URL.
Clearing all of it
This build has no settings panel, so there is no one-click control that clears every key. There will be when the panel is ported, and What is built tracks that. Two routes work today.
From the browser console on the terminal page, for the referral keys specifically:
For everything else, by hand: developer tools, Application, Local Storage, and delete the 6 keys in the table above. Or use any "clear site data" control your browser offers, which takes the trading key out of IndexedDB along with them. There is no server copy, so there is nothing else to clear and nobody to ask.
What we can see
Your builder-code fills are published on chain by Hyperliquid, as they are for every builder on that venue, and that is how promoter payments are reconciled. It is the same data anybody can query. We do not run a backend, so there is no other record of you anywhere.
No region gate
There is no geofence and no jurisdiction wall. Nobody forgot, and it is not advice: whether you may lawfully trade leveraged perpetual futures where you live is your question to answer, not ours, and this documentation is not an opinion on it.