Backtesting and replay

A backtest applies strategy rules to available historical data. It does not send live transactions and does not guarantee future performance.

Run a backtest

1. Build or load a strategy in Terminal and inspect Code.
2. Ask in Chat: “Backtest this strategy over [dates], using [capital and assumptions].” Alternatively use Run backtest in the code/results controls.
3. Use the backtest date-range/settings controls to change the requested period and available assumptions. If you leave dates unspecified, the service chooses a supported recent window rather than assuming unlimited history.
4. Watch the run's progress and wait for its completed result. If it fails, read the error and correct the missing history, unsupported asset or invalid rule before rerunning. The run card and the workspace Backtest tab keep showing the run as running, with its progress, if you reload the page, open the chat in another window or return to a tab that was in the background; its result appears in both when the run finishes. After Saving results, the Backtest tab shows Loading results with a progress bar while your browser downloads the run's equity curve and trades; the assistant's reply can arrive just before it finishes.
5. Inspect the equity chart and analysis/trade log. Compare the requested dates to the effective dates, warmup and available bars.

Available equity-chart actions sit at the top left, with separate joined groups for the blue primary actions and grey secondary actions. Once the strategy is saved, the Save as new copy icon appears beside Save in the blue group. Share strategy is an icon beside Backtest settings and opens the existing publishing flow. On narrower charts, the other secondary actions also use icons.

Undeploy and Delete keep the primary buttons' blue hover styling. Hover an icon-only HUD action to see its label. Moving among icons in the toolbar or legend moves the same tooltip, including between the blue and grey toolbar groups.

The assistant's completed backtest opens its results. A message saying a run started is not the result. Choose Results on a completed backtest card to inspect that exact recorded run, including an older run after another backtest completes. On mobile web, this opens Backtest results with Analysis, Replay and Code; Back to chat closes it. Code shows the chat's current strategy source, read-only, which can be newer than the recorded run. You do not need an inline asset chart to open the result.

The mobile recorded-result view is read-only: it does not change the current strategy, chart selection, deployment or Paper/Real money mode. If the saved result or complete archived analysis cannot load, use Retry for that same run; a different/latest run is not substituted. A missing recorded timeframe leaves Replay unavailable rather than guessing one. Installed clients can differ by release. Saving or deploying still uses its separate workflow and confirmation.

