Episode 3 of 3: Boros Trading Bot Verdict: No Edge Survived Realistic Costs
Here is the short version.
on this page
Here is the short version.
The Boros protocol was real.
The automation stack was real.
The edge did not survive.
After the full comparative pass, the repo-level answer was clear:
- Boros is technically valid
- Boros is automatable
- the currently tested strategies are too thin
- real-money deployment is not justified
That is the end of the Boros trading story, at least for now.
Series navigation: Episode 1 | Episode 2 | Episode 3
The final comparison
Here is the short version.
This was the shared scorecard under the strict realism framework.
| Strategy | What it was testing | Base-realistic net | Out-of-sample net | Classification |
|---|---|---|---|---|
carry_mean_reversion_v2 |
Boros-native fixed-vs-floating carry compression | -22.2679 bps |
-10.9869 bps |
kill the strategy |
external_relative_value_v1 |
Boros execution with external fair-value references | -61.4167 bps |
-28.3126 bps |
not viable |
funding_rate_baseline_v1 |
benchmark carry idea outside Boros-native pricing logic | -128.9692 bps |
-31.8165 bps |
not viable |
The least bad result was the Boros-native carry trade.
It was still negative.
Why the main Boros strategy failed
The original Boros carry idea was the fairest test of the protocol.
If Boros was going to justify systematic attention, this should have been the place:
- fixed rate on one side
- floating realization on the other
- explicit maturity
- a clean mean-reversion story
Instead, the strategy ran into three problems.
1. The sample got too small
Under the final strict run, the lead carry strategy only produced 4 base-realistic trades.
That is already a warning.
A tiny sample can support a story. It cannot support conviction.
2. The edge flipped sign
The attractive early read was about 3.91 bps of modeled edge per trade.
After realistic delay, spread, slippage, and exit friction, the strict result landed at -22.2679 bps.
That is the important transition.
The strategy did not just get weaker.
It stopped being positive.
3. Size did not rescue it
No tested size from 1 to 500 turned the carry strategy positive under the base-realistic profile.
That matters because it means the failure is not just about scaling up.
The edge was already gone before scale even became the hard part.
Why external data did not save it
A fair objection to the first result was this:
maybe Boros was not the problem, and the internal fair-value model was too weak.
That is why the project added external_relative_value_v1.
The idea was simple:
- still trade on Boros
- use outside market data as a pricing reference
- see whether a broader market view makes the trade more robust
It did not.
The strategy finished at:
-61.4167 bpsbase realistic-28.3126 bpsout of sample
That does not prove Boros can never host a good strategy.
It does show that adding external information did not rescue this one.
Why the benchmark also failed
The benchmark mattered because it tested a different question:
was Boros the problem, or was the whole local carry idea weak?
The funding-rate baseline was supposed to answer that.
Instead, it came back even worse:
19base-realistic trades-128.9692 bpsbase realistic-31.8165 bpsout of sample
That is useful because it sharpens the conclusion.
The current story is not:
“Boros is uniquely broken.”
The current story is:
“This nearby opportunity set looks weak once realistic execution is applied.”
That is a better and more honest negative result.
What the flat paper trader really meant
The forward paper trader told the same story in the most boring way possible.
It mostly stayed flat.
The suite snapshot showed:
43signals0positions0trades0orders
That is not inactivity.
That is a refusal.
The system kept watching live state, scoring signals, and rejecting trades that did not clear the calibration guard.
The main rejection reason was exactly what you would hope to see:
calibrated_edge_non_positive
That is not disappointing.
That is trustworthy.
What this means for Boros
If you want the plain-English answer, it is this:
Boros was worth researching.
Boros was worth simulating.
Boros was not worth deploying capital on.
At least not with the strategies tested here, under the assumptions that should matter in the real world.
What would need to change before Boros matters again
I would only revisit Boros as a serious trading target if several things changed at the same time:
- strict backtests turn positive after realistic costs
- out-of-sample results stay positive
- forward paper starts taking trades for the right reasons
- capacity stops being trivial
- the edge survives a longer and more varied history
- operational dependency risk stops dominating a tiny edge
Until then, the right stance is not “maybe later if I tweak it.”
The right stance is “move on.”
Research & Code
If you want the technical layer, that is where the repo is still valuable.
Start here:
reports/boros/REALITY_CHECK.mdreports/boros/EXECUTION_REALISM.mdreports/boros/FORWARD_VALIDATION.mdreports/boros/STRATEGY_LANDSCAPE.mdresearch/boros/reviews/SKEPTIC_REVIEW.mdsrc/ai_homelab_ops/boros/
The reusable lesson is not “copy this strategy.”
It is “build a system that is willing to kill your favorite idea.”
What we’re exploring next
The broader project is still alive.
What changes next is the target.
The better hunting grounds are likely to be:
- earlier market structures with less competition
- event-driven setups with clearer catalysts
- venues with deeper execution data
- protocols where capacity is large enough to matter
The Boros chapter ended with a no.
That is fine.
A clean no is how you make room for a better yes.