160,000 Lines Later

In 82,000 Lines of Code Later, we discussed what Plutarc had become across nine exchanges, a full adapter suite, and a set of hard-won lessons about what multi-exchange support actually costs to get right. This post is the follow-up to what a platform becomes when that number has roughly doubled. As of this writing the stack sits close to 160,000 lines — the trading engine, the orchestration layer, the strategy catalog, the backtesting simulator, the dashboard, all of it heavier than it was in April.

I said last time that line count is a poor proxy for quality, and I still believe that. What it is a decent proxy for is scope. Doubling a codebase in three months is not the same activity as writing the first 82,000 lines — the first pass builds the shape of the thing, the second pass argues with it, discovers where the shape was wrong, and rebuilds around the argument. A meaningful share of what follows is exactly that kind of rebuilding, dressed up as new features.

It would be dishonest to write this update without naming the constraint that has sat underneath every decision since the last post. Plutarc remains, for practical purposes, waitlisted for its own general availability. UK KYC restrictions currently close off nine of the ten exchanges the platform supports to a UK-registered account — a fact that was true in April and is still true now, and isn't going to change on any timeline I control. I submitted a Y Combinator application in April hoping partly to solve for that constraint through capital and pace rather than around it. It was rejected on the 5th of June. Neither of those things moved.

What did move is the decision I've made about them. Waiting for exchange access to resolve itself before releasing anything publicly was never actually a strategy — it was a deferral dressed as patience. So the plan now is a public release scoped to what is actually available: BitMEX support alone, shipped once the current testing, debugging, and QA passes are complete, with everything else added back to the roadmap as access permits rather than held as a precondition for launching at all. A platform that works correctly for one exchange and is honest about that is worth more than a platform that waits indefinitely to be correct for ten.

#The Number the Probe Missed

Some findings from a testing period arrive as confirmation. This one arrived as a correction. The pricing page has, for months, quoted a latency probe figure of roughly 50ms from AWS Tokyo to BitMEX — a real number, honestly measured, and also, it turns out, not the number that matters.

The live bot deployed on AWS Tokyo during this testing period told a different story. On the WebSocket hot path, latency sat at 4 to 6ms, stable across heartbeats. Even the REST order path — the one BitMEX actually requires, since it doesn't support order placement over WebSocket — came in around 21 to 22ms, less than half of what the marketing copy had been claiming. The probe wasn't wrong so much as it was measuring the wrong thing entirely: a generic HTTP round trip to a public endpoint carries a TLS handshake and serialisation overhead that a live, authenticated, persistent connection simply doesn't pay.

Once the socket is up, most of what the probe was counting evaporates.

The gap matters beyond the pricing page needing a correction. BitMEX is the one exchange in the current lineup without WebSocket order execution, which means 21ms is close to the floor for that particular integration. Bybit and Binance both support order placement over WebSocket, which means once they're back in the fold post-launch, order execution on those exchanges rides the same 4-6ms channel the market data already does — not just the price feed, the actual trade. That's not a number built to compete with HFT co-location, and it doesn't need to be. It's a number aimed at a prop desk, a systematic family office, or an independent trader who wants execution infrastructure a step above consumer-grade without the overhead of building it themselves. Discovering it was faster than we'd been telling people is the rare kind of surprise worth publishing.

#Toward an Operable Platform

A good share of the last three months went into things that don't photograph well in a changelog but that determine whether a platform can hold more than one person's attention at a time.

Organizations shipped, with five roles and thirty-four granular permissions spanning Owner, Admin, Quant, Risk Manager, and Viewer — the first real acknowledgment that a fleet of trading bots is eventually a team's responsibility, not one person's hobby. Testnet mode followed across all ten exchanges, letting a strategy run against fake funds on an exchange's own paper environment using the identical strategy, analytics, and bot infrastructure as a live key — the only thing that changes is the endpoint, which is exactly how a simulation should behave if you want to trust its result.

Sleep and wake scheduling for bots with defined trading sessions turned out to matter more than I expected. Compute instances deprovision fully between sessions and no charges accrue, which sounds like a minor billing optimisation until you notice what it actually enables — running a bot on a schedule stops being a cost trade-off and becomes simply correct, because the platform now reflects the true footprint of a strategy that only needs to be awake for four hours a day rather than paying for twenty.

