Write, validate, and deploy trading scripts
Dome Script is the domain-specific language built into Dome Terminal for expressing trading logic — entry and exit conditions, indicator calculations, risk rules, and bot behavior. This guide takes you from your first script to a validated, deployed strategy.
Dome Script is a purpose-built scripting language for trading. It is designed to be readable, unambiguous, and directly connected to the terminal's data pipeline. It is not a general programming language — you can't use it to build web apps or process arbitrary files. Everything it can do is in service of trading logic.
Designed for four specific use cases
Setup conditions and entry/exit logic (Strategy scripts) · Custom calculations visualized on the chart (Indicator scripts) · Bot behavior, scheduling, and risk gates (Automation scripts) · Data pipelines that connect to Python Lab research (Research scripts). Everything outside these four categories belongs in Python Lab or in a general tool, not in Dome Script.
When you create a script in Script Library, the first choice you make is the script type. Each type has a distinct purpose, a distinct output, and a different way it connects to the rest of the terminal.
Entry & exit logic
Defines when a bot enters a trade, when it exits, and what risk parameters apply. Strategy scripts connect directly to Bot Management and require validation before deployment. Outputs: signals, position sizing, stop/target levels.
Custom calculations
Defines a custom calculation that is visualized on the chart as a line, histogram, or overlay. Indicator scripts run on every bar close and plot results in a chart panel. They can be referenced by Strategy scripts.
Bot behavior & scheduling
Defines how a bot behaves in specific situations — session start/end behavior, risk gate rules, position management logic, and scheduled actions like end-of-day flattening. Automation scripts layer on top of Strategy scripts.
Python Lab pipeline
A bridge script type that defines how data flows between Python Lab notebooks and the terminal's live data feed. Created automatically when you export from Python Lab using dt.export().
Below is a complete, working Dome Script strategy. Read through it line by line — every part has a specific meaning, and understanding the structure makes writing your own strategies straightforward.
2strategy("Volume Breakout", version=1)
3
4// ─── Inputs: user-adjustable parameters ──────────────────
5input lookback = 20
6input risk_pct = 1.0
7
8// ─── Calculations ─────────────────────────────────────────
9range_high = highest(high, lookback)
10vol_avg = sma(volume, lookback)
11
12// ─── Conditions ───────────────────────────────────────────
13breakout = close > range_high[1]
14vol_confirm = volume > vol_avg * 1.5
15
16// ─── Entry logic ──────────────────────────────────────────
17if breakout and vol_confirm
18 entry("long", risk=risk_pct)
19
Line-by-line explanation
lookback in the bot configuration UI without touching the script code.highest(), sma(), ema(), and dozens of others are available and run on every bar.[1] suffix means "the value of this series one bar ago." This avoids lookahead bias: you're checking if the current close exceeds the prior bar's range high, not the current bar's (which you wouldn't know until the bar closes).risk_pct is configured to). The stop level is calculated automatically from the risk gate rules.Every script must pass validation before it can be connected to a bot. Validation is not optional, and it runs automatically when you click the Validate button in the Script Library editor. Here's exactly what it checks:
| Validation check | What it means | What to do if it fails |
|---|---|---|
| Syntax check | No typos, missing brackets, or unrecognized functions in the script | Read the error location shown — the editor highlights the exact line. Fix the syntax and re-validate. |
| Data run | The script ran against real recent data without crashing | Usually a division by zero, an invalid reference, or a calculation that breaks on edge cases. Check the error detail. |
| Risk gate compliance | The position sizing and stop levels in the script comply with your configured risk limits | Reduce the risk_pct input or adjust your account risk settings in Settings → Risk. |
| Output metrics | Statistical summary of how the strategy performed on the validation data window | A warning here is not a blocker — the script can still be deployed. But a very low Sharpe (<0.5) suggests the edge is weak. Investigate before going to paper mode. |
Once a strategy script has passed validation, it's available for bot deployment. The connection process is straightforward, but the order matters — take each step seriously.
From Script Library: Create Bot
Open the validated strategy and click Create Bot in the top-right corner. This registers the strategy with Bot Management and opens the bot configuration panel. Only validated scripts show the Create Bot option.
Configure the bot parameters
Set the input parameters (like lookback and risk_pct from the example), configure which symbol and timeframe the bot watches, and set the three risk gates: daily loss limit, max position, and correlation gate.
Enable paper mode — run for weeks, not days
Paper mode is enabled by default. Do not switch this off. Run in paper mode through at least two complete trading weeks — including days where the market is trending, ranging, and volatile. Surface-level performance over two or three good days is not meaningful data.
Review the paper logs critically before considering live
Open Bot → Logs. For each execution, ask: did this fire when it should have? Did the signal match your intended logic? Are losses clustering at specific times of day or market conditions? If something doesn't match your expectation, go back to the script and investigate before enabling live mode.
Every time you save a script in Script Library, a new version is created automatically. Versions are immutable — you can always go back. This matters for strategies in a way it doesn't for regular code: a strategy that was working six months ago and stopped working after you "improved" it is a real and painful situation. Versions are your safety net.
Use Compare before making significant changes
Before making a change to a strategy that is currently in paper or live mode, use Compare ↕ to view a diff between the current version and the version you're about to replace. This forces you to be explicit about what you're changing and why — a discipline that prevents accidental degradation of a working strategy.
Updating a live bot's script requires re-validation
If a bot is in live mode and you update the underlying script, the bot is automatically paused until the new version is re-validated and you manually resume it. This is intentional — you should never deploy an unvalidated change to a live bot without reviewing it first.