Skip to main content
BULK does not have a special “isolated mode” toggle. Instead, isolated margin is achieved through the account structure itself. There are two ways to isolate risk:
  1. Automatically (per instrument): submit an order with the i (iso) flag set and the protocol routes it into a per-instrument isolated account (IsoAccount) attached to your master/sub-account.
  2. Manually (per book): create a sub-account, fund it, and trade from it. The risk engine evaluates it independently.

​
Isolated Accounts (Implicit, Per Instrument)

Order actions that produce a position (l, m, st, tp, rng, trig, trl) carry a required i boolean. When i = true, the order is routed into a per-instrument IsoAccount attached to the signing master/sub-account.
Isolated accounts are entirely flag-managed. You never set the IsoAccount pubkey as account on a transaction, register agents on it, or query it via current-state POST /account query. It is created, traded, and torn down through ordinary signed actions on the parent master/sub-account. Its pubkey appears on read-only rows (isoPubkey), can be queried directly through the history query types on POST /account, and is accepted as the to of an internal transfer.
Properties:
  • One instrument per isolated account (e.g. the BTC-USD isolated account only holds BTC-USD positions).
  • The isolated account is auto-derived from the signing account and the instrument. No separate “create” action is required; the first i = true order materialises it.
  • It is off-curve: the pubkey is deterministically derived from the parent and the instrument, and has no private key. Only the parent account (or its registered agent wallets) can manage it.
  • It has its own balances, positions, and margin. The same portfolio margining engine applies, but since the account is limited to a single instrument, the margin calculation reduces to a single-position evaluation with no cross-asset correlation benefit.
  • Before an i = true order executes, BULK funds the isolated account to a buffered target covering leverage-based margin and the position’s size-dependent liquidation reserve. If the account already has sufficient collateral, no additional margin is moved.
  • A liquidation on the isolated account only touches that account’s margin. The signing master/sub-account is unaffected.

​
Account and History Surfaces

Current account snapshots follow the current account tree: isolated-account rows appear alongside base-account rows on the attached parent master or sub-account. Each isolated-account row carries: Aggregated fullAccount queries on a master or sub-account return both base-account rows and isolated-account rows in one response. Group on iso and isoPubkey to render per-instrument PnL/risk. Current-state POST /account types accept only master and sub-account pubkeys, while the history types on that endpoint accept an isolated pubkey for its full physical history. Paginated history uses immutable row-time ownership rather than the current account tree. A parent query merges only its own primary rows and sparse alias rows that stored that parent when they were written. A direct isoPubkey query reads that pubkey’s entire physical primary history across isolated and base lifecycle states. Detaching or reparenting never rewrites history: the former parent keeps its earlier rows, and the new parent sees only rows written after the new row-time relationship was recorded. The query cost does not grow with the parent’s current or historical lane count. A direct request reads one stream; a parent request merges at most its primary and row-time alias streams. These streams have independent hot retention, so aggregate and direct queries can report different minAvailableSlot values. See Query Account for the request and cursor shape.

​
Top-Up and Settlement

To add margin, send an internal transfer with to = isoPubkey. The other direct read-only use is a physical-history query for that pubkey:
transfer, createSubAccount, and removeSubAccount trigger a same-tick PnL/risk refresh on touched accounts (including isolated accounts), so margin headroom updates immediately without waiting for the next snapshot tick.

​
Removing an Isolated Account

Isolated accounts are removed via the removeSubAccount action submitted by the parent master/sub-account, with toRemove set to the isolated account’s pubkey. The isolated account must have:
  • No open positions
  • No open orders
On removal, remaining margin is swept back to the parent automatically. Removal affects current account state only. Historical rows keep the parent recorded when each row was written; they are not moved, relabelled, or deleted because the isolated account was removed.

​
Isolated Margin via Sub-Accounts

For more flexibility, you can isolate manually using sub-accounts. Create a sub-account, transfer in the exact amount of tokens you are willing to risk, and trade from it (set the transaction account to the sub-account pubkey; the master, the sub-account itself, or an authorized agent wallet signs):
  • The risk engine evaluates the sub-account independently.
  • If the sub-account hits its maintenance margin threshold, only that sub-account is liquidated.
  • The master account’s equity and other sub-accounts remain untouched.
  • Unlike auto-created isolated accounts, sub-accounts can hold positions across multiple instruments and benefit from full portfolio margining; cross-asset correlations and hedging discounts apply.
This gives you granular capital allocation with the full power of portfolio margin applied to a smaller, separate account.