Golden — how it works
Golden is a diversified, Kelly-weighted portfolio running on Bitunix USDT-M perpetuals. The current live instance (V34) trades six assets — BTC, ETH, SOL, BNB, BCH and LTC. This page documents how the system works — the methodology, the validation framework, the fee structure and the live infrastructure. Specific numbers (sleeve count, weights, headline metrics) live with each experiment in the Lab and with the running bots on /live.
Por qué el multiplicador de exposición (no el sleeve LTC) es la palanca de riesgo dominante, y la comparación limpia original vs de-risk a ×1/×2. En español, lenguaje plano.
Overview
The product is a proprietary algorithmic trading bot that operates the account via the Bitunix API. Users sign up with a referral code and the bot trades their account. Revenue comes from the Bitunix affiliate programme.
Strategies
The portfolio holds independent sleeves, each combining a signal, an asset, a timeframe and a Kelly weight. Sleeves are grouped into five alpha families so that no single class of edge dominates the portfolio.
- Breakout — Keltner / Donchian / range-expansion. Enter on a real volatility break, exit on mean-reversion. Return anchor.
- Multi-timeframe trend — Triple Screen, Multi-TF confirmation. A long EMA defines the regime; a short signal times the entry. Rejects most counter-trend noise.
- Momentum — dual momentum (Antonacci), momentum-of-momentum, cross-sectional rank, time-series momentum at long lookbacks (≥250 bars).
- Pairs / cloud / mean-reversion — pairs cointegration, Ichimoku, DCA-grid hybrid. Defensive anchors with low drawdown that pay during ranges.
- Funding — funding-rate signal and funding z-score. Shorts get paid when longs are over-extended; second alpha source orthogonal to price.
Weights are Kelly-optimised (a fraction below full Kelly, to dampen estimation noise) with portfolio-level constraints (per-asset and per-sleeve caps) so that no single asset dominates risk. The exact sleeve list, asset mix and current weights of the running bots live on /live. The full strategy catalog (live + validated + archived) is at /strategies.
Methodology
Each strategy had to pass five filters before entering the portfolio:
- Regime stability — Sharpe > 0 in ≥ 2 of 3 post-FTX epochs.
- Walk-forward OOS — 18 rolling 90-day windows with step 45–60 days; must stay positive in > 60% of them.
- Composite score — weighted blend of Sharpe + turnover + revenue − drawdown.
- Correlation check — average correlation with other sleeves < 0.5.
- Full-period test — must not degrade the aggregated portfolio's Sharpe.
The three post-FTX epochs used to test regime stability are: E4 recovery 2023, E5 ETF era 2024, E6 modern 2025→. A strategy that only worked in one epoch was rejected as brittle.
Why the portfolio is robust
- Decorrelated sleeves (average pairwise correlation under 0.2)
- Five distinct alpha families — if one family fails, others carry
- Four assets diversifying idiosyncratic risk
- Validated across COVID 2020 → ETF era 2024 → modern 2025
- Walk-forward OOS positive in > 80% of windows
- Volatility targeting (50% annual) + selective 5% stop-losses
- Real historical funding rates modelled — not constant
- Kelly-optimal weights (a fraction below full Kelly) with per-asset and per-sleeve caps
- 32 families rejected — rigor in filtering
Fees & funding
Backtests assume the worst-case retail tier: Bitunix VIP 0 with a 20% referral discount. Real users with monthly volume pay the same or less, so live results should be equal-or-better than the reported backtests.
| VIP tier | Taker base | With referral (−20%) | Monthly volume |
|---|---|---|---|
| VIP 0 (backtest assumption) | 0.060% | 0.048% | new user |
| VIP 1 | 0.050% | 0.040% | ~$1M/mo |
| VIP 2 | 0.050% | 0.040% | ~$5M/mo |
| VIP 3 | 0.040% | 0.032% | ~$10M/mo |
| VIP 5 | 0.0350% | 0.028% | ~$50M/mo |
Affiliate programme: revenue comes from the Bitunix affiliate programme on referred users' activity. Funding rate is fetched from live historical data and applied to each sleeve that holds an open position across the 8h funding window.
Leverage & margin
There are two distinct things called "leverage" and conflating them is the single most common source of confusion. They affect different parts of the system and the right value for each is set independently.
1. Position-size leverage (the backtest dial)
How much of the account is allocated to each position. If leverage = 2× on a $10k account, a fully long sleeve has a $20k notional position. This is the only leverage that touches the strategy's PnL, fees and drawdown.
- Set in the strategy config (a BacktestConfig field). It is part of the quantitative design.
- Drives fees linearly: bigger notional = more fees paid per round-trip.
- Drives drawdown: 2× more leverage roughly = 2× the equity swings.
- Typical value across our portfolios: 1× – 2× per sleeve. Higher than that and most strategies start producing drawdowns too large to be sellable for retail.
2. Exchange leverage (the operational dial)
How much margin Bitunix requires to hold a given position. At exec_lev = 20×, a $20k position only ties up $1,000 of account margin on Bitunix. The remaining $9k stays as free margin available for other positions.
- Set when the bot sends an order to the exchange. It is part of the operational design.
- Does not affect fees or PnL — the notional is already fixed by the position-size leverage.
- Does affect how many simultaneous positions can be open before the account runs out of margin.
- Does affect operational liquidation thresholds in isolated mode (see below).
The two-by-two of equivalences
| Capital | Position-size lev | Notional | Exchange lev | Margin required | Fees / PnL |
|---|---|---|---|---|---|
| $10k | 2× | $20k | 5× | $4,000 | identical |
| $10k | 2× | $20k | 20× | $1,000 | identical |
| $10k | 4× | $40k | 10× | $4,000 | 2× the fees + DD |
Same position-size lev = same fees, same PnL, same drawdown. Different exchange lev only changes how much of the account sits as locked margin vs free margin.
Cross vs Isolated margin
Bitunix supports two margin modes per position. We tested both rigorously across the leverage sweep (see the Leverage & margin section above):
- Cross: every open position shares the account's free margin pool. Margin used = total notional ÷ exec_lev. The full account equity is the buffer.
- Isolated: each position has a dedicated margin slot = position_notional ÷ exec_lev. The position liquidates when the underlying asset moves adversely by ~ 1/exec_lev. The rest of the account is shielded from that liquidation, which is the appeal of isolated.
The Phase 4 stress test is unambiguous: we deploy in CROSS at exec_lev 20×. Reasons:
- Notional rarely exceeds 150% of equity across all candidates and all 7+ years tested. At cross/20× this means worst-case margin used ≈ 7.4% of the account → 92.6% of equity stays as free margin even at peak exposure. Massive headroom for slippage spikes, drawdowns and additional positions.
- Isolated at exec_lev 20× is catastrophic: most of the portfolio's sleeves trade assets that occasionally move > 5% adverse in a single 4h bar. At 20× isolated, every one of those is an automatic liquidation — historically the large majority of sleeves are unsafe under isolated / 20×.
- Isolated at exec_lev 3× is the only safe isolated configuration, but it pins ~50% of equity in margin (vs 7% in cross/20×). The unused capital in each isolated slot cannot fund other positions, so the strategy can't open all of its target sleeves. Massive efficiency loss for a protection that the diversified portfolio's portfolio-level liquidation check already provides.
What this means for an illustrative $10k account (worst case)
| Item | Value | Note |
|---|---|---|
| Worst-case total notional observed | $14,800 (148%) | across 7+ years backtested |
| Margin required @ exec_lev 20× cross | $740 | = notional ÷ 20 |
| Free margin remaining | $9,260 | 92.6% of account |
| Account drawdown before margin pressure | ~30% | before any forced reduction |
| Max simultaneous positions absorbed | ~22 | combined peak exposure |
TL;DR for the bot config
- Position-size leverage (in the backtest config): 1× – 2× per sleeve. This is the risk dial. Touch only when changing the strategy.
- Exchange leverage (Bitunix order config): 20× in CROSS mode. This is the operational dial. Has zero impact on PnL.
- Never use isolated with our portfolios: either liquidates individual sleeves on normal volatility (at 20×) or wastes capital (at 3×).
Architecture
The platform has three moving parts:
- Workers (Python, Railway) — two isolated services: a paper worker for the demo bot and a live worker for the real-money bot. Each polls Bitunix public REST every 60s for new closed 1h/4h bars, dispatches to each sleeve runner, and emits signals and simulated/real trades into Supabase.
- Database (Supabase / Postgres) — tables: profiles, portfolio_configs, sleeve_states, signals, trades, equity_snapshots, bot_logs, health_pings. RLS enforces admin-only reads for non-self rows.
- Dashboard (Astro static site, Vercel) — golden.infibex.com. Supabase Auth for session + allowlist. Live page (polls Supabase), Backtesting pages (pre-rendered from JSON), Admin panel (backed by /api/admin serverless function).
Data source for both research and live execution is Bitunix public REST. Research backtests originally used Binance USDT-M perpetuals via CCXT (> 99% correlation on majors); the live engine uses Bitunix directly so signal prices match execution.
Runbook
Current mode
The platform runs two independent workers. The paper worker runs the demo bots in dry_run mode — signals and sleeve-state updates are written to Supabase but no real orders are placed. A separate live worker runs the production bot against a real Bitunix sub-account, where signals are executed as real orders on real capital. Each bot's mode is stored per-bot in the bot_settings table; there is no global mode switch — the two workers are isolated by design so the demo can never move real money.
Inviting users
Admins invite users from Admin. Supabase sends the invite email; the user lands on /reset-password to set their password. Allowlist status and role can be edited inline.
Monitoring
Live shows worker heartbeat (green if < 7 min since last ping), current sleeve positions, recent signals, trades (simulated on the paper worker, real on the live worker), and the bot log stream — all refreshed every 15s from Supabase.