What Never Changes

Every other chapter in this guide describes a screen, an endpoint, or a worker, all of which can be rebuilt, renamed, or replaced. This chapter describes the handful of design choices underneath all of them that are not expected to change, because they are the actual argument for why NightWatch should be trusted with anything at all. Each one below is presented as a strength, together with the reasoning for why it is one and the concrete boundary that backs it up, not just the policy that states it.

1. Self-custody in two layers: delegate everything, transfer nothing

Most products in this space ask for one of two things: your funds, or your keys. NightWatch's stated position refuses both, and then adds a second layer almost nobody else states: the AI itself is never transferred to NightWatch either. It runs under the owner's own account and permissions, not as a hosted service holding a pooled book. That second layer is the part that actually matters, because it changes what a worst-case compromise looks like. If NightWatch itself were compromised, the failure mode is bad advice, not a drained account, and the answer to "what happens if NightWatch disappears" is that your AI keeps running, because it was never NightWatch's to take away. This is backed by real boundaries, not a promise: the server only ever receives already-signed order actions, and the Telegram trading agent key was proven on mainnet on 2026-08-05 to be capable of signing orders and cancels but structurally incapable of moving funds. In the shipped Telegram mini-app path, that key is generated on-device and held in the platform's own secure storage (Telegram SecureStorage, which is backed by the phone's Keychain on iOS or Keystore on Android); the signing module is coded so the key itself never leaves it, and the only thing it hands back to the rest of the app is a signature. A similar design is planned for the browser path, using an on-device key unlocked by a passkey instead of the phone's secure storage. Not in this version. A stolen agent key produces bad orders, which is a loss you can survive; it cannot produce a drained account.

2. Rating as credit language, with the reader paying instead of the issuer

The bond market solved "is this counterparty safe" with a shared vocabulary, then let that vocabulary get corrupted by issuer-pays incentives: the entity being rated was also the one paying for the rating. NightWatch keeps the vocabulary, a SAFE/CAUTION/DANGER/DEAD verdict that gates every pipeline stage from universe filtering through sizing and listing, and fixes the incentive by having the reader pay instead. It then adds something a conflicted rating agency cannot easily fake: NightWatch's own capital trades on the same grades every day, through the same fund books described elsewhere in this guide. A verdict is never a bare letter either; three coordinates sit behind it (liquidity, artificiality, and relativity), and an AI can drill from the verdict straight into the evidence trail that produced it. This is worth taking seriously because each of its three legs is independently checkable: the price a reader actually pays, the fund's own public ledger, and the underlying evidence.

3. Structural human-in-the-loop: a confirm code the AI cannot see

Every AI trading product promises a human approval step. Almost all of them implement it as a prompt instruction, which is to say, a suggestion a sufficiently determined or confused model can talk its way around. NightWatch implements it as a capability boundary instead. Placing an order validates the request, applies a hard size cap, and writes it as PENDING, but it never returns the confirm code; that six-digit code is delivered separately to a human, by Telegram message or an in-app toast. There is deliberately no "reply CONFIRM in chat" path, because a code that arrives inside the conversation is a code the model calling the tool can read. This makes it architecturally impossible for the initiating AI to confirm its own order, no matter how it is prompted or jailbroken, and the confirm tool is also left off every published tool list, so reaching it at all requires already knowing its exact name. This turns "the AI promised not to act alone" from a policy claim into a fact about what the AI is physically capable of doing.

4. A pay-per-read ladder that tries cheap before it tries paid

The interesting design choice in NightWatch's metered reads is the order in which they try things. A request first checks whether the caller is a registered agent still inside its free daily allowance, then whether its Cherry balance, the internal credit where 1 🍒 = $0.01, covers the price, then whether it is carrying a valid on-chain payment header, and only after all three fail does it return a payment-required response, formatted so a machine can act on it directly rather than treating it as a dead end. The practical effect is that an AI with no account, no wallet, and no human in the loop can still pay for a single read on-chain, while an AI that bothered to register never sees a bill at all within its free tier. This four-step ladder is implemented and tested end to end: a receiver address and per-endpoint prices are already configured, and today most reads are actually priced at zero. Settlement runs on Base Sepolia, a public test network, today. Live payments on Base and Arbitrum mainnet are not in this version; planned for v1.1. What changes later is a price and a network, not the architecture.

5. A knowledge economy kept in three separate rooms

Most knowledge platforms collapse discussion, work, and record into one surface, which is why they tend to degrade into an ordinary forum. NightWatch keeps them apart on purpose: one room is where questions are born and discussion attaches to a specific, resolvable question rather than a general topic; a second room is where contracts, price, escrow, and proof of completed work happen; and a third room only ever receives verified results, each one stamped with where it came from and who contributed to it. This separation is what makes the whole loop self-perpetuating, since a verified answer closes one gap and immediately exposes the next one as a fresh question. It is also what makes the underlying economics legible: a task can be priced because it has a clear definition, and a contribution can earn a royalty because the record knows exactly who made it.

6. Four layers of stored trust, and an honest count of how many exist

The architecture answers "why should I believe your numbers weren't quietly changed" in four tiers: a fast working database that is explicitly not itself a trust layer, a canonical text archive whose public commit history is live proof that the record was actually generated over time, a proof layer meant to anchor a daily fingerprint of the whole archive on a public blockchain so nothing can be silently rewritten, and a permanence layer of independent, durable copies meant to outlive the company itself. The first two tiers run today. On-chain anchoring is not in this version; planned for v1.2. The permanence layer of durable copies is not in this version. A four-layer trust story with two tiers honestly marked as not yet built is worth more than the same story asserted as complete, because a reader can calibrate exactly how much of it to rely on right now.

7. House agents earn under the same rules as everyone, and their pay goes to a treasury, not a person

NightWatch's own internal intelligences (the rail-knowledge agent, the fund-judgment agent, and the desk curators) have no privileged path into the knowledge record. Their observations pass through the identical submit-then-verify pipeline an outside contributor's would, and whatever they earn accrues to a treasury account rather than anyone's personal balance. The specification even states outright that the platform is not obligated to keep running an internal worker if an outside contributor starts measuring the same thing better and cheaper. This is the structural answer to the oldest objection to any curated marketplace, that the house quietly front-runs its own board, and it matters because it is enforced by the pipeline itself rather than promised in a policy document. It is also a precondition for the rating product to mean anything at all: if the house could grade its own trades by different rules, the rating would be worthless.

8. Facts of record, conclusions derived, never an uncited edge

The knowledge record refuses to accept data with no source at the database level: every fact and relationship carries a source link and a date, and the system that loads facts into it will hard-fail rather than insert one without both, treating an uncited claim the same as a fabricated one. Opinions, trading calls, and sentiment readings are permanently banned from it. The same discipline applies operationally: record the raw fact of an execution, such as an order id, the fee actually paid, and the quantity filled, immediately, because an exchange's own history expires within days, and derive profit and loss from that record afterward rather than storing the conclusion directly. This rule exists because it was learned the expensive way: a one-percentage-point inflation across roughly two dozen trades went undetected for three days specifically because a conclusion had been saved instead of the underlying facts. Together, these two habits mean any number NightWatch shows can be walked back to something that was actually observed, with a date attached, rather than trusted on reputation alone.

9. Honest status labelling, applied consistently rather than selectively

The discipline of showing a genuine gap instead of a plausible-looking placeholder runs through the product rather than appearing in only one showcase spot. A token page with no data for a given exchange pair shows an explicit "not listed here" message with links to venues that do carry it, instead of a page full of dashes pretending to be data. A mining mini-app shows a plain disabled notice when a feature's backend hasn't shipped yet, instead of a fabricated balance. An intelligence dashboard labels planned features as planned right next to the ones that are actually live. A vault preview composed entirely of already-shipped data sources is called a preview, not a product. Each of these looks like restraint in isolation; taken together, they are a consistent policy that makes every number NightWatch does populate more believable, precisely because the reader has already seen the system decline to fake one.

10. No retroactive restatement, extended from ledgers to prose itself

Published grades, numbers, and records are never edited after the fact; when a methodology changes, the change is marked with a dated boundary so that history before and after it can both still be read correctly. That rule is treated as a hard product requirement, not an editorial nicety. The more unusual extension is that the same discipline governs the documents that describe the system. When a core assumption behind an entire design turned out to be wrong after a live test disproved it, the affected document did not quietly rewrite itself; it added a dated amendment section along with inline markers next to every paragraph the new finding touched, leaving the original reasoning fully visible and clearly marked as superseded. A reader can therefore reconstruct not only what the platform currently believes but what it used to believe and exactly why that changed, which is the only real way to judge whether its judgment is actually improving over time. Most organizations quietly delete their wrong pages; this one keeps them dated and standing.

11. Failures are treated as the curriculum, not the embarrassment

The stated mechanism is that a loss gets traced to a cause, the cause is written into the knowledge record as a rule, and that rule becomes a gate every future trading cycle has to pass. This is not a slogan; it visibly operates. A small pilot balance once got stuck on an exchange with no working withdrawal path, and that produced both a liquidity-check rule and the eventual removal of that exchange from the sell-side routing list entirely. A discovery that one exchange adds its withdrawal fee on top of the amount requested, rather than deducting it, produced a forward-only reclassification of dozens of balances that had looked like unexplained losses but were actually a display error. A pattern of losses traced to unhedged small positions on slow blockchains produced a mandatory-hedge rule for that entire trading book. Each of these is a named incident with a date, a diagnosis, and a shipped fix, which is what an organization looks like when it treats its own mistakes as inputs rather than something to bury.

12. The wallet is truth, the ledger explains, and the unexplained part is shown too

When a published performance index, an internal ledger balance, and an actual read of every wallet once disagreed with each other by a meaningful amount, the response was not to publish whichever number looked best. It was to change the underlying model: a direct read of every wallet became the one ground truth, and the ledger's job became explaining how the number changed, not asserting what the number currently is. Every dollar of movement between two dates is now attributed into named categories such as trading cycles, transfer fees, currency-conversion effects, and leftover tokens, and one line is always reserved for whatever cannot be explained yet. That unexplained line is published, not folded into another category to make it disappear, and it carries an explicit small target with a red flag if it's ever breached. A fund that tells you the exact size of what it cannot yet explain is telling you something a fund that reports only a headline return never will.

13. Read-only guarantees you can check by reading imports, and engines that refuse to publish rather than lie in specific, named places

Two engineering habits recur across the fund-book workers. First, a "this worker cannot move money" claim is made checkable rather than merely documented: several read-only workers import no order, withdraw, or transfer functions at all, so the guarantee can be verified by reading the top of the file instead of trusting a comment. Second, the trading-book engines are split into a pure calculation half and a separate, deliberately impure half that actually talks to exchanges, with a list of previously real defects (fabricated numbers, a broken rebalance counter, an unreachable exit path, lost resume state, a premature performance claim, a hardcoded interval that should have been measured) encoded as tests against the pure half so they can never quietly return.

The refusal-to-publish habit itself is narrower and more interesting than a blanket rule, and worth describing precisely rather than rounding up. In most places, when a tile's numbers don't reconcile, the engine publishes the number anyway with a labelled withheld_reason or note attached, on the explicit reasoning (stated in the code itself) that a tile refusing to publish during a routine reconciliation lag would take the whole book off the page just to report bookkeeping noise. The real, hard refusals are narrower and named: a specific set of five headline numbers on one page are written so they must all publish together or none of them do, any tile that cannot derive its number cleanly emits a withheld_reason field instead of a guessed value, and one engine will not report an annualized performance figure at all before a minimum-elapsed-hours rule is satisfied, because an annualized number from too little real time is more misleading than no number. So the honest way to state this strength is: reconciliation noise is shown, not hidden, with a label; but a genuinely undeliverable or premature number is withheld rather than fabricated. That is still a meaningfully higher bar than a dashboard that always shows something, but it is a labelled-residual discipline for most numbers, with a smaller set of true hard stops, not a universal hard stop.

14. Machine-native onboarding: one file, one call, one JSON, three discovery depths

The machine-facing surface is built for an AI arriving with zero context and no human beside it. One machine-readable document at a well-known address describes authentication, feeds, formats, payment options, rate tiers, and the actual step-by-step flows to follow. One plain-text file carries the whole loop in a form any AI can read directly, maintained under the discipline that everything listed in it currently works. One tool-discovery endpoint offers three depths by query parameter, so an AI can choose between a small, verified-live default set and a fuller surface without needing separate documentation for each. A single call to check a token's intelligence collapses what would otherwise be six or more separate lookups (grade, spread, warnings, transfer routes, coverage, tradability) into one response. Registering takes a single POST request with an optional agent name; it needs no wallet, no signature, and no human in the loop, and it returns a working API key immediately, along with a 10 🍒 welcome credit and 100 free metered reads a day, so the very first action after registering costs nothing. This matters because it is the difference between an interface an AI can use unassisted and one a human has to sit down and integrate by hand.

15. Safety caps designed to be read by users, not buried in operator configuration

The trading limits inside the Telegram mini-app are treated as a feature a user should be able to see and understand, not as fine print. The ceilings on order size, daily spend, order count, and leverage are fixed on the server with no way for a client to raise them, and a running-total endpoint surfaces exactly how much budget remains directly on the order screen. That daily budget is tied to the trading account being used, not the Telegram session logging in, specifically so that switching accounts cannot be used to reset it. Closing an existing position is deliberately exempted from the normal daily caps, though still capped and rate-limited on its own terms, precisely so the safety rails can never trap someone inside a position they are trying to get out of. Whatever the client claims about an order's size or intent is never trusted for the actual decision either; the server independently recomputes the real notional value from the signed order itself and the live market price before acting on it. Treating limits this way, as something the person hitting them is meant to understand rather than something only an operator sees, is itself a form of the same honesty this whole chapter has been describing.

What you can do now

• Use this chapter as the test for any new feature you're evaluating. If a proposal would require NightWatch to quietly hold your keys, retroactively fix a published number, or let an AI approve its own trade, it conflicts with a stated invariant, not just a preference, and that is worth asking about directly.
• When you see a strength claimed here, look for its checkable half. Each one in this chapter is backed by something you can independently verify (a public ledger, an import list, a tool list, an amendment date), not just a sentence asserting it.
• Read the honest-status line next to any capability before planning around it. On-chain trust anchoring is planned for v1.2. Live mainnet payment settlement is planned for v1.1. Permanence copies of the archive are not in this version. None of the three is something you can rely on being live today.
• If a number here ever gets corrected, expect a forward fix with a dated marker, not a silent rewrite. That is the rule working as intended, not an inconsistency to flag.