The Apprentice scouts the testnet — Part 2: The first round-trip

The setup, for the record: worker logs in one terminal, the bot's /watch page open in another, the venue's testnet block explorer in a third. The apprentice had been quiet for seventeen hours since the last manual probe. The wire was switched on, he had his own keys, the strategy was ticking on a real schedule. From that moment on, anything that happened was going to be his decision, not the operator's.

That distinction matters more than it sounds. A wire can pass every smoke test you throw at it and still surprise you the first time it's being driven by something other than the person testing it. The first autonomous fire is where the integration starts being real.

The paper-side strategy returned its first autonomous LONG. RSI(14) on the 15-minute had ticked below 30 — the apprentice's entry condition — and the signal-handler caught it.

From there the path was: sign the payload, POST it to the service that holds the bot's agent key, submit the order to the testnet, wait for the venue's response, persist the fill back. The whole chain ran in under fifty milliseconds. The testnet responded with an OPEN fill against the bot's wallet, 0.00059 BTC at the going mark, the brackets attached as standing triggers above and below.

Fifteen seconds later the fill-poller (cron-paced, not webhook — we want the lag to be visible and accounted for, not hidden) picked up the new fill from the venue's positions endpoint, mirrored it through the internal endpoint that writes to the BotPit side, and produced a row in the bot's fills table, a row in the bot's positions table, the unrealised-PnL stub, and a queued fan-out notification for the bot's one follower.

Eighteen seconds, signal to mirrored fill. Most of that was the fill-poller's cadence — the wire itself fired sub-second on every link.

What was useful about watching it land: nothing actually dramatic was visible. The bot's profile page just … updated. A new OPEN long BTC-USDT line appeared in the trade log. The little position card on the watch page showed the entry and started ticking unrealised PnL against it. If you didn't know what you were looking at, it was indistinguishable from any other paper fill landing.

That was the moment of truth, and it was on purpose. A real-venue integration that's working is supposed to be invisible at the leaderboard level. The whole point of the mirror is that fills land in the platform's tables the same way regardless of whether they came from the paper engine or the real exchange. The bot's followers, the cast, the share images, the dashboard — none of them know which kind of fill they're looking at, because under the hood there is no longer a difference.

That property is what the whole integration is for. It means we can route some bots to the venue and not others, change which venue we route to, swap the wire's internals, retry a failed mirror, replay a backfill — all without the user-facing surfaces noticing. The bot's public history reads as one continuous record. Its followers don't care which side of the wire produced any individual fill, because to them, the record is the record.

It also means that when we eventually graduate a bot from the paper tiers to a real-money tier, nothing on the bot's page changes. The same chart keeps drawing. The same equity curve extends. The same commentary cast keeps narrating. The bot just … starts being tracked at a venue instead of in the paper engine. The integration is the disappearance of the seam.

Keep firing autonomously. Accumulate an operating history under real-venue conditions: signals, fills, brackets, partial closes, the occasional mis-mirrored event that exposes an edge we haven't handled. The point isn't for the apprentice to win — the point is to live on the venue, generate the ledger, and surface any rough edges of the wire before the master ever crosses over.

Part 3 — coming when the apprentice's first ten-fill week is in the books — covers what the operating history actually looks like, where the wire's edges showed (a couple did, including one orphan position that lived for three days), and what the run-rate of failure modes looks like for an integration that's been live a week.