← All insights
Non-custodialSecurity

Deribit Trade-Only Sub-Account: Restricted API Key Setup

Set up a Deribit trade-only sub-account and restricted API key so a manager can place orders but can never withdraw your funds. Step-by-step, with the exact scopes.

Packed Research 11 min read
NON-CUSTODIAL

To set up a Deribit trade-only sub-account, open a segregated sub-account inside your main Deribit account, then issue a restricted API key scoped to account:read, trade:read_write, and wallet:read. Leave out wallet:read_write. That key can place and cancel orders but cannot withdraw. Add an IP whitelist, then share only the key with your manager.

A $100k+ holder can build this control alone, in a few minutes, before a single coin is at stake. That is the point of writing it down. The whole promise behind non-custodial crypto asset management rests on one exchange-enforced fact: a manager can trade your account without ever being able to move money out of it. On Deribit, that fact is not a pinky-swear. It is a set of API scopes you assign yourself and can inspect at any time.

This guide walks through the exact setup on Deribit in 2026: the sub-account, the restricted API key, and the specific permission scopes that separate “can trade” from “can withdraw.” It then maps each scope to what it does and does not allow, so you can verify the arrangement with your own eyes. If you want the wider context first, start with our pillar on non-custodial crypto asset management; if you are vetting a specific manager, use our checklist on how to choose a crypto asset manager.

What is a trade-only sub-account on Deribit, and why does it matter?

A sub-account is a segregated account that lives inside your main Deribit account. It has its own balances, its own positions, and its own set of API keys, while inheriting your identity verification and your master account’s security. You fund it with the capital you want managed, and the rest of your holdings stay outside it.

A trade-only sub-account is that segregated account paired with a restricted API key: a machine credential scoped so it can execute the strategy and nothing else. An API key on Deribit is issued with a Client ID and a Client Secret, and each key carries an explicit list of access scopes that define the ceiling of what it may do. Assign trading scopes, omit the withdrawal scope, and you have a key that places orders but cannot take money off the venue.

The reason this matters is the same reason custody sits at the top of every serious due-diligence list after 2022. When you hand a manager a fully privileged key or your login, their limits rest on trust. When you hand them a restricted key, their limits are enforced by Deribit’s own matching and withdrawal systems. Trust is optional at that point. The exchange rejects any withdrawal call the key is not scoped for, regardless of who sends it.

How do I set up a restricted, trade-only sub-account on Deribit?

The setup is five steps and needs no help from the manager until the final handoff. Everything happens inside your own Deribit account panel.

Step 1: Create the sub-account. In your Deribit account panel, create a new sub-account and name it for the mandate (for example, “Managed-Wheel”). Fund it with the capital you want traded, in BTC, ETH, USDT, or USDC, and leave everything else in your main account or in cold storage. The sub-account is yours; it does not belong to the manager.

Step 2: Open the API key form. Go to the API section of your account panel and click Add new key. Deribit lets you create a Deribit-generated key (it produces the Client ID and Client Secret) or a self-generated asymmetric key where you supply your own public key. Either works for a managed mandate; the scopes are what matter.

Step 3: Assign trading scopes and leave out the withdrawal scope. This is the step the whole model turns on. Grant account:read, trade:read_write, and wallet:read. Do not grant wallet:read_write. The trade:read_write scope lets the key create, modify, and cancel orders. The wallet:read scope lets it see balances and transaction history so the strategy can size positions. Because wallet:read_write is the scope that authorizes withdrawals and deposit-address generation, omitting it means the key physically cannot move funds off the account.

Step 4: Add an IP whitelist (recommended). Deribit lets you restrict a key to specific IP addresses or CIDR ranges through an ip restriction on the key. Enter the manager’s declared server IPs. Now the key only functions from those machines, so a copy leaked anywhere else is inert. Security guidance is blunt on this: even if someone steals your key, they cannot use it without the correct IP (TradeLink API-key security).

Step 5: Save, then share only the key. Deribit shows the Client Secret once, at creation. Copy it, then hand the Client ID and Client Secret to the manager over a secure channel. You never share your password or your 2FA. The manager plugs the key into their trading systems and goes live.