For stored-data token screens, when both dates are unspecified, automatic dates use the longest uninterrupted window within the default period and bar allowance that every screen in the strategy can run; of two equally long windows, the more recent one. These windows already account for metric lookback, recorded launch/list boundaries, the newest hours still being prepared and days whose launch facts are unavailable (for a launch-based screen, the window starts after those days plus the screen's launch-history horizon). A data gap can make the selected window end before the latest chart candle; a short recent stretch after a gap is not chosen over a longer one before it. Explicit request/source dates and retained user date choices are not silently fitted into another range; read their existing coverage error and alternatives. Missing coverage or token-specific prices still require qualification, not invented data. This is the same on desktop/mobile web and in Paper/Real money.

After a source operation, automatic date advice is optional and bounded. If it reports Backtest date advice is unavailable, no qualified automatic dates were established; this does not undo a saved edit or mean a backtest passed. A later backtest still checks stored coverage and the bar cap. Keep your intended rules and explicit dates; retrying does not create missing history.

Screening's estimated progress spans cached decisions, date segments and token shards. A new segment's dates do not mean the whole job restarted. Checks can count repeated evaluations of the same token; they are distinct from unique tokens scanned. Screening, price preparation and simulation are separate stages, so a stage reaching 100% is not a completed backtest.

The interval must also be supported by the asset's data source. Hyperliquid perpetual candles currently support 1m, 5m, 15m, 1h and 1d; a 30m strategy or secondary candle dataset is rejected before running. Choose another supported interval explicitly; Astral must not silently change the authored cadence.

Analysis tabs

Analysis separates Returns & risk (Returns on mobile), Trades, Charts, and Trade Log. Returns contains portfolio performance/risk metrics and Result context: starting/ending portfolio values, chart time zone and the available evaluation-bar or equity-observation count. Trades contains trade statistics and consecutive results. Charts contains time-based entry/P&L charts and holding-time analysis. Trade Log has its own searchable history tab. There is no Run details tab. Chart grouping uses UTC. On mobile, use Group by hour/weekday/month to choose an entry grouping; Net / Pre-fee and $ / % change the P&L display. Selecting a bar opens matching Trade Log rows; selecting a holding-time point opens Trade Log and highlights its row.

If no position records are available, Trade history unavailable explains the missing charts and log while available summary metrics and context remain. Retained records remain visible in Charts and Trade Log without partial-history banners in any tab. Its rows and the chart totals may cover less history than the summary metrics; the absence of a banner does not establish complete history. In the strategy details modal, Returns, Trades and Charts each scroll within their content area while the top tabs stay visible. Trade Log uses the remaining height and scrolls its list. Missing history does not establish zero trades. A result with known empty position history instead shows No trades recorded yet. Filled orders are not reconstructed into completed positions. The same tabs are used for saved and deployed strategy analysis; a deployment's available history can differ from a backtest's. Analysis is read-only on desktop/mobile web and in Paper/Real money; installed releases can differ.

Choose the period

With no dates specified, the default is the shorter of 30 days or 10,000 strategy bars, further limited by the account's bar allowance and qualified data. Primary-timeframe indicator warmup is included in that bar budget, leaving fewer bars for evaluation. Auxiliary price/metric lookbacks and prepared-data memory limits still apply separately. For crypto and tokens, an automatic period that ends at the latest candle starts at the first UTC midnight at least an hour inside the newest 30 days, so it can be up to about a day shorter than 30 days. This keeps it on the same recent chart history that charts use.

There is no fixed calendar-day ceiling on an explicit request. You can request more than 30 or 60 days, or a short period from a previous year, if the selected interval fits the bar allowance and all required inputs exist. For example, 90 days at 1h is about 2,160 bars; the same 90 days at 1m exceeds 10,000 bars. A short old period is not rejected merely because it is old. This does not promise that any particular asset has qualified history for those dates.

In Code, open Run options to enter UTC start/end dates and capital, then choose Run Backtest. Dates are not moved forward to today's rolling window while you type. Invalid or reversed dates must be corrected; leave dates blank to omit date overrides. Date-only controls use whole UTC days, so a sub-day allowance uses blank dates instead. Plain Run also omits overrides: the service reuses source dates or retained session date choices if present, otherwise automatic dates. Chat and API requests can specify precise timestamps. A request over the bar allowance can still be shortened with the actual period disclosed; changing the interval requires an explicit choice.

Fixed-asset prices older than the newest 30 days are read from stored chart history (compatible retained chart-native observations), not inferred from the hot chart cache or substituted from raw trades. Chart history is certified from October 10-11, 2026. For earlier dates, Hyperliquid perps and 19 crypto pairs (AVAX, BTC, cbETH, CAKE, DOGE, ETH, KAITO, ONDO, PENGU, PUMP, SKY, SOL, UNI, USD1, USDS, USDT, VVV, XRP and ZEC) use imported minute prices, which stayed within 1% of Coinbase or Hyperliquid's own candles in every hour compared. Other crypto pairs and seven thinly traded perps that missed that check (USELESS, TCNT, AVGO, CIEN, TER, BIRD and HO) cannot start before chart history. BTC, ETH and SOL also have older exchange-priced history back to June 1, 2024, for strategies that name them as fixed assets: prices from exchange minute bars and volume from on-chain trading of their wrapped tokens. Their earlier volume leaves out BNB Chain, Arbitrum and Optimism, so it is lower than recent volume, about 20% for BTC. Volume-based rules spanning both periods see that step. Stored data inputs such as market cap and USD volume, and screens that select coins, still start when stored history does. The 10,000-bar limit still applies, so a long period needs an hourly or daily interval. Stored history starts at a different date on each network. If it does not cover the requested start, the run is refused at once with the earliest start that works: choose that start or a period within the newest 30 days; retrying the same dates cannot add history. Missing or uncertified prices later in the period, metric lookback, recorded lists, launch history or price provenance can prevent a run or shorten its existing verified-window recovery. Inspect the actual test period and any coverage alternatives. A resource-limit refusal needs a smaller request; repeating it does not create more capacity.

This policy applies to desktop/mobile web, Chat and API backtests in Paper and Real money. Installed clients can differ by release. It does not enlarge initial chart loading: charts still start with at most 5,000 bars within the newest 30 days. It does not publish a historical repair or change live trading.

Review results and replay

Use the result's Replay control where offered to step through historical chart events. Review individual orders/trades alongside the equity curve, return, drawdown and win rate. The equity curve has one point per bar of the strategy's interval, valued at the bar's close. A run can value the portfolio more often, such as every minute to fill take-profit and stop-loss orders inside a bar; return, drawdown and the other metrics use every one of those valuations, so the drawdown can be deeper than the lowest point the curve shows. Filled order count and closed trade count measure different things. Inspect any open exposure at the end of the run.

The result chart and Replay use that run's recorded strategy name. Older results without a name show Backtest · [recorded date range], or Backtest when the period is unavailable. They do not display the internal run reference or borrow a different live strategy or Chat title. When comparing runs or reporting a problem, identify the selected result by its name and dates (or its position in the chat); the assistant's tools retain the exact run reference. Changing the selected result does not rename or rerun an existing deployment.

The chat's latest run also marks its simulated fills on the Terminal chart of every asset it traded, including each tab of a multi-asset or screened run; see Trades on every chart. Click a recorded filled marker and open Trade details to inspect its trade and source. When references are available, Copy reference for support copies the internal references without displaying them as the strategy's name. See Trade details and support references. These are read-only controls on desktop/mobile web in Paper and Real money; installed clients can differ by release.

Replay loads price history independently for the assets in its execution records, starting with the first traded asset. Available assets can be replayed while others load; the loading message reports the remaining asset count. This applies to desktop and mobile web, without changing Paper/Real money mode or submitting trades.

An accounting snapshot recorded a millisecond after another sample does not create an extra playback step in the same second. Exact execution events remain separate, and the recorded equity samples, fills and returns are unchanged.

Replay anchors its clock as soon as the first recorded timeline is shown, before your first click. Earlier candles arriving afterward must not rewind it. Once the selected asset is ready, Step forward one bar advances from the displayed time; backward/restart/seek controls remain deliberate actions. Closing and reopening Replay starts a new attempt at its initial recorded time. This applies to desktop and mobile web in both account modes and does not rewrite archived samples or fills.

An asset's history request stops after 30 seconds if it cannot finish. Its chart and affected position values remain unavailable, not zero or another token's prices. Close and reopen Replay to retry. Missing coverage still requires that exact asset, interval and period to be available; reopening cannot repair missing history. Loading another asset must not move the replay clock or change the run's recorded returns.

Replay is a view of the simulation, not a recording of real fills. The price/market-cap chart mode and visible zoom window do not redefine the run's accounting. Use Save to preserve the strategy and Deploy only after reviewing the separate deployment confirmation.

Explain a short or empty result

• Too little history: choose a range supported by that exact asset/interval. A newly launched token cannot supply history from before launch. With no dates specified, a token younger than the default window is tested from its first verified candle instead of failing: for example, a token first traded on October 25 gets an automatic 5m test from October 25 to now, not from October 13. The result reports the requested and actual start and the reason (verified price history).
• Warmup: indicators and screening windows need preceding data before the first eligible signal. The first fill can be much later than the requested start. The warmup is derived from the strategy's longest indicator period or lookback; it is not a setting you can raise or lower, and warmup bars are not simulated (no trades or performance accrue in them). Use the reported first eligible trade time to see where evaluation actually starts.
• Too few evaluated bars: when the warmup leaves fewer than 20 bars, or fewer bars than the warmup itself, the assistant says so before any result. An example is a daily strategy on about a month of stored history, where a 20-day indicator leaves only a few days to evaluate. The run still completes, but it is too short to judge the strategy or a return goal. The assistant offers a smaller bar size that fits the same history (indicator periods count bars, so they then span shorter time) or earlier dates where stored history covers them, and asks which to use. On the chart, an indicator whose lookback is longer than the chart's candles draws nothing; the assistant tells you rather than quietly shortening the period.
• Tokens Astral can't trade: new on-chain screens skip them using today's verdicts on every backtest date, so results show what you could trade now. A token that was tradeable then but isn't now is skipped; one never checked can still be picked. See the Strategy reference.
• Dynamic screen gaps: the test period plus the longest metric lookback must fit complete stored data. Read the reported missing range rather than assuming live discovery can fill it retroactively. A few stored minutes are recorded as permanently missing because the data provider no longer serves them. A screen backtest runs across those minutes, and so do the stored data inputs it or a fixed-token strategy reads, such as token age or crash risk. The Backtest panel does not list them, and the assistant names them when you ask about data coverage. Anything the missing data held is absent, for example a token launched in that minute may have no launch record, so launch-based screens and data inputs cannot see it. Some are minutes whose token launches were never recovered; a launch-based screen's results also name those that fall before the test period but inside its launch-history window, since tokens created then stay unknown however old they are. In a backtest, a gap of up to 5 consecutive minutes that is still missing more than a day after it ended is accepted the same way and named in the results; a deployed strategy's live screen does not run across it. Astral repairs missing stored minutes automatically from its data provider. When the provider's live dataset itself lost a stretch of Solana or Base trades, they are rebuilt from the provider's archive of on-chain swaps, which matches the original within a few percent in trade count and about 1–2% in USD volume. Hyperliquid perp candles the provider lost are rebuilt from Hyperliquid's own public record of fills, which matched Hyperliquid's published candles in a one-hour check (every open, high, close and volume, 99.96% of lows). A few Hyperliquid minutes stay without perp candles because the exchange paused and almost nothing traded; backtests run across them. A minute in which the provider confirms there were no trades counts as complete. Longer gaps, and newer ones that the repair job may still fill, keep blocking the dates as above. When dates are refused, every date option the assistant presents runs exactly as given and is at most 10,000 bars; the coverage check and the backtest apply the same rule.
• Screening inputs still being prepared: a screen backtest waits up to about 4 minutes for stored hours that are not yet prepared for screening, then stops without results. The newest hours are usually ready within minutes. Older hours that a data repair corrected are prepared again one after another. After a correction that reaches many hours, such as recovered token launches, that backlog usually takes hours, so the run stops at once instead of waiting. Automatic dates do not avoid those hours. The message estimates when to try again and, only when one still contains decisions, names an earlier end date or a later start date that avoids those hours. The stored data itself is complete, and rerunning sooner gets the same refusal.
• Screening inputs prepared incomplete: rarely, stored hours were prepared for screening without a value a screen reads, such as market cap or crash risk, and must be prepared again by Astral. Rerunning cannot help until then. The coverage check and automatic dates treat those hours as a gap, and a backtest over them stops at once. The message names the whole span of affected hours and, only when one still contains decisions, an earlier end date or a later start date that avoids all of them. The assistant reports it as a platform bug.
• Stored data input gaps: a strategy that reads stored on-chain data such as market cap as a data input needs complete stored data for the test period plus that input's window. For tokens a screen picks, inputs are also read over the indicator warm-up bars before each pick, so automatic dates leave room for that warm-up too. Minutes recorded as permanently missing (above) do not block it. A data input that reads launch records, such as token age, looks for each token's launch in the 30 days before every decision, so it also needs launch history across those 30 days; a token launched in a permanently missing minute has unknown age. When the dates cross any other gap, or need launch history from before it was recorded, the assistant lists date ranges that run, each with its bar count, and asks which to use. A chosen range runs; the gap itself is not filled.
• No trades: check whether filters and entry conditions were simultaneously true and whether the simulated size/cash allowed a trade. Ask the agent to inspect the run before changing rules.
• No asset price observations: a verified feed range does not mean that every token has a price inside it. An evaluable order without an execution price remains unfilled while other eligible trades continue. Inspect that exact token, scheduled interval and the result's gap evidence; substituting a token or inventing an entry price does not repair missing observations.
• No-market write-off: a held screen token is written down to $0 only when it went 60 minutes without a trade and never traded again before the test ended. This is a zero-proceeds loss assumption, not a successful sell or recovered cash. A token that only went quiet keeps its last price, and a sale or rotation out of it waits for its next trade.
• Prepared-price resource limit: the refusal includes estimated rows/memory and an approximate number of decisions that fit. Shorten dates, choose longer bars or narrow the screen explicitly. Retrying the same oversized request will not help. With trade rules, each token is priced while the screen selects it, and afterwards only while an open trade or order still holds it, so the size grows with the length of the test rather than its square. Missing exit prices can require a longer pricing horizon for tokens that could have been bought.
• List history: a strategy that ranks by a Tokens list cannot test dates before Astral began recording that list. Ask for coverage of that exact strategy; its decision ranges include the recorded-list boundary, publication delay, lookback and interval. Earlier price/volume coverage is not list-history coverage. If dates do not fit, review the returned alternatives before changing the requested period. If list recording is unavailable, wait for it rather than treating market-data dates as valid list dates.

Verify the input

Confirm the token's network and address, interval, entry and exit rules, sizing and requested dates. An account's maximum bar allowance is not a promise that a token has that much history.

Orders without an execution price

A fixed-token backtest can complete with unfilled order attempts. If a rule triggers but the required execution price is absent, no fill, fee or sale proceeds are invented. Independently evaluable trades continue. A one-time scheduled market attempt keeps its intended bar: a later candle does not move that entry. A rule that triggers again makes a separate attempt. Dynamic-token orders retain their existing pending-order, cancellation and timeout policies.

The result calls out unfilled orders and retains the exact token and network, side, attempt time, requested sizing, last observed price time when known, and gap classification. Ask the assistant to inspect that backtest (the latest run, or an earlier run in the same chat) to review these records and the price-coverage evidence, including for saved older runs. This inspection does not rerun or rewrite the strategy.

The evidence distinguishes confirmed inactivity in the indexed source, trades without a candle, partial candles, and unknown coverage. A missing candle alone never proves inactivity. An unavailable activity read leaves the classification unknown. Confirmed inactivity does not establish that a hypothetical live trade was impossible.

Confirmed inactivity can be a valid simulated outcome. Missing or unknown data produces completed with data gaps and estimated performance; a run without enough observations to evaluate performance reports insufficient data, with affected metrics unavailable rather than zero. A missing losing trade can otherwise make a strategy appear more profitable. A missing exit price leaves the position owned, with stale or uncertain valuation disclosed. It does not create a sale, recovered cash or a new write-off policy.

Missing inputs that prevent a signal from being evaluated are different from a triggered order that could not fill; they do not create a failed order record. Required indicator warmup, history-service failures, uncertified intervals, resource limits and accounting checks can still prevent a run. Coverage gaps are not silently bridged; only the short price gaps described under verified price-history coverage are crossed, and results name each one. This handling applies to fixed on-chain-token universes; mixed universes with other asset types keep their existing history checks. The same result and inspection rules apply to desktop/mobile web and Paper/Real-money backtests; installed clients depend on their release. Backtests do not send real transactions.

Read the actual test period

The requested window can differ from the effective test window. Inspect loaded-data start/end, history caps, indicator warmup, first eligible bar and first fill where reported. Do not infer the period solely from the date picker.

Verified price-history coverage can shorten a test even when the chart shows earlier candles. An aggregate candle does not prove that all underlying minutes are complete. A minute counts as verified for prices when its price candles arrived complete, even if another feed (token launches and supply changes, or individual trades) missed it. A fixed-asset backtest runs across a gap in verified prices of up to 5 consecutive minutes that is still missing more than a day after it ended: the bar holding it is built from the prices that were recorded, so it can miss that bar's true high or low. Longer gaps, and newer ones that the repair job may still fill, are not crossed; use a period on one side or wait for the historical-data repair.

For fixed-asset runs with several certified ranges, after joining those short gaps, Astral selects one common interval with the most observed price bars; the latest observed end breaks a tie. Results retain that selection policy and, per asset, the certified-range count, the gap that cut the run's start or end, the short gaps it ran across, and the certification watermark. The notice above the results says in plain words which token's missing prices shortened the run and when, lists the short gaps it ran across, and says when a token simply began trading after the requested start; the assistant can inspect the same evidence. Later chart candles can be valid outside the chosen interval. A 10,000-bar allowance is a ceiling, not proof that all intervening minutes are certified.

This disclosure applies to desktop/mobile web and both trading modes. Older results without that provenance are not retroactively diagnosed from today's coverage. Missing historical certification still needs data qualification; the notice does not bridge gaps, rerun the strategy or change recorded returns.

An end date without a time includes that UTC day. Explicit timestamps remain precise bounds; the final included candle opening is inclusive for dynamic selections too. Defaults stop at the last completed stored candle. Completed-candle rounding is distinct from an account history cap. First and last trade times refer to actual fills, not the final valuation of an open position.

Indicators written directly inside signals need warmup too. If the loaded history cannot warm up an SMA(50), a zero-trade result is not an adequate test: request a supported interval/window with enough history. Time functions such as HOUR() use the strategy's engine timezone; a UTC strategy evaluates UTC hours.

Inspect on-chain assumptions

New strategies start with 0% commission and 0% slippage, including on-chain token assets and token screens. These simulated costs are opt-in. The costs are recorded in the strategy source, which you can inspect in Code; ask in Chat to change them and rerun. For example: “Set commission to 0.5% and slippage to 0.5% per fill, then backtest again.” In source, those values are commission_bps=50 and slippage_bps=50 (100 basis points = 1%). Each applies on both buys and sells.

Spot results with recorded zero costs show Before trading costs · Commission 0% · Slippage 0% in Analysis and result evidence. This is a strategy baseline before trading costs, not an estimate of net live returns. Existing strategies retain their own cost settings; ask for a zero-cost rerun to compare them. Saved results keep the assumptions used for that run. Missing cost evidence is not treated as zero or given the pre-cost label.

This behavior applies to desktop/mobile web and backtests in both Paper and Real money modes; installed clients depend on their release. Backtest settings do not waive real execution fees. Perp backtests still include their separate Astral builder fee and funding, even with zero configured commission and slippage, and do not receive the pre-cost label. See Perps.

On-chain results can also report commission and slippage in basis points, the price kinds used for each asset, first/last bars and a simulation disclaimer. Read those disclosures with the results.

Order size is not limited by a bar's trading volume unless you ask for a limit: by default each order fills whole at the observed price. When a buy or sell is larger than the USD its token traded in the fill bar, the results warn and count those fills, name the largest, and mark each one in the order records the assistant can inspect. Returns from those fills are unreliable, because an order that size could not have filled there in a real market. A bar-based simulation does not reproduce all live liquidity, routing, network or market-impact effects.

To test only buys the market could absorb, ask in Chat, for example: “Backtest again with buys limited to 10% of each candle's volume.” Each buy then uses at most that percent of the USD its token traded in the candle it fills in (volume × that candle's close). The rest of the buy is cancelled and stays as cash; it is not retried on later candles, so later sizing and returns follow the smaller position. Sells, closes and take-profit, stop-loss and trailing exits always fill in full. The assistant reports how many buys were cut and how much buying was cancelled, from the run's own records; a buy whose candle has no volume figure is not limited and is counted. The limit is a backtest assumption (max_volume_pct in the run or in costs(...), from just above 0 to 100) and saved results record it; Paper and real-money deployments do not use it. Perp backtests do not offer it.

