The Books: Paper, Pilot, and the Wallet as Truth

Why this chapter exists

NightWatch does not only publish a rating and ask you to trade on it. It runs its own money through the same pipes, at small scale, under the same rules an outside trader would face. That is the platform's credibility claim in one sentence: our own fund trades on the same grades every day. This chapter explains how that fund actually works, book by book, and the honesty machinery built after a real incident showed that a fund's own reported numbers cannot simply be trusted at face value.

A note on audience before you read further: this chapter is written for the operator's own understanding of how the fund's plumbing works, not as public-facing marketing copy. The platform's public surfaces (the /thusus page and similar reader-facing views) anonymize exchange venue names to codes rather than showing names like Bithumb or bybit directly. This chapter uses the real venue names throughout, on purpose, because the operational detail (which exchange, which API limitation, which incident happened where) is the point of an internal explanation like this one.

Read this if you want to know how much weight to put on any number describing the fund. Several books are paper (simulated) and several are real money, and the newest piece of this system exists specifically because a real wallet balance and the fund's own reported ledger disagreed with each other.

Several separate books, never blended by accident

NightWatch runs more than one trading book at once. Each book is its own pot of capital (simulated or real), its own start-and-stop periods called epochs, and its own ledger. None of them get folded into each other silently, and one of them is built to never be folded in at all.

The Multi X Book deserves a specific warning: its profit and loss is never merged into the fund's main number, and nothing in the system ever folds it in. Robin's own instruction (2026-09-03) established this rule, because folding its results into a bigger pool would hide how constrained its fixed $10,000 of paper capital actually is. Its five headline numbers (APY on total capital, APY on deployed capital, layers open, liquidation premium, and participation rate) must appear together, so publishing only the flattering ones cannot misrepresent the strategy's real constraint.

Three carry books, three different honesty problems solved in code

Multi X is a three-leg, intra-exchange calendar-basis carry: the coin itself is posted as native collateral, a short position is taken in the coin-margined (inverse) perpetual, and a matching long position is taken in the coin-margined dated future, all on the same exchange and the same coin. It exists because an earlier internal trial found real defects: funding could be fabricated, rebalancing could be keyed to a call counter instead of real conditions, and so on. The engine and its "runner" (the part that actually talks to exchanges) are split into two pieces on purpose: a decision-logic core with no network calls, no database access, no clock reads and no randomness, so its behavior can be tested exactly, and a separate runner that owns the messy real-world I/O. The split means the fixes for the earlier defects are checked as pass/fail tests against the pure logic, not just described in a document.

Torii Carry learned a similar lesson the hard way. Its predecessor (Epoch 2, opened and shut down within an hour on 2026-09-02) carried six named defects the current test suite checks against by name, including fabricated funding, a rebalance rule keyed to a call counter rather than real time, and an APY published after only 0.64 hours of data. Epoch 3, running today, exists to close all six. Its universe is five venues (Hyperliquid, bybit, binance, gate, mexc), and the engine evaluates every ordered pair of them, shorting whichever side of the pair is paying less funding. It also separates realized funding (money actually collected) from unrealized basis (a mean-reverting price gap that has not yet closed), never blending the two, because a fund reporting basis as if it were funding is reporting a number that can evaporate. Venue names in the book's own public payload are anonymized to codes since 2026-08-30, consistent with the platform's public-surface rule, even though this chapter names them plainly for operational clarity. An earlier version also annualized a one-time entry fee, producing a nonsensical -112% headline; that bug is fixed in the current version.

HYPE Carry goes furthest on refusing to guess. Because Hyperliquid pays perp funding in USDC rather than in the underlying coin, there is no coin-denominated funding leg to reconcile, which removes one whole category of arithmetic error the other books have to guard against. It was chartered on 2026-09-11 as the unified paper book's fifth book, an independent $10,000 dry run, with the unified paper book's base rising from $40,000 to $50,000 to make room for it; every fill in it is a paper fill priced at an observed touch, and no order is ever sent. Its publisher enforces five explicit "tile laws," and Law 5 is the interesting one: nothing the published tile states may disagree with its own underlying source data, a check named tile_consistency. If that check fails, the publisher raises an error rather than emitting a page that contradicts itself. Law 4 sets a fixed waiting period: net APY is withheld for 168 hours (one week), with the elapsed hours and the threshold both shown on the page, so a reader never sees an annualized number extrapolated from a few hours of data.

Watching without spending: the shadow trackers

Before NightWatch puts real money into a strategy, it often watches the strategy first with zero capital at risk. The Won-Carry Shadow Tracker records every Korea-premium or discount opportunity the scanner surfaces, then re-prices it after a realistic transfer delay to see whether the edge would have actually survived the trip. It deliberately never recomputes the scan logic itself, only reading the live API over HTTP, so it cannot silently drift out of sync with what the real scanner saw.

