Built-in strategies

Forven ships with a library of pre-registered strategies you can backtest the moment you have data. These are the built-in strategies: classic indicator and price-action templates, each a working implementation of the BaseStrategy interface, discovered and registered automatically at startup. You do not write any code to use them — pick one in the Backtest Studio, set a symbol and timeframe, and run.

This page is a map of the library: how it is organised, what the families do, and the parameter and trade-mode conventions that apply across all of them. It is a reference, not a recommendation. Forven does not endorse any strategy as profitable — the built-ins exist so you have honest, well-understood baselines to run through the research process.

How the library is loaded

At startup, the registry walks forven/strategies/builtin/ and imports every module. Each module declares a TYPE_NAME (the string you reference, e.g. rsi_momentum) and a STRATEGY_CLASS extending BaseStrategy. The registry validates the abstract contract, then caches TYPE_NAME → class in a global type map. The result is 75+ pre-registered strategies available everywhere — the Studio, the strategy lab, grid search, and the MCP tools.

Discovery is idempotent and resilient: if one built-in module fails to register, the registry logs a warning and keeps going, so a single bad module never blocks the rest. To see exactly what is registered on your install, list them:

# Every registered strategy (built-in + custom) with metadata
Invoke-RestMethod -Uri "http://127.0.0.1:8003/api/strategies"

The same catalog backs the prebuilt picker in the Studio, so the API and the UI always agree.

What you'll see

In the Backtest Studio prebuilt picker, each built-in appears by its TYPE_NAME with its editable parameters exposed in the parameter editor. Selecting one loads its default parameters; you can run as-is or deviate before submitting. After a run, strategies with chart support draw their indicators and trade markers on the candlestick chart (see Charting below).

Strategy families

The library groups loosely into families by the kind of edge each template chases. Family membership is not a hard label in the code — it is a way to reason about which market regimes a template tends to suit. The names below are the real TYPE_NAME values from the registry.

Momentum & oscillators

Mean-reversion and momentum signals from bounded oscillators. These tend to suit RANGE_BOUND conditions, where overbought/oversold extremes revert.

• rsi_momentum — Relative Strength Index crossings of oversold/overbought thresholds.
• stochastic — Stochastic oscillator %K/%D crossovers.
• williams_r — Williams %R extremes.

Moving averages & trend

Trend-following templates built on moving-average relationships and trend filters. These tend to suit TREND_UP / TREND_DOWN regimes.

• ema_cross — Fast/slow exponential moving-average crossover.
• macd — Moving Average Convergence Divergence signal-line crossings.
• supertrend — ATR-banded trend follower.
• ichimoku — Ichimoku cloud relationships.
• parabolic_sar — Parabolic SAR stop-and-reverse.

Volatility bands & channels

Bands and channels around a moving centre, traded for breakouts or reversion to the band.

• bollinger — Bollinger Bands (standard-deviation envelope).
• keltner — Keltner Channels (ATR envelope).
• donchian — Donchian Channel high/low breakouts.

Breakout & price action

Levels and ranges traded on the break.

• breakout_range — Range/level breakout entries.
• orb — Opening-range breakout.
• vwap_cross — Volume-Weighted Average Price crossover (reversion/continuation).

Derivatives & flow

Templates that lean on perpetual-futures microstructure — funding and order flow — enriched into the backtest frame automatically.

• funding — Funding-rate-driven positioning.

These families do not exhaust the library; they are the named anchors from the registry. The full set of 75+ is whatever GET /api/strategies returns on your machine — treat that endpoint as the source of truth, not this list.

Parameters

Every built-in exposes a set of named parameters with sensible defaults. The Studio's parameter editor loads those defaults when you select a strategy; you can override any of them per backtest.

A few conventions hold across the whole library:

