Core Concepts

Bot Builder

A visual canvas for building trading strategies out of blocks. Most bots need no code at all; when a rule cannot be assembled from the existing blocks, a Custom Condition or Custom Value block lets you write it.

Node types

A bot is a free-form graph of blocks, not a tree. Each block has a category that determines its role, and the engine runs blocks BY CATEGORY — a block's category decides when it runs, not what it is wired to.

That has one consequence worth knowing before you build anything: a block that is connected to nothing still runs. Leaving a filter unwired does not disable it. To stop a block affecting your bot, delete it.

Category	Logic	Components	Purpose
Signal	OR (any can trigger)	RSI, MACD, Bollinger, MA Crossover, Volume, Stochastic	When to consider entering
Filter	AND (all must pass)	Time, Volume, Volatility	Gate conditions
Entry	Single selection	Market, Limit, Stop	How to enter
Exit	OR (any can trigger)	Take Profit, Stop Loss, Trailing Stop	When/how to exit
Sizer	Single selection	Fixed Percentage, Volatility-Based	Position size calculation
Risk	AND (all applied)	Max Risk Limits	Safety limits (required)

Structural nodes

In addition to trading components, you can use structural nodes to organize complex strategies:

Weight: Allocate capital across sub-strategies
Group: Organize related components
If/Else: Conditional logic branches
Asset: Target specific instruments

How bots evaluate

On each cycle the engine collects every block by category and runs the categories in a fixed order. It does not follow your connections to decide what runs:

Evaluation cycle

For each evaluation cycle:
  1. Resolve the symbols from the trading universe
  2. Compute any Custom Value blocks (in dependency order — see below)
  3. Evaluate EVERY signal block          (OR — any one firing is enough)
     → If none fires → stop here
  4. Check EVERY filter block             (AND — all must pass)
     → If any blocks it → stop here
  5. Calculate position size via the sizer
  6. Apply risk limits                    (AND — can only REDUCE the size)
     → If any refuses → stop here
  7. Submit the order via the entry rule
  8. Exit blocks are checked while a position is open
     → If ANY exit triggers → close the position
"EVERY" means every block of that category on the canvas,
connected or not.
Connections decide execution in exactly three places:
  • which branch a Compare / If-Else takes
  • which blocks sit under a Weight block
  • Custom Value → the block that reads it, so the value
    is computed first

Strategy example

Here’s a simple mean-reversion strategy structure:

Example: RSI mean-reversion bot

1Trading universe
2├── Signal: RSI (period: 14, oversold: 30, overbought: 70)
3├── Filter: Volume (min: 1,000,000 daily avg)
4├── Filter: Time (market hours only)
5├── Entry: Market Order
6├── Exit: Take Profit (target: 2%)
7├── Exit: Stop Loss (limit: 1%)
8├── Sizer: Fixed Percentage (2% of portfolio)
9└── Risk: Max Risk Limits
10    ├── Max drawdown: 5%
11    ├── Max daily loss: 2%
12    └── Max position size: 5%

Incremental complexity

Constrain initial graphs to a minimal signal set and exit structure; expand branching only after paper-trading results confirm the baseline behavior matches the design intent.

Checking what a bot will do

Three tools answer three different questions, and none of them places an order.

Compile — what did my blocks become?: Builds the plan the engine would build and reports what each block turned into, without saving or scheduling anything. It is derived from the real plan, so it cannot disagree with what would actually run. Use it when a setting does not seem to be taking effect.
Debug — why has my bot not traded?: Reads the bot's own execution log and reports how far each cycle got: how many looked at the market, how many produced a signal, how many were stopped by a filter or a risk rule, and how many placed an order. It separates a bot that is working as configured — no signal fired, or it is already holding the position — from a real fault, and names the blocks responsible.
Pine export — what does this look like on TradingView?: Translates the strategy into a Pine Script v6 strategy you can paste into TradingView. It also lists what Pine cannot express — Pine has one symbol, no account state and no broker, so limits such as a daily loss cap do not survive the translation. That list stays visible on every plan, because a script that quietly dropped a risk limit would backtest better than the bot it claims to be.

A backtest is not a promise

Results from a backtest, and results from TradingView, are simulations over past data. They will not agree with each other to the tick, and neither predicts what a live bot will do.

Structural checklist

Validation executes prior to backtest and deployment; the following items mirror the constraints enforced by the engine. Missing dependencies—e.g. a data source where market input is required—produce blocking errors until the graph is completed.

At least one signal path to define entry triggers
Exactly one entry rule in the deployable configuration
One or more exit rules to define position closure
Exactly one position sizer for sizing logic
Risk management nodes as required by product policy
Data sources attached wherever upstream feeds are mandatory
Parameter completeness: required fields populated within documented bounds

Risk management is required

Every bot must include risk management. This is a safety requirement and cannot be bypassed. Bots without risk limits cannot be deployed.