CONTINUUMManager Monitor
Connecting—
Checking connection
Data limitations
Who to trust, and how much
Overview
| Evidence | Status | Funded live | Track | ||||||
|---|---|---|---|---|---|---|---|---|---|
Production history · BTC benchmark · completed UTC days
BTC beta & tail correlations
Loading return streams
Production history · BTC benchmark · completed UTC days
BTC beta & tail correlations
Manager-to-manager correlation · same BTC day filter
How these calculations work
Beta measures sensitivity to BTC: 0.20 means an estimated 0.2% manager move per 1% BTC move, not a guaranteed response. Correlation measures how closely daily returns move together. Both use only shared, completed UTC days, retain observed flat days, and exclude missing days and gaps between sources.
Up/down means BTC above/below 0%. Worst/best 10% means the lower/upper BTC daily-return decile within each row or pair's shared window, restricted to negative/positive BTC days. Cutoffs can differ across pairs; hover for dates and thresholds. These are historical BTC scenarios, not a guarantee about future extremes or a formal tail-dependence estimate.
Avg daily return and loss days show the manager's average return and frequency of losses within the selected scenario. Hover a matrix cell for the frequency both managers lost. Correlations and beta require 30 days, or 20 in a tail. Samples below 150 days (40 in a tail) are marked limited. A flat series has no defined correlation; insufficient data is not zero risk.
All risk comparisons are in USD. ETH/DOGE mandate histories are translated at daily USD closes; native performance on manager pages is unchanged. CSV history remains manager-reported. SFOX returns remove recorded capital flows and take priority on overlapping dates. Each row uses the named book, not a blend of its sibling books. Production dates are manager-reported; earlier testing remains in the manager's full-key comparison.
Not enough return history to calculate correlations.
|ρ| ≤ 0.15
0.16–0.35
0.36–0.50
> 0.50
— fewer than 30 matched days; * limited sample
How to read this page
Evidence tier
How verifiable the record is, before you look at any number. API + Live means a read-only exchange key confirms the history and our own funded account is producing an independent record — the strongest case. API verified means the exchange record is signed and read-only but we have no money in yet. CSV only means the manager typed the numbers into a spreadsheet — nothing independently confirms them, so scale slower no matter how good they look.
Observed Sharpe
Return per unit of risk, computed from the record we can actually see (exchange API, or CSV when that is all there is). Sharpe ≈ annualized return ÷ annualized volatility. Rule of thumb: 1 is respectable, 2 is very good, 3+ over a long record is exceptional (or a red flag on a short one). It says nothing about where the returns came from — a Sharpe earned on Bybit perps is not automatically achievable on SFOX spot.
SFOX model Sharpe
The manager re-models their strategy as if it had traded on SFOX spot — real venue constraints, spot-only instruments, estimated fees. This is what they claim our account should look like. The small print under it shows the model minus the observed record: a big positive gap means they are promising SFOX will be better than what they demonstrably did elsewhere — treat that with suspicion; a negative gap (drag) is the honest cost of moving venues. Where the manager already trades pure spot (SmartTech), there is no separate model — the record is the SFOX-style record, so the same number is shown.
Shrunk Sharpe
The observed Sharpe is what the record says; the shrunk Sharpe is what the length of that record can support. Start from a prior that assumes no skill (mean 0, SD 1.0 — a true Sharpe of 2 is a two-sigma manager), then weight the observed number by how precisely it was measured: weight = prior variance ÷ (prior variance + SE²), with SE ≈ √((365 + Sharpe²/2) ÷ days). A multi-year record keeps most of its Sharpe; a two-month record collapses toward zero on its own. Judge managers on the shrunk number and watch it climb as the live record grows — that is the same statistic as the t-stat, expressed as something you can compare to your allocation bar. One honesty rule: separate exchange keys are separate accounts, so managers with several keys (Zavara) are scored on the most recent key only — stitching accounts overstates the sample. For CSVs the math is identical but the inputs are unverified; that risk lives in the Evidence chip, not the formula.
Funded live
Our own SFOX account with real money, measured independently with deposits and withdrawals removed. Small and short for everyone right now, so expect it to look unimpressive — its job is to slowly confirm (or contradict) everything to its left as it grows.
Drawdowns
No funded accounts yet.
Drawdown is the decline from a high-water mark, not the return since funding. Policy: freeze additions at 5% daily-close drawdown, review a 50% withdrawal at 10% daily-close drawdown, and review flattening at 15% intraday. Daily NAV closes at 00:00 UTC and uses daily-close peaks; intraday drawdown includes hourly and minute peaks. Statistical model bands are separate context. Alerts do not execute trades.
How the risk lines work
75th percentile: one in four simulated paths reaches this drawdown.
90th percentile: one in ten simulated paths reaches this drawdown.
95th percentile: one in twenty simulated paths reaches this drawdown. These model levels are not automatic policy actions or proof a strategy has failed.
Continuum SFOX · current positions and exposure
Live Positions
—
Live Performance
—No funded account history
Open SFOX positions
—0 open SFOX positions.
How the limits work — and what a breach actually means
Each limit answers one question: how deep does a dip have to be before "normal bad luck" stops being a believable excuse? We take the manager's own daily returns, resample them in consecutive blocks (so losing streaks stay intact), and replay 12,000 simulated runs the same length as the live record. Every run is a healthy version of the strategy — same edge, same volatility, different luck. Then we look at how deep healthy runs dip.
Monitor — 1 in 4 healthy runs dips this far. Totally ordinary. Stop adding money, stay invested.
Halve — only 1 in 10 healthy runs gets here. Luck is now an unlikely explanation. Cut the allocation in half.
Kill — only 1 in 20 healthy runs ever gets this deep. In plain terms: if you always cut at this line, then out of 20 genuinely working managers you would wrongly cut about 1 — that is the price. But a broken strategy (one whose edge is gone, drifting on volatility alone) reaches this depth far more often, and unlike the healthy one it keeps sinking instead of recovering. The line is where the odds flip from "probably unlucky" to "probably broken."
The gauge on each card shows today's drawdown as a share of the distance to the kill line, with ticks at monitor and halve. Limits are sized to the live record, so they start tight and loosen as more days accumulate — a brand-new account gets much less rope than a yearlong one.
Data source
Objective
Manager equity curves
Normalized to 100 at each record's real startNo manager equity records
Weights and volatility
Weights rebalance automatically to 100%| Manager | Record | Base vol | Effective vol | Vol multiplier | Capital weight | Allocation | Risk contrib. |
|---|
—
Selected manager
—
—
Equity curve
—Waiting for data
Selected window
Statistics
Selected-period risk
Underwater
Waiting for drawdown data
Trailing risk-adjusted return
Rolling 90-day Sharpe
Needs 90 daily observations
Track record
Monthly returns
Live account
Rolling gross & net exposure · % of NAV
No exposure snapshots yet
—
Live SFOX activity
Trades
| Time | Effect | Market | Notional | Realized | Fee | Financing |
|---|
Reference
Details
Selected manager
—
Account value—
—
—
Cumulative return
Waiting for data
Production vs full API history · includes earlier testing
Default charts and calculations use Mo's reported production windows: BTC Apr 22, ETH Aug 7, and BTC + ETH Aug 10. BTC includes Apr 22 returns from the Apr 21 UTC close; ETH and BTC + ETH start from their inception day's UTC close. Intraday inception NAV is not reconstructed. Full key retains all earlier API activity separately.
Period returns
Monthly returns
Summary
Decision
Trailing 90-day risk
Rolling 90-day Sharpe
Needs 90 daily returns
Rolling 90-day volatility
Needs 90 daily returns
Drawdown from peak
Waiting for data
Historical drawdowns
Exposure · % of NAV
Exposure appears once the account is funded
Who traded this
Trades
| Time | Effect | Market | Notional | Realized | Fee | Financing |
|---|
Account & reference
Fidelity
—
Live account costs
Recorded SFOX fees, coverage, turnover, and drag
Live account costs
Recorded SFOX fees, coverage, turnover, and drag| Account | Equity | Quoted tier | Recorded fee | Fee coverage | Turnover (30d) | Fee drag (30d) |
|---|
Robuxio
Jack's own capital. Rebuilt from the fund GAV endpoint and the hand-kept flow ledger.
Performance
—No fund GAV history yet
Deposits and withdrawals
——| Date (UTC) | Type | Asset | Amount | Running contributed | Fund GAV that day |
|---|
No flows recorded.
How this is built
Read this before quoting a number off itThe fund GAV endpoint reports the whole share class, not you. Differencing it raw counts a subscription as a gain. Each day's return here is (GAV today − your flow today) ÷ GAV yesterday − 1.
Other investors are invisible to us. Their subscriptions and redemptions land in the return as if they were performance. The largest single-day residual after removing your own flows is shown as —, which is the size of that error.
The flow ledger is typed by hand. Binance cannot see money moving through Robuxio's own ledger, so config/robuxio_flows.json is the only record. An unrecorded deposit reads as a new high-water mark. Update it when you add or withdraw.
Each class is scored in its own unit. The BTC class earns BTC; reading it in dollars scores it on the BTC price, not on Robuxio.
GAV sits above what the account actually holds, and nobody has explained why. Robuxio takes no fee, so GAV should equal the Binance balance. It does not: it runs about 1% higher. That is not another investor (you were 100.00000000% of the class at inception and no subscription appears in 477 daily steps), not assets elsewhere on the key (every other wallet reads zero), and not the mark (the USDT leg is around 2.1 BTC, so a 1% price move shifts this by 0.02 BTC, not 0.4). Current value and P&L on this page are taken from Binance rather than from the curve for that reason.
Some of the withdrawals are your own 3% management fee, not redemptions. A 3% annual fee drawn monthly is 0.250% of GAV, and the draws cluster there tightly enough to separate from every real redemption. Both totals are under the flow table.
The two clocks do not line up. Robuxio calculates the fund once a day at 23:55 UTC, so the GAV here is normally yesterday's close, while the Binance figure it is compared against is a live mark. That is why the share of the fund can read slightly over 100%.