The Hedged-Arb Shadow Tracker is labeled "shadow" but was, according to a 2026-07-18 fund-wiring audit, the busiest thing in the live book: that audit found roughly 45 of the last 60 real trades in the Korea fund were hedged Bithumb buys, versus 6 won-carry trades. It exists to test whether hedging an arbitrage position at the expensive venue recovers the roughly 61% of edge that an unhedged transfer window destroys. That figure comes from a 2026-07-18 audit and has not been re-measured since; treat it as a snapshot of mid-2026 activity rather than a current claim. The Lending-Arb Shadow Tracker watches a separate opportunity (borrow on Bithumb, sell into the premium, buy back cheaper, repay in kind) with no execution and no lending-API writes at all, purely observational.

Real money: the six-stage cycle and the humans it needs

When NightWatch actually trades with real capital, it does so through a fixed six-stage state machine: T0_RECHECK -> BUY_KRW -> WITHDRAW_TOKEN -> ARRIVAL_CONFIRM -> SELL_USDT -> SETTLE. The names describe a Korea-premium round trip, but the same stage names cover both directions (buying the discount side and selling into the premium side) with the meaning of each stage flipped depending on which way the trade runs.

Live trading with real capital runs under close guard: a cycle can be halted mid-stage instantly, leaving it marked stuck for a human to resume by hand, and only one cycle is allowed to be "running" at a time. A resumed cycle continues from its own id and re-checks whether a stage was already completed before ever repeating a real buy or a real withdrawal, so a crash mid-cycle cannot cause a duplicate trade.

The Stage0 Driver is what watches for fresh signals and starts these cycles automatically, but it makes a point of not making any judgment calls itself: sizing and entry decisions belong entirely to the cycle's own T0_RECHECK stage. Stage0 only presses the button, and it does so by launching the cycle as a separate subprocess rather than importing it directly into its own process, specifically so a crash inside one cycle cannot take the whole automated loop down with it.

The Global Pilot runs the same real-money discipline on cross-exchange transfer routes (bybit to gate, gate to binance). Its original design sized cycles at roughly $50 across ten pilot cycles; the sizing policy in force today is larger and more nuanced, set by knowledge-graph rules read by the pilot engine: a $350 cap on any single cycle, and a separate $70 floor-adjusted cap (the greater of 20% of $350, or $50) on any cycle where no perp is available to hedge the position. Its rule on hedging is not optional beyond that cap: if there is no perp available to hedge a candidate at all above that ceiling, the candidate is skipped outright rather than executed unhedged.

That hedging discipline exists because of a real incident. On 2026-08-30 the pilot bought $300 of a token called EGL1 on gate and moved it to KuCoin, where the destination order book could only absorb a small fraction of the position, so the sell attempt returned a filled amount of $0.00 and the cycle was marked complete at roughly -100%. A pre-check already existed for thin order books on the buy side; nobody had checked the sell side's depth at all. The position was not a total loss: after nearly four hours unattended, a human noticed and manually routed it back through gate, recovering $295.13 and leaving the cycle's actual final loss at about -$5.17. The fix now requires the destination's order book depth within 1% of the best bid to be at least three times the sell size, and the destination's 24-hour trading volume to be at least twenty times the sell size, before a trade is entered. Both rules are read from the same knowledge-graph facts by both the pilot engine and the live-cycle engine, through a shared module, so the two engines' judgment of safe liquidity can never drift apart.

A forensic follow-up (2026-08-31) found three further gaps in what happens if something goes wrong anyway: a documented $50 cap on unhedged position size that had been silently overridden to $300; a Telegram alert path that could fail silently with nobody able to tell; and the sell described above returning zero filled volume yet still being marked complete, leaving the position unattended for nearly four hours until a person noticed. All three were closed: the unhedged size is now clamped before it reaches the order call, failed alerts on any loss over $10 retry automatically, and a fill under half the intended size, or a loss worse than 20%, now marks the cycle, triggers an emergency liquidation attempt at the destination, and sends a confirmed alert rather than letting the cycle sit silently marked complete. The pilot's automatic execution remains paused; restarting it is reserved for Robin.

Bithumb has no working withdrawal API, so a human taps a button

One real constraint shapes an entire piece of the pipeline: Bithumb's API has no working authenticated withdrawal path (verified through six failed attempts), so a human has to trigger that one step by hand through Bithumb's own web interface. The Semi-Auto Trade Alarm Bot is designed to make that single manual step as safe as possible: the moment a won-carry candidate is armed, it is meant to alert a human on Telegram, with two hard timeouts guarding against a missed tap: an armed alert expires after 90 seconds unanswered (no loss, since no purchase happened yet), and a purchase not followed by a visible withdrawal within 5 minutes triggers an automatic resale to recover the position. The flow itself is built, and it is explicit that it does not fire real orders or real alerts on its own; whether it is actually running live is a standing decision left to Robin.

The wallet is truth, the ledger explains

