Strategy Execution Engine

Overview

Every Norena strategy goes through four stages from block to live execution:

Strategy Compilation

When you click Compile, the Strategy Builder serializes your Blockly workspace into JavaScript using Blockly's JavaScript generator. Each block type has a customforBlock generator function that produces the exact runtime call.

For example, an RSI block with period 14 on the 1h timeframe generates:

((_v) => HP.__cond("RSI(14)", String(+_v.toFixed(2)), "RSI(14) < 30", _v < 30))(RSI({ tf: "1h", period: 14 }))

This pattern wraps every boolean comparison in HP.__cond(), which records the condition label, runtime value, rule string, and result into the condition log — without any extra work from you.

The compiled JS also includes a timeframe manifest comment injected at the top:

// @norena-timeframes: 1h,4h

The runner reads this comment to know which kline series to load before executing the strategy. Both the live runner and the backtest engine use this manifest — it is the single source of truth for which timeframes a strategy needs.

What compilation validates

The Run Loop

The Norena runner is a Node.js process that runs a continuous 2-second polling loop. On each tick it calls claim_due_projects — a database function that atomically claims up to 5 projects whose next scheduled run time has passed. Claiming is atomic, so multiple runner instances cannot process the same project simultaneously.

while (true) {
  const projects = await claimDueProjects(limit=5);
  for (const project of projects) {
    await runProject(project);   // per-project, per-symbol
  }
  await sleep(2000);
}

Per-project execution steps

1. Load settings — reads the latest settings_json from the database (mode, wallet, trade hours, etc.).
2. Check guards — trade hours window, disable weekends. Skips and logs if any guard fails.
3. Load compiled JS — reads the latest generated_js from the project row.
4. Extract timeframes — parses the @norena-timeframes manifest.
5. Per-symbol loop — for each configured symbol:
   • Check kline readiness (bootstrapped & fresh within 3 min)
   • Check max daily trades limit
   • Build the broker (Paper or Live)
   • Build the API surface (indicators + HP)
   • Run the strategy in a sandbox (5s timeout)
6. Update run record — writes status, finish time, and per-symbol error summary.

Sandbox Isolation

User strategy code runs inside Node.js's built-in vm module with a strict null-prototype global. This means strategy code has no access to:

• The filesystem (fs, path)
• The network (fetch, http, https)
• The process (process, require, import)
• Any global not explicitly whitelisted

The sandbox exposes only the strategy API (indicators, HP, position state functions) plus frozen versions of safe builtins: Math, Date, JSON,Array, Object, Number, String, Boolean. Mutable globals like Array and Object are frozen to prevent prototype pollution between sandboxed runs.

In the backtest engine, a Function() constructor is used instead of Node'svm module (since backtests run in the browser). The same whitelisting logic applies — only the strategy API is injected as named parameters.

Strategy API Surface

Inside the sandbox, strategy code has access to a precisely defined set of named functions. These are the only things a strategy can call:

Condition Tracking System

One of Norena's most distinctive features is that every boolean comparison in your strategy is automatically recorded at the moment a trade is placed. This is not optional logging — it is baked into the compiled code.

The Blockly generator wraps every logic_compare, logic_operation,logic_negate, and controls_if block in calls toHP.__cond, HP.__group, HP.__checkpoint, andHP.__flipFrom. These functions accumulate a ConditionRow[] array that captures what happened — in order — during the current tick.

When HP.buy() or HP.sell() is called, it snapshots the entireconditionRows array and resets it to empty. Each discrete trade call gets exactly the conditions accumulated since the last trade call in that tick. The snapshot is immediately written to the TRADE_TRIGGER log.

Signal Generation

A "signal" in Norena is simply a call to HP.buy() or HP.sell()inside the strategy code. There is no separate signal queue or event bus — the strategy code evaluates conditions inline and calls the trade function directly when conditions are met.

The decision flow per symbol per tick is:

1. System conditions are appended to the condition log (trade hours, max daily trades).
2. Indicators are computed lazily on first access and cached for the remainder of the tick.
3. Strategy code evaluates its if branches in top-to-bottom order.
4. If a branch's condition is true, the body executes — which may call HP.buy() or HP.sell().
5. The trade action captures a snapshot, logs TRADE_TRIGGER, executes the order, logs TRADE_EXECUTED.
6. If no trade call was made, the runner logs "Result: No trade conditions met."

Multiple HP.buy() or HP.sell() calls in a single tick are possible if the strategy has multiple branches. Each call produces its own TRADE_TRIGGER + TRADE_EXECUTED log pair and its own condition snapshot.

Duplicate Signal Prevention

The runner prevents several classes of duplicate or nonsensical signals automatically:

Multi-Timeframe Execution

Norena supports strategies that read from multiple timeframes simultaneously. The@norena-timeframes manifest comment in the compiled JS lists every timeframe the strategy references. The runner loads all of them into the kline cache before execution.

The primary timeframe — the first in the manifest — determines:

• Which series drives the bar loop in backtesting
• Which series is used for BARS_SINCE_ENTRY and COOLDOWN_OK calculations
• Which series drives the kline readiness check before each live tick

Secondary timeframes are available on the same tick — the indicator cache serves all timeframes simultaneously. A strategy can read a 1h EMA and a 4h RSI on the same bar without any additional configuration.