Five steps to a trade-only Deribit sub-account A vertical flow: create the sub-account, open the API key form, assign trade scopes while leaving out the withdrawal scope, add an IP whitelist, then share only the key with the manager. TRADE-ONLY SETUP: FIVE STEPS, ALL DONE BY YOU 1 Create the sub-account segregated, funded by you, owned by you
  <rect x="36" y="108" width="628" height="54" rx="10" fill="#16161A" stroke="#242425"/>
  <circle cx="70" cy="135" r="15" fill="#1A1A1B" stroke="#2A2A2B"/>
  <text x="70" y="140" text-anchor="middle" font-size="14" font-weight="700" fill="#C9C7C1">2</text>
  <text x="104" y="131" font-size="14" font-weight="600" fill="#DDDBD5">Open the API key form: Add new key</text>
  <text x="104" y="150" font-size="11.5" fill="#8B8881">Deribit issues a Client ID and Client Secret</text>

  <rect x="30" y="164" width="640" height="66" rx="12" fill="#2B7FFF" fill-opacity=".07"/>
  <rect x="36" y="170" width="628" height="54" rx="10" fill="#16161A" stroke="#2B7FFF" stroke-width="1.5"/>
  <circle cx="70" cy="197" r="15" fill="#0E0E0F" stroke="#2B7FFF" stroke-width="1.5"/>
  <text x="70" y="202" text-anchor="middle" font-size="14" font-weight="700" fill="#7FA8FF">3</text>
  <text x="104" y="193" font-size="14" font-weight="700" fill="#FFFFFF">Grant trade scopes, leave out the withdrawal scope</text>
  <text x="104" y="212" font-size="11.5" font-family="'IBM Plex Mono', monospace" fill="#9FC0FF">account:read  trade:read_write  wallet:read   (no wallet:read_write)</text>

  <rect x="36" y="236" width="628" height="54" rx="10" fill="#16161A" stroke="#242425"/>
  <circle cx="70" cy="263" r="15" fill="#1A1A1B" stroke="#2A2A2B"/>
  <text x="70" y="268" text-anchor="middle" font-size="14" font-weight="700" fill="#C9C7C1">4</text>
  <text x="104" y="259" font-size="14" font-weight="600" fill="#DDDBD5">Add an IP whitelist</text>
  <text x="104" y="278" font-size="11.5" fill="#8B8881">key works only from the manager's declared IPs or CIDR range</text>

  <rect x="36" y="298" width="628" height="54" rx="10" fill="#16161A" stroke="#242425"/>
  <circle cx="70" cy="325" r="15" fill="#1A1A1B" stroke="#2A2A2B"/>
  <text x="70" y="330" text-anchor="middle" font-size="14" font-weight="700" fill="#C9C7C1">5</text>
  <text x="104" y="321" font-size="14" font-weight="600" fill="#DDDBD5">Share only the key, never your password or 2FA</text>
  <text x="104" y="340" font-size="11.5" fill="#8B8881">Client Secret is shown once; copy it, then hand it over securely</text>
</g>
The entire arrangement is built inside your own account. Step 3 is where trade rights and withdrawal rights split apart.

That is the whole procedure. The manager never touched your account to build it, and you can undo it in one click.

Which Deribit API key permissions let a manager trade but not withdraw?

Deribit uses named access scopes, and each functional scope comes in three levels: read, read_write, and none. A requested scope can never exceed the key’s assigned scope, so what you grant at creation is the hard ceiling. The table below maps the scopes that matter for a managed account and marks whether each belongs in a trade-only key.

ScopeWhat it allowsIn a trade-only key?
account:readRead account details, positions, and settingsYes
trade:read_writeCreate, modify, and cancel orders (place trades)Yes
wallet:readRead balances and transaction historyYes
wallet:read_writeWithdraw funds and generate deposit addressesNo, omit it
account:read_writeChange account settingsNo
block_rfq:read_writeCreate and quote Block RFQsOnly if the strategy uses block trades
ip:ADDRRestrict the key to an IPv4 address or CIDR rangeRecommended

The load-bearing line is the split between wallet:read and wallet:read_write. Reading a wallet and writing to a wallet are different permissions on Deribit, and only the write level authorizes withdrawals. A key that holds wallet:read sees the money; a key that holds wallet:read_write can send the money. A trade-only key keeps the first and refuses the second. Order placement lives entirely under trade:read_write, which is a separate scope from anything in the wallet family, so a manager can run a full options-income strategy with zero withdrawal capability. (Scope names and levels: Deribit access-scope docs.)

