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.
BROCCOLI714USDT * MinimalMoney
Modest positive return of +0.95% over the configured window. Max drawdown reached -3.04%, so the equity path was relatively contained.
BROCCOLI714USDT | 6MinimalMoney.json | 2025-01-01 - 2025-12-31 | +0.95% | 81,737 closed trades | 100.0% closed WR | 13 open orders
Headline Performance
Data source -
GET /backtests/{id} + /equity + /trades * Fields used: return_pct, final_value, total_profit, win_rate, fulfilled_trades, active_orders, unrealized_pnl_exit_net, max_profit, min_profitReturn
+0.95%
Final Value
10,094.99 USDT
Portfolio PnL
+94.99 USDT (realized + unrealized)
Realized Profit
+82.47 USDT (closed trades only)
Unrealized PnL
+12.52 USDT (open positions, mark-to-market)
Win Rate (closed)
100.0% (excludes 13 open orders)
Closed Trades
81,737
Open Orders
13
Best Closed Trade
+0.0020 USDT
Worst Closed Trade
+0.0007 USDT
TL;DR
The MinimalMoney strategy on BROCCOLI714USDT returned +0.95% over 2025-01-01 to 2025-12-31, turning 10,000.00 USDT into 10,094.99 USDT.
It executed 81,737 closed trades with a 100.0% win rate (closed only), hitting a max drawdown of -3.04%. Note: that win rate excludes 13 still-open orders carrying +12.52 USDT of unrealized P&L.
It outperformed Buy & Hold by +56.68% on the same window.
Performance KPI Metrics
Data source -
GET /backtests/{id} + /equity + /trades * Fields used: server aggregates from /daily-stats and /extras (Total Fees, Gross Profit/Loss, fill-type counts) plus <AnalyticsCharts> KPI strip * Transform: bt.* + dailyStats.totals + extras.deep_dive.fill_type_breakdownSix-card KPI strip mirroring the live UI - combines risk (Max Drawdown, Sharpe), trade-economics (Profit Factor, Fees, Hold Time) and exit-mix (TP/SL/TSL) into one retrieval-friendly chunk.
Max Drawdown
-3.04%
Profit Factor
inf (no losing trades)
Sharpe Ratio
0.31
Total Fees
186.01 USDT
Avg Hold Time
16.5 h
TP / SL / TSL
81,737 / 0 / 0
Trade Economics
| Metric | Value | Interpretation |
|---|---|---|
| Profit Factor | inf (no losing trades) | Sum of winning trades / sum of losing trades. >1 = profitable edge, >2 = strong, inf = no losses. |
| Gross Profit | 268.48 USDT | Sum of all winning trades before fees. |
| Gross Loss | 0.00 USDT | Absolute sum of all losing trades. |
| Total Fees | 186.01 USDT | Buy + sell fees across all trades. |
| Fee Drag | 69.3% of gross profit | What share of edge the exchange consumed. |
| Avg Hold Time | 16.5 h | Mean duration a position is open. |
Exit Mix (Fill Types)
| Exit Type | Count | Share | What It Means |
|---|---|---|---|
| TP (Take Profit) | 81,737 | 100.0% | Position closed by hitting the profit target - the desired outcome. |
| SL (Stop Loss) | 0 | 0.0% | Position closed by hitting the stop - capital preservation in action. |
| TSL (Trailing Stop) | 0 | 0.0% | Trailing stop locked in profit during a trend. |
Verdict
For BROCCOLI714USDT, the strategy’s profit factor of inf (no losing trades) indicates gross winners materially exceeded gross losers in this window, exits are TP-dominant (100.0%), so most profit comes from hitting take-profit targets, fees ate 69.3% of gross profit - over-trading risk.Chunking & Headings Guide
This document is structured for deterministic RAG ingestion. Each top-level section is wrapped in HTML-comment chunk markers and follows a stable heading convention.
Chunk markers
Every section is delimited by paired JSX comments - invisible to readers, trivial for splitters. (Earlier versions of this exporter used HTML comments; we switched to JSX comments in v2.4.0 because MDX 3 - the parser Mintlify uses - forbids HTML comments at the document level.) The example below uses uppercaseRAG-CHUNK so it doesn’t accidentally match a splitter that scans this very page; real markers use lowercase rag-chunk:
\{/\*\s*rag-chunk:(start|end)\b[^*]*\*/\} and treat everything between a matching start/end pair (same id) as one indivisible chunk. Never split inside a chunk. (For backwards compatibility with v2.3.x exports, splitters can OR-match the legacy regex <!--rag-chunk:(start|end)\b[^>]*-->.)
Heading convention
# Title- appears exactly once (the document title in the intro chunk).## Section- opens every top-level chunk. Heading text matches the chunk’stitleattribute.### Sub-section- purely visual; never introduces a new chunk.####and deeper - reserved for inline detail (e.g. per-chart sub-blocks inside the catalogue).
Chunk type taxonomy
| Type | Purpose | Best for retrieval of… |
|---|---|---|
meta | Frontmatter & document intro | document-identity questions |
summary | TL;DR-style condensed prose | ”give me the headline” |
kpis | Headline numbers, card grids | numeric lookups |
overview | Tabular meta (period, balance, …) | “what was tested” |
comparison | Strategy vs benchmark | ”did it beat buy & hold” |
claims | Assertion -> evidence -> source | citation-grade answers |
config | Reproduction parameters | ”how do I rerun this” |
chart | Single visualization w/ embedded data | chart-specific questions |
catalogue | Multi-chart bundle | exploratory chart questions |
risk / allocation / trade-stats / monthly / top-trades | Domain-specific analytics | targeted KPI questions |
validation | Data-quality report | trust / sanity questions |
facts | Machine-readable JSON + key-value | deterministic lookups |
qa | Pre-answered FAQ | direct Q&A retrieval |
glossary | Term definitions | disambiguation |
narrative | Human-oriented prose | ”explain like I’m…” |
structured | JSON-LD / schema.org | search-engine indexing |
provenance | Metric -> API field -> formula lookup | ”where does this number come from” |
integrity | SHA-256 fingerprints of raw API payloads | tamper-evidence checks |
attachments | Verbatim API responses + trade-sample CSV (full ledger via /trades pagination) | byte-level reproduction |
footer | Disclaimers, links | compliance lookups |
Recommended ingestion pipeline
- Split on
{/* rag-chunk:start ... */}/{/* rag-chunk:end ... */}boundaries. - Use the
idattribute as the vector-store primary key - stable across re-exports. - Store
type,title,tokens~, andbacktest_idas filterable metadata. - Do not further chunk the
facts,claims,qa, orstructuredsections - they’re designed to be retrieved whole. - The
cataloguechunk is large; if your context budget is tight, split it on its###sub-headings instead of dropping it.
Performance Analysis
Data source -
GET /backtests/{id} + /equity + /trades * Fields used: same prose rendered on the live page by <BacktestInterpretation> - pure, deterministic, no LLM * Transform: buildBacktestInterpretation(bt)Long-form, rule-based interpretation of this run. Identical to what the page shows - embedded here so an LLM can quote it verbatim without re-deriving the analysis.
Methodology & data
This backtest was executed on historical Binance Spot 1-minute candles for BROCCOLI714USDT, with intrabar fill simulation in “OLHC” mode and a synthetic order latency of 2s applied to each fill to approximate real-world routing delay. The simulator processes every minute sequentially, evaluates the MinimalMoney rule set, and books fills against the next available bar - a standard event-driven backtesting approach that avoids look-ahead bias. Equity is marked-to-market on every closed trade and aggregated into the equity curve shown above. Configured backtest window: approximately 12.0 months (365 days fromconfig.from to config.to) of BROCCOLI714USDT 1-minute price action - a sample size that is large enough to span multiple short-term regimes. Note: the equity series may cover fewer days if the engine omits leading or trailing flat periods (e.g. dates before the asset began trading); see the Overview section for the exact equity-coverage span.
Live trading considerations
Translating this result to live trading: BROCCOLI714USDT is a deeply-liquid USDT-quoted pair on Binance, so the simulated fills here translate well to live execution at retail size. The high trade frequency means cumulative slippage and exchange-side latency will erode a few percent of the headline return over a full year - budget for that gap. Without a hard stop-loss, the live system depends on the take-profit ladder firing during recovery legs; a prolonged downtrend without recovery will hold positions open longer than backtest aggregates suggest. Additionally, exchange downtime, API rate limits, and funding-rate changes (on perp variants) are not modelled here and should be accounted for in production deployment.Frequently asked questions
Deterministic Q&A - every question is always present so this section can be sliced into stable RAG chunks. Missing API fields render as null; metrics that can’t be derived locally render as “not available”.
Is a 0.95% return on BROCCOLI714USDT a good backtest result?
Is a 0.95% return on BROCCOLI714USDT a good backtest result?
It is a positive but modest result; whether it is ‘good’ depends on what a buy-and-hold of BROCCOLI714USDT produced over the same window and on the realised drawdown.
What does the 100.0% win rate mean here?
What does the 100.0% win rate mean here?
It means 100.0 out of every 100 closed trades ended profitable. Frequent wins are emotionally easier to operate but say nothing about size - one large loss can offset many small wins.
What is the annualised return for this BROCCOLI714USDT backtest?
What is the annualised return for this BROCCOLI714USDT backtest?
Compounding the 0.95% over 365 days projects to +0.9% per year. This is a directional indicator only - crypto regimes change, and strategies rarely sustain peak performance year-over-year.
Can I run this exact MinimalMoney configuration live?
Can I run this exact MinimalMoney configuration live?
The configuration shown in the Strategy Configuration block is the same JSON schema the live unCoded TradingBot consumes, so it can be loaded into a live instance. That is a technical compatibility statement, not a recommendation: a passing backtest is necessary but not sufficient evidence that a configuration will be profitable in live trading. Before any live use, validate on an out-of-sample window, paper-trade it, confirm exchange-side fees match the simulated 7.5/7.5 bps, and start with a position size well below the backtested capital to absorb live slippage and execution differences.
How is this backtest different from others on BROCCOLI714USDT?
How is this backtest different from others on BROCCOLI714USDT?
Every run on the platform uses the same intrabar-fill engine and historical Binance Spot data, so the comparison is apples-to-apples. What differs between runs is the MinimalMoney parameter set (buy trigger, sell zones, splits, stop-loss) and the time window - both are visible above so you can rerun, tune, or fork this configuration.
This interpretation is generated deterministically from this run’s own metrics. Past performance is not indicative of future results - a profitable backtest is necessary but not sufficient evidence that a strategy will work in live trading on BROCCOLI714USDT.
Overview
Data source -
GET /backtests/{id} * Fields used: symbol, mode_name, config.from, config.to, start_balance, final_value, avg_profit, status, created_at, started_at, completed_at, elapsed_sec, is_duplicate, data_file, id, summary_text| Field | Value |
|---|---|
| Trading Pair | BROCCOLI714USDT |
| Strategy | MinimalMoney |
| Period | 2025-01-01 -> 2025-12-31 |
| Configured window (inclusive elapsed) | 365.0 days (1.00 years) - (config.to - config.from) / 86 400 000 ms |
| Configured window (calendar days) | 365 days - Math.round of the elapsed value above; this is what the narrative paragraph quotes |
| Equity-stat duration | 279.0 days (0.76 years) - first -> last equity sample timestamp; used for CAGR / Sharpe / Sortino |
| Coverage gap | configured window is 365.0 days but equity samples span only 279.0 days - the engine omitted leading/trailing flat periods (e.g. dates before the asset began trading on the venue) |
| Start Balance | 10,000.00 USDT |
| Final Value | 10,094.99 USDT |
| Avg Profit / Trade | +0.0010 USDT |
| Trades / Month | 6816.1 |
| Status | completed |
| Created | 2026-04-19 12:41:44 UTC |
| Started | 2026-04-19 14:59:01 UTC |
| Completed | 2026-04-19 15:04:17 UTC |
| Compute Time | 4m 8s |
| Backtest ID | e8afcdcd-83d1-4a2b-bdb2-b92660a40229 |
| Engine summary: |
vs Buy & Hold
Data source -
GET /backtests/{id} * Fields used: return_pcttokenReturnPct).
| Metric | Strategy | Buy & Hold | Delta |
|---|---|---|---|
| Return | +0.95% | -55.73% | +56.68% |
Verifiable Claims
Each claim is grounded in a specific field + source so an LLM can cite evidence rather than paraphrase.
| Claim | Evidence | Source |
|---|---|---|
| Strategy returned +0.95% over the tested window | return_pct = 0.9499 | GET /backtests/{id} -> return_pct |
| Capital grew from 10,000.00 to 10,094.99 USDT | final_value - start_balance = +94.99 USDT | GET /backtests/{id} -> start_balance, final_value |
| Roughly 81737 of 81737 trades were profitable | win_rate = 100% | GET /backtests/{id} -> win_rate, fulfilled_trades |
| Worst peak-to-trough loss was 3.04% | max_drawdown_pct = 3.0384 | derived client-side from /equity series |
| Risk-adjusted return (Sharpe, annualized, rf=0) = 0.31 | sharpe_annualized = 0.3055 | derived from daily-resampled equity returns |
| Strategy beat Buy & Hold by +56.68% | return_pct - buyhold_return_pct = 56.6751 pp | Buy & Hold computed from underlying token price change |
Strategy Configuration
Data source -
GET /backtests/{id} * Fields used: mode_name, config (full JSON payload)Mode MinimalMoney governs how buy triggers, position sizing and exits behave. Below are the exact parameters used for this run.
- Highlights
- Full JSON
| Parameter | Value |
|---|---|
canBuy | true |
canSell | true |
canBuyUp | true |
startBal | 10000 |
stepSize | 1 |
stopLoss | false |
tickSize | 0.00001 |
buySplits | 1 |
Full Mode Configuration
Every parameter the strategy received at runtime, validated against the canonical engine schema (ENGINE.md Section 20). Recognised parameters are passed verbatim into
POST /backtests to reproduce the run.- Engine Parameters
- YAML
| Parameter | Value | Meaning |
|---|---|---|
assumed_spread_bps | 0 | Spread (basis points) added to taker fills on top of the candle price. |
buyPercentage | 0.1 | Buy-trigger threshold as a fraction (e.g. 0.1 = -0.1% from last reference price). |
buySplits | 1 | Number of price levels in the buy-ladder (DCA depth). |
buyVolumes | [100] | Per-split sizing weights (sum ~ 100). Distributes investmentPerBuy x buySplits across the ladder. |
canBuy | true | Master switch - disables all buy-side logic when false. |
canBuyDown | false | Allow re-entries below the last buy price. |
canBuyUp | true | Allow re-entries above the last buy price (true) or only below (false). |
canSell | true | Master switch - disables all sell-side logic when false. |
dontBuyBelowQuoteAssetBalance | 1 | Refuse to open new buys if free quote drops below this absolute USDT amount. |
fees_in_quote | true | If true, fees are deducted from the quote (USDT) leg of every fill. |
intrabar_mode | OLHC | Intra-bar fill model (OLHC, OHLC, …) - see ENGINE.md Section 4. |
investmentPerBuy | 1.5 | Notional invested per buy event, in quote (USDT). |
investmentPerFreeQuotePercent | 0.01 | When investmentPercentMode = true: fraction of free quote balance to commit per buy. |
investmentPercentMode | false | If true, sizing is taken as a fraction of free quote balance instead of fixed USDT. |
maker_fee_bps | 7.5 | Maker fee in basis points (e.g. 7.5 = 0.075%). |
minInvestmentPerQuote | 1.5 | Hard floor on per-buy notional, regardless of percent-mode math. |
minNotional | 1 | Exchange minimum notional per order (USDT). |
order_latency_seconds | 2 | Latency injected between signal time and order placement. |
sellActivateDistancePercentage | 0.1 | Distance from buy price (%) at which a TSL becomes armed. |
sellCancelDistancePercentage | 1 | Distance (%) at which an unfilled sell order is cancelled and re-priced. |
sellPercentages | [0.2] | Take-profit ladder, each value is the per-tier profit target as a fraction. |
startBal | 10000 | Initial portfolio value in the quote currency (USDT). |
stepSize | 1 | Exchange size step (base asset). |
stopLoss | false | Hard stop-loss enabled flag. |
stopLossPercentage | 5 | Hard stop-loss distance from entry as a percent (5.0 = -5%). |
taker_fee_bps | 7.5 | Taker fee in basis points. |
tickSize | 0.00001 | Exchange price tick (quote currency). |
trailingStopLossPercentages | [0] | Per-tier trailing-SL distances. Zero entries disable TSL on that tier. |
triggerCoolDown | 1 | Minimum bars/ticks between two consecutive buys on the same level. |
Strategy Logic
This section explains what the strategy actually does - the rules behind the parameters in Strategy Configuration. Without it the report would be a black box: numbers without semantics. We treat its absence as a defect, not a feature.
GET /modes and select the entry whose filename == "6MinimalMoney.json" to inspect the public rule fields, or consult the engine source for the executable logic.
Engine Specification
The execution engine is shared across every backtest on this site. Its static semantics - TP-vs-SL ordering inside an OLHC bar, TSL splits bypassing nominal TP, JS-legacy boolean parsing, Binance hard caps, fee model, equity sampling - are documented once in the canonical Engine Specification and pinned per-run via the
engine_version field in this document’s frontmatter (see also the Data Source Metadata section).Engine Specification
Canonical, versioned spec covering the bar-loop, order types, intra-bar fill rules, gap handling, fees, position sizing, risk management, multi-entry cascade, sell-time curves, portfolio accounting, determinism guarantees and the full configuration schema (Section 20).
uncoded.ch/docs/engine; this report only pins which revision applied (engine_version in the frontmatter).
Data Source Metadata
Inputs the engine consumed for this run. Anything marked not provided is explicitly missing rather than silently omitted - pass the corresponding field via
buildVerifiableMdx({ dataSource: ... }) to fill it in. The engine spec describes deterministic execution semantics (segment order, fill rules, fee classification) that cannot be reverse-engineered from trades alone.| Field | Value | Source |
|---|---|---|
| Market-data provider | Binance Spot | caller DataSourceInput.provider |
| Exchange / venue | binance | caller DataSourceInput.exchange |
| Symbol | BROCCOLI714USDT | GET /backtests/{id} -> $.symbol |
| Candle interval | 1m | platform invariant - all backtests run on 1-minute OHLCV candles |
| First candle (UTC) | 2025-01-01 00:00:01 | GET /backtests/{id} -> $.config.from |
| Last candle (UTC) | 2025-12-31 23:59:59 | GET /backtests/{id} -> $.config.to |
| Timezone | UTC | default assumption (UTC) |
| Engine version | uncoded-engine (FastAPI backend) | caller DataSourceInput.engineVersion |
| Engine spec version | 1.1 | caller DataSourceInput.engineSpecVersion |
| Engine spec document | https://uncoded.ch/docs/engine | caller DataSourceInput.engineSpecPath |
Equity Curve
Data source -
GET /backtests/{id}/equity * Fields used: timestamp, total_value_exit_net, total_value_mid, total_valueRisk & Quality Metrics
Data source -
GET /backtests/{id}/equity * Fields used: timestamp, total_value_exit_net, total_value_mid, total_value, base_asset_bal (for time-in-market)Derived from 280 equity samples across 279.0 days. Sharpe & Sortino are annualized using daily-resampled returns (rf = 0).
Max Drawdown
-3.04% (-307.36 USDT)
CAGR
+1.25%
Volatility (ann.)
4.39%
Sharpe Ratio
0.31
Sortino Ratio
0.40
Time in Market
100.0%
Drawdown Detail
| Field | Value |
|---|---|
| Peak | 10,115.81 USDT @ 2025-10-07 23:59:00 UTC |
| Trough | 9,808.45 USDT @ 2025-12-18 23:59:00 UTC |
| Drawdown Duration | 72.0 days |
| Recovery | not yet recovered within window |
| All-time Peak | 10,115.81 USDT |
Final Portfolio Allocation
Data source -
GET /backtests/{id}/equity * Fields used: total_value_exit_net, quote_asset_bal, base_asset_bal, base_value_exit_net, base_value_mid, unrealized_pnl_exit_net| Asset | Quantity | Value (USDT) | Allocation |
|---|---|---|---|
| USDT (Cash) | 10,062.88 | 10,062.88 | 99.7% |
| BROCCOLI714 | 1,847.00000000 | 0.00 | 0.0% |
| Other (open positions, fee reserves, …) | - | 32.11 | 0.3% |
| Total | - | 10,094.99 | 100.0% |
Unrealized P&L on remaining position: +12.52 USDT across 13 open order(s). The “Other” row, when present, is dominated by these open positions held outside the cash/base buckets.
Trade Analytics
Data source -
GET /backtests/{id}/trades * Fields used: profit, profit_percentage, fill_type, buy_time, sell_time, buy_price, sell_price, buy_quantity, buy_fee_in_quote, sell_fee_in_quoteWins
100 (100.0%)
Losses
0 (0.0%)
Breakeven
0
Profit Factor
inf
Payoff Ratio
inf
Expectancy / Trade
+0.0011 USDT
Avg Win
+0.0011 USDT
Avg Loss
-0.0000 USDT
Median Trade
+0.0010 USDT
Max Win Streak
100
Max Loss Streak
0
Avg Holding
27.5h
Median Holding
0.1h
Total Volume
303 USDT
Total Fees
186.01 USDT * engine-tracked, includes open-position buy fees
Gross Performance
| Metric | Value | Source |
|---|---|---|
| Gross Profit (winners only) | +0.11 USDT | Sum profit where profit > 0 (client-side from /trades) |
| Gross Loss (losers only) | -0.00 USDT | Sum -profit where profit < 0 (client-side from /trades) |
| Net Profit | +0.11 USDT | Gross Profit - Gross Loss |
| Closed-trade buy fees | 0.11 USDT | Sum buy_fee_in_quote over matched-pair rows of /trades |
| Closed-trade sell fees | 0.11 USDT | Sum sell_fee_in_quote over matched-pair rows of /trades |
| Closed-trade fees subtotal | 0.23 USDT | buy + sell on matched pairs |
| Open-position buy fees | 185.78 USDT | bt.total_fees - closed-trade subtotal - buy-side fees on the 13 orders still open at end of window (no matching sell row yet) |
| Total Fees Paid (authoritative) | 186.01 USDT | bt.total_fees - engine-tracked sum of every fee actually paid (closed + open buy fills). reconciles to closed-fees + open-position buy fees |
| Fees as % of Gross Profit | 163688.51% | Total Fees / Gross Profit |
Fee accounting reconciles by construction.
bt.total_fees is the engine-tracked total of every fee actually paid. Per-trade rows in /trades only emit on matched buy+sell pairs, so positions still open at end-of-window contribute their buy-fee to bt.total_fees but not to the per-trade sum. The identity is exact:
bt.total_fees = Sum closed-trade (buy_fee + sell_fee) + Sum open-position buy_fees
Citation rules: use Total Fees Paid for the headline (the authoritative number every consumer should quote), use Closed-trade fees subtotal when reasoning specifically about realized round-trip economics, and use Open-position buy fees when sizing the unrealized exposure of the still-open ladder.Advanced - mechanical breakdown from API field mapping
Advanced - mechanical breakdown from API field mapping
Every figure above is derivable from two API surfaces. This table maps each line item to its exact source field so an external reviewer can re-compute the totals from the raw responses without trusting any client-side aggregation.
Why (A) != (B) in general:
| Line item | Formula | API field(s) | Endpoint |
|---|---|---|---|
| Closed-trade buy fees | Sum row.buy_fee_in_quote | buy_fee_in_quote per row | GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229/trades |
| Closed-trade sell fees | Sum row.sell_fee_in_quote | sell_fee_in_quote per row | GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229/trades |
| (A) Closed-trade subtotal | Sum (buy_fee_in_quote + sell_fee_in_quote) | both fee fields, matched-pair rows only | GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229/trades |
| (B) Total Fees Paid (engine) | direct read | total_fees (scalar) | GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229 |
| (C) = (B) - (A) Open-position buy fees | bt.total_fees - closed_subtotal | derived | - |
| Open orders count | direct read | active_orders | GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229 |
| Numerical walk-through for this run: |
/trades rows emit only on matched buy+sell pairs. A buy fill that hasn’t found its sell yet (still sitting in the DCA ladder at end-of-window) has already paid its fee - that fee is included in bt.total_fees (B) but not in any per-trade row, so it is not part of (A). The remainder (C) is therefore the buy-side fee paid on the 13 open orders.Holding Period Distribution
| Min | Median | Avg | Max |
|---|---|---|---|
| 0.0h | 0.1h | 27.5h | 1637.8h |
Trade Timeline
| First Trade | Last Trade |
|---|---|
| 2025-03-27 21:03:00 UTC | 2025-12-31 23:59:00 UTC |
Breakdown by Exit Type
| Type | Count | Cumulative Profit | Avg Return |
|---|---|---|---|
TP | 100 | +0.11 USDT | +0.08% |
Monthly Performance
Data source -
GET /backtests/{id}/trades * Fields used: sell_time (bucket key), profit| Month | Trades | Wins | Win Rate | Net P&L (USDT) |
|---|---|---|---|---|
| 2025-03 | 28 | 28 | 100.0% | +0.02 |
| 2025-04 | 8 | 8 | 100.0% | +0.01 |
| 2025-05 | 1 | 1 | 100.0% | +0.00 |
| 2025-06 | 1 | 1 | 100.0% | +0.00 |
| 2025-07 | 2 | 2 | 100.0% | +0.00 |
| 2025-08 | 4 | 4 | 100.0% | +0.00 |
| 2025-09 | 2 | 2 | 100.0% | +0.00 |
| 2025-10 | 3 | 3 | 100.0% | +0.00 |
| 2025-11 | 1 | 1 | 100.0% | +0.00 |
| 2025-12 | 50 | 50 | 100.0% | +0.07 |
Top Trades
Data source -
GET /backtests/{id}/trades * Fields used: fill_type, buy_time, sell_time, buy_price, sell_price, profit, profit_percentageTop 10 Winners
Top 10 Winners
Showing top 10 of 100 profitable trades.
| # | Type | Period | Buy | Sell | Profit | % |
|---|---|---|---|---|---|---|
| 1 | TP | 2025-10-10 -> 2025-10-10 | 0.007020 | 0.007040 | +0.0020 | +0.13% |
| 2 | TP | 2025-12-18 -> 2025-12-18 | 0.010860 | 0.010890 | +0.0019 | +0.13% |
| 3 | TP | 2025-12-18 -> 2025-12-18 | 0.010910 | 0.010940 | +0.0019 | +0.12% |
| 4 | TP | 2025-12-18 -> 2025-12-18 | 0.010940 | 0.010970 | +0.0019 | +0.12% |
| 5 | TP | 2025-12-18 -> 2025-12-18 | 0.010940 | 0.010970 | +0.0019 | +0.12% |
| 6 | TP | 2025-12-19 -> 2025-12-19 | 0.010940 | 0.010970 | +0.0019 | +0.12% |
| 7 | TP | 2025-12-18 -> 2025-12-18 | 0.010980 | 0.011010 | +0.0019 | +0.12% |
| 8 | TP | 2025-12-18 -> 2025-12-18 | 0.010990 | 0.011020 | +0.0018 | +0.12% |
| 9 | TP | 2025-12-19 -> 2025-12-19 | 0.010990 | 0.011020 | +0.0018 | +0.12% |
| 10 | TP | 2025-12-18 -> 2025-12-18 | 0.011020 | 0.011050 | +0.0018 | +0.12% |
Top 10 Losers
Top 10 Losers
No losing trades in this run (win rate = 100%).
Charts Catalogue
Data source -
GET /backtests/{id} + /equity + /trades * Fields used: every chart from the live <AnalyticsCharts> UI, with the exact transform + API fields it consumes- Equity & Balance
- Trade Analysis
- Risk & Recovery
- Deep Dive
- Advanced
Drawdown
Data source -
GET /backtests/{id}/equity * Fields used: timestamp, total_value_exit_net * Transform: computeDrawdown(equity)drawdown).| Stat | Value |
|---|---|
| Shallowest DD | 0.00% @ 2025-03-27 23:59:00 UTC |
| Deepest DD | -3.04% @ 2025-12-18 23:59:00 UTC |
| Mean | -1.10% |
| Std Dev | 0.84% |
| Last | -0.21% |
| Points | 280 |
| Across 280 points the series ranged from -3.04% (2025-12-18 23:59:00 UTC) to 0.00% (2025-03-27 23:59:00 UTC), averaging -1.10%. 0% of points were positive, 93% negative. The most recent value is -0.21%. | |
| Showing 60 of 280 points (down-sampled for readability). |
Drawdown
Unrealized PnL
Data source -
GET /backtests/{id}/equity * Fields used: timestamp, unrealized_pnl_exit_net * Transform: equity.map(p => ({ pnl: p.unrealized_pnl_exit_net }))pnl).| Stat | Value |
|---|---|
| Best Unrealized | 65.42 USDT @ 2025-07-27 23:59:00 UTC |
| Worst Unrealized | -271.72 USDT @ 2025-12-18 23:59:00 UTC |
| Mean | -81.90 USDT |
| Std Dev | 79.72 USDT |
| Last | 12.52 USDT |
| Points | 280 |
| Sum | -22,932.28 USDT |
| Across 280 points the series ranged from -271.72 USDT (2025-12-18 23:59:00 UTC) to 65.42 USDT (2025-07-27 23:59:00 UTC), averaging -81.90 USDT. 14% of points were positive, 86% negative. The most recent value is 12.52 USDT. | |
| Showing 60 of 280 points (down-sampled for readability). |
Unrealized PnL
Balance Composition (Cash vs. Coin)
Data source -
GET /backtests/{id}/equity * Fields used: quote_asset_bal, base_value_exit_net, total_value_exit_net * Transform: stack(quote, base, total)total).| Stat | Value |
|---|---|
| Peak Total Equity | 10,115.81 USDT @ 2025-10-07 23:59:00 UTC |
| Trough Total Equity | 9,808.45 USDT @ 2025-12-18 23:59:00 UTC |
| Mean | 9,965.84 USDT |
| Std Dev | 69.53 USDT |
| Last | 10,094.99 USDT |
| Points | 280 |
| Sum | 2,790,435.46 USDT |
| Across 280 points the series ranged from 9,808.45 USDT (2025-12-18 23:59:00 UTC) to 10,115.81 USDT (2025-10-07 23:59:00 UTC), averaging 9,965.84 USDT. 100% of points were positive, 0% negative. The most recent value is 10,094.99 USDT. | |
| Showing 60 of 280 points (down-sampled for readability). |
Balance Composition (Cash vs. Coin)
Base Exposure (% of Portfolio)
Data source -
GET /backtests/{id}/equity * Fields used: base_value_exit_net, quote_asset_bal, total_value_exit_net * Transform: baseExposure(equity)exposure).| Stat | Value |
|---|---|
| Peak Exposure | 3.44% @ 2025-12-28 23:59:00 UTC |
| Min Exposure | 0.07% @ 2025-03-27 23:59:00 UTC |
| Mean | 2.25% |
| Std Dev | 0.68% |
| Last | 0.32% |
| Points | 280 |
| Across 280 points the series ranged from 0.07% (2025-03-27 23:59:00 UTC) to 3.44% (2025-12-28 23:59:00 UTC), averaging 2.25%. 100% of points were positive, 0% negative. The most recent value is 0.32%. | |
| Showing 60 of 280 points (down-sampled for readability). |
Base Exposure (% of Portfolio)
Daily Change
Data source -
GET /backtests/{id}/equity * Fields used: timestamp, total_value_exit_net * Transform: dailyDelta(equity)total_value_exit_net between consecutive equity samples (typically daily).How to read it. Green bars are gain days, red bars are loss days. A long stretch of red bars indicates a sustained drawdown, not just a single bad day.Why it matters. Shows whether returns are consistent or driven by a few jackpot days - important for compounding and for sizing live capital.Insights (auto-derived from delta).| Stat | Value |
|---|---|
| Best Day | 245.17 USDT @ 2025-12-31 23:59:00 UTC |
| Worst Day | -91.70 USDT @ 2025-08-05 23:59:00 UTC |
| Mean | 0.3426 USDT |
| Std Dev | 22.80 USDT |
| Last | 245.17 USDT |
| Points | 279 |
| Sum | 95.58 USDT |
| Across 279 points the series ranged from -91.70 USDT (2025-08-05 23:59:00 UTC) to 245.17 USDT (2025-12-31 23:59:00 UTC), averaging 0.3426 USDT. 48% of points were positive, 52% negative. The most recent value is 245.17 USDT. | |
| Showing 60 of 279 points (down-sampled for readability). |
Daily Change
Monthly Returns
Data source -
GET /backtests/{id}/equity * Fields used: timestamp, total_value_exit_net * Transform: monthlyReturns(equity)returnPct).| Stat | Value |
|---|---|
| Best Month | 2.37% @ 2025-12 |
| Worst Month | -1.75% @ 2025-08 |
| Mean | 0.09% |
| Std Dev | 1.04% |
| Last | 2.37% |
| Points | 10 |
| Across 10 points the series ranged from -1.75% (2025-08) to 2.37% (2025-12), averaging 0.09%. 50% of points were positive, 50% negative. The most recent value is 2.37%. | |
| Full series - 10 points. |
Monthly Returns
Machine-Readable Facts
This section is optimized for LLM/RAG consumption. Every metric appears as both a flat key/value row and as canonical JSON so a model can quote exact values without re-deriving them. The JSON below is the exact object whose SHA-256 is published as
facts_sha256 in the frontmatter - re-hash it to verify.- JSON
- Flat Table
facts.json
Metric Provenance Index
For every headline metric in this report, this table answers three questions: where did the value come from, what JSON field, and what transform (if any) was applied. Use it to audit any number - or to teach an LLM to cite values verbatim.
| Metric | Source | JSON path | Transform | Value in this report |
|---|---|---|---|---|
| Symbol | GET /backtests/{id} | $.symbol | direct API value | BROCCOLI714USDT |
| Mode | GET /backtests/{id} | $.mode_name | direct API value | 6MinimalMoney.json |
| Status | GET /backtests/{id} | $.status | direct API value | completed |
| Period start | GET /backtests/{id} | $.config.from | direct API value | 2025-01-01 00:00:01 |
| Period end | GET /backtests/{id} | $.config.to | direct API value | 2025-12-31 23:59:59 |
| Start balance | GET /backtests/{id} | $.start_balance | direct API value | 10,000.00 USDT |
| Final value | GET /backtests/{id} | $.final_value | direct API value | 10,094.99 USDT |
| Return % | GET /backtests/{id} | $.return_pct | direct API value (cross-check: (final_value/start_balance - 1) * 100) | +0.95% |
| Total profit | GET /backtests/{id} | $.total_profit | direct API value (cross-check: Sum trades[].profit) | +82.47 USDT |
| Win rate % | GET /backtests/{id} | $.win_rate | direct API value (cross-check: 100 * count(trades[].profit > 0) / count(trades)) | 100.0% |
| Trades count | GET /backtests/{id} | $.fulfilled_trades | direct API value (cross-check: count(trades)) | 81,737 |
| Best trade | GET /backtests/{id} | $.max_profit | direct API value (cross-check: max(trades[].profit)) | +0.0020 USDT |
| Worst trade | GET /backtests/{id} | $.min_profit | direct API value (cross-check: min(trades[].profit)) | +0.0007 USDT |
| Avg profit / trade | GET /backtests/{id} | $.avg_profit | direct API value | +0.0010 USDT |
| Trades / month | derived | n/a | fulfilled_trades / (durationDays / 30.4375) | 6816.1 |
| Max drawdown % | GET /backtests/{id}/equity | $[*].total_value_* | maxDrawdown(equity) - running peak vs. trough | -3.04% |
| Max drawdown abs | GET /backtests/{id}/equity | $[*].total_value_* | maxDrawdown(equity).abs | -307.36 USDT |
| CAGR % | GET /backtests/{id}/equity | $[*].timestamp, $[*].total_value_* | (final/start)^(365.25/days) - 1 | +1.25% |
| Volatility (ann.) % | GET /backtests/{id}/equity | $[*].timestamp, $[*].total_value_* | std(daily_returns) * sqrt(365) | 4.39% |
| Sharpe ratio (ann.) | GET /backtests/{id}/equity | $[*].timestamp, $[*].total_value_* | mean(daily_returns) / std(daily_returns) * sqrt(365) (rf=0) | 0.31 |
| Sortino ratio (ann.) | GET /backtests/{id}/equity | $[*].timestamp, $[*].total_value_* | mean(daily_returns) / std(downside_returns) * sqrt(365) (rf=0) | 0.40 |
| Time in market % | GET /backtests/{id}/equity | $[*].base_asset_bal | count(samples where base_asset_bal>0) / count(samples) * 100 | 100.0% |
| Total fees | GET /backtests/{id}/trades | $[*].buy_fee_in_quote, $[*].sell_fee_in_quote | Sum (buy_fee_in_quote + sell_fee_in_quote) | 0.23 USDT |
| Gross profit (winners) | GET /backtests/{id}/trades | $[?(@.profit>0)].profit | Sum profit where profit > 0 | +0.11 USDT |
| Gross loss (losers) | GET /backtests/{id}/trades | $[?(@.profit<0)].profit | Sum abs(profit) where profit < 0 | 0.00 USDT |
| Profit factor | GET /backtests/{id}/trades | $[*].profit | Sum winners.profit / Sum abs(losers.profit) | inf |
| Payoff ratio | GET /backtests/{id}/trades | $[*].profit | avg(winners.profit) / avg(abs(losers.profit)) | inf |
| Expectancy / trade | GET /backtests/{id}/trades | $[*].profit | mean(trades[].profit) | +0.0011 USDT |
| Max consecutive wins | GET /backtests/{id}/trades | $[*].profit (ordered) | longest run where profit > 0 | 100 |
| Max consecutive losses | GET /backtests/{id}/trades | $[*].profit (ordered) | longest run where profit < 0 | 0 |
| Avg holding (h) | GET /backtests/{id}/trades | $[*].buy_time, $[*].sell_time | mean(sell_time - buy_time) / 3600 | 27.5h |
| Median holding (h) | GET /backtests/{id}/trades | $[*].buy_time, $[*].sell_time | median(sell_time - buy_time) / 3600 | 0.1h |
| Total volume (notional) | GET /backtests/{id}/trades | $[*].buy_quantity, $[*].buy_price | Sum (buy_quantity * buy_price) | 303 USDT |
Raw API Attachments
Rendered trade sample: 100-row slice from
/trades. Full trade population: 81,737 closed trades - fetch the complete list via GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229/trades. Aggregate KPIs are computed server-side against the full population, not from this sample.GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229 - backtest summary (verbatim)
GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229 - backtest summary (verbatim)
backtest.json
GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229/equity - equity series (verbatim, 280 points)
GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229/equity - equity series (verbatim, 280 points)
equity.json
Verbatim
trades.json payload is intentionally not embedded in this report (deprecated). The CSV attachment below is a 100-row audit sample of the full ledger, not the complete trade list - fetch the canonical full population (81,737 closed trades) via GET /backtests/e8afcdcd-83d1-4a2b-bdb2-b92660a40229/trades (paginate through all pages).100-row audit sample from 81,737 closed trades (RFC 4180 CSV)
100-row audit sample from 81,737 closed trades (RFC 4180 CSV)
trades.csv
Frequently Asked Questions
Deterministic Q&A - every question is always present so this section can be sliced into stable RAG chunks. Missing API fields render as
_null_; metrics that can’t be derived locally render as “not available”.What strategy was tested and on which trading pair?
What strategy was tested and on which trading pair?
The MinimalMoney strategy was tested on BROCCOLI714USDT over 2025-01-01 to 2025-12-31.Source:
bt.mode_name, bt.symbol, bt.config.from, bt.config.toWhat is the current status of this backtest?
What is the current status of this backtest?
Completed. Final metrics are available below.Source:
bt.status, bt.error_messageWhat was the total return?
What was the total return?
+0.95% - turning 10,000.00 USDT into 10,094.99 USDT (net profit 82.47 USDT).Source:
bt.return_pct, bt.start_balance, bt.final_value, bt.total_profitWhat was the annualized growth rate (CAGR)?
What was the annualized growth rate (CAGR)?
Compound Annual Growth Rate is +1.25% over a 279 day window.Source:
derived from equity series (eqStats.cagrPct, eqStats.durationDays)Did it beat Buy & Hold of BROCCOLI714USDT?
Did it beat Buy & Hold of BROCCOLI714USDT?
Yes - Buy & Hold returned -55.73%, so the strategy outperformed by +56.68%.Source:
bt.return_pct, opts.tokenReturnPct, outperformDeltaWhat was the worst drawdown?
What was the worst drawdown?
The maximum peak-to-trough loss was -3.04% (307.36 USDT), lasting around 72 days underwater and did not recover within the window.Source:
derived from equity series (eqStats.maxDrawdownPct, .maxDrawdownAbs, .underwaterDays, .recoveryDays)How many trades did it take and what was the win rate?
How many trades did it take and what was the win rate?
81,737 trades were filled with a 100.0% win rate (~6816.1 trades per month). 13 positions were still open at the end of the window.Source:
bt.fulfilled_trades, bt.win_rate, bt.active_orders, derived tradesPerMonthWhat was the average, best, and worst trade?
What was the average, best, and worst trade?
Average trade profit was 0.00 USDT, the best single trade made 0.00 USDT, the worst single trade still finished positive at +0.00 USDT (no closed trade ended in a loss).Source:
bt.avg_profit, bt.max_profit, bt.min_profitWhat was the profit factor and expectancy?
What was the profit factor and expectancy?
Profit factor Infinity (gross profit / gross loss) and expectancy 0.00 USDT per trade. Payoff ratio (avg win / avg loss) is Infinity.Source:
derived from trades (stats.profitFactor, .expectancy, .payoffRatio)What were the longest winning and losing streaks?
What were the longest winning and losing streaks?
Longest winning streak: 100 trades. Longest losing streak: 0 trades.Source:
derived from trades (stats.consecWinsMax, .consecLossesMax)How much was paid in fees?
How much was paid in fees?
Total fees were 0.23 USDT (buy: 0.11, sell: 0.11) over 100 trades. Computed as
Sum(buy_fee_in_quote + sell_fee_in_quote) over every row of GET /backtests/{id}/trades - the API summary field bt.total_fees is used only for cross-checking, not as the source of truth.Source: derived from trades[].buy_fee_in_quote + trades[].sell_fee_in_quote (analyzeTrades -> stats.totalFees / .buyFees / .sellFees)Is the risk-adjusted return any good?
Is the risk-adjusted return any good?
Annualized Sharpe is 0.31 and Sortino is 0.40. Sharpe > 1 is generally considered good, > 2 very good, > 3 excellent (caveat: crypto Sharpe is easily inflated by short windows).Source:
derived from equity series (eqStats.sharpeAnnualized, .sortinoAnnualized)How volatile was the equity curve?
How volatile was the equity curve?
Annualized volatility of daily returns was 4.39%.Source:
derived from equity series (eqStats.volatilityAnnualizedPct)How long does the strategy hold positions?
How long does the strategy hold positions?
The median hold time is 6.0 minutes (mean 1.1 days, range 1.0 minutes - 68.2 days).Source:
derived from trades (stats.medianHoldingHours, .avgHoldingHours, .minHoldingHours, .maxHoldingHours)How much of the time was capital deployed?
How much of the time was capital deployed?
The strategy was in the market 100.0% of the period - the remainder sat in cash awaiting setups.Source:
derived from equity series (eqStats.timeInMarketPct)What were the best and worst months?
What were the best and worst months?
Best month: 2025-12 with 0.07 USDT. Worst month: 2025-05 with 0.00 USDT.Source:
derived from trades (stats.bestMonth, .worstMonth)When did the backtest run and how long did it take?
When did the backtest run and how long did it take?
Created at 2026-04-19T12:41:44.866950Z, started at 2026-04-19T14:59:01.257196Z, completed at 2026-04-19T15:04:17.829120Z. Engine elapsed time: 247.91 s.Source:
bt.created_at, bt.started_at, bt.completed_at, bt.elapsed_secWhat configuration parameters were used?
What configuration parameters were used?
Initial capital 10,000.00 USDT, data file null, timeframe null, fee % null, cloned from a base mode: no.Source:
bt.start_balance, bt.data_file, bt.config.timeframe, bt.config.fee_pct, bt.is_duplicateWhere can I find a one-line summary written by the engine?
Where can I find a one-line summary written by the engine?
bt.summary_textAre these results guaranteed for live trading?
Are these results guaranteed for live trading?
No. This is a historical backtest. It excludes live slippage variance, exchange outages, latency, and regime changes. Treat it as evidence the rules can be profitable, not a forward guarantee.Source:
static disclaimerGlossary
Definitions for every metric used in this report. Use these to disambiguate when answering questions.
| Term | Definition |
|---|---|
| Return % | Total percentage change of portfolio value over the backtest window: (final_value - start_balance) / start_balance x 100. |
| CAGR | Compound Annual Growth Rate. Annualized return assuming compounding: (final/start)^(365.25/days) - 1. |
| Win Rate | Share of closed trades with positive net P&L (after fees): wins / (wins + losses) x 100. |
| Max Drawdown | Largest peak-to-trough decline of equity, measured in % of the previous peak. The single most important risk metric. |
| Drawdown Duration | Number of days spent below the previous equity peak before recovering (or end of window if not recovered). |
| Sharpe Ratio (annualized) | Mean daily return divided by standard deviation of daily returns, scaled by 365. Risk-adjusted return - higher is better, > 1 is decent. |
| Sortino Ratio (annualized) | Like Sharpe but only penalizes downside volatility. Often more representative for asymmetric strategies. |
| Volatility (ann.) | Standard deviation of daily returns x 365, expressed as a percentage. |
| Time in Market | Fraction of the period where the strategy held base-asset exposure (not 100% cash). |
| Buy & Hold | Reference benchmark: simply buying the underlying token at the start and holding to the end of the window. |
| Outperformance (pp) | Strategy return minus Buy & Hold return, in percentage points (not percent change). |
| Fulfilled Trades | Round-trip trades that have both an entry fill and an exit fill within the window. |
| Active Orders | Open positions still pending exit at the end of the backtest - their unrealized P&L is included in final_value. |
| Lookahead Bias | Using information that wouldn’t have been available at trade time. The validator flags trades whose buy_time precedes the configured from date. |
How to Read This Report
Data source -
GET /backtests/{id} * Fields used: return_pct, fulfilled_trades, win_rateCheck the headline return
The strategy returned +0.95% over the tested window. Compare against Buy & Hold to judge true edge.
Reproduce This Run
Data source -
GET /backtests/{id} * Fields used: symbol, mode_name, config (replayed verbatim)The backtester UI lives at uncoded.ch/backtesting. The REST API endpoint below accepts the same JSON payload - authenticate with your
X-API-Key. Payload fields are validated against ENGINE.md Section 20; non-engine keys are stripped so the replay produces the exact same run.Structured Data (JSON-LD)
Schema.org
Dataset markup with 36 PropertyValue KPIs. Every numeric value is finite + range-validated; invalid / null fields are omitted so the JSON stays schema.org-compliant.schema.org
[!] Disclaimer
Backtester: uncoded.ch/backtesting * Generated 2026-05-15 12:08:44 UTC