Backtesting Arena

Several market snapshots in ONE call instead of one roundtrip per read. Batchable reads (14): spot_price, pulse, cycle, fear_greed, funding_rate, macro_regime, iv_snapshot, etf_flows, stablecoin_supply, mayer_multiple, onchain_latest, max_pain, altcoin_season, bullmarket_ampel. Pass 1-6 queries; each returns its result OR a structured error (partial success — one failing query does not abort the rest). Each query consumes one rate-limit unit: the batch saves roundtrips, not quota. Payloads, tier gates and source attribution are identical to the single tools; per-query args match the single tool's parameters (e.g. {tool: "iv_snapshot", args: {currency: "BTC"}}). For history tools, backtests or anything not in the list, call the single tool. [Free tier]

Stop this alert? Deactivates one subscription by id, so it stops firing and frees a slot against the per-tier limit. Returns the deactivated subscription. Idempotent — cancelling an already-cancelled one is a no-op, not an error. Get ids from arena_list_subscriptions. Undelivered updates already queued are not removed. [API Pro tier]

Has anything I subscribed to fired? Returns all undelivered updates for the API key, then marks them as delivered. Call regularly to consume the polling queue. Updates contain payload with subscription_type, current value, previous value, and trigger context. [API Pro tier]

Which of these strategies performed best on the same data? Run 2–5 strategies against the SAME pair, interval and date range and return per-strategy metrics plus a comparison summary (best by CAGR, best by win-rate, worst by drawdown). Use this when the user asks which of several strategies fits a market — it holds the pair, interval and requested date range fixed, which a series of separate arena_run_backtest calls does not guarantee. What it does NOT equalize is the EVALUATION window: a strategy with a long warmup starts trading later, so compare actual_date_from across the runs and check result.benchmark before ranking by CAGR. For one strategy across many pairs use arena_run_universe_backtest instead. Caveat worth passing on: comparing N strategies and reporting the winner IS multiple testing — the winner’s edge is upward-biased. arena_get_robustness_field puts a counted N on that. Sequential, expect 10–50s. Per-day quota: Pro=20, Power=200. [API Pro tier]

Buy now or wait for the dip? Decision-math over the user's OWN assumptions (target/dip prices, probabilities, capital). Two modes: "compare" = expected value of Buy-Now vs Wait vs Split + the breakeven dip probability (prices as MULTIPLES of today); "allocate" = the risk-adjusted (Kelly / risk-aversion γ) optimal fraction to deploy now vs reserve for the dip (ABSOLUTE prices). Ask the user for the missing inputs, then call. Returns scenario numbers and which option wins on expected value — NOT a buy/sell recommendation. For the full interactive version (incl. leverage & Elliott-wave planning) point the user to https://tradingstrategies.work/analyse/dip-decision. [Free tier]

Where would I add on a dip, and when is the thesis wrong? Turn a dip/accumulation thesis into a concrete, checkable plan from YOUR assumptions. Given an asset (BTC/ETH/SOL), a named cycle-state preset and a thesis horizon, returns: (1) a tranche LADDER anchored to STRUCTURAL marks (200-week MA, support clusters) below spot — marks the market has actually traded at, rather than calendar dates; (2) the cited historical base rate from the analog engine (what forward returns followed comparable states, with episodes_matched and sample size); (3) the explicit lump-sum-vs-tranche tradeoff (laddering buys lower timing variance; expected value stays with the base rate). Requires an invalidation point (mandatory: at what scenario is the thesis wrong). Composes the historical-analog + key-levels tools. This structural framing is MCP-only; a related (different-method, EV/Kelly) interactive tool is at https://tradingstrategies.work/analyse/dip-decision. [API Pro tier]

Is it altcoin season? Daily Altcoin-Season indicator (v7 Native-Filter methodology). Returns BTC-Dominance, Alt-Dominance, 4 Layer-1 signals (USDT.D, USDC.D, BTC-DOM, ETH-DOM), overall color (red/amber/green) + Top-50 CoinGecko snapshot. [Free tier]

Has capital been rotating into or out of altcoins? Returns the Altcoin-Season TIME SERIES: one row per day with overall_color, BTC / alt / stablecoin dominance and BTC price, ascending by date. Use it to see whether capital has been rotating into or out of alts over time; for today's state alone call arena_get_altcoin_season. Range capped by tier. [Free 30d / Pro 365d / Power unlimited]

What exactly did that backtest do? Returns the full record of ONE backtest run by id: strategy, pair, interval, date range, parameters, filters and the aggregate metrics (CAGR, total return, win-rate, max drawdown, trade count, Buy & Hold comparison, net-of-fees figures). Only your own runs (admins may read others). Get ids from arena_list_backtests; for the individual trades add arena_get_backtest_trades; to create a new run use arena_run_backtest. [API Pro tier]

