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: Upbit & Binance spot, Binance USDT-M & COIN-M futures — leverage, long/short, isolated/cross margin.
• 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 from FRED, read with ctx.data('key')), real FX rates (USD/KRW — ctx.fx; premium math is yours) and external signals (webhooks). Unknown values are null — never faked as 0.
• Orders: market, limit, split entries, live-only smart orders (chasing/trigger).
• Safety: order caps (guardrails), fee-aware loss kill-switch, dry-run.
• 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 stock (KIS) live trading — KRX deploys, paper and live orders (KIS order TRs) are wired, but the order TRs and response fields have not yet been checked against a real account. If something is wrong, the broker's error code (msg_cd) is shown as-is. Start with a small amount.

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.