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, price-action, and crypto-flow templates, each a working implementation of the BaseStrategy interface, discovered and registered automatically at startup. You don't write any code to use them — pick one on the Manual Backtest page and run it on its own market, or open one in the Strategy Creator (Open… → Prebuilt) and adapt it.

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, such as rsi_momentum) and a STRATEGY_CLASS extending BaseStrategy. The registry validates the contract and maps TYPE_NAME → class. The result is 73 research templates available everywhere — Manual Backtest, the Strategy Creator, The Forge, the optimizer, and the MCP tools.

Discovery is resilient: if one 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, with each template's parameters and ranges:

# The built-in template catalog (the same list the Strategy Creator shows)
Invoke-RestMethod -Uri "http://127.0.0.1:8003/api/strategies/prebuilt"

Each catalog entry names the template's own asset, its declared timeframe (when its defaults name one), the trade_modes it supports, and its default_trade_mode — see market and trade modes.

Two registered types are not research templates and are left out of that catalog: rule_engine, which runs the Strategy Creator's Rules designs, and stress_test, a deterministic trade generator used to validate the system itself.

Strategy families

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

Momentum & oscillators

Signals from bounded oscillators — traded as momentum or, at the extremes, as reversion. Oscillator extremes tend to revert in RANGE_BOUND markets.

• rsi_momentum — RSI crossings of oversold and overbought thresholds.
• rsi_boundary_rejection — bounces off the RSI oversold and overbought zones.
• rsi_divergence — price and RSI disagreeing.
• connors_rsi — Connors RSI.
• stochastic — Stochastic %K/%D, long and short.
• kdj — the KDJ stochastic variant.
• williams_r — Williams %R with an ADX filter.
• williams_ema_reclaim — Williams %R recovery above an EMA support filter.
• cci — Commodity Channel Index.
• mfi — Money Flow Index.
• ultimate_oscillator, awesome_oscillator, ppo, roc, trix — classic oscillators and rate-of-change signals.
• elder_ray — Elder Ray bull and bear power.

Moving averages & trend

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

• ema_cross, dema_cross, tema_cross, hma_cross — fast/slow moving-average crossovers.
• macd — MACD signal-line crossings.
• adx_trend — ADX trend strength.
• trend_pulse_adx — ADX trend continuation on an EMA pullback reclaim.
• ema_rsi_pullback — EMA trend pullback confirmed by RSI recovery.
• supertrend — ATR-banded trend follower.
• parabolic_sar — Parabolic SAR stop-and-reverse.
• ichimoku — Ichimoku cloud relationships.
• aroon — Aroon up/down.
• heikin_ashi — Heikin-Ashi candle colour changes.
• linear_regression — linear-regression channel.

Volatility, bands & breakouts

Bands and channels around a moving centre, traded for breakouts or for a fade back inside, plus volatility-squeeze setups.

• bollinger — Bollinger Band breakout.
• bb_fade — fade the Bollinger Band edge.
• bb_squeeze, ttm_squeeze, volatility_contraction_breakout — trade the expansion out of a volatility squeeze.
• keltner — Keltner Channel breakout.
• donchian — Donchian Channel high/low breakout.
• donchian_regime — a regime-aware Donchian breakout tuned for durable trends.
• atr_breakout — ATR-sized breakouts.
• atr_volume_breakout — ATR breakouts confirmed by expanding volume.
• breakout_range — N-bar high/low breakout.
• chandelier_exit — the Chandelier Exit trailing rule.

Mean reversion

• zscore_reversion — z-score mean reversion.
• zscore_mean_reclaim — z-score rebound with EMA context.
• stddev_breakout — standard-deviation (z-score) stretch and revert.
• momentum_burst_mean_reversion — fade a momentum burst.
• pivot_point — bounces off pivot-point support and resistance.
• vwap_cross, vwap_pullback — VWAP crosses and pullbacks.

Price action & patterns

• orb — opening-range breakout.
• inside_bar — inside-bar breakout.
• engulfing — bullish/bearish engulfing candles with volume confirmation.
• three_bar_reversal — three-bar reversal.
• double_pattern — double top and double bottom.
• gap_fill — gap detection and fill.

Volume & order flow

• obv_trend — On-Balance Volume with an EMA crossover.
• adl — Accumulation/Distribution Line.
• chaikin_mf — Chaikin Money Flow.
• taker_aggression — momentum from aggressive taker buying or selling.

Crypto derivatives & sentiment

Templates that lean on perpetual-futures microstructure and sentiment, read from enrichment streams merged into the backtest frame.

• funding, funding_regime_reversion — mean reversion on extreme funding rates.
• funding_crowding_composite — funding and positioning crowding combined.
• crowding_detector — contrarian on crowded positioning.
• liquidation_cascade — mean reversion after liquidation cascades.
• fear_greed_contrarian — contrarian on the Fear & Greed Index.