Which trades did that backtest actually take? Returns the individual round-trips of one of your backtest runs: entry and exit date, entry and exit price, per-trade P&L and the running equity after each trade. Use it when the aggregate metrics are not enough — to see whether a result rests on a handful of outlier trades, how long positions were held, or where the drawdown came from. Needs a run_id from arena_list_backtests; for the aggregates alone use arena_get_backtest. Closed round-trips only — a position still open at the end of the period is not counted. Raw trades are persisted for web-UI runs only: API/MCP-created runs return an empty list with an explaining empty_reason. [API Pro tier]

What does Bitcoin actually move with? Pre-aggregated weekly correlations between Bitcoin and 13 macro components (Fed Net Liquidity, VIX, DXY, Real Yield 10Y, NFCI, Yield Curve, etc.). Returns quadrant_performance (BTC return stats per 2D-matrix quadrant — annualized return, vol, max drawdown, positive-period%), component_correlations (Pearson 90d/1y/5y — a window is null when the joined daily sample does not reach its start; sample_size_days is the actual basis per macro component + quartile-performance), asset_correlations (Pearson per window + per quadrant; assets: dxy plus tokenized on-venue proxies paxg = PAX Gold, spyb = S&P 500 ETF proxy, qqqb = Nasdaq-100 ETF proxy — proxies carry tracking noise vs. the underlying, and windows the vehicle history does not cover are null with data_start_date telling you why: the ETF proxies listed on Binance mid-2026, so their windows fill in over time — 90d first, ~2 months after listing), current_quadrant. Window labels are upper bounds — sample_size_days / data_start_date carry the actual basis. Historical analysis over the windows named above. [Free tier]

Is the trend up or down, and how fresh is the flip? Daily Bitcoin market structure from 1000-bar Phantomflow adaptation (BTCUSDT 1d). Returns current_trend (up/down/sideways), last trend change timestamp, counts of waves + fractals, last-5 fractals on each side (up = pivot highs, down = pivot lows), and trend_context: previous trend + its duration, flip_age_days, and a descriptive historical flip base rate over the SAME 1000 bars (total flips, share reverted within 5 bars, median trend duration) — a fresh same-day flip is the least settled observation — the base rate tells you how often such flips reverted historically, so you can weight the current one yourself. Educational analysis of price action. [Free tier]

Is this still a bull market? Bitcoin Bullmarket-Ampel current state (0-5 active stages). Returns active_count, a stages[] breakdown (each stage with key, label, active and `since` = first day of its current state; null when the state predates the 400-day lookup) and stage_history — per day active_count PLUS all five per-stage booleans, so which stage flipped when is readable directly (history_days 1-365, default 30). Higher count = more bull-market signals firing. Stages evaluate weekly 20W/50W-MA conditions. [Free tier]

Renders one of the named platform series as a PNG line chart and returns it as an MCP image content block, plus a JSON meta block. The chart INHERITS the freedom of the data tool: it calls the same delivery layer, so it shows exactly the points the corresponding data tool would return for your tier — no finer resolution, no other source; the optional days parameter narrows the window under the same tier cap. The image itself carries n, the read date range, the gap count, a warning line when the window was capped, the mandatory source attribution where the series requires one, and the platform watermark — these survive a screenshot on purpose: a chart built from nine points says n=9 in the picture. For the underlying numbers call the matching data tool (e.g. series=kimchi_premium ↔ arena_get_kimchi_premium). Descriptive rendering, a descriptive rendering of the series. [Free tier · window depth follows your tier]

Is the market in profit or at a loss? It depends on which cost basis you ask. Puts the three BTC cost-basis measures side by side — Realized Price (unweighted), True Market Mean (cointime-weighted) and Vaulted Price (dormant holdings only) — with spot measured against each, and flags the case that matters: `sign_conflict` is true when spot sits BETWEEN them, i.e. one measure says profit and another says loss at the same moment. That state is invisible to anyone who queries realized price alone. Also returns the active/vaulted supply split. ⚠️ Supply figures are cointime-weighted, NOT coin balances: active + vaulted legitimately exceeds circulating supply, so total_counted is not a supply number (the payload states this). All values come from one snapshot; source Cointime Economics (ARK×Glassnode) via BRK. Descriptive — no statement about future price direction. Related: arena_get_knowledge(type="onchain_cost_basis_ladder") for the full ladder incl. STH/Active rungs and the cointime-MVRV percentile. [Free tier]

