Backtesting Arena

DEPRECATED — renamed to arena_get_platform_activity: the endpoint measures platform activity (what is being backtested on Backtesting Arena). Same payload plus deprecation fields; this alias will be removed after 2026-11-15. Use arena_get_platform_activity. For market sentiment use arena_get_fear_greed, arena_get_funding_rate, arena_get_altcoin_season or arena_get_pulse. [Free tier]

What is in this shared backtest link? Fetches a backtest that someone published via a share link, addressed by its share_id — no ownership and no Pro tier required, which is what makes it the right tool when a user pastes a /shared/backtests URL. Returns the same result shape as arena_get_backtest (config plus aggregate metrics). Use arena_get_backtest instead for the user's own runs. [Free tier]

Should I take this entry? Answers it for one (strategy, pair, interval) in ONE call instead of seven. Aligns what each entry filter historically did to this strategy (arena_get_strategy_filter_effect) with where that filter stands TODAY (bull-market gauge, altcoin-season signal, volatility phase, 200-week trend for BTC): `filters[].blocks_this_entry` says which filter would sit this entry out, with the measured worst-loss / return deltas next to it. Adds the current signal state (anticipated is always false — before candle close there is no signal), an `edge_vs_benchmark` block gated by the MEASURED noise floor (a gap below the floor is a measurement artifact, not a finding), a `contradictions` block (e.g. Pulse risk-off while the macro regime reads risk-on — reported, never resolved), and measured invalidation zones (pivot clusters, 200-week SMA; BTC only). `detail`: 'headline' (default) returns the statement, three key numbers and only the decisive filters; 'full' adds every variant, the raw pulse/macro/filter-effect blocks. Every source can fail independently — sources_used / sources_unavailable make the basis auditable; the answer never silently narrows. Returns a plain-language `statement` with its `confidence` and the reason for that confidence — state it, do not hedge it further; the payload carries its own scope note. Compose further with arena_get_strategy_performance_by_regime (WHEN has this worked) and arena_is_distinguishable. [Free tier]

When did which classic top/bottom signal actually flip? Event log of discrete transitions across 13 declared signals: bullmarket_stage_1..5 (20W/50W-MA stages), pulse_band, hash_ribbons, mvrv_z_regime, mayer_band, nupl_zone, pi_cycle_cross, golden_death_cross, price_vs_200wma. Each event: from/to state, occurred_at (day of the flip) vs event_date (day it became CONFIRMED — dwelled signals confirm after min_dwell days; use event_date for any forward evaluation, occurred_at carries look-ahead), declared threshold params, btc_close and drawdown_from_ath_to_date_pct (vs the ATH up to that day, never a later one). The window is capped in SIZE but free in POSITION: end_date moves it anywhere in the reconstructable history (coverage block names per-signal start, measured). Events are RECONSTRUCTIONS from today's stored series under declared rules — not what a live observer necessarily saw, and not forecasts: the log includes every rule that stayed silent through the October 2025 top. Filter with `signal`. [Free tier]

Is this strategy signalling buy or sell right now? Current signal-status (green/yellow/red) for a strategy on a pair+interval. Backed by the daily check-signals cron — needs at least one user with an active Ampel on this combination. [Free tier]

Current BTC, ETH and SOL spot price — what is Bitcoin (or ETH/SOL) worth right now? Live USDT-quoted last price plus 24h change %, high and low from Binance. Use this to anchor the connector’s own analytics (cycle, historical-analog, gem scores) with the current market price instead of switching to web search mid-analysis. [Free tier]

Aggregate stablecoin supply (crypto-liquidity proxy) — is the liquidity impulse turning or accelerating? macro_regime only gives the 30d delta; this exposes the trend: current supply, 30d/90d change (USD + %) plus a compact time series so direction and speed are visible, not just a single delta. Read `impulse` for what the supply change is doing — four states (accelerating / decelerating / reversal / flat). The neighbouring `acceleration_usd` is the signed difference last-30d minus prior-30d and gets LARGE exactly when the trend reverses, while the older boolean `accelerating` requires the same direction AND a bigger magnitude; a reversal therefore shows a big `acceleration_usd` next to `accelerating: false`. Source DefiLlama peggedUSD. [Free tier]