• Canonical names. Parameters are canonicalized before signals are generated, and common aliases are mapped to canonical names (for example entry_oversold is mapped to k_oversold). When you set parameters via the API or a config, use the canonical schema — the editor in the UI already shows canonical names.
• Parameter space for optimization. When you run grid search, a strategy that does not declare its own parameter_space() gets a mechanical fallback space of roughly ±40% around its defaults. Strategies can override this to declare meaningful ranges. See optimization in the lab for how this feeds the grid search optimizer.
• Risk knobs are separate. Execution-level risk controls (stop-loss, take-profit, trailing stop, sizing) are not strategy parameters. Setting stop_loss_pct in a strategy's params is ignored by the backtest engine by design — these must be passed as execution_controls. This is a deliberate safety boundary (the "B-4" defense) so a risk field can never silently do nothing. See writing custom strategies for the full distinction.

Trade modes

Each strategy runs in one of three trade modes, which controls direction and how metrics are sliced:

The both (hedged) mode needs the strategy to produce explicit directional signals — a legacy two-series (entries, exits) payload is not enough for hedged trading. Most built-ins default to long_only; check the strategy's metadata for its supported modes. Trade mode also affects the by_side metric breakdown (long vs short) you see in the result.

Regime compatibility

A built-in can declare compatible_regimes — the market regimes in which it is allowed to take entries (for example [TREND_UP, RANGE_BOUND]). When regime gating is on, the backtest pre-computes the regime for every bar and blocks entries outside the compatible set, forcing an exit if the regime changes mid-trade. This is how a trend follower avoids getting chopped up in a range, and how a mean-reverter sits out a strong trend.

Regime detection needs warmup: on windows shorter than ~210 bars there is not enough history to classify, so the engine defaults to RANGE_BOUND. Give a regime-gated strategy a long enough window for the gate to mean anything.

Charting support

A subset of built-ins draw their indicators on the backtest chart. As of this writing, the chart context supports: rsi_momentum, bollinger, keltner, macd, ema_cross, stochastic, vwap, and supertrend. Selecting one of these after a run renders the indicator panels plus entry/exit markers and regime shadings. Strategy types without chart support still backtest normally — the chart simply omits indicator overlays and logs a warning.

Vectorized vs per-bar execution

Roughly 16 built-ins have a vectorized path that computes all entry/exit signals at once (O(n)) instead of bar by bar (O(n²)). This is purely a performance detail — vectorized strategies backtest faster on long windows — and it does not change the signals or the metrics. Strategies without a vectorized path fall back to per-bar generation, which is correct, just slower.

Steps: run a built-in strategy

1. Make sure you have candles for your symbol and timeframe — load them in the data manager first if needed.
2. Open the Backtest Studio (/backtest/new) and choose the Prebuilt source.
3. Pick a strategy by its TYPE_NAME (for example ema_cross).
4. Set the symbol (e.g. BTC), timeframe (e.g. 1h), and a date range or bar count.
5. Adjust parameters in the editor if you want to deviate from the defaults.
6. Submit. The engine splits the data 70/30 into in-sample and out-of-sample windows and returns in_sample, out_of_sample, and robustness blocks. Read out-of-sample first.
7. If the result looks promising, take it to the strategy lab to optimize parameters and run the gauntlet before it can be promoted to paper.

Using a built-in as a starting point

Built-ins are baselines, not destinations. The intended path is: run one to understand a behaviour, optimize its parameters in the lab, harden the survivor through the gauntlet, and only then let it advance toward paper. A passing backtest on a built-in is the beginning of the pipeline, never the end of it.

If you want to go beyond the library, the same interface that powers every built-in is open to you — see writing custom strategies for the BaseStrategy contract, parameter spaces, regime declarations, and the safety guard that screens uploaded code.

Related

• Backtesting a strategy — run a built-in against historical data.
• The strategy lab — optimize parameters and run the gauntlet.
• Writing custom strategies — build your own on the BaseStrategy interface.
• Market regimes — how compatible_regimes gating works.