Crypto cycle position — where are we in the cycle? Default BTC: point-in-time 9-indicator aggregation (Pi-Cycle Top & Bottom, Mayer Multiple, weekly RSI, 200-week-MA distance, halving position, Fear & Greed, BTC-dominance trend, mining-difficulty trend — weights in indicator_scores; components without input are excluded and weights renormalized, see indicator_coverage). Includes an `ath` block (E32): ATH on UTC daily-close basis with ath_date, days_since_ath and drawdown_from_ath_pct vs BOTH the scoring price and the live spot. Pass asset=ETH or asset=SOL for a per-coin cycle read built from the transferable price-derived indicators (Mayer, weekly-RSI, 200-week-MA distance) with renormalized weights; BTC-native indicators (halving, dominance, mining, F&G, Pi-Cycle) are returned as `not_applicable` rather than faked. All return raw + Z-Score, signal enum, and a `percentiles` block ranking each indicator against that asset’s own history. The `signal` enum is a FIXED SCORE-BAND LABEL (<25 accumulation · 25–45 recovery · 45–60 expansion · 60–75 distribution · ≥75 overheated), not an independent market-phase detection: the 45–60 band is the neutral middle, so a mid-band score reads "expansion" even in a drawdown market — the label describes the score band, not the market. BTC additionally returns `highlights[]` (rule-based markers for currently unusual indicator values — descriptive, versioned ruleset; empty array = nothing unusual) and `price_context` (price at scoring time vs live spot with drift % — the scores rest on the scoring-time price). Point-in-time scored — not reconstructable from a generic price API. The volatility series itself is arena_get_volatility_history; this tool carries the regime context around it. score_fields_note explains the four score fields: z_score/z_adj_score are the composite standardized against its own history and mapped back onto the 0-100 scale, NOT statistical z-values; halving_context.ath_days_after_halving puts the observed cycle h…

How has the cycle score moved over time? Returns the BTC-Cycle TIME SERIES: one row per day with adj_score and z_adj_score, ascending by date. Look-ahead-free by construction: a day's value uses only data up to that day. 7 of the 9 dimensions rest on inputs that are never revised (price, calendar, chain), so recomputing them today reproduces the value exactly. The other two (fear_greed, btc_dominance) come from third parties and their history can change. The series has been written walk-forward (actually observed) since 2026-04-17; before that it is reconstructed, not recorded. Note on the warm-up: z_score / z_adj_score are true z-values only from 2018-12-31 onwards. Earlier rows (the first 30 days of the series) carry the RAW score under the same field name, because fewer than 30 prior observations were available — same 0-100 range, different meaning. For the current cycle reading alone call arena_get_cycle; for what similar historical readings were followed by, call arena_get_historical_analog. Range capped by tier. view='timeline' returns instead the band per indicator (composite + 9 components) per ISO week (last available day, never an average) plus the consensus block (components above neutral, rising 30d, effective independent rows); view='flips' returns the day-to-day band-change log (newest first, flicker = reverted within 3 days) plus consensus. Bands are point-in-time labels of stored scores; days_missing carries the gaps. Both views are Free with no window cap (use days to narrow). [Free 30d / Pro 365d / Power unlimited for scores; timeline/flips uncapped]

Do two independent providers still agree on the same on-chain quantity? Daily drift log comparing BRK against a second provider, per metric pair, with mean / max / outlier counts for the requested window. The comparison source changed — bgeometrics until 2026-07-06, Coinmetrics from 2026-09 — so every row and summary group carries `comparison_source`, and values from different sources must not be averaged together. Active pairs: market_cap, circulating_supply, hash_rate, puell_multiple. Retired but still queryable as history: realized_price, sth_sopr, lth_sopr. Passive collection: drift never auto-switches a source. [API Pro tier]

