Six Dollars of Proof

There's a number I keep returning to, because it's smaller than it has any right to be: six dollars. That's the total cost, in exchange fees, of catching, confirming, and fixing five separate bugs in the code that stands between a strategy's decision and a real order landing on a real exchange, across five separate sessions, against real capital that would sting a little to lose but never enough to worry about. The account is still funded from the twenty it started with. It shouldn't be possible to buy that much certainty that cheaply, and the fact that it is says less about frugality than about what verification actually requires once you stop mistaking rigor for expense.

In Three Adapters, One Wire I described the wire — the discipline of trusting only what an exchange actually sends over its actual endpoints, never what its documentation claims it sends. The wire tells you what an adapter can talk to. It doesn't tell you what happens once a bot built on top of that adapter is actually running, evaluating a fast clock, opening and closing positions under its own logic rather than under a researcher's careful, one-at-a-time prodding. For that you need a different kind of instrument, and the one I built has no interest in making money. That was never its job. It exists to open a position, close it again almost immediately, and repeat that as many times a minute as the fast clock allows, across five assets held concurrently — one position per asset, each cycling on its own clock, up to five open at any given moment rather than one — until every logical path the bot can take has actually been taken, live, on mainnet. It carries a time stop tuned so short that a position rarely lives long enough to develop an opinion about direction at all, which is why almost every one of those six dollars was a fee rather than a loss the market inflicted. The strategy was built to fail in small, cheap, frequent ways rather than to succeed occasionally and expensively, and cheap, frequent failure turns out to be a far more efficient teacher than the alternative.

The first thing it found wasn't subtle. A position that should have closed and reopened instead kept growing — the same side, entered again and again, silently merging into one position that ballooned to six times its intended size before anyone noticed, because the guard meant to stop exactly that kind of runaway growth was blind to the specific way the merge was happening. It's the kind of bug that looks catastrophic in the abstract and is almost always caught in a single afternoon once you're actually watching it happen, which is precisely the point of watching.

The more interesting failure wasn't one bug. It was two, in two different parts of the system, each one quietly standing in front of the other. The first lived in the bot itself — a position, once closed, left behind a marker that was meant to be temporary and never actually cleared, so the second time that same position closed, the bot silently ignored it. Fix that, and a strange thing happens: a close that used to be swallowed now actually fires, travels somewhere it never used to reach, and lands on the wrong record entirely, because the dashboard carried its own long-standing assumption that a position only ever closes once. Two bugs, and for a long while the first had been unknowingly protecting the second from ever being seen. Trading software has no special claim on this; it's a general property of layered systems that a fix doesn't just resolve a problem, it can also expose the next one standing directly behind it, and the only way to learn how many layers there actually are is to go through them one at a time, in production, under conditions real enough to matter.

A quieter lesson showed up in how the bot handled its own stop orders. Several times, an exchange-side trailing stop did exactly what it was supposed to do — filled, closed the position, worked correctly — and the bot's own bookkeeping treated that success as a failure, because the order it went looking for afterward was already gone, and "already gone" and "something went wrong" had been coded as the same condition. I wrote, last time, about my own reflex to assume the bot was wrong before checking what had actually happened. It turns out the code had inherited that exact reflex. An outcome that isn't the one you were braced for doesn't automatically mean the outcome was bad, and teaching a system to tell the difference between something that failed to happen and something that already happened correctly, without needing you, mattered more this round than any single flashier fix.

By the fifth session, the fast clock's core claim — that a signal gets evaluated on precisely the cadence it's configured for, second after second, asset after asset, without drifting or skipping a beat — had been exercised so many thousand times over that it stopped being a question I was watching for. That's a different kind of proof than any of the bug fixes above: an absence rather than a repair, the thing that never once broke across five sessions specifically engineered to break everything they could reach.

What did eventually break was something none of the earlier sessions had gone looking for, because none of them had pushed hard enough to find it. Push a fast clock far enough — enough assets at once, tight enough a cadence — and you stop testing the bot's logic and start testing the pipe that logic talks through. An audit of roughly nine thousand exchange calls from a single session found a pattern hiding in plain sight: a meaningful share of that traffic was asking, on every tick, for numbers the exchange was already broadcasting continuously on an entirely different channel — funding rate, open interest, figures that barely move from one second to the next, fetched fresh every second anyway because nothing had ever told the adapter it didn't need to ask. The fix became a standing principle, one that now applies to every exchange the platform talks to rather than just this one: anything an exchange is willing to stream should be read from that stream, and polling gets demoted to what it should have been from the start — a fallback exercised only when the stream itself turns unhealthy. A REST call firing during normal operation is itself a confession that something upstream isn't doing its job.

Across the five sessions, at its fastest, the strategy managed something like twenty to thirty round trips a minute on a single bot — open, close, open again — none of it meant to be profitable, all of it meant to prove the fast clock evaluates exactly as fast as it claims to. Worth being precise about where that number actually came from, because the honest answer isn't that the exchange wouldn't let us go faster. It's that our own design was spending its rate-limit budget on work that had no business costing a REST call in the first place — the funding, open-interest, and reconciliation traffic described above, asked for on every tick instead of read off the stream it already lived on. The exchange's actual ceiling was never reached, because a self-inflicted one sat well in front of it. Call twenty to thirty a floor, then, observed under conditions that hadn't yet been optimised, sitting somewhere well below whatever the architecture can actually sustain now that the streaming work from this round has moved that self-inflicted ceiling out of the way. The expectation now is that the number moves, and moves upward, because the part of the system that was actually holding it back has just had a meaningful amount of slack put back into it.

Six dollars bought five sessions' worth of exactly the kind of proof an audit can't provide on its own — proof that the logic behaves correctly while it's actually running, repeatedly, under conditions where being wrong costs something real, however small. The next adapter in the queue already has its own wire, built the same disciplined way the first three did, and there's no reason to expect it will need to relearn any lesson this round already paid for. The ceiling on how many exchanges I can personally validate with real money hasn't moved an inch this week. What's changed is how much confidence now sits underneath the ones already past it, and confidence of that particular kind was never going to come from believing the code was right. It comes from watching it be right, over and over, until believing it stopped being necessary.

There's a particular satisfaction in all this that never quite made it into any of the findings above, and it deserves its own sentence rather than getting lost underneath five sessions' worth of fixes. By the fifth run, watching the dashboard had stopped feeling like debugging and started feeling closer to theatre — five assets running at once, one position live on each, closing clean on one while another opened a beat later on a different asset entirely, the whole board in quiet, continuous, five-part motion, every one of those motions matching something equally real happening on BitMEX's side at the exact same moment. There's nothing technically impressive about a screen doing what a screen is supposed to do. But watching a week's worth of accumulation guards and phantom fixes and stop-order corrections stop being findings and start being a rhythm — five positions opening and closing in place, correctly, without me needing to hold my breath through any of it — is its own kind of proof, one that doesn't show up in an audit or a call count. It's the difference between knowing a system works and getting to just sit there, for a few quiet minutes, and watch it.