State Machines: One Strategy That Can Change Its Mind

One strategy, several modes

A Studio strategy has three trees. Entry decides when to open, cancel governs a resting order, and exit decides when to close. One set of three, running forever, for every market the strategy follows. That is enough for most ideas and it is deliberately simple.

Some rules cannot be written that way, because the rule you want depends on what has already happened. Enter on a modest signal the first time and only on a much stronger one afterwards. Work an order patiently while a move is young and take liquidity once it matures. After closing a losing position, stop adding for a while without stopping the exit. Each of those needs the strategy to be in a different mode, and a single tree has nowhere to keep one.

What those rules have in common is memory. A strategy that only reads the market has none: every evaluation starts from nothing and sees the book any other evaluation would see. A state machine is the smallest useful memory you can give one — not a number it accumulates, but a place it is in. Classifying a market into a regime and managing each regime differently is exactly that, and it is the most common reason to reach for one.

A state machine gives it somewhere. You declare up to ten states, each a complete strategy in its own right, and draw directed arrows between them. Every arrow carries a rule built from the blocks you already use. The runner evaluates only the state a market is currently in.

What a state holds

A state is a name and a full lifecycle. While a market sits in it, the strategy is exactly that lifecycle: its entry decides whether to open, its cancel governs any resting order, its exit decides whether to close. Nothing from the other states runs.

This is why a state is more than a flag. You are not toggling a parameter, you are swapping the strategy. A flat state might hold nothing but three do-nothing trees. A scaling-in state might rest a post-only quote and cancel it when it ages out. A cooling-off state might refuse new orders while still closing the position it inherited.

The strategy's own top-level trees always mirror whichever state you marked as the start. That keeps a machine readable as an ordinary strategy by anything that does not know about graphs, and Studio produces it automatically. You never maintain it by hand.

The rules live on the arrows

A transition is directed: from one state to another, and never to itself. Staying put is already what happens when no arrow is satisfied, so a self-loop would say nothing.

Each arrow carries one condition, edited in the ordinary block inspector with the whole palette available. A transition rule is written exactly like a branch test inside a tree — choose a block, pick a comparison, set a threshold. Anything you can ask a branch, you can ask an arrow.

Two rules govern when they fire. Arrows leaving a state are tested top to bottom and the first satisfied one wins, so their order is a priority you control. And at most one arrow is followed per evaluation, so a graph whose rules are all true walks one step per tick instead of spinning around a loop inside a single tick.

Transitions are tested before the trees. An arrow taken on a tick immediately puts its destination in charge of that tick's decision rather than costing a full evaluation interval.

Every market keeps its own place

A strategy that follows several markets does not hold one position in the graph. It holds one per market. Bitcoin can be scaling in while Ethereum is still flat and Solana is cooling off. They may equally sit in the same state; the point is that they are independent, not that they differ.

Positions are stored by state identity rather than by position in a list, so renaming a state or inserting a new one never moves a live market. Delete a state a market was in and that market returns to the start instead of being stranded. Changing a strategy in a way that alters its identity resets every market to the start.

One consequence is worth stating plainly. A transition is decided once, on the shared signal path, and broadcast to every follower, so two people following the same strategy are never in different states on the same market. It also means an arrow cannot read your own resting order. Those blocks stay valid in a cancel tree, where they belong.

Reuse a strategy you already published

A state's logic does not have to be written from scratch. Add from published strategy copies an existing published strategy's three trees into a new state and records where they came from.

The copy is a snapshot, not a link. The state keeps running that exact version after the original is republished. That is deliberate: it keeps a backtest of the machine reproducible, and it stops a later edit by someone else from silently changing what your strategy does.

Only a strategy of the same type can be copied, because a state shares the machine's universe, venue, and sizing. Duplicating a state inside the machine does not carry the provenance across — a duplicate is yours from that point on.

Building one

The panel sits above the canvas. Turn it on and the strategy you already have becomes the single starting state, so nothing you built is lost. Add an empty state for a fresh lifecycle, or add one from a published strategy.

Selecting a state switches the trees below to that state, and a badge over the lifecycle tabs names the one you are editing. Rename it in place; names are free text and renaming is always safe. Mark a different state as the start, duplicate a state with all three of its trees, or remove one along with every arrow that touches it.

Draw an arrow with Add a transition to, or by dragging from a state's right edge on the graph, then click it to edit its rule. When more than one arrow leaves a state, reorder them with the up and down controls. Reached from lists the arrows that enter the selected state, so you can see how a market arrives and not only where it goes next.

The live preview follows the state you are editing rather than always the starting one, so the animation below the graph is what the strategy does while it is in that state.

The handover

One rule is worth learning before building anything real. A transition is followed before the trees run, which means the state being entered is the one that must know how to close an open position.

If a state is holding inventory when its arrow fires, that inventory is handed to the destination. If the destination's exit does nothing, the position stays open, because the state that knew how to close it is no longer the state being evaluated. Put the exit in the state you are moving into.

The same applies to resting orders. A state whose entry can leave an order on the book must have a cancel tree of its own, which the contract enforces, and the state you hand that order to needs a cancel tree that will actually retire it.

What it changes, and what it does not

To see the difference we replayed three strategies over one synthetic recording built with four deliberate regimes: a clean rally, a whipsaw chop, a sell-off, and a sharp recovery.

The first was an ordinary momentum strategy with no machine. The second was the same policy expressed as a two-state machine, and it matched the first exactly — wrapping a strategy in a graph does not change it. The third used a rule a single tree cannot express: the first entry needs a modest signal, every later entry needs a much stronger one.

Over the same data the third made two round trips instead of ten and paid roughly a fifth of the fees, because the chop never produced a signal strong enough to re-arm it. The recording is synthetic, so this measures the engine and the strategies rather than any market, and the harness ships with the platform so the comparison is reproducible.

A state machine makes a strategy more expressive, not more likely to be right. More states mean more places for a rule to be wrong, and a graph that is hard to read is hard to trust. Start with two states and one arrow, confirm in a backtest that it does what you expect, and add a state only when a rule genuinely needs somewhere to live.