> ## Documentation Index
> Fetch the complete documentation index at: https://uncoded.ch/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Sub-Accounts — Strategy Isolation

> Use sub-accounts to isolate experimental strategies from your validated production setup. A misbehaving experiment can't affect what's working.

<Info>
  **Sub-accounts give you strategy isolation without going to a different exchange.** Binance, Bybit, OKX, and others support sub-accounts: separate API keys, separate balances, separate fee tiers, but managed under one master account. Use them to keep experimental strategies from affecting validated production setups.
</Info>

## Why sub-accounts matter for risk management

<CardGroup cols={2}>
  <Card title="Isolated balance" icon="lock">
    Each sub-account has its own balance. A bad strategy in one sub-account can lose its allocated capital but cannot reach into another sub-account.
  </Card>

  <Card title="Per-strategy P&L clarity" icon="chart-bar">
    Each sub-account's trade history is independently inspectable. "How is my experimental mode performing?" is answered by looking at one sub-account.
  </Card>

  <Card title="Experimental safety" icon="flask">
    New modes, new strategies, new symbols can be tested in a sub-account with small capital. If they misbehave, only the small capital is at risk.
  </Card>

  <Card title="One venue, multiple bots" icon="server">
    Run multiple TradingBot containers, each pointing at one sub-account on the same venue. Each bot operates independently within its sub-account.
  </Card>
</CardGroup>

## When to use sub-accounts

<AccordionGroup>
  <Accordion title="Testing a new mode" icon="flask">
    You want to try Tsl2Sell (Mode 7) but you've been running BasicMode (Mode 4) successfully. Don't disturb your validated setup.

    Pattern:

    1. Create a sub-account on Binance.
    2. Generate API key for the sub-account (same security disciplines).
    3. Spin up a second TradingBot container with the sub-account credentials.
    4. Allocate `$1,500–$3,000` to the sub-account.
    5. Run Tsl2Sell on the sub-account for 4+ weeks.
    6. If it works, scale up. If not, only the small sub-account capital was at risk.
  </Accordion>

  <Accordion title="Testing a new symbol" icon="boxes-stacked">
    Same pattern as new mode. New symbol means new market behavior, possibly new edge cases. Test on small sub-account capital before adding to your main allocation.
  </Accordion>

  <Accordion title="Testing a SignalEditor recipe" icon="wand-magic-sparkles">
    A new custom strategy you've authored. Pre-built modes are well-tested; custom strategies aren't yet.

    Run the recipe in a sub-account first. After it's validated forward-test, consider promoting to your main account.
  </Accordion>

  <Accordion title="Strategy diversification within one venue" icon="diagram-project">
    You want to run BasicMode AND FullBullMarket simultaneously on Binance. Running both on the same balance creates capital-conflict potential.

    Better: Sub-Account 1 runs BasicMode, Sub-Account 2 runs FullBullMarket. Each has dedicated capital, each manages independently.
  </Accordion>

  <Accordion title="Family / partner account separation" icon="user-group">
    You manage a partner's capital alongside your own. Sub-accounts let you cleanly separate the two — your partner's sub-account has its own API key, its own bot, its own P\&L statements for tax/accounting.
  </Accordion>
</AccordionGroup>

## When NOT to use sub-accounts

<AccordionGroup>
  <Accordion title="❌ For first-month operators" icon="ban">
    Sub-accounts add operational complexity. If you're new to unCoded, learn the basics on a single account first.

    Add sub-accounts after month 2 when you're comfortable with the bot's behavior.
  </Accordion>

  <Accordion title="❌ When you don't have enough capital to fragment" icon="ban">
    Each sub-account needs sufficient capital to operate (per-mode minimums apply). Don't fragment `$10,000` into 4 sub-accounts of `$2,500` each — most modes won't operate effectively at that size.

    Consolidate at lower capital; fragment at higher capital.
  </Accordion>

  <Accordion title="❌ As substitute for proper backtesting" icon="ban">
    Sub-account "live testing" is forward-testing. It's not a substitute for backtesting. Backtest first, then sub-account forward-test.

    Going live in a sub-account without prior backtesting is just spending money to discover what backtesting would have shown for free.
  </Accordion>
</AccordionGroup>

## How sub-accounts work in unCoded's architecture

