Strategy API (ctx)

A strategy is one JavaScript function. Backtest and live use exactly the same interface — nothing exists on only one side.

function onUpdate(ctx) {
  // called per candle (backtest) / per update (live)
  // return null, one order object, or an array of orders
}

What can you build?

• Markets: crypto spot (Upbit, Binance and other connected exchanges), perpetual futures (Binance USDT-M & COIN-M and others — leverage, long/short, isolated/cross margin), Korean stocks (broker open APIs — Start trading Korean stocks), US & global stocks (IBKR — not yet confirmed on a real device), FX/CFD (MetaTrader 5 — live path in progress). Backtest, paper and live coverage differ per market.
• Live futures: some derivatives exchanges require the key screen's [Connection test] (a small order round trip) before live trading. Once your account passes it you can trade live and run automatically on that exchange right away (change the key and you test again). Exchanges whose API cannot separate trading from withdrawal need you to read a warning and consent explicitly before the key is stored, and seed phrases are never accepted — see Security.
• Multi-symbol scanner: one strategy watches many symbols (up to 200) on the same exchange — per-symbol positions, orders and state, separated automatically.
• Ordering on two exchanges from one strategy (legs — cross-exchange arbitrage/hedging): backtests (incl. jobs), paper AND live real orders are supported. Per-leg wallets, fees and an interlocked kill-switch; live requires API keys for every leg before it starts (no half-executed hedge, no silent downgrade). P&L of legs in different currencies is never aggregated (an approximate USD figure is shown for reference only).
• Aux-symbol reference: use another symbol/exchange's price as a signal (ctx.ref slots — e.g. watch Binance BTC while trading on Upbit). Works in backtests, paper and live.
• Multiple exchanges at once: you can also launch one run per exchange — a single agent holds keys for several exchanges and runs them all in parallel (strategy A on Upbit + strategy B on Binance futures).
• Multi-agent cluster: scanner symbols are distributed across several agents automatically and run in parallel (Elite plan + onboarding required).
• Data: candles (1m–1d), volume, orderbook, funding rates, open interest/liquidations, base indicators (US Treasury yields, dollar, VIX, oil… — collected by your agent, read with ctx.data('base.name')), your own DB (a DATA declaration in the strategy code — connection details stay on the agent), and external signals (webhooks & polling — ctx.signal, see External signals). Unknown values are null — never faked as 0.
• FX rates (USD/KRW for the kimchi premium, KRW↔USDT conversion): there is no built-in rate — we no longer collect FX. Fetch it yourself — the simplest is a webhook signal ctx.signal: e.g. a TradingView alert on 1-minute USDKRW (once per bar close) posting to /api/hooks/t/<token>?slot=usdkrw with body {"rate": {{close}}, "t": "{{timenow}}"}, then const s = ctx.signal('usdkrw'); const rate = s && Number(s.payload.rate) and drop stale values by s.age (seconds; server limit 12 per minute per slot). Backtests see only the records from when you started sending, as-of. Otherwise live with ctx.http (declare your FX vendor, approve it on the run) or, for backtests too, with ctx.data (your own rate table in DATA, or the daily base.usdkrw_h10 series, which is published about 10 days late). No rate = null = no premium. The old ctx.fx is kept only so saved strategies don't crash — it always returns null.
• Orders: market, limit, split entries, live-only smart orders (chasing/trigger).
• Safety: the wallet (max loss = the wallet), order-rate limit and approval ceiling, dry-run. (Old live runs deployed without a base amount and legs keep the previous loss kill-switch.)
• Validation: backtests up to 100k bars, walk-forward via fixed end dates, plus a per-tick decision-time estimate in the studio and a live tick monitor (see on the run card whether your server keeps up).