What did recent buyers pay on average — and how far is spot from that? Latest BTC short-term-holder cost basis (realized price of coins younger than ~155 days, BRK brk_sth_realized_price), derived STH-MVRV (spot ÷ STH cost basis), an in_loss flag, plus ±1σ/±2σ bands: basis × exp(±k·σ), σ of ln(price ÷ basis) over a 730-day ROLLING window (sigma_method/sigma_window_days travel in the payload; similar construction to public STH band charts, own convention — not a rebuild). band_zone names the state (above/below basis, beyond ±2σ); sth_mvrv_percentile is the rolling 730d rank. Measured band coverage (2026-08-25, full history): 32.1% of days outside ±1σ (near the Gaussian 31.7%), 7.4% outside ±2σ (wider than the Gaussian 4.6% — fat tails); the bands are descriptive geometry (the measured coverage above tells you how literally to take them). On-chain context you weigh with the percentile field. [Free tier]

What would each entry filter have changed for this strategy? Per-(strategy, asset, interval) filter-effect analysis. Returns baseline-stats (no filters) + each observed filter-variant's stats with cagr_delta / drawdown_delta / win_rate_delta vs the time-overlap-matched baseline + best_by_cagr pick (null with best_by_cagr_reason when every variant is low_data or none beats the baseline — no pick below the data gate) + not_applicable_filters list (e.g. altcoin_season excluded on BTC-pair). Baseline and each variant carry their aggregation `window` (from/to + avg_run_years) — CAGR is time-normalized, so identical trade sets over different windows legitimately produce different CAGR. Based on REAL backtest aggregations — not theoretical 2^5 permutations. Use this to answer 'Which filters would improve my backtest for X on Y?'. [Free tier]

Which strategy and interval combinations actually performed? Aggregated backtest performance per (strategy × interval) cell. If `strategy` AND `interval` provided, returns detail with per-asset breakdown + param variants. Otherwise returns the matrix. Free tier is limited to the same strategies that are free in the backtester itself (rsi_sma, golden_cross, rsi_ob_os, bnh_fixed, dca_reference); the response then carries `plan_capped: true` plus `plan_cap_note`, so a short matrix is never mistaken for a thin database. Detail mode on a Pro-only strategy returns 403 rather than a silently empty answer. API Pro and Power receive every cell. [Free: 5 strategies / Pro+: full]

How did this exact strategy, asset and interval perform? Aggregated backtest performance for ONE specific (strategy, asset, interval) combination. Returns run_count, avg_cagr, avg_win_rate, avg_drawdown, effective_years, vs_buy_hold comparison (beats_buy_hold, cagr_delta) and an `evidence` block declaring the gate machine-readably (gate_applies_to: stats.run_count, threshold 5 runs, benchmark value, aggregation data window). For multi-strategy overview use arena_get_strategy_insights. Use this to answer 'How does strategy X perform on asset Y?'. [Free tier]