This is the principle security writers call least privilege: give a key no more power than the job needs. If a key only trades, it should hold only trading and read scopes. The same guidance appears in every serious API-key security note: never enable withdrawal permissions on a key you share with anyone, however trustworthy they seem (TradeLink).

What a trade-only key can and cannot do The manager connects to your Deribit sub-account through a restricted key. The trade and read paths are allowed in accent blue with a check. The withdrawal path is blocked, shown as a dashed grey line with a cross. ONE KEY, TWO OUTCOMES: ALLOWED VS BLOCKED Your sub-account funds stay here BTC ETH USDT Manager restricted API key trade:read_write PLACE, CANCEL, READ Withdrawal attempt rejected by Deribit wallet:read_write NOT GRANTED Same key, same manager. Trading clears. Withdrawal never leaves the building.
The blue path is everything the strategy needs. The dashed path is the one scope you never grant, so withdrawals are blocked at the exchange.

Can a manager withdraw with my API key if it only holds trade scopes?

No. This is the question worth pressure-testing, because it is the whole reason the structure exists, and the answer is enforced by Deribit rather than by anyone’s good behavior.

A withdrawal on Deribit requires the wallet:read_write scope. A trade-only key does not carry that scope, so when any withdrawal request arrives on that key, the exchange rejects it at the system level. It does not matter whether the request comes from the manager, from a bot that copied the key, or from an attacker who breached the manager’s servers. The credential simply lacks the authority. Security researchers describe the failure mode in the opposite case plainly: an API key is dangerous precisely when the withdrawal function is enabled, because then a thief can drain the account. Remove that permission and that attack disappears.

This is also why you disable the withdrawal scope rather than merely trusting a whitelist. Deribit lets you whitelist withdrawal addresses so funds can only ever exit to wallets you pre-approved, and that is a valuable second lock. But address whitelisting still assumes the key could initiate a withdrawal at all. A trade-only key removes the capability one layer earlier. There is no withdrawal to route, whitelisted or otherwise.

For the record, a trade-only key is not a magic shield against every bad outcome. It cannot stop the manager from placing losing trades, which is why strategy diligence stays on your checklist. What it guarantees is narrower and more valuable: the money cannot leave your account through that key.

How do IP whitelist and 2FA harden a trade-only API key?

Removing the withdrawal scope closes the money-out path. Two more controls narrow who can even reach the account.

The IP whitelist binds the key to specific IP addresses or a CIDR range through Deribit’s ip restriction. A key scoped this way rejects any connection from an address outside the list. If the Client Secret leaks through the manager’s error, a laptop theft, or a repo pushed to the wrong place, the leaked copy is useless from any machine but the whitelisted ones. Pair it with a standing habit of deleting keys you no longer use, since an unused key is only ever a liability.

Two-factor authentication on your master account protects the layer above the key. The API key governs what the manager’s software can do; your 2FA governs what can be done through the Deribit web login, including creating or changing keys, editing the withdrawal whitelist, and moving funds between accounts. The manager never has your 2FA, so those actions stay yours alone. Keep the Client Secret in a password manager rather than in plaintext, chat, or email.

LayerWhat it controlsWho holds it
Trade-only scopesWhether the key can trade vs withdrawSet by you, used by the manager
IP whitelistWhich machines the key works fromSet by you
Withdrawal address whitelistWhere funds could ever exit toSet by you, your addresses only
2FA on master accountWeb login, key creation, settingsYou only

Stacked together, the worst action available to anyone holding the trade-only key is a bad trade inside the sub-account. The income strategies this structure is built for, such as the covered-call and cash-secured-put mechanics we cover in the wheel strategy for crypto and the grid-plus-hedge mechanics in the hedged grid strategy, all run comfortably within trade:read_write and never need a withdrawal scope to function.

Trade-only sub-account vs full-access key vs handing over your login

Three arrangements can put a manager to work on your Deribit account. They differ enormously in what the manager could do on their worst day. The middle and right columns are the ones that turn a strategy problem into a custody problem.