Not supported yet (we don't pretend otherwise):

• Live trading with legs split across agents — split execution (a compute agent plus per-leg execution agents) works in paper only. Live orders open after a two-device measurement. Live legs runs today use one agent that holds every leg's keys.
• Automatic cluster rebalancing — distribution is static. If an agent drops, its symbols wait and the UI says so honestly (they are not silently moved).
• Real-account verification of some Korean brokers — LS Securities, NH Namuh PLUG, NH N2 PLUG, Toss Securities: the order/fill round trip has not yet been confirmed on a real account (the deploy shows an 'unverified' warning with the reason). If something is wrong, the broker's error code is shown as is. Start small.

Rules

• Pure function — no network, no imports, no async. Only the ctx below.
• qty is always an amount of coin (not cash).
• Indicators return null without enough data — always null-check.
• Keep your variables in ctx.state; they persist across calls.
• ctx.ref slots use logical names ('hedge' etc.) — real symbols are bound at deploy time.
• Do not feature-detect ctx (typeof ctx.watch === 'function' and the like). The platform checks at deploy time that the agent supports every ctx feature the strategy uses, and refuses with the required version if not.
• ctx.watch only displays the prices you are waiting for on the chart and run card — it is not an order. Only the return value of onUpdate trades.
• If the entry also needs non-price conditions (RSI etc.), add them as conds — with the same values you decided on (same period, same bar): conds: [{ label: 'RSI(14) close', now: rsi, op: '<', ref: 30, closed: true }]. If any is false the run card shows "waiting on conditions" and hides the arrival estimate.

Order objects

• Market: { side: 'buy'|'sell', qty } — walks the book (slippage, partial fills, taker fee).
• Limit: { side, qty, type: 'limit', price } — fills at your price with maker fee when touched. postOnly: true rejects a limit that would fill immediately.
• Smart (work order): { side, qty, type: 'smart', chase?, slices?, trigger?, hardStopMs? } — executed over time: chasing (peg the book → cross at deadline), slicing, stop/trailing triggers, and a hard time budget, in live and paper runs. Backtests approximate it as a market order — validate with a live paper run.
• Limit ladder: { book: [{ key, side, qty, price | at: 'top' }], tol?, refreshMs? } — return the list of limits that should be resting, every tick. It is reconciled with what is already resting: inside the tolerance nothing is sent, outside it the order is amended, keys you drop are cancelled. Tolerance = max(0.05%, distance from price × 0.2) — tight near the price, loose far away, nearest handled first. Maker-only (postOnly) by default. at: 'top' = best bid + 1 tick (or the best bid if that would cross). refreshMs re-prices inside the tolerance when the order is that old and ≥1 tick off (live: only while the rate limit has spare budget). A filled key is not placed again until you omit it once. Backtests have no tick size, so top-of-book joins the best price (noted in the result).
• Cancel all: { cancel: 'all' } — cancels resting limits AND all work orders (chasing can't be stopped by canceling a single order).

Sending out (ctx.http) — alerts & external APIs

A strategy can call Telegram/Discord/Slack alerts or an external API (agent 1.348.0+). Keys never go in the code — keep them in your agent's HTTP vault; the code only names a slot.

const HTTP = { origins: ['https://api.telegram.org'], creds: { tg: 'https://api.telegram.org' } };
function onUpdate(ctx) {
  if (ctx.close > 100000) ctx.http.send({ id: 'alert', cred: 'tg', path: '/sendMessage', method: 'POST', json: { chat_id: 1, text: 'BTC > 100k' } });
  return null;
}

• Nothing leaves for an origin not in the HTTP declaration. Each run needs your explicit approval of slot ↔ vault entry on the agent screen (re-approve when the declaration or code changes).
• The vault shows the domain large when you add a key; lookalike (te1egram.org…) or unfamiliar domains must be retyped to save. A key is attached only for its origin and scrubbed from responses.
• 5 sends per tick · 64KB responses · redirects not followed · private IPs blocked. Results arrive next tick via ctx.http.result(id).
• Backtests never send — the result only counts them in httpNotSent.
• Key-shaped strings in code: a warning on save, placeholders when an AI reads the code, and the strategy is skipped by the public git publish.

The table below is the entire ctx (generated from the same source as the editor autocompletion). To get strategy code from an AI, use Create an AI Strategy or paste the whole AI reference.