For a rotating cash allocation with a valid completed-bar decision price, the reinvestment quantity uses that decision price; the fill uses the next observed open. The reserved allocation still limits spending, and a cheaper fill can leave cash unspent. This does not guarantee identical fills in a deployed wallet.

Compare order-size precision too. A fractional-unit backtest and a broker-constrained Paper replay can differ because the execution route rounds each order to its permitted quantity step. Later rotations use the proceeds actually settled, so rounding differences can propagate. This does not explain every cash or position discrepancy: retain the exact run and fill evidence, keep accounting checks and cost assumptions intact, and do not rewrite older results to make them agree. A Paper precision check does not qualify real-wallet execution.

In a candle-close (on_close) simulation, a stop level is a trigger, not a promised fill price. A candle can cross the stop and recover before its closing-price fill, producing a profitable exit labeled stop-loss. Compare the trigger, that candle's high/low and its close when auditing such a trade.

For strategies using the 60-minute no-market policy, a write-off requires continuous verified no-trade evidence for the timeout and no trade for the rest of the test; a token that trades again later is held at its last price meanwhile and its exits fill at its next trade. Missing candles, unknown gaps or chain-wide coverage alone do not prove that a token stopped trading. A qualifying write-off values the position at $0: an assumed loss, not a sale, and no cash is recovered. An entry order that cannot fill within its timeout is cancelled at no cost. These simulation assumptions do not authorize a live sale or certify that a token is economically worthless.

