Building a Prop Firm Stack: Engine, Anchor, Scaling, and Booster
A practical way to assign each account a job, avoid duplicated risk, and expand only after the current layer has paid for itself.
A stack is useful when each account solves a distinct constraint. Four accounts taking the same trade at the same size are multiplication, not architecture.
The useful idea in the original strategy
The original PropMinMax strategy grouped accounts by role instead of treating every purchase as interchangeable. That core idea remains useful. It forces a trader to say why an account belongs in the portfolio before paying for it.
Why this matters
What does not belong in a durable playbook is a fixed list of firms or a projected monthly payout range. Programs, prices, rules, and firm behavior change. The framework should survive those changes even when every example account is replaced.
Engine: the repeatable operating account
The engine is the account whose rules best match the process you already trade. It should minimize operational surprises: compatible platform, understandable drawdown, realistic payout cadence, and a cost you can absorb without changing behavior.
Why this matters
An engine is selected for repeatability, not the largest advertised balance. If its rules force you to alter normal exits, overtrade for minimum days, or hold a buffer your process rarely clears, it is not functioning as an engine.
Anchor: reduce business concentration risk
The anchor is a second path that reduces dependence on one firm, platform, or payout policy. Its job is business continuity. It does not diversify market risk when it receives the same copied trade as the engine.
Different firms can diversify company risk. Different trades, instruments, or time horizons are what diversify trading risk.
Why this matters
An anchor can justify some added complexity when the operational independence is real. A second brand using the same infrastructure, identical rule exposure, or a shared failure point may provide less protection than it appears.
Scaling layer: add capacity after evidence
A scaling layer increases exposure to a process that has already produced net withdrawals. It should be funded from realized results, not from a simulated balance or an assumed future payout.
Why this matters
Add one layer at a time. Normalize quantity for each account's remaining cushion, daily limit, and trailing behavior. A copier can synchronize entries, but it cannot make unlike rules carry equal risk.
Booster: optional, capped, and allowed to fail
The booster is a deliberately small allocation to a higher-friction or higher-variance opportunity. It may offer faster eligibility, a specialized product, or promotional pricing, but the portfolio must not depend on it.
Why this matters
Because this role is easiest to rationalize, give it the hardest cap. Predetermine the maximum attempts and cash loss. A booster that repeatedly needs rescue from the engine has stopped being optional.
Build in gates, not earnings promises
Move from engine to anchor only after the engine has produced enough net withdrawals to cover its complete cost. Add scaling only after the combined operation has survived ordinary losing periods and execution errors. Add a booster only when its full loss would not change the plan.
If you cannot state the account's unique job, maximum cash loss, and removal condition in one sentence each, it does not belong in the stack yet.
Why this matters
Use the Stack Builder to compare account roles and concentration, then verify every candidate against its dated official rules. The tool organizes constraints; your records determine whether the strategy has earned expansion.
