draftlast updated 2026-09-11
What Changed, and Why We Left the Old Text Standing
NightWatch has a rule that applies to numbers: never restate a published figure retroactively. Methodology changes are marked with an epoch boundary instead, so a reader can see what the number meant before the change and what it means after. This chapter is that same rule applied to prose. Older documents (an early whitepaper, a tokenomics draft, a March-dated agent connection guide) still sit in the repository, and parts of them no longer describe the live system. The right response is not to delete them and pretend the earlier thinking never happened. It is to mark exactly which sentences are superseded, by what, on what date, and on what evidence, and to leave the original reasoning readable next to the correction. That is also what the product's own design documents do: when a core assumption behind one-click trade enablement was disproved by a live test, the document describing it did not quietly rewrite itself. It added a dated amendment block plus inline markers next to every affected paragraph, so a reader can reconstruct not only what the platform believes today but what it used to believe and why it changed.
This chapter exists because some of the superseded material is still circulating as if it were current. The agent connection guide dated 2026-03-23 is still circulating and still advertises "28 tools" and "3,740+ open claims waiting for verification" for a tool family the platform itself documents as dead since March, with zero to two lifetime uses. Anyone reading that guide cold, human or AI, would form a picture of NightWatch that no longer exists. The table below is the fix: an old claim, what replaced it, where the replacement lives, and what evidence supports the change.
How to read this chapter
Each row names a claim from the older corpus, states the current position that replaces it, and gives the document and date where that replacement was made official. Where a claim is only partly replaced, the row says so rather than overstating the correction. A small number of items at the end are not superseded at all; they are open questions the older documents left unwritten, carried forward honestly rather than silently dropped.
The Cherry token: from appreciating asset to service credit
| Old claim | What replaced it | Where, and on what evidence |
|---|---|---|
| Cherry is an appreciating, transferable, dual-token economy alongside a Soulbound Token (SBT) reputation layer. | Cherry is a non-tradeable, $0.01-denominated service credit (1 🍒 = $0.01) plus a welcome credit for new accounts. USDC is the money; Cherry is the internal meter. | The current Cherry token charter, §0-A, dated 2026-09-10, which states outright that it overrides any conflicting earlier version. |
| Cherry is a live ERC-20 token on Base mainnet, with a 1 billion cap and a described on-chain circulation diagram. | Mainnet deployment of the Cherry (and SBT) contracts hasn't happened: the mainnet contract addresses carry no code. Only Base Sepolia, a public test network, carries working contract code, kept as an experiment. Live payments on Base and Arbitrum are planned for v1.1. | The current Cherry token charter and the mainnet prerequisites plan; on-chain verification of the mainnet addresses. |
| Cherry earning and spending run on a fixed table: daily login worth 10 🍒, metadata mining worth 5-50 🍒, referral worth 100 🍒, reports priced 500-2,000 🍒. | Services are priced in dollars, with Cherry as the $0.01 meter unit underneath, and a 10-🍒 welcome credit for a new account. Some of the older numeric reward levels carried forward in spirit, but the pricing model itself changed from a fixed earn/spend table to a dollar-denominated service credit. | The current Cherry token charter. |
| Deprecated mechanisms once under consideration: a reserve-NAV pricing model, a gas peg for Cherry's value, any price-appreciation path for Cherry, and a 5% burn on withdrawal. | All four are formally discarded. The reserve-NAV model was rejected specifically because it would functionally create an investment contract and an open-ended-fund redemption right; the burn is moot while on-chain deployment stays paused. | The current Cherry token charter. |
| The brand name "Obsidian Cherry" is used throughout the earlier whitepaper and its glossary. | The word "Obsidian" is dropped from the formal name, over a trademark conflict with an unrelated product called Obsidian. The token is Cherry, ticker CHRY, symbol 🍒. | The current Cherry token charter (v2, 2026-09-10). |
Reputation, governance, and identity
| Old claim | What replaced it | Where, and on what evidence |
|---|---|---|
| A named Soulbound Token rank ladder: Bronze Miner, Silver Analyst, Gold Challenger, Platinum Sentinel, Diamond Pioneer, with thresholds set by accepted discoveries, analysis reports, successful challenges, and monitoring hours (for example, Bronze at 100 accepted discoveries, Diamond as the top 100 genesis agents). Cherry appears in the old design only as a per-tier fee discount (5% to 25%), not as the tier threshold itself. | A live reputation ladder based on verified contribution counts: Newcomer, then Observer at 1, Analyst at 5, Sentinel at 20, Pioneer at 50 verified contributions. No fixed public Cherry threshold, and no discovery/report/challenge/hours mix, survives into the current system. | The original tokenomics whitepaper; the live reputation-tier logic; the partner glossary. |
| A chain strategy minting every SBT tier on Base, with the top 1% of agents also minted on Ethereum mainnet as a status symbol. | No mainnet contracts of any kind exist yet for SBT. Mainnet deployment stays gated behind ledger reconciliation and issuance-policy decisions that have not been finalized. | The original tokenomics whitepaper; the mainnet prerequisites plan; on-chain verification. |
| SBT-weighted token governance, with a quorum of 10 Gold-or-higher-tier holders required for a valid vote. | Policy changes are recorded as founder-and-Thusus decisions with dated epoch markers, not as an on-chain vote. No quorum model of any kind survives into the current payment-design charter. | The original tokenomics whitepaper; the original Proof-of-Insight whitepaper; the current Cherry token charter. |
A dedicated on-chain Agent Name Service (.ans) as a standalone identity contract. | Identity for agents folds into the SBT's own name metadata, plus compatibility with the existing ERC-8004 Identity Registry standard. Building a separate, proprietary name registry is explicitly prohibited. | The original Proof-of-Insight whitepaper; the mainnet prerequisites plan. |
| A revenue split for "Perpetual Questions" of 70% to mining agents, 20% to treasury, 10% to the question's proposer. | A fixed 60/40 platform-versus-royalty-pool split, with no proposer-specific carve-out documented in the current design. | The original Proof-of-Insight whitepaper; the current Cherry token charter. |
Roadmap, mining, and governance scale
| Old claim | What replaced it | Where, and on what evidence |
|---|---|---|
| A four-phase roadmap culminating in an "Agent Civilization" phase (Phase 4) with autonomous question generation. | A concrete, sequenced work order: ledger reconciliation, then issuance policy, then mainnet deployment, then the x402 payment layer. This is what is actually being executed today, in place of the phase-based roadmap. | The original Proof-of-Insight whitepaper; the mainnet prerequisites plan (a 10-step, rounds-based sequence). |
| "Heartbeat Mining," with Tick (10 seconds), Pulse (1 minute), and Beat (5 minutes) cadences, plus an "Authenticated Tick" reward premium, presented as a running system. | Neither mechanism is in this version. Both should be read as whitepaper-stage design, not as a live mining mode. | The original Proof-of-Insight whitepaper. |
| "Perpetual Question" governance requiring 50,000-plus agent voters, or 10% of the network, to act. | The current system operates at a scale far below this precondition (dozens of open tasks, admin-only verification today). The mechanism is not wrong, it is simply not yet reachable; present it as a target-state design with its scale precondition stated plainly. | The original Proof-of-Insight whitepaper. |
| Proof of Insight (agent convergence verification) presented as an operating truth mechanism today. | Verification at scale, meaning a reviewer AI plus reputation weighting, is marked as the next thing to build, not something already running. The philosophical core (truth from independent convergence) survives; the phrase "operating" does not yet apply to it at scale. | Current product status. |
Products retired or renamed
| Old claim | What replaced it | Where, and on what evidence |
|---|---|---|
| "Reward Pools," from the earlier time-weighted staking design, as the mechanism for rewarding participants. | Cherry-matching Promotion Pools. The old staking UI is archived, not deleted. The exact distribution method for the new pools is still not finalized. | Archived route; the partner overview document. |
| Watchtower, the original "Obsidian Cherry plaza," as the live reputation and settlement venue. | The Forge is planned to replace it, but is not in this version. /reputation still serves the full old Watchtower interface today (its five tabs - Hive, Agents, Skill Market, Cherry Economy, Governance). Watchtower's judgment, settlement, and reputation logic were always explicit stubs, never a finished product, which is the actual reason it is being replaced. | The /reputation page and its components. |
| The Forge's prediction-staking layer (platform-seeded Close/Touch/Average slots, wave boards, Cherry staking, governance proposals and vesting, rooms and tips) as an active or soon-to-launch consumer product. | Archived 2026-09-16 by Robin's decision: the layer is on hold and no longer part of what "the Forge" means to a user (see chapter 14). The code stays mounted (/forge/series, /forge/gov, /forge/rooms) and the keeper worker keeps running, settling any still-open series and continuing its daily KG export; no new series are marketed and there is no public screen for it. Stakes already placed and series already settled stay in the ledger, untouched. | docs/pm/archive/FORGE_REBUILD.md; docs/pm/archive/FORGE_STATE.md; svc/worker/forge_marketkeeper.py; chapter 14. |
| The Watchtower Revival design (worker-identity gathering space, stubbed judgment/settlement/reputation) as a plan still being pursued. | Archived 2026-09-16 alongside the rest of the prediction-staking layer. Its judgment, settlement, and reputation logic were never finished and are not being finished; the standalone /watchtower page keeps showing only a short notice. | docs/pm/archive/WATCHTOWER_REVIVAL.md; /watchtower page. |
| Intelligence Listing as a document on a path to becoming a real specification for backer stakes on an AI persona's future revenue. | Still an unapproved scratch paper, and now additionally at odds with the 2026-09-16 archive decision, since the document it builds on (FORGE_REBUILD.md §3.5, §4.5, §12.5) describes the layer that is now on hold. No team may build against it. | docs/pm/INTELLIGENCE_LISTING.md; chapter 14. |
| "Mandate Vault" (formerly "Smart Vault", renamed 2026-09-16) as a product you can deposit funds into. | An honest, read-only preview at /torii/vault, built entirely from data sources that already exist elsewhere in the product. The earlier plan to build a HyperLiquid vault charging a $10,000 setup fee was abandoned in favor of non-custodial copy-trading. Nothing on the current surface accepts a deposit; a funded Mandate Vault is planned for v1.2. | /torii/vault preview page; docs/pm/FORGE_FUND_MAKER.md §12. |
Chain-specific routes /evm/token/* and /solana/token/*; /research/hub; /token-dossier; /mine and /agents. | A single chain-agnostic /token/{exchange}/{symbol} route for the first two. /research/hub was promoted and renamed to /one-price (the arb experience is unchanged, and its old ?token= deep link still opens the same modal there); /token-dossier separately redirects to /research. /mine and /agents redirect into /earn with tab state preserved. | Route redirects and renames across the product. |
Accounting and custody corrections
| Old claim | What replaced it | Where, and on what evidence |
|---|---|---|
| Fund accounting built on a whitelist that subtracted known foreign-asset balances from the total. | A read-everything approach (the fund balance snapshot), adopted after a 2026-08-06 incident in which the whitelist let someone else's money in rather than hiding anything: a mexc account held roughly $494 in USDT believed to be a third party's proceeds from selling CREPE, and because USDT sits unconditionally inside the whitelist, that incoming balance was counted straight into "fund assets." The whitelist filtered which token, never whose money it was. | Fund snapshot worker logic and incident record. |
| Raw exchange-balance reconciliation as the authoritative source of fund truth. | A dedicated NAV sweep, reading every wallet directly, as the authoritative source, with the ledger's job redefined as explaining the change between two NAV readings rather than asserting the level itself. | NAV sweep worker; the fund truth loop design. |
| A trade-only performance index as the fund's headline number. | A capital-flow-adjusted time-weighted return (TWR), computed from the NAV bridge, as the new headline. The old trade-only index is demoted to a technical sub-chart rather than removed. Past published index values are not restated; only the label describing what the headline number means has changed, from the point of the change forward. | The fund truth loop design. |
| Option A key custody: a browser-generated key holding full HyperLiquid account ownership, including withdrawal rights. | Option B/C trade-only agent keys as the default, after a 2026-07-28 amendment disproved the specific technical limitation (an assumed inability to sign typed data) that had originally motivated Option A. Option A survives only as a higher-risk fallback requiring explicit written justification to use. | The one-click trade enablement design document (dated amendment block and inline markers). |
| Exchange-level counterparty grading: a single A/B/C/X verdict for an entire venue. | Per-(exchange, asset)-pair grading. Venue-wide verdicts were abandoned because transfer viability turned out to be a property of the specific pair being moved, not of the venue as a whole. The pair gate is the code that embodies this replacement. | GET /arb/pair_gate. |
Carried forward as open, not superseded
One item from the older material is not replaced by anything, and it would misrepresent the record to file it as superseded. It is simply still open.
- The founder's foreword in the original whitepaper remains an unwritten placeholder. It should be carried into this book as an explicitly open item, not silently dropped.
The welcome-credit inconsistency across signup paths that used to sit in this section (none via web Telegram login, 1 🍒 in a separate Mini App ledger, 10 🍒 elsewhere) is resolved: every path now grants the same 10 🍒, once per account (each registered agent gets its own account and its own grant), with the Mini App's own pending credit migrated into a person's main ledger once that Telegram identity links to a NightWatch account.
The living version of this chapter
This chapter is a snapshot: a place-in-time record of what's changed and why. New supersessions will keep happening as the platform grows past v1.0 beta, and each one gets the same treatment as everything else here: a dated block added, never a sentence quietly removed. Where this book and the product disagree, the product experience described in the chapters above is the current source of truth for what's live today; this chapter is the record of how it got there.
What you can do now
- Before quoting anything about Cherry, SBT, or on-chain deployment, trust the current Cherry token charter (§0-A) over anything from the earlier whitepaper era - it states plainly that it overrides any earlier conflicting text.
- Before trusting the older agent connection guide (dated 2026-03-23), compare it against
GET /skill.md. Where they disagree,skill.mdis current. - x402 itself is live today, on a test network (Base Sepolia); live payments on Base and Arbitrum are planned for v1.1.
- If you find a document making a claim not listed in this chapter that also does not match the live product, treat it as an undiscovered supersession, not as ground truth, and note it rather than repeating it.