Service and accounting failures

A busy history service retries within a bounded request deadline. If it still cannot finish, wait briefly and retry the same asset, dates and rules; changing them does not repair overload. Persistent failures need a report with the run reference. A missing or uncertified history range is different: retrying cannot manufacture certified data or qualified launch facts.

An execution-ledger mismatch is an accounting refusal, not a completed result or a source-edit instruction. Keep the exact source, dates and cost assumptions and report the run with its diagnostics; the assistant's bug report records the run's references. Do not reduce fees or relax accounting checks to obtain a pass.

Interpret results together

Review portfolio equity, return, drawdown and the trade list. Portfolio equity remains a valid term for token strategies. Distinguish filled orders, closed trades and open positions. Win rate can use closed trades only, and profit factor can be undefined when there are no losses or no closed trades.

Do not treat unavailable metrics as zero or assume that a high return outweighs limited history. Avoid comparing runs with different capital, periods, assets or cost assumptions without acknowledging those differences.

Completed cards display the final value immediately. In the chart legend, use Remove Last run to dismiss the previous-run comparison; this keeps the current result. The same comparison control is available in desktop and mobile Terminal views.

To read a result against the market, add a reference line. In the result chart's legend select Add benchmark (Compare a market below the chart on mobile), search for an asset and select it. To take one off, open the search again and select the same asset. Listed crypto, on-chain tokens and perpetuals can all be added, and several can be shown at once. Each line is that asset's price change over the result's own period, starting at 0% with the strategy, so it shows what holding the asset would have returned before costs. A backtest of a screened-token strategy starts with its network's coin already added (SOL for Solana, ETH for Base, Ethereum, Arbitrum, Optimism and Robinhood Chain, BNB for BNB Chain); once you add or remove a benchmark, your selection is kept for later runs in that panel. An asset without price history for the period draws no line. Benchmarks are chosen per panel and are not saved with the strategy; the strategy pages in Dashboard and Explore offer listed crypto only.

Ask the assistant to inspect a specific backtest (for example, "the run before this one" in the same chat) to audit its orders, fees and positions, including after a newer run. A run that is still going is reported as running and a failed run reports its error; neither is described as missing. Available archived evidence belongs to that exact run. If only compact history survives, missing fees or position rows are unavailable rather than zero. Degraded saved results keep their coverage warnings; follow the full artifact for detailed records.

The assistant can inspect account-wide backtest capacity. The occupied-slot count is a snapshot, not a reservation. An unavailable capacity store does not mean no runs are active; wait and retry rather than starting duplicate work.

Replay and iteration

Use available analysis and replay controls to inspect signal timing. Change one assumption at a time and keep the version that produced each result. Public marketing previews use illustrative data and are not historical trading results.

See Strategy workflow for saving and mode selection.