Martingale (default)

The default martingale entry point: an alias of linear martingale, kept as its own catalog value so a configuration that simply asked for "martingale" is preserved verbatim through the engine, the database and the dashboards.

Identical to `marti_grid_linear`: level i commits i base lots and places i take-profit targets. Choosing this value rather than the explicit one changes nothing the engine does — only the label that appears in logs and monitors.

Because level i opens i separate unit orders, each carrying its own take-profit, order count grows quadratically with depth while size grows linearly. At 10 levels this ladder rests 55 entry orders. Check the venue's open-order limit before configuring depth.

Below is the wizard's own ladder table and the trading terminal's chart engine, both driven by buildLadderPlan for this mode. Change the level count, spread or target and the rung prices, sizes, capital ramp and chart lines recompute exactly as they would in the grid designer.

Triangular in depth, exactly as linear martingale. Treat the two as one capital plan.

Read the cost vs 5 levels column as the escalation test. A flat ladder doubles when the depth doubles; anything materially above that is a curve whose coverage has to be bought rather than simply configured.

With every rung filled, the volume-weighted average entry is 92.14 against a base of 100 and a deepest rung of 90.00 — so the average sits 79% of the way down the covered range. Getting back to flat from the bottom therefore needs a 2.38% bounce, against 5.00% for a flat ladder of the same depth — 2.62% less work.

Size grows with depth, so most of the position — and nearly all of the risk — ends up in the deepest rungs that filled last. The average entry therefore falls faster than the price does, and a modest retrace recovers a disproportionate amount. The same property is the liability: a trend that keeps going forces the largest orders at the worst prices, and the capital requirement rises faster than the coverage it buys.

The last row is the metric that separates modes. Profit for a full cycle is the target percentage of deployed capital in every mode, so it cannot discriminate. What differs is how much capital has to sit reserved to earn one shallow cycle: this mode reserves 55.0× base to collect 1.8 bps of it when the first rung completes.

Same as linear martingale: choppy mean-reversion with funding deep enough to absorb a triangular capital ramp.

Default martingale behaviour, identical to linear: each level opens i base-sized orders so exposure rises arithmetically with depth, pulling the average entry down quickly for faster break-even.

Same convex tail as linear martingale, and the same multi-order pressure on venue order limits.

This is the product's grid backtester, not a summary of one. It fetches public candles for the instrument you pick, rebuilds the ladder anchored on the first candle of the window, then applies the engine's own fill, take-profit, refill and stop-loss rules bar by bar. The caveat block inside the panel is part of the output — read it before trusting a number.

First the arithmetic, then the market. The table below is computed from the size curves alone; the sweep underneath replays every one of those ladders over the same real candle window, with grid_mode as the only variable.

• A configuration or integration already says `marti_grid` and you want the value preserved.
• You want default martingale behaviour without choosing between variants.

• You are documenting or reviewing a strategy — prefer the explicit `marti_grid_linear` so the curve is unambiguous to the next reader.

• Read the Linear Martingale article: every dial and caution there applies unchanged.

• Watch the deepest filled level, not the P&L. Depth is the leading indicator; P&L is the lagging one.
• Compare peak committed notional against the account, weekly. A growth curve that has never been deep has never been tested.
• Treat every level increase as a capital decision: adding levels to a growth curve is not a linear cost.

1. 1
   Ambiguity in review

   The only failure unique to this alias is human: a monitor showing "martingale" tells a reviewer less than one showing "linear martingale", and the difference matters when the alternative variants are exponential or triangular.

• Spread sets how fast the ladder consumes depth. Widening it buys coverage for the same level count at the cost of fewer fills.
• Target sets what each cycle books. Below round-trip fees plus slippage, a grid is a fee generator regardless of the size curve.
• The stop loss is the only bound on the tail. Without it, the curve's worst case is whatever the market does, not what you planned.

1. 1
   Should I migrate to `marti_grid_linear`?

   There is no behavioural benefit, and switching mode is a structural edit that cancels and re-places the resting ladder. Change it when you are already rebuilding, not for tidiness alone.

• Sizes and capital: levelMultiplier / gridModeCurve in lib/grid/gridModes.ts, mirrored from grid_modes.hpp and the Python engine's lot calculator.
• Rung and exit prices, capital ramp, init targets and the stop line: buildLadderPlan — the same builder the wizard and grid designer use.
• Backtest fills, cycles and P&L: runBacktest / runBacktestSweep over public broker candles, applying the engine's fill, exit, refill and stop rules.
• Price charts: the trading terminal's chart engine, with the ladder drawn through its own price-line API.

• 1.Grid Modes — Overview — The full taxonomy and how to choose
• 2.Martingale family — What every curve in this family has in common
• 3.Capital Allocation — Sizing an account to a Martingale (default) ladder
• 4.Stop Loss — Bounding this curve's tail
• 5.Reading the Ladder Plan — Verifying the curve before deploying
• 6.Grid Structure — Levels, init batch and base size