Help & Glossary

Plain-English definitions for the trading terms used throughout the app. Times are shown in UTC.

How the bot works

Every thirty minutes the bot wakes up, looks at the current state of the market, and decides whether your strategy says to place an order. Each wake-up is called a tick.

It runs a pre-trade safety check first.
If that passes, it calls the language model to make a decision.
If the model decides to trade, it submits the order to Coinbase and records the result on the reports page.

Glossary

Tick: One run of the bot's decision loop, every thirty minutes per strategy. A tick can result in an order, a "no-action" decision, or a rejection.
No-action tick: A tick where the bot decided not to place an order — usually because the strategy's conditions weren't met or the pre-trade safety check blocked it.
Rejection: An order Coinbase declined to accept. Common causes include insufficient funds, an unsupported asset for your funding currency, and order-size limits. Each rejection includes a token like INSUFFICIENT_FUNDS and a remediation hint.
Pre-trade safety check: A small Python check we generate from your strategy that runs before the language model is called. If it fails, no order is placed and we save the cost of an LLM call. Examples: "only trade if volatility is below X" or "skip if the market just gapped".
Notional: The fiat-currency value of an order — quantity × fill price. For example, buying 0.001 BTC at GBP 50,000 has a notional of GBP 50.
Slippage: The difference between the price the bot expected and the price the order actually filled at, expressed in basis points. Positive slippage = filled worse than expected.
Basis point (bp): One hundredth of a percent. 1 bp = 0.01 %. 100 bps = 1 %.
Funding currency: The currency the bot uses to fund orders (GBP, USD, EUR…). Set on the Settings page; affects which trading pairs are available.
Strategy status: Draft — being refined, doesn't tick yet. Ready — refined but waiting for credentials. Active — ticks every 30 minutes. Paused — manually stopped; can be reactivated.
Snapshot age: How fresh the price data was when the tick fired — typically a few seconds. Higher numbers mean the bot was working with older data.

Keyboard shortcuts

On desktop, press ? at any time for the full list. Quick reference:

g d: Go to Dashboard
g r: Go to Reports
g s: Go to Settings
n: New strategy
/: Focus search (on Reports)

Backtesting

Backtests give you a directional read on how a strategy might have behaved against the last 30 days of market data. They are explicitly labelled an "approximate guess" — not a faithful replay of how your live strategy reasons.

Why we call this an approximate guess

Live trading runs a language-model decision on every preflight-passing tick — for a 30-day window that's hundreds of model calls. To keep backtesting cheap enough to iterate freely, we make exactly one model call at the start of each backtest run. That call generates a small Python decision function from your strategy prompt, and the simulator then runs that function deterministically over historical snapshots, with no further model calls.

The synthesised function is a simplified shadow of what the live model would do. It captures the broad shape of your strategy — thresholds, when to buy or sell, position sizing — but it cannot reproduce the model's per-tick reasoning, context-sensitivity, or response to ambiguous market signals.

What the backtest is good for

Rejecting clearly broken strategies before activating them.
Sanity-checking changes — does revising the prompt make the backtest worse, or better?
Comparing fee / slippage sensitivity across runs of the same strategy revision.
Ranking iterations of your prompt directionally.

What the backtest is NOT good for

Predicting live PnL.
Making absolute risk statements ("max drawdown will be 8%").
Deciding capital allocation.
Replacing paper-trading or a small live test before scaling up.

What we simulate honestly

Fees, slippage, and partial fills.
Point-in-time asset registry — at tick T the simulator only sees the trading-rules that were in force on or before T.
Min-notional rejections, thin-market gates, FX staleness, and every other rejection path that fires in production.
Long-only spot, no shorts (matches the live engine's design).

What we don't simulate

Live liquidity at the exact tick T (we use the next snapshot's price for fills, plus a configurable slippage buffer).
Exchange outages, partial-fill cascades, order-book depth.
Regime changes, news shocks, market structure breaks.
The non-determinism of the live model — every per-tick reasoning decision is collapsed into the synthesised function.

Why a 30-day window?

Two reasons: cost predictability (the historical-data store fits a few hundred MB and refreshes once a month) and storage minimisation. 30 days is short for confident Sharpe / annualised return — those figures should be read directionally only, not as forecasts.

Need more help?

If something is unclear or behaving unexpectedly, please contact support and include the request ID shown on any error page.