Cross-asset & macro

• btc_dominance_rotation — rotate on shifts in Bitcoin dominance.
• cross_asset_divergence — mean reversion when related assets diverge.
• dollar_strength_filter — trade with a US-dollar strength filter.
• vix_regime_filter — trade with a VIX volatility-regime filter.
• macro_regime_composite — a composite macro-regime signal.

These need their data present locally. Check data coverage before trusting a result from a flow, sentiment, or macro template — a stream with no data behind it leaves the strategy almost nothing to trade on.

Market-specific templates

• ema_cross_eth_15m, vwap_pullback_eth_15m — ETH 15-minute templates built on the EMA-cross and VWAP-pullback families.
• regime_adaptive_eth — an ETH template that adapts to the detected regime.

These were tuned on one market and timeframe. On anything else, treat them as ordinary templates that have to earn their place like any other.

Parameters

Every built-in exposes named parameters with defaults. The parameter editor loads those defaults when you pick a strategy; you can override any of them per run.

A few conventions hold across the whole library:

• Canonical names. Parameters are canonicalized before signals are generated, and common aliases map to canonical names (for example entry_oversold → k_oversold). Use the canonical names in the API; the UI already shows them.
• Parameter space for optimization. Most built-ins declare their own parameter_space() — the ranges the optimizer searches. A built-in that declares none gets a fallback that sweeps each numeric parameter about ±40% around its default. (A sandboxed strategy from an agent or the AI Drop Zone gets a small ×0.8 / ×1.0 / ×1.2 grid instead; see writing custom strategies.) See The Forge.
• Risk settings are separate. Stop-loss, take-profit, trailing stops, and sizing are execution settings, not strategy parameters. A stop_loss_pct inside a strategy's params is ignored by the engine, by design — pass it as an execution setting instead, so a risk field can never silently do nothing. See backtesting.

Market and trade modes

Every built-in declares the market it was written for, and the catalog reports it with the template:

• Asset. Most templates are written for BTC; some name ETH, SOL or BNB. On Manual Backtest the template's own market is adopted; running it anywhere else is a what-if that never re-homes anything.
• Timeframe. Only the few templates whose defaults name a bar size declare one, such as the ETH 15-minute templates. The rest leave the timeframe to you.
• Trade modes. The sides the template implements, and the one it runs by default.

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

Manual Backtest offers only a template's supported modes. Trade mode also drives the by_side breakdown (long vs short) in the result. To trade both sides, write a custom strategy — see trade modes.

Regime compatibility

A built-in can declare compatible_regimes — the market regimes in which it may take entries (for example [TREND_UP, RANGE_BOUND]). When it does, the backtest classifies 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 about 210 bars there is not enough history to classify, so bars default 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 own indicators on the backtest chart: rsi_momentum, bollinger, keltner, macd, ema_cross, stochastic, VWAP, and supertrend. Every strategy still gets entry/exit markers and regime shadings; the others simply omit indicator overlays. (Strategy Creator designs preview their indicators as you build them.)

Vectorized vs per-bar execution

About a dozen of the classic templates have a vectorized path that computes all signals at once instead of bar by bar. It is purely a performance detail — those templates backtest faster on long windows — and it does not change the signals or the metrics.

Steps: run a built-in strategy

1. Make sure you have candles for the symbol and timeframe — see managing market data. If they're missing but the source can serve them, the run fetches them first.
2. Open Manual Backtest (/backtest/new).
3. Pick a strategy (for example ema_cross). Its own market is filled in; set a timeframe (for example 1h) if the template doesn't declare one.
4. Adjust parameters, trade mode, and execution settings if you want to deviate from the defaults; blank fields resolve the way the strategy does. Use Signal preview to check the strategy actually fires.
5. Run. The window ends at the held-back data cutoff, and the engine splits it 70/30 into in-sample and out-of-sample. Read out-of-sample first.
6. If the result looks promising, open it in the Strategy Creator and Send to Forge →, so it enters the pipeline and has to survive the gauntlet before it can reach paper.

The backtest walkthrough shows this step by step.

Using a built-in as a starting point

Built-ins are baselines, not destinations. The intended path: run one to understand a behaviour, adapt it, send it into the pipeline, and let the gauntlet decide. A passing backtest on a built-in is the beginning of the pipeline, never the end of it.

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 custom code.

Related

• Backtesting a strategy — run a built-in against historical data
• Strategy Creator — open a built-in and adapt it, or build your own
• The Forge — optimize parameters and run the gauntlet
• Writing custom strategies — build your own on the BaseStrategy interface