Each strategy in the workspace runs in one of two sizing regimes, and the portfolio has an initial capital. The regimes can be mixed freely inside the same session — strategy A on 3 fixed contracts, strategy B dynamically sized at 2% of capital.
In the default Fixed regime (× on the strategy row), the weight scales the strategy's
daily P/L before everything is summed. It is not an allocation percentage and weights do
not need to add up to 1.
| Weight | Effect on that strategy |
|---|---|
1.0 | unchanged (default) |
2.0 | doubles its P/L contribution |
0.5 | halves it |
0 | mutes it (kept in the session, excluded from the curve) |
Because the equity curve is the cumulative sum of weighted P/L, changing one weight rescales that strategy's contribution and the whole portfolio — and every metric — updates live.
Weight vs. visibility
Setting a weight to 0 keeps the strategy listed but out of the maths. Hiding a strategy does the
same visually. Both are non-destructive — the data stays in your session.
Invest Studio: a base-100 index read in real dollars
An Invest Studio export is a normalized equity index that starts at 100, not a dollar curve. Its daily P/L is in index points: if the index runs 100 → 402 the summed P/L is ~302 points. Read as dollars 1:1 that would show a meaningless $302 (it's really +302%).
So on upload VEEMAN auto-scales an Invest Studio line to your initial capital: it sets the strategy
weight to the capital, and because the index base is 100, weights above 200 are divided by 100
downstream — weight 100,000 becomes a ×1,000 multiplier. The base-100 index now maps to $100,000, so
the ~302 points read as ≈ $302,000 and the equity runs $100,000 → $402,000. Change the initial
capital before uploading to rebase it; you can always override the weight by hand afterwards.
Switching a strategy to Sizing (% on the strategy row) replaces the fixed multiplier with a
per-trade contract count, computed by the risk/margin engine. For every trade, in time order within
its day:
contracts = floor( capital × Cap% ÷ unit )
where unit is the per-contract denominator chosen by the basis:
unit = SL $ if a fixed dollar stop is set, otherwise
unit = |premium| × SL% ÷ 100 (requires per-trade data with premiums);unit = the trade's margin requirement from the CSV, or the manual
per-contract margin you set.Every per-trade quantity is read per contract. Option Omega exports report Premium per contract but P/L and Margin Req. as position totals: the engine divides those totals by the row's No. of Contracts, so a multi-lot backtest sizes exactly like a 1-lot one (the same normalization feeds the File (~median) margin reference in the sizing popover).
The optional Min 1 contract floor and Max contracts cap are applied last (the max wins over
the min if they conflict; the margin cap wins over both). The
strategy's realized P/L becomes contracts × per-contract P/L, attributed to the trade's close date
— the P&L / ct column of the Trades band shows
that per-contract figure so the row can be checked by hand.
One calendar: a trade belongs to the period it closes in
The close date is not only where the P/L lands on the curve — it is also the date a reading period uses to decide which trades are inside it. A position opened on 28 March and closed on 7 April counts in April, on the chart, in the metrics, in the monthly grid and in the trade ledger.
That single convention is what makes the ledger reconcile with the panel above it: the sum of the P/L in the period's trade list equals the period's net P/L. Filtering the ledger by open date instead produced two different totals for the same interval, neither of them wrong on its own terms.
A binding cap changes what the numbers mean
Once the cap is reached the size stops following the account: the Contracts column sits flat on the cap for long stretches, which is the cap working, not a stuck calculation. The engine says so in the warnings strip, naming the strategy and how many trades were limited.
There is a knock-on effect worth knowing. A binding cap (or floor) means this strategy's P/L is no longer proportional to capital, so align starting capital cannot simply scale it on a windowed period. It does not carry the leg over at its real P/L either: instead it recomputes the factor from the sizes themselves — for every trade in the window it takes the size the capital wanted, scales it by the period factor, re-applies the declared limits, and compares the two totals.
That recomputation matters because the two limits behave in opposite directions: a cap that binds today may not bind at a reduced capital (the size would fall below it), while a floor that does not bind today certainly will. Judging from "did the limit bite?" was wrong both ways — measured at +588% and −83% on real portfolios. Other legs in the same portfolio are unaffected: the factor is per strategy, and the period curve is recomposed leg by leg.
Fixed-amount costs are not rescaled
Manual costs charged per trade or per day are a fixed amount: $50 a trade stays $50 a trade whatever the account size. Only the per-contract basis follows capital, because it follows the contracts.
So on a windowed period a sized leg is recomposed as factor × gross − fixed costs, not
factor × (gross − costs). The difference is real: scaling the net would shrink the commissions in
proportion, and you would appear to pay less to trade simply because you zoomed into a quarter.
Strategies without per-trade data
Daily-only imports (no premiums) are sized as one synthetic trade per day. The premium-based SL% cannot work there — declare the per-contract risk as SL $, or use the margin basis with a manual value. The engine warns explicitly when a strategy ends up at 0 contracts.
Three parameters appear in the workspace header once at least one strategy uses dynamic sizing:
max daily loss %) — a per-day ceiling as % of current capital. Sized
trades consume it in time order; once the day's cumulated amount reaches it, later trades are scaled
down (to 0 if needed). Fixed-regime legs do not consume it — they declare no
per-contract risk. 100% means "the whole account", which is a real ceiling and not the absence of one:
in a multi-strategy book several legs at 45% each can ask for more than the capital in a single day,
and that day is capped. What it caps depends on the leg's basis, because
it throttles the same unit the leg is sized on: on the risk basis it caps the summed
per-contract loss (contracts × SL $) — a genuine daily loss budget; on the margin basis
there is no per-contract loss figure, so it caps the summed margin committed
(contracts × per-contract margin) — a daily margin-utilization budget, not a loss cap. Set
0% and the budget is $0, so sized legs take 0 contracts (it is a floor, not "unlimited").contracts × per-contract margin of the sized trades already taken earlier
that day. Execution times are respected on both sides: a fixed leg entering at 15:30 does not take
room away from a sized trade at 09:35, and at an identical timestamp the fixed leg goes first
(it cannot be reduced, so counting it after would allocate margin that overflows a moment later).
If a trade's required margin would
push that total above the cap, its contracts are reduced to the maximum the remaining margin
allows at that moment (floor(headroom ÷ per-contract margin)), down to 0 — the trade is not
opened at all — when there is no room even for one contract. Only the executed part consumes the
daily risk budget and realizes P/L; the trimmed part is excluded from the calculation. Every
reduction is recorded in the reduced-trades list (date, strategy, open time, planned and final
contracts, required and committed margin, margin already committed, day limit, capital, excluded
P/L) that the workspace opens from the button under the charts. Fixed legs are never touched
(their size is yours): when the non-reducible margin alone exceeds the cap, sized trades have no
headroom that day and the engine reports the unresolvable days in the warnings. Trades without
margin data cannot be evaluated, so they pass through untouched. Realized P/L counts executed
contracts only, so the equity, the allocation rows and the margin band all reflect what was
actually taken. The Monte Carlo simulation does not apply the cap. New sessions start at the
80% default; you change it per session from the workspace header, next to Max daily risk
and Compounding.The cap wins over Min 1 contract
The two knobs are not the same kind of thing. Min 1 contract is a size preference — "below this size the trade is not worth taking" — and it duly overrides the capital allocation and the daily risk budget. The margin cap is a statement about capacity: the free margin is either there or it is not, and an account does not open a position it cannot margin. So when the cap leaves no room for a single contract the trade is excluded, floor or no floor.
It used to be the other way round, and the consequence was quietly wrong: with Min 1 contract ticked the cap could never reach 0, so the engine kept opening trades at one contract well past the declared 80%, mentioning it only in a warning. If you want those trades back, the honest levers are raising the initial capital, lowering the other strategies' Cap %, or moving the limit to 100% — not the contract floor.
Fixed legs are aggregated exactly as before (weighted daily P/L on the master calendar). Sized legs
are allocated per-trade with the rules above. The portfolio's daily P/L is the sum of both, the
equity is initial_capital + cumsum, and the margin band adds the fixed legs' margin (scaled by
weight) to the sized legs' allocated margin (contracts × per-contract margin), counted on every
business day the position is open, close date included — margin is released when the position closes,
not when it opens, so a trade held Monday to Friday ties up capital for five days. That matters for the
peak, which is the figure the optimizer's margin constraint is checked against.
The fixed legs' margin is counted at the time each position actually opens, not from the opening bell: a leg that enters at 15:30 leaves the morning's cash free. This holds when you zoom into a sub-period too — with align starting capital on, the book is re-simulated over the framed trades and that re-simulation sees the same execution times and the same cap as the full-history one, so the same day never sizes two different ways depending on how the chart is framed.
With sizing active the charts card also exposes the Trades band (one row per sized trade: contracts, risk, margin, cumulative margin, capital, P/L — a trade reduced by the margin cap shows its final size with the committed margin in amber, and one the cap excluded entirely carries a ⊘ on its zeroed contract count; the full requested size lives in the reduced-trades list) and any engine warnings right under the KPI strip. The Rolling band (moving-window returns, 1w→1y) is available for every portfolio, fixed ones included.
The initial capital is the equity the P/L accumulates on:
equity(t) = initial_capital + cumulative_sum(daily P/L up to t)
It sets the baseline and therefore scales every percentage figure (Profit %, CAGR, drawdown %), while the dollar P/L itself comes from your trades. In the dynamic regime it is also the sizing base (the current capital when compounding is on). You can edit it inline in the status bar, or set a default for new sessions in Settings.
Strategies collected into a group get a second, independent lever: the sleeve's size knob. The two compose by multiplication, and the engine keeps them separate:
effective_weight = weight × group_scale (fixed-contract legs)
effective_cap_pct = cap_pct × group_scale (dynamically-sized legs)
The knob multiplies the lever each member actually uses — the contract multiplier for a fixed leg, the per-trade allocation for a sized one — because in the dynamic regime the weight plays no part in the calculation.
Three properties follow, and they are what make the knob safe to play with:
weight and cap_pct are never rewritten. The scale is applied when the
numbers are read, so the ratios inside the group survive any amount of knob-turning and setting the
knob back to 1 always returns the original configuration.The scale does not change how contracts are computed, only what goes into the formulas above: every rule on this page — daily risk budget, compounding, margin cap, whole-contract truncation — applies unchanged to the effective values.
One strategy leaving its group
Saving a single strategy to the library takes it out of its group, and the scale does not follow it there. To keep what you were looking at, the effective exposure is baked into the saved weight. Saving the whole portfolio instead keeps base weights and groups separate, as described above.
From the command palette (⌘K / Ctrl-K):
1/n across the visible strategies.1.00.Both act on the base weights and leave any group scale untouched — so a sleeve keeps its size while its internal balance is rewritten.
Next: filter by day of the week with the Weekday filter.