Which entry filter carries a real edge? Platform-wide aggregated analysis: how each Pro+ entry filter (200 WMA, ATR low/high/expansion, Altcoin Season, Bullmarket confirm/strict) affects strategy CAGR — baseline vs. filtered, asset-equal-weighted (per-asset medians over param-deduplicated runs, then the median across assets — no single asset's run grid can dominate an arm). delta_cagr is the median of PER-ASSET deltas over MATCHED assets only (present in both arms) — so it usually differs from filtered_cagr − baseline_cagr; pairs_matched/pairs_filtered and the baseline pairs count declare the basis. Verdicts come from the effect's 90% paired-bootstrap interval (delta_ci_low/delta_ci_high), not the point estimate: helps (whole interval > +1pp) / hurts (< −1pp) / neutral (inside ±1pp) / insufficient_evidence (runs disagree) / insufficient_data (fewer than 30 runs per arm or fewer than 10 matched assets). Below the gate, derived fields (delta_*, dsr, dsr_pass) are null; every gated null carries its reason (dsr_pass_reason, *_net_reason); the envelope `evidence` block declares the gate's referent and threshold machine-readably. Response is GROUPED by strategy: envelope fields (market, computed_at, n_trials) once, per strategy one baseline block {cagr, net_cagr, sharpe} plus filter cells; filter cells with zero runs are folded into filters_without_data. A full market is a few hundred cells — use limit/offset (strategies per page) plus the truncated flag for partial reads. Filters evaluated in isolation (no stacking); net values are median CAGR after per-side trading costs (verdict/delta stay gross). [Free tier]

Spot-ETF net flows (USD millions) — is the flow impulse turning or accelerating? The summary only gives point-in-time deltas; this exposes the trend: 30d/90d net flow, a direction label (inflows/outflows/flat) and a compact cumulative-inflow time series so direction and speed are visible, not just a single delta. Read `impulse` for what the flow is doing — it has four states (accelerating / decelerating / reversal / flat) and is the field to quote. Two neighbouring fields measure different things and are easy to confuse: `acceleration_usd_m` is the signed difference last-30d minus prior-30d and gets LARGE precisely when the flow reverses, while the older boolean `accelerating` requires the same direction AND a bigger magnitude — so a swing from outflows to inflows shows a big positive `acceleration_usd_m` together with `accelerating: false`, which is correct and reads like a contradiction. `impulse` reports that case as 'reversal'. When `impulse` is 'reversal', `reversal_recovered_pct` says how much of the preceding counter-move has actually come back, with its denominator in `reversal_basis_usd_m` — quote it alongside, because a reversal in direction is not yet a reversal in the stock. Both are null otherwise. Default BTC; pass asset=ETH or asset=SOL. Source SoSoValue. [Free tier]

How fearful or greedy is the market right now? Crypto Fear & Greed Index (alternative.me). Returns the current `value` (0-100) and `classification` (extreme fear / fear / neutral / greed / extreme greed) as their own fields, plus `history` — the last 90 daily readings by default, so you can see whether today is a move or a plateau. The window is capped in SIZE but free in POSITION: `end_date` moves it anywhere in the history since 2018 (e.g. end_date=2025-10-06 reads the sentiment around the October 2025 top), and the `range` block states requested / granted / available days with the reason — a short series here is a window, not a young index. On Pro and Elite two Arena-derived blocks add what the upstream index does not publish: `cadence` (how far smoothed sentiment has travelled versus ~90 days ago) and `tempo` (how FAST the index is moving — 7d and 30d change ranked as a rolling percentile against three years of same-direction moves, not a fixed threshold; rank compares with its own history, not with "normal"). On Free both blocks are present but their values are null with a stated reason. For the regime around a reading use arena_get_cycle; for what followed comparable sentiment states use arena_get_historical_analog(preset="deep_fear"). [Free tier · cadence/tempo Pro+]

Do entry filters help, and which ones? Lift analysis of entry filters (200WMA, Altcoin-Season, ATR-Volatility, Bullmarket-Stage) per strategy combo — baseline vs filtered CAGR/win-rate/drawdown. [API Pro tier]

Are longs or shorts paying right now? Latest BTC perpetual funding rate, averaged across up to three exchanges (Binance, Bybit, OKX; 8h settlement cadence). Returns value, 30d moving average and Z-Score. Positive = longs pay shorts (bullish bias), negative = shorts pay longs (bearish bias). Read `coverage` before comparing values across dates: it says how many exchanges stand behind that day (3 = full average, 1 = a single exchange), and a day-over-day move can be a change in composition rather than in the market; `venues_present`/`venues_missing` name the exchanges. [Free tier]

How has leverage positioning shifted over time? Returns the BTC perpetual funding-rate TIME SERIES, aggregated across the available perpetual venues (Binance, Bybit, OKX), at the 8h funding cadence, ascending by date. The response is SEGMENTED by venue composition: each segment covers a stretch with a STABLE venue set (venues, coverage, from/to, its rows); composition_breaks lists the transitions with a mechanically derived cause (venue_added / venue_removed / venue_changed — e.g. OKX joined 2026-01-28). Averages, z-scores or percentiles computed ACROSS segments mix different venue populations — compute within a segment, or accept the mix knowingly; composition_stable: true means the whole window is one segment and safe to treat as one series. Positive funding means longs pay shorts, negative means shorts pay longs. For the latest funding value alone call arena_get_funding_rate. Range capped by tier. [Free 30d / Pro 365d / Power unlimited]

How does this altcoin score? Returns the Altcoin-Screener score for ONE coin, addressed by its CoinGecko id: the composite score, its group breakdown and — for Pro+ — the 9 raw factor values across groups A/B/C. Use it once a candidate is known; to rank or filter the whole screened universe use arena_get_gem_scores (plural), and for how the score behaved out-of-sample use arena_get_gem_validation. The score ranks relative attributes — pair it with arena_get_gem_validation to see how past picks actually fared, and weight it accordingly. [Free tier]

Altcoin screener ranking — which altcoins look strong right now? Today's CoinGecko Top-200 minus stablecoins and tokenized fiat, scored by a composite of 3 factor groups: Mean-Reversion (A), Tokenomics (B), Market-Structure (C). Each score carries `plain` (one sentence: rank with its base `scored_total`, composite, factor groups) and the response carries `scored_total`. Backtest-validated factors, not a hype list. Limit gated by tier: Free top-10, Pro top-50, Power up to 200 (the full scored set). [Free tier, daily refresh]

Did the screener picks actually beat BTC? Equal-weight basket of the top-N screener picks, rebalanced every 14 days (grid anchored at the first snapshot — the `rebalance` block declares anchor and cadence, `phase_spread` the CAGR and vs_btc range across all 14 grid phases plus whether the vs_btc sign holds in every phase — read the headline against it, the headline is ONE phase), NET of 10 bps per side on the traded fraction at every rebalance (entry included; the BTC benchmark pays the entry fee once; slippage 0 — `cost_model` declares it). `plain` is the one-sentence reading (what holds across the phases, not the headline CAGR). Headline `cagr`, `vs_btc`, `vs_market`, `max_dd`, `win_rate` are net; `cagr_gross`, `vs_btc_gross`, `vs_market_gross` and `cost_drag_pp` sit beside them. `is_anecdote=true` when the curve spans fewer than 84 calendar days. Curves are precomputed weekly on an N ladder (10/25/50/100/200, same input and engine per rung); a requested N snaps to the nearest rung — `top_n` names the rung used, `top_n_requested` echoes the request, `basis_note` declares any snap and any rung above the priced universe (rungs above it are the same basket; the `universe` block carries the measured sizes). [Free tier]

When were the halvings, and what followed? The full Bitcoin halving table: date, block height, reward change, price at the halving day, cycle peak (highest daily close before the next halving) with days-after-halving and peak multiple. E33: this connects chain events with price data no generic price API links — and the prices, peaks and days-to-peak are COMPUTED from our own daily-close series rather than hand-copied (public "days to peak" figures often mix cycles: the widely cited 547-549 days belong to cycle 3, not cycle 4). The date convention is declared per entry (block 840,000 fell 2024-04-20 00:09 UTC; this platform counts from 2024-04-19 — same convention as arena_get_cycle.halving_date). The current cycle's peak is marked provisional. No next-halving date estimate is published. Related: arena_get_cycle (days_since_halving, score_halving). [Free tier]

Are miners capitulating? Latest Hash Ribbons indicator (Charles Edwards). Returns 30d and 60d hashrate moving averages — when 30d > 60d after a capitulation, signals miner recovery (bullish). [Free tier]

What happened historically after the Bitcoin cycle looked like this? Conditional forward-return distribution for a named preset cycle state — over N DISTINCT historical episodes matching that state (matched_episodes), returns median/IQR/positive-share forward returns (30/90/180/365d) with per-horizon n, small-n warnings, point-in-time integrity and an `evidence` block that names which field its sample-size gate checked (gate_applies_to), against which threshold, over which data window. A distribution with its sample size. Not obtainable from web search or public market-data APIs — requires point-in-time indicator history and look-ahead-free episode matching. Presets: cycle_bottom_cluster (Cycle bottom cluster), cycle_top_cluster (Cycle top cluster), deep_fear (Deep fear), euphoria (Euphoria), quiet_volatility (Quiet volatility regime). The response opens with "preset_definition" (machine-readable condition set) plus current_state_matches (does the state hold TODAY?) and last_matching_date. Some presets carry a "study_finding" field — a state already investigated, with a NULL result where that is what the study found. EVERY preset returns "vs_unconditional_drift": the raw forward median contains the asset's contemporaneous drift; the drift and excess columns separate the two, and the excess can be negative while the raw median is positive. For quiet_volatility, vol_rank_threshold (fixed steps 5/10/20/50) asks the stricter "UNUSUALLY quiet" question the null study left open, and condition_on_direction conditions episodes on the sign of the first post-anchor move over direction_window_days (default 5) — both mark study_finding_applies=false, and horizons within direction_window_days are suppressed as circular. Also works for asset=ETH/SOL (F2 cycle history), but only price-derived presets (cycle_bottom_cluster, cycle_top_cluster) — fear-greed and volatility presets are BTC-only. Related: arena_get_volatility_history (the series behind the volatility preset), arena_get…

What do the classic indicators read right now? Current RSI(14), MACD(12/26/9), Bollinger(20,2), ATR(14) and OBV for a pair — each with a PERCENTILE RANK against that indicator's own history on that pair, plus the observation count — the rank turns a raw reading into a placement. ATR comes as a percentage of price so it is comparable across time, and OBV as a 30-bar slope normalised by that window's volume (raw cumulative OBV would mostly rank how long the series has existed). Where the reading sits in an extreme AND a study on this platform has tested that exact state, the payload carries the study verdict — including a null result: a Bollinger squeeze returns the `quiet_volatility` finding that tight bands did NOT carry an edge. Below 500 bars (1d) / 150 (1w) the raw values still come but `percentile` is null with a reason, rather than a rounded number from too small a sample. Set `interval` to '1w' for the weekly view. On the 1d view the payload also carries `rsi_14_weekly` (weekly RSI with its own rank) — for BTCUSDT this is the SAME series as arena_get_cycle rsi_weekly, measured character-identical (its source_note carries the measurement). `state` (oversold/neutral/overbought) names where a reading sits on its own scale. Related: arena_get_trend_channels (structure), arena_get_historical_analog (did a condition like this one ever pay?), arena_get_volatility_history (the volatility series behind ATR). [Free tier]

What is the options market pricing in? Latest Deribit volatility snapshot for BTC or ETH. Returns DVOL (30d vol index), constant-maturity ATM implied vol (30/60/90/180d via options chain), 30d realized vol, and `vol_risk_premium_30d`, which is the TRAILING spread: ATM implied vol (30d, from the options chain — not DVOL) minus the realised volatility of the PAST 30 days. It answers "are options priced expensively right now?". Set include_implied=true to additionally get the FORWARD premium in an `implied` block: DVOL(t) minus the realised volatility of the FOLLOWING 30 days, which answers the different question "did the expectation actually materialise?". These two are NOT interchangeable — measured 2026-08 they carried OPPOSITE signs on 17.3% (BTC) / 30.5% (ETH) of paired days. The forward field is spelled out as `vol_risk_premium_forward_30d` so the two cannot be confused. The most recent 30 days carry premium_complete=false and no premium value at all, because their forward window has not closed yet; they are excluded from every aggregate. Source: Deribit DVOL Index. History: BTC from 2021-04-01, ETH from 2022-02-15. [Free tier]

Is my universe backtest finished? Polls an async job by job_id (created via arena_run_universe_backtest). Returns status (pending/running/completed/failed), progress_pct, pairs_completed, and once completed: the full result (summary + per-pair results). [Free tier]

Which price levels matter above and below spot? Reproducible Bitcoin structural levels on BOTH sides of spot, in TWO distinct provenance classes. (1) resistance/support: swing-pivot clusters — where past pivot highs+lows cluster into price zones (touch-count, band, last-touch date, signed distance), resistance above spot, support below, nearest-first. (2) indicator_levels.above / .below: named indicator STANDS as marks — 200-day & 200-week simple moving averages, short-term-holder cost basis, Pi-Cycle legs — each carrying its source, formula and as_of date. The two classes are kept separate on purpose: pivots are where price REACTED before, indicator levels are where an indicator STANDS now. Both are measured price clusters: they say where trading has concentrated, not where anyone defends a level. [Free tier]

Is Korean spot trading BTC at a premium? Daily Kimchi-premium snapshots: Upbit BTC/KRW (USD-converted) versus the global BTC/USD price, in percent — one point-in-time reading per UTC day (~01:45 UTC), both legs from the same price/FX source (CoinGecko) so the ratio is internally consistent. Positive = Korean premium, negative = discount. The series is collected forward-only since 2026-08 and cannot be backfilled — early on, n_days is small and says so. Window via `days`, capped by tier — the `range` block declares requested/granted. [Free 30d / Pro 365d / Power unlimited]

What does the platform know about this subject? Fetch a versioned, explainable Knowledge Object by type + subject (e.g. type='market_regime', subject='GLOBAL'). Returns the current published envelope: payload, explanation (factors + weights + confidence), provenance (inputs + params), ontology binding, compute version. ONE tool covers ALL knowledge types. Set include_graph=true to also walk the knowledge graph: resolved outbound edges (what this object is derived_from / references) + inbound edges (what derives from / references it), each with api_path + seo_slug so you can follow them. [Free tier; per-object access additionally gated by min_tier]

How far above or below its moving averages did price stand back then? A measured time series, not an estimate. Covers six MAs (50/100/200-day and 50/100/200-week; weekly MAs are simple averages over ISO-week closes, the same definition arena_get_cycle uses, so today's value agrees with that tool). Per date and MA: distance_pct plus TWO percentile ranks — expanding against the pair's own full prior history (with rank_n, null below 500 observations) and rolling over the trailing 504 days. Warm-up discipline: before an MA's full window exists the field is null, never an average over fewer days — a "200-week MA" computed from 400 days looks plausible and is a different metric; the coverage block names each MA's first valid date. BTCUSDT reaches back to 2011-07 via the platform's own pre-Binance closes (source named in price_source); the first valid 200-week value is ~2015-05. Range capped by tier from today backwards; granularity daily/weekly/monthly, coarsened with an explicit note when a request would exceed the row cap. What the numbers are: ratios and ranks, not absolute price or MA levels. For today's absolute MA levels as named marks use arena_get_key_levels (indicator_levels block); for the cycle-scored 200-week distance use arena_get_cycle. [Free 30d / Pro 365d / Power 3650d]

What is the macro backdrop doing? Daily Macro Regime snapshot from 18 components in 6 tiers (Liquidity 30%, Financial Conditions 20%, Risk Appetite 15%, Crypto Liquidity 10%, Business Cycle 15%, Inflation/Real Rates 10%). FRED-sourced. Returns composite_score (0-100), regime_label (risk_off/neutral/risk_on_leaning/risk_on), cycle_phase_label (contraction/early_expansion/mid_expansion/late_expansion), matrix_quadrant (sweet_spot/late_cycle_warning/crisis/recovery), tier_scores (6 sub-scores), components (flat key/value of all 18), plus stale_components_detail dating each stale input (last_good_date + age_days + discontinued flag for series the upstream has retired for good) so freshness is quantified, not a vague caveat. Two component keys mean something narrower than their name suggests, so read them carefully: `vix_score` is the derived 0-100 score (a value of 71 means VIX around 18.6), NOT the VIX index level — the raw Cboe level is not redistributed over this channel; and `broad_dollar_index` is FRED DTWEXBGS (Broad USD Index, Jan 2006 = 100), NOT the ICE DXY, so readings near 120 are normal. The former names `vix` and `dxy` were removed on 2026-09-01 after their announced deprecation window; `consumer_confidence_value` went with them (OECD retired the series, frozen since 2024-01-01, never weighted in the composite). [Free tier]

What happened at the last Deribit expiry? Max pain and how spot settled against it: max_pain_strike, spot_at_expiry, %-diff, put_call_ratio, notional. Plus up to 10 upcoming expiries, each with current live max-pain level, days_to_expiry, open_interest_contracts and open_notional_usd. Field semantics: days_to_expiry is floored at 0 and cannot separate "expires later today" from "already settled" — settles_at (full ISO timestamp) and hours_to_settlement (SIGNED; negative = settled but not yet finalized) carry that distinction. settlement_time_utc names the settlement time where evidenced against the exchange (08:00:00Z for DERIBIT_BTC); where not evidenced, all three timing fields are null. open_interest_contracts (upcoming: latest daily snapshot) and total_contracts (settled: last snapshot BEFORE expiry) are the SAME measurement at different observation times; contracts_as_of names the snapshot. total_notional_usd is computed against the SETTLEMENT spot and never changes; open_notional_usd uses the CURRENT spot and moves with spot (notional_spot/notional_spot_date name the reference). oi_available distinguishes "null" from "not collected". Expiry flags NEST rather than partition (quarterly ⊂ monthly ⊂ weekly ⊂ daily): filter on the booleans, read expiry_type as the label — only it separates a Friday expiry from a mid-week one. All flags are calendar-derived, so upcoming expiries carry them too. spot_at_expiry is the exchange settlement price: for DERIBIT_BTC the Deribit delivery price (30-min index TWAP before 08:00 UTC — rows before 2026-08-31 were recomputed from that series; they had carried the BTCUSDT daily close, 16 h later), for IBIT the ETF close of the expiry day. Pass `market` to switch venue (DERIBIT_BTC default, IBIT). `include_strike_ladder=true` adds, per expiry, open interest per 2.5 % price band around spot (±25 %, calls/puts, absolute contracts) with day-over-day delta — a stock, not a side: no hedge direction follows from it. `include_gex=true` (D…

Does max pain actually pull price to the strike? Settled Deribit BTC options expiries with the max-pain level we compute per expiry, for measuring the convergence question: does spot drift toward the max-pain level as expiry approaches? Each row: expiry_date, max_pain_strike, spot_at_expiry, %-diff, P/C ratio, notional, expiry-type flags. The mandatory base_rates block answers the convergence question PER expiry class (n, median |diff|, shares within 1%/2%, max, sample_adequate at n>=30) — the pooled median mixes tiny daily expiries with large quarterlies, which is what the per-class split separates. Filter with expiry_type / min_contracts / snapshot_expiry_date instead of post-processing the full row set. With include_open_snapshots=true it adds the daily observation series of still-open expiries — that series starts 2026-05-28, is not backfillable, and its per-expiry depth is thin, so check open_snapshot_coverage before computing anything from it. Days auto-capped by tier: Pro 365d, Power 3650d. Max-pain levels are our own aggregation across the option chain; the chain itself is not redistributed. Source: Deribit. Related: arena_get_max_pain (current + upcoming), arena_get_iv_snapshot. [API Pro tier]

Is BTC stretched against its 200-day average? Returns the current Mayer Multiple — BTC price divided by its 200-day SMA — as spelled-out fields: date, mayer_multiple, price_usd, sma_200d (with sma_200d_source declaring its provenance) and the Trace Mayer (2014) bands as a machine-readable field (<0.7 capitulation, 0.7–1.5 neutral, 1.5–2.4 bullish, >2.4 euphoria). The former raw row shape (d, value.v, value.close) is still present but deprecated — see deprecated_fields with removal date. One ratio, not a regime call: for the multi-indicator cycle read use arena_get_cycle, for the series behind this number arena_get_mayer_multiple_history. The bands describe the historical distribution — the percentile tells you where today sits within it. [Free tier]

How stretched has BTC been against its 200-day average? Returns the Mayer-Multiple TIME SERIES (BTC price ÷ its 200-day SMA), one row per day, ascending by date. Values around 1 mean price sits at its 200d average; historically high readings clustered near cycle tops and low ones near bottoms — a descriptive ratio; the percentile fields show where today sits in its own history. For the current value alone call arena_get_mayer_multiple. Range capped by tier. [Free 30d / Pro 365d / Power unlimited]

How has this on-chain metric moved over time? Returns the full TIME SERIES of one on-chain metric from the Bitcoin Research Kit — date/value pairs in ascending order, with history back to 2009 for most series. Use it for trend and percentile work; for the single current reading call arena_get_onchain_latest, and to discover valid series_ids call arena_list_onchain_series. Values are as-reported: on-chain metrics can be revised retroactively, so this is not a point-in-time vintage. Range capped by tier — the response carries a `range` block (requested_days, granted_days, clamped, clamp_reason, tier), so a clamped window announces itself instead of silently looking like the full history. [Free 30d / Pro 365d / Power unlimited]

What does this on-chain metric read right now? Returns the most recent value of ONE on-chain series from the Bitcoin Research Kit as { series_id, metric_name, date, value }. Cheapest way to answer "what is X right now" (MVRV, SOPR, realized price, hash rate, …). Discover valid series_ids with arena_list_onchain_series; for the history behind the number use arena_get_onchain_history. A single reading has no context — pair it with the series percentile before calling any level high or low. [Free tier]

What does this term mean here, exactly? Resolve a knowledge-platform term to its canonical definition (e.g. term='regime'). Returns label, definition (EN/DE), calculation, unit, source + source_ref, version, related terms. Use this to resolve the onto:<term>@<version> references inside Knowledge Objects. [Free tier]

What are people backtesting right now? What is being backtested on Backtesting Arena right now — platform activity, NOT market sentiment. hotAssets, hotStrategies, trendingUp/trendingDown, assetDistribution, strategyAssetMatrix and totalRuns aggregate over the window selected by `period` (7d default, 30d or 90d). Three fields have FIXED windows independent of `period`: dailyActivity (daily counts, up to 365 days — year heatmap), weeklyTrend (weekly counts, up to 365 days), profitTrend (share of profitable runs per pair, last 30 days vs. previous 30 days). The counts include our own systematic coverage runs, so this measures where testing attention concentrates (coverage-weighted), not crowd positioning; for market sentiment use arena_get_fear_greed, arena_get_funding_rate, arena_get_altcoin_season or arena_get_pulse. Replaces arena_get_sentiment (deprecated alias, removed after 2026-11-15). Pass detail:'summary' for a ~2 KB digest (totals + top-3 of each list, no matrix or daily series) — prefer it unless you need the full blocks; the full response is ~53 KB. [Free tier]

How hot is the Bitcoin market today? Daily 0-100 heat score for the Bitcoin market, aggregated from 8 components (BTC-Cycle, F&G, Altcoin-Season, Bullmarket-Ampel, Funding-Rate, Hash-Ribbons, Mayer-Multiple, MVRV-Z). Returns score, band label, color, 7d/30d delta, verdict, components breakdown, plus score_percentile ranking today’s score against its own history (e.g. 42 = 44th percentile — how hot/cold vs history, not just the raw number). score_semantics says which value you hold: the daily snapshot frozen once a day by the cron, or — before that cron has run for today — a live preliminary that still moves and whose percentile/deltas compare against frozen snapshots. [Free tier]

How did market heat get to where it is? Returns the Arena-Pulse TIME SERIES: one row per day with date, 0–100 score and band, in ascending date order. Use it for trend, turning points and "how did we get here"; for today's value alone call arena_get_pulse (cheaper, one row). include_components=true adds the 8 stored component readings per day (key, rawValue, earnedPoints, maxPoints) — this answers WHICH component moved the score, and caps the window at 365 days (the payload is ~8× a score row); check component_epochs before comparing component values across dates. Range capped by tier. [Free 30d / Pro 365d / Power unlimited]

Is my report ready? Poll the status of a Custom-Report job. Lifecycle: pending_payment → queued → running → generating → success/failed. Returns progress_pct, succeeded/failed counts, plus pdf_url / xlsx_url when done. [API Pro tier]

Is this backtest result real, or a lucky cell? Assess one backtest result against its neighborhood instead of trusting a single "+X% CAGR" cell. Given a (strategy, interval, pair) and YOUR result (user_cagr, optional user_sharpe), returns: the cross-asset distribution of the SAME strategy+interval across every pair the backtest factory ran it on (median, IQR, positive-share, your percentile), a plateau/spike/fragile/mixed verdict, and — where Sharpe coverage allows — a Deflated Sharpe threshold whose N is COUNTED (the number of neighbor assets IS the testing family), not guessed. Honest small-n handling: fewer than 15 neighbors → "insufficient", no DSR-N claimed. Set axis="parameter" for the secondary, always-anecdotal view (the few parameter settings tested on this exact pair). Read-only over result aggregates, look-ahead free. [API Pro tier]