On 2026-08-30, three numbers describing the same fund disagreed with each other: a published trade-only index read 102.04 (up 2.0%), the internal ledger showed $2,992 of assets, and a direct read of the actual wallets showed $3,069. Rather than pick whichever number looked best, NightWatch changed which number counts as ground truth. The wallet balance became authoritative, and the ledger's job changed from stating the fund's value to explaining how it changed.

The NAV Sweep worker performs a read-only, single-point-in-time balance check across every fund account and wallet, applying five correctness rules: it accounts for sub-wallets, removes duplicate counting, excludes deposit-only addresses, excludes a personal (non-fund) holding of Robin's that sits in a fund-adjacent exchange account, and prices each holding from a live venue price, preferring Binance and falling back to the holding exchange's own price, and then a Bithumb KRW-market conversion, in that order. This table is now what the fund's own reconciliation reads first. Its read-only discipline is stated plainly as policy ("READ-ONLY, no order/withdraw/transfer calls"), and in practice it only ever reads a balance, never sending an order, withdrawal, or transfer call.

The NAV Bridge (GET /arb/thusus/nav_bridge) turns two wallet readings on two dates into an explanation. Every dollar of change is attributed to a named line: profit from live arbitrage cycles, profit from pilot cycles, transfer fees, foreign-exchange fees converting won to dollars, valuation changes from exchange-rate movement, leftover unsold tokens, and hedge funding not already counted in a settled cycle. Whatever remains is shown as its own line, unexplained, never hidden inside another category. The target is that this residual stays under $2 per week, and a bigger gap is shown in red rather than smoothed over.

Two real gaps were found and closed this way. Completed real-money cycles were not automatically reaching the fund's ledger; the Fund Events Auto-Loader now pulls each newly settled cycle in as soon as it finishes. And the actual fee paid on each inter-exchange transfer had never been recorded, even though the transferred amount was; the Fund Transfer Fee Auto-Loader closed that gap after an audit found it explained a significant part of a $139 discrepancy between a displayed index of 101.8 and a reconciled 87.9.

The published headline number is also changing as a result. The old index tracked trading performance alone; the new one is a time-weighted return on NAV with deposits and withdrawals removed, so a reader sees investment performance rather than a number that moves whenever new money enters the fund. The old index does not disappear; it is demoted to a technical sub-chart. Consistent with the platform's rule against rewriting history, past published numbers are never recalculated when the method changes; only the label changes, with the boundary date marked.

One caveat on how consistently this labeling actually reaches the reader today: an internal page-map audit of the fund's own display surface found that its Trade Log rows and its headline summary figure did not always describe the same scope of data (one epoch's worth of trades displayed under a different epoch's headline), so "check which book and which period a number belongs to" is advice worth following on that page specifically, not just a general caution.

A preview of a future product: Mandate Vault

/torii/vault shows something called the Mandate Vault (named Smart Vault before 2026-09-16), and it is worth naming exactly what it is today: a read-only preview built entirely from data sources that already exist elsewhere (the Thusus paper fund's performance, the shadow Quartermaster capital allocator, and curator signal track records). There is no wallet connection on this page and no way to deposit; nothing behind it lets you actually put money into a vault. Not in this version; planned for v1.2. The honest label matters here: it is a preview composed only of real numbers, not a mockup of numbers that do not exist.

Facts recorded, causes classified, rules written down

Behind all of this sits a repeating discipline: when a real trade settles, its outcome is classified into one of a small number of causes (a slow blockchain transfer, a predicted profit that turned out to be a phantom, entry or exit slippage, an adverse hedge move, or unattributed), and the resulting rule is written into the knowledge graph as a fact rather than hardcoded as a constant. The live cycle engine reads those same facts at decision time, so a lesson from one incident becomes a gate the next cycle has to pass, not just a note in a document nobody rereads. Two rules in force today: a transfer over 15 minutes is treated as a slow chain (based on 42 real cycles: under 15 minutes averaged +0.34% realized, over 60 minutes averaged -0.92%), and any predicted profit above 2.0% is capped as suspicious, based on a trade where an 8.32% predicted edge turned into a -1.98% real loss.

What you can do now

• Before treating any fund number as final, check which book it comes from (paper or real capital) and which period it covers; the fund's own display page has a documented history of headline and detail rows describing different scopes.
• Read the NAV Bridge waterfall (via the fund book page) to see exactly which lines explain a period's change in fund value, and check whether the unexplained line is small.
• Do not treat the Multi X Book's numbers as part of the fund's overall size; by design they are reported separately and never merged.
• Treat /torii/vault (Mandate Vault) as a dashboard of existing numbers, not as a place you can deposit into - that's planned for v1.2, not in this version.
• If you see a headline "index" number, check whether it is the older trade-only index or the newer NAV-based time-weighted return; they answer different questions.
• The Global Pilot's automatic execution is paused today; restarting it is a decision reserved for Robin.