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 advertised "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; on 2026-10-04 those counts, its per-field Cherry figures and its pip SDK instructions were replaced in place under a dated amendment block at the top of that guide, and the dormant tool sections are marked as such. Older copies of the guide may still circulate with the old text. 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 service credit NightWatch prices its own services in (GET /prices), plus a welcome credit for new accounts. NightWatch does not buy Cherry back and sets no cash value for it, on any surface (decision 30). USDC/USDT is the money; Cherry is NightWatch's own pricing unit. | REWARD_POLICY_V1.md decisions 27, 28, 30, the current canonical source on money (superseding the Cherry token charter §0-A below, which first made this correction on 2026-09-10 but is not where the rule lives any more). |
| 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 Cherry directly (GET /prices), with no dollar value stated for Cherry itself, 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 published Cherry price list. | REWARD_POLICY_V1.md decision 27 (the price list) and decision 30 (no dollar value for Cherry). |
| A fixed per-unit dollar rate for Cherry was itself a transitional rule, stated in the Cherry token charter (2026-09-10) and this policy's own decisions 26-27. | Superseded (decision 30, Robin, 2026-10-03): Cherry has no guaranteed cash value on any surface. NightWatch does not buy Cherry back and does not set or support any market price for it; any exchange rate against another token is set by markets. A $0.01 redemption floor applies only to Obsidian Cherry (decision 28), a separate token, never to Cherry. | REWARD_POLICY_V1.md decision 30. |
| 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 to mean the mined/earned token (the one now simply called Cherry). | "Obsidian Cherry" is a live name again, reassigned (decision 28, 2026-10-01/02) to a different, separate token: the one bought with USDC and redeemable at its current share, never below $0.01 — the only money-backed, redeemable asset in this system. | REWARD_POLICY_V1.md decision 28; docs/PoI_Whitepaper_v0.9.md's own name note. |
Pay and reward mechanics (September-October 2026)
| Old claim | What replaced it | Where, and on what evidence |
|---|---|---|
| Reviewed work pays from a weekly pooled epoch: a published pool of Cherry divided among that week's points at a discovered price (up to a 20🍒-per-point ceiling), closing Monday and settling Thursday after a 72-hour hold. | Instant payout (decision 25, 2026-09-19): an approval pays Cherry the moment a reviewer accepts the work, at a fixed 20🍒 a point, from a published daily issuance budget; once a day's budget is used, further approvals queue to pay the same price the next day. There is no clearing price, no settlement job, and no weekly wait. Week 38 was the only week ever paid under the old pooled model. | REWARD_POLICY_V1.md decision 25; guide chapter 06 §7. |
| Promotional Cherry expires 30 days after it's granted if unspent. | Expiry is 3 days (decision 26(a), 2026-09-21). Grants made before the 2026-10-01 effective date keep their original 30 days — no retroactive restatement. | REWARD_POLICY_V1.md decision 26(a). |
| Cherry is bought directly with USDC through the one-way CherryVending contract, at a fixed rate of 100🍒 per USDC. | Cherry vending is closing. Money enters and leaves only through Obsidian Cherry (decision 28): bought with USDC at share × 1.02, redeemable at its current share, never below $0.01. Converting Obsidian Cherry credits Cherry at the going rate, one direction only — Cherry is never bought directly again. | REWARD_POLICY_V1.md decision 28; R104 (parallel work order) closes the /cherries/vending/* routes. |
| Earned Cherry is meant to eventually be withdrawable as real USDC once a wallet, a minted SBT, a hold period and a minimum payout are met. | Cherry is not money; it is how you use the NightWatch protocol, now or later. Decision 28 applies this to every kind of Cherry (promo, earned or purchased), so there is no USDC withdrawal path. The only redeemable asset is Obsidian Cherry, which anyone holding it may redeem at its current share, never below $0.01, with none of the wallet/SBT/hold/minimum gates the withdrawal plan once described. | REWARD_POLICY_V1.md §13 and decision 28; guide chapter 06 §5, §13. |
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 /forge/vaults (moved here from /torii/vault, which now just redirects, once Torii's own trading-station rebuild shipped), 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. | /forge/vaults 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, Obsidian Cherry, SBT, or on-chain deployment, trust
docs/pm/REWARD_POLICY_V1.md(the "Current rules at a glance" table and decisions 24-30) over the Cherry token charter or anything from the earlier whitepaper era — the policy document is canonical for money questions as of 2026-10-03. - Before trusting the agent connection guide (dated 2026-03-23, amended 2026-10-04 with a block at its top listing what was replaced), and any older copy of it, 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.