One Winning Trade, Two Broken Bots: What an Overnight ETH Test Really Revealed

*Thinking...*

> **Revising article for clarity**
>
> I need to rewrite an article that's moderately long for Substack, using the original link provided by the user without additional research. It's essential to avoid any assumptions or misinterpretations in the phrasing and deliver around 1000 words with a distinct title and clear structure. I want to ensure I maintain the central details while keeping it engaging, producing a summary rather than detailed pseudocode. I'll aim for a clear and concise piece that might stretch up to about 1100 words.

# One Winning Trade, Two Broken Bots: What an Overnight ETH Test Really Revealed

### Three Ethereum futures bots passed qualification despite negative backtests. One earned $41.50 in paper trading. The more important story was everything that happened around it.

A trading bot makes money overnight. Its entry fires, its exit works, and the dashboard turns green.

That feels like progress—and it is.

But progress toward a functioning trading system is not the same as evidence of a profitable strategy.

During an overnight paper-trading session from **6:00 p.m. on September 24 to 9:30 a.m. on September 25, 2026**, three automated, long-only CME Ethereum futures bots were put to the test.

One completed a winning trade worth **$41.50**. The other two never traded: one suffered from missing market data, while the other struggled with gateway disconnections.

All three had passed a qualification process. All three also had negative historical backtests.