Trade-only sub-accountFull-access API keySharing your login
Can place ordersYesYesYes
Can withdraw fundsNo, wallet:read_write withheldYes, key holds withdrawal scopeYes, full control
Can change security settingsNoDepends on scopes grantedYes
Reaches your other balancesNo, isolated sub-accountDepends on account structureYes, entire account
You revoke access byDeleting one API keyDeleting one API keyChanging password and 2FA
Custody stays withYouEffectively the managerEffectively the manager

Only the first column keeps custody with you while letting the manager trade. The other two collapse back into the custodial model that failed so many depositors in the last cycle, where your holdings depend on a counterparty choosing not to move them. For the broader comparison of account structures, see non-custodial crypto asset management.

How do I verify and revoke before I fund the account?

Two checks take about five minutes and are worth doing before real capital goes in.

To verify, open the API section of your Deribit account panel and read the scope list on the key you created. Confirm it shows the trading and read scopes and does not show wallet:read_write. Confirm the IP whitelist field carries the manager’s addresses. Many managers will also demonstrate on a small balance first: watch an order appear and fill in your own account view, then confirm no withdrawal option is reachable through the key.

To revoke, delete the API key from the same panel. Access ends immediately and needs nobody’s consent. The manager’s systems are disconnected the moment the key is gone, and because the funds were always in your sub-account, nothing has to be returned. Revocation is the exit that custodial arrangements cannot offer, where leaving means a withdrawal request and a wait.

The takeaway

A trade-only Deribit sub-account turns “we can’t touch your money” from a marketing line into something you configure and inspect yourself: three scopes granted, one scope withheld, an IP whitelist added, a single key handed over. The strategy runs; the withdrawal path stays dark. You hold the keys, and the manager only trades. That is the operational floor Packed Capital builds every client relationship on. Assets stay in your own Deribit account through a restricted, trade-only sub-account we can never withdraw from, while we run rules-based, hedged options-income strategies refined since 2018 across $100M+ in monthly trading volume. Minimums start at $100k for the Option Wheel and $1M for the Hedged Grid, with a target of 20-25% a year stated as a target, not a promise, and the risks named alongside it.

FAQ

What Deribit API scopes make a trade-only sub-account? Grant account:read, trade:read_write, and wallet:read, and leave out wallet:read_write. The trade:read_write scope allows placing and cancelling orders; wallet:read allows reading balances; withholding wallet:read_write is what removes the ability to withdraw. That combination is a restricted API key that trades but cannot move funds.

Can a manager withdraw with my API key if it only has trade:read_write? No. Withdrawals on Deribit require the wallet:read_write scope, and a trade-only key does not carry it. Deribit rejects any withdrawal request on that key at the system level, whether it comes from the manager or from anyone who obtained a copy of the key. To disable a withdrawal API key path entirely, never grant the wallet write scope in the first place.

How do I revoke a Deribit API key if I want the manager out? Open the API section of your account panel and delete the key. Access ends instantly and requires no approval from the manager. Because your capital never left your own sub-account, there is nothing to claw back; the manager’s software is simply disconnected.

Does an IP whitelist replace removing the withdrawal permission? No, they work at different layers. The IP whitelist limits which machines the key functions from, so a leaked copy is useless elsewhere. Removing wallet:read_write removes the withdrawal capability itself. Use both: withhold the withdrawal scope, and restrict the key to the manager’s IPs or CIDR range.

Should managed capital go in a sub-account or my main Deribit account? Use a dedicated sub-account. It isolates the managed balance from the rest of your holdings, so the trade-only key cannot even see coins outside the mandate, and it keeps reporting clean. Fund the sub-account with working capital and keep long-term holdings in your main account or cold storage.

Is a trade-only sub-account enough to make managed crypto safe? It removes one specific risk completely: the manager cannot take your funds. Exchange risk, strategy and market risk, and key hygiene still apply, so drawdowns remain possible and venue quality still matters. Treat the trade-only structure as the custody floor, then diligence the rest. If you want to discuss the setup for a mandate, reach us via contact.


Sources: Deribit developer docs — access scopes · Deribit developer docs — creating an API key · TradeLink — how to secure an API key

Put your idle crypto to work
Non-custodial. Your keys, our strategy. Target 20–25% / yr.
Request access