In which macro regime has this strategy worked? Historical backtest performance for ONE (strategy, asset, interval) combination SPLIT BY macro market regime (sweet_spot / late_cycle_warning / crisis / recovery — classified at each trade's entry date), PLUS the CURRENT live regime so you can align the buckets yourself. You get the per-regime numbers to weigh directly (per-bucket verdicts live in the per-cell tools, where the pool is stable). Each regime bucket returns trades, trades_per_config (trade counts pool ALL parameter-variant configs — see config_count), win_rate, avg_pnl_pct (per-trade return, not annualized), reward_risk_ratio (per-trade mean/stddev, NOT annualized Sharpe), share_of_time_pct (calendar-day-weighted — each regime observation counts the days until the next one, so the mixed weekly/daily cadence of the regime history does not skew the share) and a rating. The `benchmark` block anchors the payload with the combination's buy-and-hold CAGR (identical to arena_get_strategy_performance vs_buy_hold — without that anchor, regime avg_pnl_pct is a trajectory, not an excess). For a decision-grade view compose with arena_get_strategy_filter_effect and arena_is_distinguishable. [Free tier]

Are taker buys or taker sells dominating? Daily SPOT taker-buy share for a Binance pair: taker-buy volume divided by total volume, one value per UTC day (0..1; 0.5 = balanced aggressor flow, above 0.5 taker buys dominate). Derived ratio only — raw volumes are not redistributed. This is SPOT aggressor flow, not futures positioning — for leverage positioning use arena_get_funding_rate_history. Returns the series ascending plus latest, window_mean and n_days; the forming day is excluded (its share still moves). Window via `days`, capped by tier — the `range` block declares requested/granted. [Free 30d / Pro 365d / Power unlimited]

Where does price sit inside its trend channel? Mechanically fitted trend channels for a pair: log-linear regression over close plus 1σ/2σ bands, computed over three fixed windows at once (90/180/365 bars, not selectable) — three side by side show whether a channel is robust or an artifact of the window choice, and `agreement.consistent` states which it is. `r_squared_percentile` ranks the fit against all same-size windows on this pair, so an R² comes with its placement instead of standing alone. Where history is too short the window is omitted and listed in `windows_unavailable` with a reason — never estimated from fewer bars; below 500 bars (1d) / 150 (1w) the raw values still come but `percentile` is null rather than a rounded number from too small a sample. Pairs listed within the last few months (the tokenized equities and ETFs) therefore return `data_sufficient: false` and an empty channel list — that is the answer, not an error. Set `interval` to '1w' for the weekly view; note that a window is counted in bars, so 365 on '1w' means 365 weeks and most pairs do not reach it. Band edges describe past dispersion around the regression line. Related: arena_get_key_levels (pivot clusters), arena_get_btc_market_structure (trend flips and their base rate), arena_get_historical_analog (whether a condition like the current one ever paid). [Free tier]

Which pairs are in this universe? Returns one pair universe in full: its id, label, selection rule and the complete list of pairs it currently contains. Use it to see what you are about to test BEFORE handing a universe_id to arena_run_universe_backtest, or to resolve a universe into explicit pairs. For the list of available universes call arena_list_universes. Universes reflect the CURRENT membership — they are not point-in-time, so a backtest over them carries survivorship bias for the earlier years. [Free tier]

How volatile has Bitcoin been? Daily Bitcoin volatility time series: realized volatility (30d & 90d, √252-annualized, close-to-close) and ATR% (Wilder EMA-14, captures intraday range + gaps), on the same scale. Ranks come in two flavours answering different questions: `rvRank`/`atrPctAnnRank` expand from the start of history and are look-ahead-free, but they include BTC's structural volatility decline; `rvRankRolling`/`atrPctAnnRankRolling` rank against a trailing 2-year window, which removes that trend from the comparison. History reaches back to 2009 via a stitched pre-Binance close series; ATR is null before the Binance era because no daily high/low exists that far back (see meta.coverage). Use `from`/`to` for a specific window instead of pulling everything and discarding it, and `granularity`/`fields` to keep long ranges affordable. For long ranges pass `schema_version: "2026-08"` (rounds floats; opt-in until the default flips 2026-11-01) plus `fields: "minimal"` and `meta: "minimal"` — every response carries a `size` block with `chars_before`/`chars_after`/`saved_pct` measuring the saving for YOUR call. Free tier: last 365 days. Related: arena_get_volatility_phases (current phase per pair), arena_get_iv_snapshot (implied vs. this realized — same RV method, but its realized_vol_30d is computed at snapshot time BEFORE that date has traded, so on fresh breakout days the two can differ; this series uses completed closes and is the one to trust for finished days), arena_get_cycle (regime context). [Free tier]

Does this strategy work better in calm or wild markets? Breaks realized strategy performance down by VOLATILITY PHASE (low / normal / high) per asset and timeframe, so you can see whether an edge only exists in one volatility regime. Answers "when does this work", not "does this work" — for the overall verdict use arena_get_strategy_insights, for the macro-regime cut arena_get_strategy_performance_by_regime, and for the raw volatility time series arena_get_volatility_history. Cells below min_trades are suppressed rather than shown as noise. [API Pro tier]

Is this pair calm or wild right now? Current ATR-based volatility phase (low/normal/high/expansion) per tracked pair, updated daily at 08:00 UTC. This is a single current state — for the time series behind it use arena_get_volatility_history, and for what the phase implies for strategy choice use arena_get_volatility_recommendations. Filter with `pair` when you only care about one asset instead of pulling all of them. [Free tier]

Which strategies suit the current volatility phase? Top-3 by historical win-rate for that phase on a given pair. Phase comes from the latest snapshot (arena_get_volatility_phases); minimum 20 trades per phase required for inclusion. Answers "which strategies did well in a phase like the current one?" — a historical ranking of what held up in comparable phases. Related: arena_get_volatility_phases (the phase itself), arena_get_edge_reports (filter effects with verdicts), validate_strategy (evidence check on a concrete configuration). [API Pro tier]

What are the strongest backtest results on the platform? Public leaderboard: the highest-CAGR backtest results across all users, with anonymized usernames, pair, strategy, interval and period. Answers "what has scored best on this platform so far". A top-of-leaderboard entry is the winner of a large search — pair it with arena_get_robustness_field or validate_strategy to see how much of the edge survives outside its winning cell. For the user's own runs use arena_list_backtests. [Free tier]

Do these two CAGR figures actually differ? Check before ranking them. Pass the two values as `a` and `b` (gross CAGR in percent, same basis) plus `axes` — which arbitrary choices went into them — and the tool returns whether their gap clears the MEASURED noise floor of those choices, along with the floor itself, the dominant axis, and the probe + date it was measured on. `axes` accepts: grid_phase (how a multi-day candle grid is aligned to the Unix epoch; exists only on 2d/3d), parameter_choice (neighbouring parameter settings — by far the largest axis), window_edges (shifting the start date), pair_selection (which pairs made it into the universe). Pass ALL axes that genuinely varied; the floor is their maximum, not their sum. Optionally set `interval` to the candle interval so the floor can be sharpened where an axis was measured per interval — passing grid_phase together with a non-multi-day `interval` is a hard error, because that axis does not exist there. `label_a` and `label_b` are optional display names for the two values and are echoed back inside the explanation, so a multi-way comparison stays readable. Read-only, no market data touched. [Free tier]

Which backtests have I run? Lists the backtest runs belonging to the authenticated user — newest first, with id, strategy, pair, interval, date range and headline metrics per run. Use it to find a run_id, then call arena_get_backtest for its detail or arena_get_backtest_trades for the individual trades. Only your OWN runs; for the public cross-user leaderboard use arena_get_winners. Paginated via limit + offset. [API Pro tier]

What knowledge objects exist here? Discover what Knowledge Objects exist: lists all published types + their subjects (with min_tier, api_path, seo_slug, latest as_of). Use this BEFORE arena_get_knowledge to learn valid type/subject pairs instead of guessing. New types appear automatically. [Free tier]

Which on-chain series are available? Lists all 65 available Bitcoin Research Kit (BRK) on-chain series across the groups pilot, sentiment, mining, supply, cointime, activity, liquidity (e.g. MVRV, NUPL, SOPR, Realized-Price, Mayer, Puell, STH/LTH SOPR, Hash-Ribbons). Returns id + label + group. Use the id with arena_get_onchain_latest / _history. [Free tier]

Which strategies can I backtest here? Lists all backtest strategies (key, label, plan, supported asset classes, primary indicators). Filterable by asset class and plan. Use this before calling arena_run_backtest to discover valid strategy names. Entries deprecated for an asset class stay listed (historical results depend on them) and carry deprecated_for + deprecation {since, reason} — do NOT call arena_run_backtest or validate_strategy for those combinations, they return 400. [Free tier]

Which alerts do I have running? Returns every ACTIVE subscription belonging to the current API key: id, type, trigger configuration, delivery method and expiry. Use it to see what is already running before creating a duplicate, and to get the subscription_id that arena_cancel_subscription needs. Does not return fired updates — that is arena_check_subscription_updates. [API Pro tier]

Which asset universes can I test against? Lists all crypto asset universes (BTC, top-10 crypto, top-50 crypto, etc.) — the underlying pair-sets used by custom-report and universe-backtest endpoints. [Free tier]

What would a custom report cost? Get a pricing quote for a custom report (universe-backtest PDF + Excel) without committing to a purchase. Returns price, universe size + preview, excluded pairs, and filter config. Crypto universes use top-N tiers (top-10 … top-250) or a custom pair list. [API Pro tier]

How would this strategy have performed? Run ONE strategy on ONE pair over a date range and get the full result: CAGR, total return, max drawdown, win-rate, trade count, Buy & Hold comparison, net-of-fees figures, and a run_id for later retrieval. Synchronous, typically 3–10s. Use this when the user wants a concrete result for a specific setup. For several strategies side by side use arena_compare_strategies; for many pairs at once use arena_run_universe_backtest; to judge whether an EXISTING result is trustworthy rather than produce a new one, use validate_strategy or arena_get_robustness_field. Filters are optional and only remove entries; run once without them for the baseline. Read result.benchmark before comparing cagr to buyhold_cagr: warmup or a late listing can shorten the strategy window, and matches_strategy_window:false means the two figures are annualized over DIFFERENT periods — in that case benchmark.strategy_window carries the like-for-like buy-and-hold over the window the strategy actually traded, and THAT is the one to compare against. Per-day quota: Pro=50, Power=500. [API Pro tier]

Would a grid bot have made money here? Simulate a GRID BOT (buy-low / sell-high ladder inside a fixed price range) on historical candles. Returns final value, return %, CAGR, trade count, fees paid and a Buy & Hold comparison. This is a different machine from the strategy backtester: grid bots earn from oscillation inside a range, not from trend — for signal-based strategies use arena_run_backtest instead. The result depends heavily on the range you choose (low_price / high_price); a range the price left early makes the bot idle, so treat range choice as part of the hypothesis, not a detail — arena_suggest_grid_range proposes a defensible range. Each run is saved to your account (the returned id is the run_id); publish a public snapshot page with arena_share_grid_backtest. grid_mode picks neutral (default) or long. Optional leverage (2/3/5, grid_mode long only, Pro) with funding_mode (conservative default / historical BTCUSDT / none): simulates an isolated-margin futures long grid — margin = total_investment, the grid trades margin × leverage, funding accrues daily on the open position, liquidation is checked per candle at the low. It simulates, it does not recommend: the result can be a total loss of the margin. Free tier limited to BTCUSDT/ETHUSDT. Per-day quota: Free=5, Pro=50, Power=500. [Free / Pro / Power tier]

Does this strategy hold up across a whole universe? Runs it against every pair in the universe. Pair cap depends on your API tier: Pro 50, Power 250 — Power covers crypto-top-250 in ONE job, and a single job keeps the ranking on one pair set (merging results across different pair sets measures pair selection, not strategy quality). THIS CALL IS ASYNCHRONOUS AND RETURNS NOTHING BUT A job_id: the result is NOT in this response. You MUST poll arena_get_job_status until status is 'completed'; estimated_seconds in the create-response says how long to budget. Provide either universe_id (call arena_list_universes) OR explicit pairs[]. Benchmarks bnh_fixed and dca_reference are accepted here — run one of them over the SAME universe and interval alongside: an excess over buy-and-hold is only readable next to the buy-and-hold value itself, which can be negative. beats_bh_count compares each pair's cagr against the LIKE-FOR-LIKE buy-and-hold — the benchmark measured over the window the strategy actually traded, not from the requested start. A long warmup or a pair listed after date_from shifts that start, and comparing across two different windows is a handicap, not a benchmark. The old pairing is still reported as beats_bh_count_requested_window, and pairs_with_window_offset says on how many pairs the two can differ at all; per-pair, buyhold_cagr_strategy_window and benchmark_matches_window carry the same distinction. PERSISTENCE: universe results live ONLY in the job response (api_jobs.result). They are deliberately not written to backtest_runs, so they carry no filter_binding and no coin-denominated history, and you will not find them later via arena_list_backtests — copy what you need out of the job result. Per-day quota: Pro=5, Power=50. [API Pro tier]

Want a public link for a grid result? Publishes a read-only snapshot page (with OG preview image) for one of YOUR saved grid backtest runs and returns its URL. Pass the run_id you got back from arena_run_grid_backtest (every authenticated run is saved automatically). The page shows the numbers the engine actually computed — this tool takes no result values, so shared pages cannot carry fabricated figures. Shares are permanent snapshots; language picks the page copy (en default). [Free tier]

Am I connected, and what can this key do? Returns auth status (key kind: oauth connector or bearer API key, tier), server version, current UTC time, and the rate-limit state (hour/day used, remaining, reset) WITHOUT consuming extra quota beyond this call itself. Call this first when other tools fail: it separates auth problems (reconnect), tier problems (upgrade) and rate limits (wait) from real outages. [Free tier]

Notify me when the bull-market stage count changes? Tracks the Bullmarket-Ampel active stage count (0–5). Optional direction filter (up/down/any) plus specific stages of interest. For the current stage count without subscribing, call arena_get_bullmarket_ampel. Creates a standing subscription; it does not return a value now — collect fired updates with arena_check_subscription_updates (polling) or receive them by webhook, and end it with arena_cancel_subscription. For the CURRENT value instead of a change notification, call the matching read tool. [API Pro tier and up — max 3 active subscriptions for Pro, 20 for Power]

Notify me when the cycle band changes? Bands: (capitulation → risk-off → neutral → constructive → euphoric). Optional bands filter restricts to specific target bands. For the current band without subscribing, call arena_get_cycle. Creates a standing subscription; it does not return a value now — collect fired updates with arena_check_subscription_updates (polling) or receive them by webhook, and end it with arena_cancel_subscription. For the CURRENT value instead of a change notification, call the matching read tool. [API Pro tier and up — max 3 active subscriptions for Pro, 20 for Power]

Notify me when market heat crosses a threshold? Fires when the daily 0–100 Arena-Pulse score crosses threshold_above (upward) or threshold_below (downward). At least one threshold is required. For the current score without subscribing, call arena_get_pulse. Creates a standing subscription; it does not return a value now — collect fired updates with arena_check_subscription_updates (polling) or receive them by webhook, and end it with arena_cancel_subscription. For the CURRENT value instead of a change notification, call the matching read tool. [API Pro tier and up — max 3 active subscriptions for Pro, 20 for Power]

Notify me when this signal flips? Fires when an existing Ampel-Config's signal flips (BUY ↔ SELL). Prerequisite: the user must have created that ampel-config in the web UI (`/dashboard/ampel`) — pass its UUID here; this tool cannot create one. Optional signal_types filter narrows to BUY-only or SELL-only. For the current signal state without subscribing, call arena_get_signal_status. Creates a standing subscription; it does not return a value now — collect fired updates with arena_check_subscription_updates (polling) or receive them by webhook, and end it with arena_cancel_subscription. For the CURRENT value instead of a change notification, call the matching read tool. [API Pro tier and up — max 3 active subscriptions for Pro, 20 for Power]

Which price range should my grid bot use? Answers the question arena_run_grid_backtest deliberately leaves open (its own description says: treat range choice as part of the hypothesis). Returns TWO independent range suggestions side by side: iv_anchored (BTCUSDT/ETHUSDT only — sized from option-implied volatility, Deribit DVOL Index; the methodically grounded answer) and recent_volatility (7 trading days of realized volatility before anchor_date — the method exchange auto-modes use, available for all pairs). When both exist and disagree strongly, the options market expects a different volatility regime than the recent past showed — that disagreement is information. Output field names (low_price, high_price, grid_count, grid_type) map 1:1 onto arena_run_grid_backtest inputs. Inputs: pair (required), anchor_date, sigma_mult (IV range width in sigmas, default 1.5), dte (IV horizon in days, default 30). For a historical backtest set anchor_date to your start_date so the volatility range matches the entry, not today; iv_anchored always reflects the latest IV snapshot regardless of anchor_date. Free tier limited to BTCUSDT/ETHUSDT (same gate as the grid backtest itself). [Free tier]

Does this strategy survive an honest test? Backtest a trading strategy honestly — look-ahead-aware validation with Deflated-Sharpe-Ratio / multiple-testing correction (Bailey & López de Prado). Returns an EVIDENCE verdict (insufficient_evidence | anecdote | failed_oos | passed_oos) plus metrics, flags and caveats — NOT a buy/sell recommendation. Call this before acting on a strategy or signal list. Accepts a named catalog strategy (type=rules), a timestamped BUY/SELL signal list (signal_list), or a timestamped trade list (trade_list). Checks: realistic next-bar fills (look-ahead/optimism), net of cost, out-of-sample split, and a hard 30-round-trip sample gate (under 30 is always "anecdote"). Not reproducible via generic backtest tools that ignore overfitting. [API Pro tier]