Support tickets, reply-via-email, a proper notification preference matrix, and a genuine improvement to how reliably a bot reports its own status, equity, and lifecycle events back to the dashboard round out this category. None of it is glamorous. All of it is the difference between a platform that works when you're watching it and one that works when you aren't.

#Reading the Market's Mood

The most consequential addition to the strategy catalog this cycle isn't a new signal — it's a new category of component that doesn't ask where price is going, only what kind of market it's currently in. Choppiness Index and Bollinger Bandwidth Regime both quantify consolidation directly, and Counter-Trend Veto blocks an entry when the higher timeframe is trending hard against it. ADX and the EMA Distance Guard were both given trend and range modes, so the same component can confirm a breakout or gate a reversion depending on how a template configures it.

The distinction this closes is one that's been implicit in the catalog since launch and only now has proper vocabulary for it. A signal answers "is there an edge here." A regime filter answers "is this the kind of market where that edge is real." Divergence, mean-reversion, and counter-trend entries all share a property that trend-following doesn't: they work in one regime and actively lose in the other, and no amount of tuning the signal itself fixes a filter problem. You cannot parameter-search your way out of asking the wrong market the right question.

#What "Infeasible" Actually Means

The clearest demonstration of that principle shipped as a system template — RSI Divergence, 1-hour regular and hidden divergence entries gated by a Counter-Trend Veto on the 4-hour. The first backtest came back with a profit factor between 0.59 and 0.72, comfortably unprofitable, the kind of number that invites a reasonable person to conclude the signal simply doesn't work and move on. That conclusion would have been wrong, and knowing it was wrong required looking at the trades rather than the summary statistic.

What the chart showed was false-positive entries clustering during strong 4-hour directional moves — the exact regime where a divergence signal has no business firing, because a genuine trend can print higher highs and higher lows on the RSI right alongside price for long stretches before it ever reverses. The signal wasn't broken. It was being asked to answer a question in a market condition where the question doesn't apply.

Adding the counter-trend veto as an entry guard — restricting the strategy to fire only when the 4-hour was consolidating, which is where divergence actually means something — brought the profit factor to roughly 1.1 to 1.12. Tuned and validated on BTC across a full seven-month, multi-regime window, that settles out to a profit factor near 1.1 and an 8% max drawdown net of fees. It's a real edge, on the right instrument, in the right regime, and it is meaningfully weaker off BTC — marginal on DOGE, close to breakeven on ETH, weaker still on higher-volatility alts like SOL. The template ships knowing that, rather than pretending an edge is universal because it once was.

There's no fixed take-profit anywhere in this template, which is the design decision that tends to draw the most questions. A break-even stop caps the downside and a trailing stop lets a winning trade run for as long as the trend continues, which means the strategy's profitability is entry-dependent by construction rather than target-dependent. That's a deliberate trade against the comfort of a fixed number, made because a fixed take-profit on a mean-reverting entry inside a consolidating regime caps exactly the trades that are most likely to keep working.

The broader lesson generalises past this one template, and it's the reason the RSI Divergence config earns a section here rather than a line in a changelog: a failing backtest is genuinely ambiguous between two very different diagnoses — no edge, or a real edge deployed in the wrong regime — and the default metrics a backtest reports cannot tell you which one you're looking at. Profit factor, win rate, and expectancy all describe the outcome. None of them explain the mechanism. You have to go looking for the mechanism yourself, on the chart, trade by trade, before you're entitled to conclude a strategy is infeasible rather than merely unfiltered.

The same session that produced this template also produced a second lesson about the catalog itself: components should decompose to the smallest independently meaningful condition rather than bundling logically separate behaviours into one. A compound RSI component that mixed divergence detection with exhaustion detection got split into a pure RSI Divergence signal and a separate RSI Exhaustion guard, growing the catalog from 48 to 53 components in the process. A strategy builder is only as expressive as its smallest unit, and a bundled component quietly forecloses combinations that a decomposed one leaves open.

#Guardrails and Loose Ends

