Per-exchange custody
Each venue offers a different shape of trade-only credential, and each one keeps your funds in your hands by its own design. fxyz inherits all of that protection and adds product-side guarantees on top.
Hyperliquid
Model. A protocol-level "agent key" approved by your main wallet. The HL contract enforces that an agent can place, modify, and cancel orders, and nothing else.
What this means for you. Withdrawals, transfers, and account-setting changes require your main wallet, the same wallet you use on Hyperliquid's own UI. fxyz never holds that wallet, never sees it, and has no way to ask for it. The agent credential we hold is trading-only by Hyperliquid's own protocol rules, with no exceptions.
Revoke. Click Disconnect Hyperliquid. One signature rotates the slot at HL to an unrecoverable address, and from that moment the venue itself rejects every trade attempted against the slot. This isn't "we promise to forget the key". The protocol turns the key off, on-chain, irrevocably.
Lighter
Model. An API key tied to your Lighter account. Lighter's L2 protocol routes any withdrawal to your registered L1 owner address; the wire format has no recipient field at all.
What this means for you. Funds on Lighter can only go home to you. Even an attacker who somehow held the key could not point a withdrawal anywhere except your own L1 address, because there is no field to set.
On top of that, fxyz's own Lighter client deliberately omits withdraw and transfer from the surface available to strategy code. The protocol and the client are two independent walls.
Revoke. Click Disconnect Lighter. fxyz drops its copy of the key immediately. For complete revocation, rotate or delete the key on Lighter's own UI as well.
Pacifica
Model. An API Agent Key bound to your Solana account. Pacifica's withdrawal endpoints carry no destination field at all, so a withdrawal settles to the registered Solana owner.
What this means for you. Funds on Pacifica can only go home to you. An agent key can start a withdrawal, so treat it as a forced-exit risk rather than a theft risk: the worst case is your own funds arriving in your own wallet sooner than you planned, not leaving for someone else's.
It can't escalate, either. Pacifica's agent-binding call refuses agent signatures, so a key can never promote itself or bind a new one.
Revoke. Click Disconnect Pacifica. fxyz drops its copy of the key immediately. Remove the agent key on Pacifica's own UI to close the door completely.
Backpack
Model. An API key generated on Backpack and held by fxyz under the credential protection described in the security overview.
What this means for you. Backpack's protocol doesn't restrict what a trading key can do the way Hyperliquid's or Lighter's does. The protection here is our own code: fxyz's Backpack client omits withdraw and transfer entirely, so they aren't in the surface available to strategy code and no part of the product can move funds off your account.
That's a real guarantee, but it's a guarantee about our code rather than a rule the venue enforces, so it's worth adding the venue-side layer too.
TIP
Configure Backpack's withdrawal-address whitelist on your account. Any withdrawal is then limited to addresses you've pre-approved, enforced by Backpack itself. It's a sensible safeguard whether or not you use fxyz.
Revoke. Click Disconnect Backpack. fxyz drops its copy of the key immediately. For complete revocation, rotate or delete the key on Backpack's UI as well.
Binance
Model. A restricted API key generated in Binance's API Management. Binance keys are broad by default, so fxyz verifies the restrictions before it will accept one.
What this means for you. At connect time fxyz refuses any key that reports withdrawal permission, and refuses any key that isn't IP-restricted. Those checks run against Binance's own API, so they're verified rather than assumed. A key without withdrawal permission has no withdrawal path, and an IP-restricted key is unusable from any machine that isn't ours even if it leaks.
As with Backpack, nothing in the Binance protocol itself would stop a sufficiently permissioned key from withdrawing. What makes the key safe is how it's restricted, which is why fxyz treats those restrictions as mandatory instead of advisory.
WARNING
A Binance API key deserves more care than a Hyperliquid agent key. On Hyperliquid the protocol makes withdrawal impossible. On Binance, the restrictions do. Keep withdrawals off, keep the IP list tight, and don't reuse the key anywhere else.
Revoke. Click Disconnect Binance. fxyz drops its copy of the key immediately. Delete the key in Binance's API Management to kill the credential itself.
At a glance
| Venue | What keeps funds yours |
|---|---|
| Hyperliquid | The protocol restricts agent keys to trading. Withdrawals require your main wallet. |
| Lighter | The L2 protocol routes withdrawals to your registered L1 owner address and nowhere else. |
| Pacifica | Withdrawals carry no destination field, so they settle to your own Solana account. |
| Backpack | fxyz's client has no withdraw or transfer code path. Backpack's withdrawal-address whitelist locks it down further. |
| Binance | fxyz refuses any key that can withdraw or isn't IP-restricted. Both are checked against Binance at connect time. |
Hyperliquid, Lighter, and Pacifica are protected by the venue's own protocol, which is the strongest form this can take: the restriction holds no matter what our code does. Backpack and Binance are protected by our client surface and by how the key is restricted. Both are real, but they're worth understanding as different in kind, which is why the whitelist and restriction advice above matters more on those two.
What's next
- How your keys are kept safe: the storage and isolation model.
- What fxyz cannot do: the explicit list.