Automated trading is hard for a simple reason: the world does not wait for your code to catch up.

Markets move. Feeds arrive out of order. Exchanges acknowledge orders late. Your position changes because of fills, cancels, fees, funding, liquidations, and sometimes just because the venue has a different view of reality than you do for a few milliseconds.

That sounds like a trading problem. It is also a software problem.

A trading strategy is a real-time system trying to make decisions from imperfect messages. It needs to know what the market looks like, what the portfolio looks like, what orders are live, what risks are active, and what it should do next. Every tick asks the same question:

What should this strategy want now?

Most strategy code becomes painful when that question gets mixed together with everything else. Signal calculations sit next to order management. State transitions get buried inside execution logic. One parameter change creates behavior you cannot explain. A backtest looks good, but you cannot reproduce it cleanly. The strategy still "works," until you have to modify it, debug it, or trust it with real capital.

Structure is built around a different idea: a strategy should have an anatomy.

Not as branding, but as engineering. If you cannot point to the moving parts, you cannot reason about the machine.

The Three Parts of a Strategy

On Structure, we break strategies into three core components:

1. Data, computations, and signals

2. State machine

3. Target positions

That is the whole trick.

The first layer turns market data into values you can reason about. The second layer decides what state the strategy should be in. The third layer says what position the strategy should target in that state.

Each part has a different job. Keeping those jobs separate is what makes the system readable, deterministic, and much easier to improve.

Start With the State

The cleanest way to think about a trading strategy is not as a pile of orders. It is a state machine.

A state machine is just a set of possible states, plus rules for moving between them. For a simple directional strategy, the states might be:

• LONG

• SHORT

• FLAT

That is already useful. The strategy is not "kind of bullish" or "mostly unwound unless an order is still resting somewhere." It is in one of three states. No fog around the intent.

Take a basic EMA crossover strategy. If the market looks strong, the strategy wants to be long. If the market looks weak, it wants to be short. If there is no clear signal, it wants to be flat.

In pseudocode, the state machine can be written like this:

if should_be_long:
    return LONG

if should_be_short:
    return SHORT

return FLAT

if should_be_long:
    return LONG

if should_be_short:
    return SHORT

return FLAT

if should_be_long:
    return LONG

if should_be_short:
    return SHORT

return FLAT

That may look almost too simple. That is the point.

The state machine does not care how the signal was calculated. It does not care whether you are currently flat, long, short, or halfway through a fill. Its job is only to answer one question:

Given the information we have right now, what state should the strategy be in?

This is where clarity starts. If should_be_long is true, the state is LONG. If should_be_short is true, the state is SHORT. Otherwise, the state is FLAT. There are no hidden fourth states.

Then Calculate the Signals

Now we can ask the question most people associate with strategy development:

How do we know whether we should be long or short?

That belongs in the signal layer.

For the EMA example, the idea is straightforward. We calculate an exponential moving average of the asset price. If the current price is meaningfully above the EMA, we treat that as a bullish signal. If the price is meaningfully below the EMA, we treat that as a bearish signal. If it is close to the EMA, we assume the signal is not strong enough and stay flat.

The calculations might look like this:

should_be_long = price > EMA(price, half_life) + edge
should_be_short = price < EMA(price, half_life) - edge

should_be_long = price > EMA(price, half_life) + edge
should_be_short = price < EMA(price, half_life) - edge

should_be_long = price > EMA(price, half_life) + edge
should_be_short = price < EMA(price, half_life) - edge

There are two trader-defined parameters here:

• half_life: how much history the EMA should remember

• edge: how far price must move away from the EMA before the signal matters

There is also one live market value:

• price: the current market price

Every time the market ticks, price changes. The signals update. The state machine runs again. The strategy gets a new answer to the same question: long, short, or flat?

This separation matters more than it may seem.

If the EMA logic is wrong, you know where to look. If the state transition is wrong, you know where to look. If the strategy is targeting the wrong exposure, you know where to look. You are not digging through one giant blob of trading code at 2 a.m. while an exchange feed is doing something weird.

Good architecture is not about sounding sophisticated. It is about making the obvious thing easy to find when the system is under stress.

Finally, Resolve State Into Target Positions

Once a strategy enters a state, it needs to express what it wants.

At Structure, that expression is a target position.

If the strategy is in LONG, it might target +1 BTC. If it is in SHORT, it might target -1 BTC. If it is in FLAT, it targets 0 BTC.