<AccordionGroup>
  <Accordion title="One TradingBot per sub-account" icon="robot">
    The single-exchange-per-container design extends naturally to sub-accounts: one TradingBot container per sub-account.

    Each container uses the sub-account's API key. Each operates independently. They share the same database for configuration but operate against different exchange-side balances.
  </Accordion>

  <Accordion title="Shared Dashboard surfaces all" icon="gauge">
    The Dashboard reads from the shared database. It surfaces:

    * Per-sub-account positions and P\&L.
    * Aggregate analytics across all sub-accounts.
    * Per-sub-account configuration (modes, pairs, kill-switch state).

    You manage all sub-accounts from one Dashboard.
  </Accordion>

  <Accordion title="Per-sub-account API keys" icon="key">
    Each sub-account has its own API keys. Apply universal security:

    * Spot trading + read only.
    * Withdrawals NEVER enabled.
    * IP allowlisted to your VPS.
    * 2FA on the master account (sub-accounts don't have separate 2FA on most venues).
    * Quarterly rotation across all sub-account keys.
  </Accordion>

  <Accordion title="Per-sub-account TelegramBot (optional)" icon="paper-plane">
    Most operators run one TelegramBot reading from the shared database — gets all sub-account close notifications.

    For per-sub-account isolation in notifications: deploy one TelegramBot container per sub-account, each with its own chat ID. More setup, more separation.
  </Accordion>
</AccordionGroup>

## Setting up sub-accounts

<Steps>
  <Step title="Create a sub-account at the venue">
    Most venues have a sub-account creation flow in the master account's settings. Create the sub-account, give it a descriptive name (e.g., `experimental-tsl2sell`).
  </Step>

  <Step title="Fund the sub-account">
    Transfer capital from your master account to the sub-account. This is an internal transfer (not a withdrawal). Each venue's UI handles this; doesn't go through the API.

    Initial allocation: small. `$1,500–$3,000` for experimental strategies.
  </Step>

  <Step title="Generate API key for the sub-account">
    From the sub-account's API management page, generate keys with:

    * Spot trading + read.
    * No withdrawals.
    * No internal transfers.
    * IP allowlisted to your VPS.

    Save key + secret in your password manager with the sub-account's identifier.
  </Step>

  <Step title="Spin up a second TradingBot container">
    Add a new TradingBot service to your Docker compose, pointing at the same database but with the new sub-account's API credentials.

    Use a distinct container name and `EXCHANGE_ID` configuration.
  </Step>

  <Step title="Configure the experimental setup in the Dashboard">
    Add the sub-account as an exchange in the Dashboard. Configure the experimental mode, pair, capital. Watch the connection-state indicator turn green.
  </Step>

  <Step title="Run for the validation window">
    `4` weeks minimum for most experiments. Watch behavior daily for the first week, weekly thereafter.
  </Step>

  <Step title="Decide promote or retire">
    After validation:

    * **Promote**: scale capital and consider migrating the strategy to the main account.
    * **Retire**: stop the experiment, withdraw the capital from the sub-account, archive the configuration.

    Either way, the sub-account stays available for the next experiment.
  </Step>
</Steps>

## Best practices

<Tip>
  * ✅ **Use sub-accounts for any new mode/strategy** before promoting to main account.
  * ✅ **Allocate small capital initially** — `$1,500–$3,000` for experiments.
  * ✅ **Apply universal API key security** to every sub-account key.
  * ✅ **Run separate TradingBot containers** per sub-account.
  * ✅ **One Dashboard for all** — central operator surface.
  * ✅ **Track per-sub-account P\&L separately** during weekly reviews.
  * ✅ **Tax-report each sub-account independently** — venues typically produce per-sub-account history.
  * ✅ **Don't fragment capital below mode minimums** — consolidation matters at smaller total capital.
  * ✅ **Use descriptive sub-account names** — `experimental-tsl2sell-2026q2` is clearer than `Sub-Account 3`.
  * ✅ **Quarterly rotation across all sub-account keys** — same cadence as main.
  * ✅ **Rotate via the master account's API management** — venue-specific UI, but the principle is universal.
</Tip>

## What's next

<CardGroup cols={2}>
  <Card title="Risk overview" icon="shield" href="/risk-management/overview">
    The full risk framework.
  </Card>

  <Card title="Capital allocation" icon="money-bill-wave" href="/risk-management/capital-allocation">
    Sizing within and across sub-accounts.
  </Card>

  <Card title="API Key Security" icon="key" href="/exchanges/api-key-security">
    Per-sub-account key discipline.
  </Card>

  <Card title="TradingBot" icon="robot" href="/modules/tradingbot">
    The single-exchange-per-container design that extends to sub-accounts.
  </Card>
</CardGroup>