Every strategy now requires at least one protective stop — a Hard Stop Loss, a Break-Even Stop, or a Chandelier Exit — before the builder will let it save. It is a small constraint with an outsized effect: it is no longer possible to construct and deploy a strategy with no defined downside, which was previously possible and is exactly the kind of thing that should never have been possible in the first place. Alongside it, the trailing stop on the trend and momentum system templates was retuned to lock in gains earlier, so a profitable move is less likely to round-trip all the way back to breakeven before the stop finally catches it.

A handful of visibility fixes matter more in practice than their size suggests. Mid-flight changes to a bot's active asset list now show up in the activity feed. A rejected leverage or margin-mode setting from the exchange — previously silent — now surfaces as an explicit activity entry rather than an unexplained gap in behaviour. A bot whose strategy needs a candle interval the exchange can't serve now stays online and flags the problem instead of simply failing to start. And the Update button, which had quietly stopped appearing on bots that were offline or errored, now shows up where it should, so a bot that failed to start can actually be updated to a newer version in place rather than requiring a full redeploy.

IP whitelisting also got a clarifying note rather than a feature: each bot uses a single reserved static IP for exchange API key whitelisting, and that IP is stable across restarts, updates, and sleep/wake cycles. It's the kind of documentation gap that costs someone an hour the first time they hit it and costs nothing to close.

#The Fast Clock

The strategy catalog was, until this cycle, built almost entirely around a candle-close paradigm — a component evaluates once a candle finishes, which is a fine assumption at an hourly or four-hour cadence and a much worse one once you're trying to scalp. Fast-timeframe support now runs the full interval ladder from 1 minute to 4 hours, with trend, momentum, volatility, and mean-reversion components each carrying their own supported-interval menu configurable per component in the template editor. Funding and open-interest components stay hourly, which they should — funding doesn't update on a one-minute clock no matter how fast you ask it to.

Two new components exist specifically for this end of the spectrum. Micro Momentum is a fast short-EMA slope tuned for low-timeframe entries. Fast Volatility Gate blocks entries when short-window realised volatility sits outside a workable band, updating on the same fast timescale as the entries it's guarding. Per-strategy controls for trigger interval, entry cooldown, and exit-ATR interval mean a single template can now run anywhere from a slow swing cadence to a genuine scalp without needing a separate architecture for each — the same catalog, evaluated on a different clock.

#The Vault

The last significant change this cycle isn't a platform feature at all — it's a change to how the platform gets built. Development documentation for Plutarc, and increasingly for the rest of the Valeon stack, now lives in a single Obsidian vault synced across every device I work from. Architecture decisions, design rationale, open issues, diagnostic principles like the regime-mismatch distinction above — all of it gets written down as it's discovered, not reconstructed afterward from memory or from old chat logs.

The part that actually changes the day-to-day is that the vault is always available as context for every session with Claude. A design decision made in March doesn't need to be re-explained in July. A principle distilled from debugging one strategy template is there, fully formed, when the next template runs into the same failure mode. The vault is doing something a codebase's comments and a project's changelog can't do on their own — it's holding the reasoning, not just the result, and making that reasoning portable across however many sessions it takes to get somewhere.

It's a small infrastructural decision by the standards of everything else in this post. It may end up being the one that compounds the most.

#One Live Footnote

Building all of this doesn't exempt you from forgetting it in the moment that matters. Last week the BitMEX bot went long for the first time, entirely on its own — no override, no manual trigger, just the strategy doing what it was built to do. I didn't trust it. I placed a tight stop underneath the position because something about the number felt wrong, which is to say a private, undocumented instinct overrode a signal I had, at that point, spent several years and 160,000 lines building a discipline around. The bot, unbothered by my feelings, tried to add to the position — its logic reading continuation, not warning. I stopped that too, and then spent the rest of the day convinced I'd caught a genuine bug, going through logs looking for the fault.

There wasn't one. The invalidation criteria never fired because there was nothing to invalidate. By evening the price had moved comfortably into the bot's favour, exactly where the entry logic expected it to go. Somewhere between forty-eight strategy components, a regime-mismatch diagnostic, and an entire section of this post about not trusting a summary statistic over a mechanism, I still managed to out-instinct the one system built specifically to be more disciplined than I am. The bot knew. I didn't. There is, at some point, probably a component for that too.