Skip to main content

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 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.

​
Why sub-accounts matter for risk management

Isolated balance

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.

Per-strategy P&L clarity

Each sub-account’s trade history is independently inspectable. “How is my experimental mode performing?” is answered by looking at one sub-account.

Experimental safety

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.

One venue, multiple bots

Run multiple TradingBot containers, each pointing at one sub-account on the same venue. Each bot operates independently within its sub-account.

​
When to use sub-accounts

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.
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.
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.
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.
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.

​
When NOT to use sub-accounts

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.
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.
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.

​
How sub-accounts work in unCoded’s architecture

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.
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.
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.
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.

​
Setting up sub-accounts

1

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).
2

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.
3

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.
4

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.
5

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.
6

Run for the validation window

4 weeks minimum for most experiments. Watch behavior daily for the first week, weekly thereafter.
7

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.

​
Best practices

  • ✅ 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.

​
What’s next

Risk overview

The full risk framework.

Capital allocation

Sizing within and across sub-accounts.

API Key Security

Per-sub-account key discipline.

TradingBot

The single-exchange-per-container design that extends to sub-accounts.
Last modified on May 3, 2026