Skip to content

1. Introduction

1.1 Why this exists

Dio is open-source financial infrastructure. It is MIT licensed, the image is public, and the source is on GitHub with no approval step and no gatekeeping. The parts of trading that are hard are engineering problems: sizing capital so a strategy survives real drawdowns, handling order state correctly across fragmented venues, and keeping capital accounting honest when many positions share one balance. These are worth solving once and carefully, and the solution should be available to anyone who wants to trade.

There is a second reason for open source that matters just as much. Trading systems carry a great deal of hidden risk. Position sizing logic, order handling, and failure behaviour are usually invisible to the person whose capital is at stake. Publishing the system means the decisions can be read, questioned, and checked by anyone. A strategy run on this engine can be examined the same way the engine itself can.

This is an early release. The version series is pre-1.0, which signals that the interfaces may still move and the vocabulary will keep growing.

1.2 The problem

Much of retail trading assumes that volatility is a problem to be forecast around. Conventional approaches take a directional view, which requires continuous market analysis and accurate execution to be worth doing, and imposes a cognitive and emotional load that most participants cannot carry.

The specific failure Dio was built to address is the stop-loss. It is the most common piece of risk machinery in retail trading, and it carries a structural defect: it is triggered by price, at a moment chosen by whoever set it, which converts a temporary decline into a realized loss and forces a sale at the worst available moment. The usual remedy is to apply it more tightly, which produces more frequent and equally mistimed exits.

Dio takes the opposite position. A survivable decline calls for holding capital sized to absorb it. That single decision shapes most of what follows in this document.

1.3 Design goals

The engine was built against seven goals. Each is stated here with the section that addresses it, so a reader can tell which parts of the following material are load-bearing and which are supporting detail.

  1. Survive drawdowns without stop-losses. Conventional risk control sits at the order level and fires on price. Dio moves it to the sizing layer: capital is allocated so a strategy cannot exhaust before funding a large fraction of the worst decline the asset has ever actually produced. See section 3.1.

  2. Separate capital decisions from order execution. A sizing brain decides whether to trade and at what size. An executor places orders. Neither second-guesses the other, and the boundary between them is a four-field contract. See sections 3.1 and 4.2.

  3. Let a strategy be a file. Trading behaviour should be something a person writes and the engine loads. Adding a strategy is a configuration change. See section 4.

  4. Run one engine across any liquid instrument and any venue. The oracle derives its references from each asset's own price history, and behaviour lives in a bound script file, so nothing is tied to a particular asset class or a particular exchange. See sections 3.1, 4, and 6.

  5. Operate without continuous supervision. Each asset runs in an isolated domain, the oracle is health-monitored and restarted automatically, and accounting state survives restarts. See section 3.4.

  6. Hold assets directly by default. The core ladder holds fully backed spot inventory. Venue derivatives are optional and isolated to overlay strategies, with explicit collateral reservation, live position/margin monitoring, and reduce-only risk stops. Funding and liquidation risk are managed explicitly rather than assumed away. See section 6.

  7. Make the system inspectable. No hidden state, no second copy of a value, and no decision a reader cannot trace to the code that made it. See sections 3.1 and 4.2.

What the engine won't do is as much a part of the design as what it will. It makes no directional predictions, adds no hidden leverage, and does not rely on market orders to get filled. The default strategy places explicit limit orders; an overlay chooses its own order type and collateral policy.

1.4 Approach

Dio implements these goals by giving a strategy a realtime price, the state of the engine, and a sizing decision, then executing whatever the strategy asks for within the capital that sizing has committed. Orders are placed at configurable price intervals by rule, so a position can profit from movement in either direction without a directional call. Most algorithmic systems bolt on stop-losses to limit downside; Dio treats volatility as an opportunity to accumulate.

Beyond active trading, accumulated positions can support compounding returns where the underlying asset pays yield, whether through dividends, coupons, staking, or lending. That is a portfolio decision the operator makes alongside the engine, and section 2.5 explains why the sizing and execution paths stay independent of it.