The [original analysis from The Order Book Edge](https://www.theorderbookedge.com/p/the-dislocated-alpha-of-overnight) explores that apparent contradiction. Its most useful lesson is straightforward:

**A successful trade can show that a bot works mechanically without showing that it has an edge.**

Here’s what the session revealed—and what still needs proving.

---

## Three Bots, One Completed Trade

The overnight results were:

| Bot | Result | Operational finding |
|---|---|---|
| `bar_eth_long_20260914_194814` | No trades | Market-data gaps |
| `bar_eth_long_20260918_012747` | No trades | Rithmic gateway disconnections |
| `bar_eth_long_20260924_104027` | One win, +$41.50 | Completed the trading pipeline |

These are not three comparable strategy results.

They are **one trading observation and two infrastructure findings**.

The inactive bots did not demonstrate that their trading rules were bad. They demonstrated that the systems supporting those rules were not reliable enough to evaluate them.

The profitable bot cleared that first hurdle. Whether it can make money consistently remains unanswered.

## The Shared Strategy: Slow Signals, Faster Execution

All three bots use the same event-driven foundation, built around a shared base class called `RedisEventDrivenTradingBot`.

Redis delivers completed market bars. The bots update their indicators and respond to those events rather than continuously polling for changes.

Their defining architectural choice is a separation between two clocks:

- **The signal timeframe** determines whether a trading opportunity exists.
- **The execution timeframe** determines when a pending entry can be acted on.

The article describes three possible pairings:

| Signal bars | Execution bars |
|---|---|
| 10 minutes | 2 minutes |
| 15 minutes | 3 minutes |
| 30 minutes | 5 minutes |

The intention is to combine slower signal formation with more frequent execution opportunities.

That distinction matters: the faster execution clock does **not** discover a crossover before the slower signal bar closes. It provides a separate schedule for acting once a signal has been confirmed.

### What triggers an entry?

The bots look for a **9-period EMA crossing above a 21-period EMA**, subject to two gates:

1. At least **20 completed signal bars**.
2. A **momentum score of 40 or higher**.

A crossover means an actual transition from below to above—not simply that the fast EMA is already higher than the slow EMA.

Once the conditions pass, the bot sets a pending-long flag and waits for an execution-bar close. Only one position is allowed at a time.

The momentum formula itself is not disclosed in the article. Its example calculation is illustrative, not a verified implementation.

## The 6:1 Bracket Is a Design Goal—not a Realized Payoff

The exit structure is deliberately asymmetric:

- **Stop:** one Average True Range below entry.
- **Target:** six Average True Ranges above entry.
- **Additional exit:** a bearish EMA crossover.
- **Account safeguard:** forced liquidation and a trading halt at 15% drawdown from peak equity.

In an idealized system where every winner earns 6R and every loser loses 1R, the before-cost breakeven win rate is:

**1 ÷ (1 + 6) = approximately 14.3%.**

That sounds attractive. A strategy could lose frequently and still break even.

But the qualification is crucial: **the calculation assumes the stated payoffs actually occur.**

These bots can exit early on a reversal. A winning trade might earn much less than 6R. Fees, slippage, and execution problems also change the outcome.

The useful question is therefore not:

> Does the bot have a 6:1 target-to-stop ratio?

It is:

> What does the bot actually earn or lose per unit of initial risk, after costs?

That requires a trade history, separated by exit reason—not just bracket settings.

## The Entry Price Deserves an Audit

The execution model uses the midpoint of the completed execution bar as an entry reference:

```text
reference_price = (bar.high + bar.low) / 2
```

A reference price is not a guaranteed fill.

By the time the bar closes, the market may already be above that midpoint. A market order would execute at available prices. A limit order placed at the midpoint might remain unfilled.

This is particularly important for a long strategy entering after bullish momentum: a simulator that automatically grants midpoint fills could make its results look better than executable trading would justify.

Before treating the $41.50 as robust evidence, the trade needs an execution audit:

- What order type was simulated?
- Was the assumed entry price available after submission?
- Were fees and slippage included?
- Did the exit reach the target or close on a reversal?
- How were bars touching both stop and target handled?

**Paper-trading P&L is only as credible as the fill assumptions behind it.**

---

## The Two Inactive Bots Exposed the Bigger Problem

### Missing bars mean unreliable indicators

For the first bot, market-data gaps interrupted the strategy before it could trade.

Missing bars can distort EMA values, omit volatility information from ATR, hide crossovers, and delay warmup.

The appropriate response is not to continue as though the missing observations never existed. The system needs to detect the gap, backfill and replay the missing bars, or reset its indicators and warm up again.

Until that happens, apparently valid signals may be based on incomplete history.

### Disconnections create more than missed opportunities

The second bot struggled with its Rithmic gateway connection.

A disconnection can interrupt data, prevent order routing, and leave local position records out of sync with the broker.

The most serious concern is an open position whose protective orders exist only inside the bot. If connectivity disappears, locally managed protection may become ineffective.

That makes reconnect reconciliation essential: check actual positions, inspect working orders, restore missing protection, and rebuild indicator history before resuming entries.

**A reconnect should trigger verification—not an automatic return to business as usual.**

## Warmup Makes Restarts Expensive

The 20-bar warmup requirement has very different consequences across timeframes:

- **10-minute signals:** 3 hours, 20 minutes.
- **15-minute signals:** 5 hours.
- **30-minute signals:** 10 hours.

A cold-started 30-minute bot beginning at 6:00 p.m. would not finish warmup until roughly 4:00 a.m., assuming uninterrupted bars.

Repeated restarts could consume much of the overnight test window.

There is also an initialization detail to resolve: the warmup threshold is shorter than the slow EMA’s 21-period length. Whether that is workable depends on the implementation’s seeding and historical-data handling.

The broader lesson is that recovery design affects both reliability and the amount of usable trading evidence collected.

## Why Qualification Is Not Proof of Profitability

The article reports that all three bots qualified despite negative backtests, but it does not disclose the actual qualification thresholds or weighting.

We therefore cannot establish precisely why they passed.

Qualification might assess software health, configured risk controls, or suitability for continued testing. None of those automatically establishes positive expected returns.

The defensible interpretation is:

**These bots may have qualified as experiments. They have not been demonstrated to be profitable trading systems.**

Even that distinction needs operational discipline. Configured stops and drawdown guards are not enough if missing data or connectivity failures prevent them from working as intended.

## What Does the $41.50 Actually Tell Us?

The winning trade is evidence that one bot completed a trading cycle against live market data in paper mode.

That is useful.

It is not enough to distinguish a profitable strategy from a breakeven or losing one. All three can produce an isolated winner.

The article offers a rough estimate of approximately **200 trades** to distinguish a 20% win rate from an idealized 14.3% breakeven rate using a simple standard-error calculation.

That is a useful illustration—not a universal validation threshold. Actual confidence also depends on realized payoffs, trading costs, dependence between trades, and changing market conditions.

The next milestone should not be another screenshot of green P&L. It should be a sufficiently large, auditable record of net returns.

## What Should Happen Next?

A sensible validation sequence follows directly from the session:

1. **Repair the infrastructure.** Detect missing bars, backfill history, and reconcile positions and orders after reconnects.
2. **Audit execution assumptions.** Test realistic fills, costs, and conservative handling of ambiguous stop/target events.
3. **Collect more paper trades.** Record initial risk, realized R, exit reason, execution details, and system health.
4. **Evaluate net expectancy.** Decide whether the evidence supports further testing, a redesign, or retirement.

Position sizing also belongs in that process. A one-ATR stop specifies a price distance—not how much account equity is at risk.

---

## The Bottom Line

The overnight session produced **one profitable paper trade and two operational failures**.

The encouraging finding is that one bot completed the intended trading workflow. The unresolved question is whether that workflow produces positive returns after realistic costs over a meaningful sample.

Those are separate achievements, and they should stay separate.

**First establish that the system can be trusted to execute its rules. Then establish whether those rules deserve capital.**

For the detailed architecture, pseudocode, and bot-by-bot breakdown, read [The Dislocated Alpha of Overnight Crypto Futures on The Order Book Edge](https://www.theorderbookedge.com/p/the-dislocated-alpha-of-overnight).

🔥 Curious about strategies like this? Explore our Python Crypto Futures collection for ready-to-use trading bot code.

*This post discusses paper-trading research, not a recommendation to trade. Automated futures trading carries substantial risk of loss.*