The state describes the strategy's opinion. The target position describes the portfolio shape that matches that opinion.

This distinction is important because order management is its own problem. Suppose the strategy is currently short and the next tick moves it into LONG. Getting from short to long is not the same as getting from flat to long. One path requires closing the short and then building long exposure. The other just requires buying into the long. If an order partially fills, the path changes again.

You can write all of that yourself. Many teams do. It is tedious, easy to get subtly wrong, and usually not where the alpha is.

So in Structure v1, the strategy author stops at the target position. You define the states and the target position for each state. Structure's executor handles the order work needed to move the connected account toward that target.

That keeps the strategy definition focused on the actual trading idea:

• What data matters?

• What signals should be computed?

• What state should those signals produce?

• What position should each state target?

Everything else is machinery. Important machinery, but machinery.

Why We Do Not Put It All in One Graph

Early versions of Structure were less separated. Data computation, signal logic, state transitions, and actions all lived closer together inside one coherent strategy graph.

It was elegant in the way a very dense whiteboard can be elegant. The pieces were there. The logic was there. But reading it required too much mental stack.

That is dangerous in trading.

Strategies evolve. You learn more about the venue. You discover a fee edge. You realize your signal overtrades. You change a parameter. You add a filter. You test a new market. If the architecture does not make those changes easy to isolate, you cannot tell whether the strategy improved or just changed.

The goal is scientific iteration. A backtest should be reproducible. A parameter change should have a clear interpretation. A live strategy should be auditable. When behavior changes, you should be able to explain why.

That is why Structure separates the anatomy:

• Data and computations produce deterministic signals.

• Signals drive a state machine.

• States resolve into target positions.

• The executor manages the orders required to reach those targets.

This is simple, but not simplistic. The best financial systems usually have this quality. They reduce the number of things you need to hold in your head at once, without hiding the parts that matter.

The EMA Example, End to End

Here is the full mental model for the EMA strategy:

1. Market data arrives tick by tick.

2. The strategy computes an EMA from price.

3. It compares current price to the EMA plus or minus an edge.

4. Those comparisons produce should_be_long and should_be_short.

5. The state machine chooses LONG, SHORT, or FLAT.

6. Each state maps to a target position.

7. Structure executes toward that target position.

That is the architecture in miniature.

The trader spends energy on the part that matters most: whether the signal is any good. Is the EMA useful? Is the edge too tight? Does it overtrade after fees? Does it survive slippage? Does it generalize across venues or only look good in one regime?

Those are good questions. Those are the questions worth spending time on.

You do not want to spend that same brain asking, "Did my cancel replace logic accidentally leave me with double exposure because one callback arrived after another callback?"

That problem needs to be handled. It just should not be mixed into the signal idea.

Why This Matters for Using Structure

As you use Structure, you will see this anatomy everywhere.

The product asks you to define data and computations because signals need to be deterministic and auditable. It asks you to define states because a strategy needs a finite set of possible intentions. It asks you to define target positions because execution should be separated from the trading idea.

This is not arbitrary product design. It is the operating model.

Fully automated trading becomes much easier to reason about when the strategy can be inspected in layers:

• What does it know?

• What does it believe?

• What does it want?

• What position should it hold?

That is the difference between a strategy you can deploy once and a strategy you can keep improving.

Structure is designed for the second kind.

The whole point is to remove boilerplate without removing rigor. We want traders to build, test, and ship strategies faster, but not by turning the system into a black box. The machine should be easier to operate because its parts are visible.

Signals. States. Target positions.

That is the anatomy. Once you see it, the platform starts to make a lot more sense.

Not Financial Advice

The content above is for general educational and informational purposes only. It is not financial, investment, trading, legal, tax, accounting, or other professional advice, and it is not a recommendation, offer, or solicitation to buy, sell, hold, or use any asset, strategy, protocol, venue, or financial product.

Trading and automated strategies involve substantial risk, including the possible loss of principal. Crypto assets and DeFi markets can be highly volatile, illiquid, technically complex, and subject to execution, smart contract, custody, regulatory, and counterparty risks. Past performance, backtests, simulations, or examples do not guarantee future results.

You are responsible for your own decisions. Do your own research, understand the risks, and consult qualified professional advisers before making financial, legal, tax, or trading decisions. Structure does not provide personalized investment advice and does not guarantee any strategy outcome, return, or level of performance.