The Forge: Makers and Verified Records

Why this chapter exists

The Forge is NightWatch's public front for makers: a person or an AI that runs a strategy in the open, under a verified identity, and asks to be judged on the record. A maker registers a book, declares a mandate — the instruments, caps, sessions, and limits it will trade inside — and is scored every day by a fetched-data X-ray nobody can talk their way around. This chapter explains what a maker actually does at /forge, what the verified record and the mandate mean, and what still moves to v1.2. An earlier product built under this same name — platform-seeded prediction slots with Cherry staking — is archived as of 2026-09-16 and is covered separately, briefly, below; it is not what "the Forge" means to a user today.

The Forge hub — nav, tabs, and the Forge Map

The main site nav's "The Forge" now opens /forge directly — the Makers front described below is no longer reachable only by a direct link. /forge has its own six tabs, mounted once by a shared layout so they show on every Forge screen, vault/maker/index detail pages included (before W1.5, the tab bar was mounted by hand on six hub pages and never appeared on a vault or maker's own page at all): Overview (/forge), Indices (/forge/indices), Makers (/forge/makers), Vaults (/forge/vaults), Supply ↗ (leaves the Forge for /market, "The Floor" — a separate lane), and Rules ↗ (opens guide chapter 31, the machine-readable rulebook, directly — /forge/rules itself now just redirects there). A separate red ＋ Create action sits apart at the right end of the tab bar — it is not a peer tab; it opens the Create hub described below.

Overview (/forge) shows an "alive" strip (how many books are listed and their last activity, the most recent on-chain vault flow and its NAV, how many supply auctions are open right now, and this week's site-wide Earn payout pool), three seat entrances (Depositor → Vaults, Maker → New, Supplier → The Floor), and the Forge Map.

The Forge Map is a graphic journey — eight nodes, Index → Identity → Plan + Bond → Pilot → Vault → Deposits → Supply auction → Signals & Mirrors — each showing your own state (done / in progress / next), a "Do it manually" link to that node's screen, a "Do it by API" line (both branches' endpoints, and an MCP tool name when one exists), and its cost, worded the same way svc/common/agent_catalog.py's Agent Router catalog does (e.g. registering a pilot book: 1,000🍒 or 10 USDC via POST /forge/vaults; requesting perp promotion: 10,000🍒 or 100 USDC via POST /forge/vaults/{id}/promote). Signed out, it shows an example journey instead of an empty page — an illustration of the shape of the whole path, worded generically ("Example: an index has been picked…") and never a claim about any specific vault's real status. Once you have submitted an index application, Index shows done and Plan + Bond shows in progress ("application status: submitted; NightWatch reviews it") until NightWatch approves it (done) or rejects it (back to next, with the status), whether or not your identity is minted yet. Source: GET /forge/me/journey (svc/api/routes/forge_journey.py) — derived read-only from the SBT, identity, pilot-application, vault, deposit, supply-bid and mirror tables that already exist; it writes nothing. A miniature of the same map, with the current node highlighted, sits at the top of every vault and maker page.

Vaults (/forge/vaults) lists every book behind one filter row — Status (All · Pilot · Live · Retired), Venue (All · BSC spot · HL perp) and Sort (Updated · NAV · Return · Name) — house books leading within whichever sort is chosen, each card's source badged House or Maker and every card carrying "updated N ago". A book with no scored X-ray yet no longer reads the dead-end word "insufficient" — it reads "Record day N" plus the real reason (a paper book's daily worker hasn't scored it yet, or a live/house book has no fills recorded yet), never a fabricated day-30 promise. The Status filter maps onto the book's real nw_pilot_vaults.status values, not a separate invented state: Pilot = pilot/promotion_requested, Live = reviewed, Retired = rejected. The Venue filter reads the book's dex: HL perp is main/xyz (a real Hyperliquid account); everything else, including the new spot pilot books below, is BSC spot. Makers (/forge/makers) carries the same filter row (filtered at the underlying book level, then grouped into makers), and lists house books first, then makers, each with their minted identity card (GET /forge/identity/{id}/card.svg), pilot progress as D+N/30, and "updated N ago" from that book's own last anchored record. A house book's card shows its public strategy name (e.g. "Won Carry"), never the internal book-code slug. This page is also where the old /reputation/publishers directory folds in (§8 decision ②(b) below) — that route now redirects here. GET /forge/vaults is the only request the list makes: each item already carries its headline dials (metrics_json), its latest anchored day (anchors, the same shape as GET /forge/vaults/{id}/anchors?limit=1), its newest on-chain flow (latest_flow) and whether it has a deployed vault or auction contract (vault_contract, has_auction_contract), so a page never asks once per card.

＋ Create (/forge/new) is a hub, not the wizard directly: "Make your mark on NightWatch" — three layers in order (1) Badge (SBT), a soulbound token, your one NightWatch identity; (2) Maker identity (NFT), bound 1:1 to the badge — this is what a pilot book registers to; (3) DragonGlass (see below) — then three ways to build on it: Fund from an index (→ /forge/indices, the spot application flow), Signal book (→ /forge/new/signal-book, the 5-step perp wizard described below, moved here unchanged), and Mandate Vault flow (→ /forge/vault-flow, described below). The same badge/identity status card shown here is the one Account → Identity shows too — one component, not two copies that could drift apart. Requesting the badge is a form on that card (and on step 1 of the Signal Book wizard, the Forge Map "Identity" node's manual target): a display name (up to 32 characters, engraved on the token for good), minted to the EVM wallet linked to your account — with no wallet the card says so and links to Account → Wallet to connect one. It calls POST /sbt/request, then shows Requested, Approved, Minted or Refused with the time and the next step. An operator approves by hand (no time is promised); the approval submits the mint, and NightWatch's own wallet pays that network gas on the Base Sepolia test network, so the badge costs you nothing. A refused request can be filed again from the same card.

DragonGlass — "Proof-of-Achievement NFTs — earned, never bought" — is NightWatch's name for an earned, non-transferable mark: "a DragonGlass mark", capital G, never "Dragonglass". Soulbound: a mark stays with the identity that earned it and cannot be transferred or sold. One token, one wallet, one Hall — the ranking surface that reads only NightWatch-issued marks (issuance, minting, the Hall itself: a separate order, v1.1). The Create hub's DragonGlass card lists what NightWatch can detect today without ever showing a fake mark: verified work (tiers 1/5/20/50, agent.py's _reputation_tier), delivered (tiers $100k/$1M/$100M, auction_tiers.py's thresholds), and pilot completed (30 days, nw_pilot_vaults.record_start) are all live-detectable; first vault created and re-observation streak are v1.1 — the detection code for those two doesn't exist yet.

The Signal Book wizard (/forge/new/signal-book, formerly /forge/new directly) asks explicitly what you are building before showing either form: (a) a spot index/ETF fund on BSC (pick a registered, tradable-only index at Indices — reuses the existing Indices-hub plan+bond application) or (b) a perp book on Hyperliquid (main or xyz, passive rulebook or an active mandate, paper option — the pre-existing vault-registration form, unchanged). Every step's wizard screen ends with a "For agents" line naming the exact endpoint (and X-NW-User-Key works everywhere a bearer token does).

The Mandate Vault flow (/forge/vault-flow, its own page, separate from any one vault's own detail page) is the "missing middle" now closed: a checklist (badge + identity → a spot pilot book on an applied index → the spot pilot length in days — 14 by default — in pilot), a list of your own applications and their status, a Request vault creation button once eligible, and a live-vs-later table. The middle step — an index application becoming a real pilot book — used to have nothing behind it (a 2026-09-29 review found an accepted application could never reach the vault-creation queue). As of this order: an operator reviews a submitted application (POST /admin/forge/index-applications/{id}/approve or .../reject, a reason required to reject) — approval refuses with 409 unless the application's own venue is bsc_spot (an hl_perp application can never become a spot book), then creates exactly one spot pilot book (nw_pilot_vaults, venue BSC spot, dex='bsc_spot', no Hyperliquid address) for that maker's own index and plan, whose day 0 is the approval timestamp itself (a spot book has no HL account to take a first snapshot from). From there the pre-existing queue (unchanged by this order) takes over: POST /forge/vaults/{id}/request-creation (idempotent, refuses a perp book with 409, refuses a pilot younger than the spot pilot length (14 days by default) with 409), states requested → approved → created(address) or rejected(reason), an operator approves with POST /admin/forge/vault-requests/{id}/approve (recording the manual deploy-script parameters) and later records the deployed address, chain id (97, BNB Smart Chain testnet, the only one accepted for now) and deposit token with POST .../mark-created; the vault page then shows the contract and its testnet Deposit and Request withdraw buttons (chapter 27). NightWatch never deploys from the API at any step. Each of these operator steps now has a screen in the deck's Money section, under "Forge reviews": an "Index-fund applications" queue (applicant, index, venue, plan text, proposed cap, bond figure, submitted time; Approve or Reject, a note required on both, and the note is the reason the applicant sees on a rejection), an "Identity (badge) requests" queue and a "Vault-creation requests" queue (the pilot's record link, the request state, Approve with optional deploy parameters, then — after the operator has run contracts/deploy_spot_vault.py outside the screen — Mark created with the contract address, or Reject with a reason). What the applicant sees: GET /forge/indices/applications/mine and the Mandate Vault flow list show status (submitted, approved with the pilot book, or rejected with the reason), and the vault page's creation panel shows the request state and address. Perp books still cannot become deposit vaults — that stays v1.2; a perp book's own vault-creation attempt gets one plain line back: "perp vaults arrive in v1.2; run as a signal book with mirroring today."

Rules ↗ opens /guide/31-mandate-vault-rulebook directly — the machine-readable rulebook (also GET /rules/mandate-vault — fees, bonds, roles, gates, and now a "Maker onboarding" section covering the application-review/spot-pilot-book/14-day spot pilot/perp-refusal rules above) and its under_review list, worded "NightWatch is deciding: …" rather than hidden. /forge/rules itself is now just a redirect to that same chapter.

Buy Cherry lives in the site header: a "🍒 Buy Cherry" button sits on every page, desktop and phone, left of the account chip. Cherry itself is never bought directly with money; the popup is the Obsidian Cherry panel (chapter 06), with three actions: Buy (USDC to Obsidian Cherry, from your connected wallet), Redeem (Obsidian Cherry back to USDC at its current share, no fee) and Convert (burns Obsidian Cherry and credits Cherry to your account, one direction only). A one-step "Buy Cherry" button runs Buy then Convert (two confirmations); "Sign in to buy" (returning to the same popup) shows when signed out. The same popup opens from "＋ Buy" on the Account wallet's own Cherry row. The corner widget that used to sit on /forge/vaults is gone. Live rail: USDC on Base (testnet today, Base Sepolia; mainnet behind its own switch). v1.1: Arbitrum USDC/USDT0. Later, not yet on any list: ETH, BTC, BNB — they need a price source, a quote window and a treasury holding rule to exist first, and are never selectable until then.

One route retired in favor of the hub above (§8 decision ②(b)): /reputation — the older prediction/reputation-market page (Bazaar and Following tabs, a Founders' Row governance modal) — now redirects to /forge; its backing API (svc/api/routes/forge.py, forge_gov.py) is untouched, only the route changed.

Where things stand

Archived: the prediction-staking layer

Before the Makers front described below, "the Forge" meant a different product: platform-seeded prediction slots (Close, Touch, and Average markets, plus a laddered weekly wave board), where people and AI agents staked Cherry against a fixed, checkable formula, with a governance layer of proposals, vesting, rooms, and tips built up alongside it. Real Cherry was staked and real series were settled, automatically, by a background worker running on a five-minute timer. Robin put this whole layer on hold on 2026-09-16: it is no longer part of what the Forge means to a user, and it has no public screen. The code stays mounted at /forge/series, /forge/gov, and /forge/rooms, and the keeper worker keeps running — it still settles any series left open and still runs the daily knowledge-graph export it always has. Chapter 22 carries the fuller record of what changed and why. Separately, the contract fund product once called Smart Vault is now named Mandate Vault, planned for v1.2.

The Makers front: makers, pilot books, and a verified record

The Forge's public front at /forge is the Makers front, live today, though not yet linked from the main site navigation. A maker is a person or an AI that runs a strategy in the open, under a verified identity, and asks to be judged on the record. This part of the Forge keeps growing past what the rest of this chapter describes, so this section is updated with every release.

What you see at /forge. Cards for every registered book, NightWatch's own house books first with a "House" badge. Each card shows the maker's identity image and name, the fund type (passive or active), the registered fee, five behaviour dials computed by NightWatch from the book's own fills and positions (average leverage, share of time with an open position, top-three concentration, fee drag as a share of equity, maximum drawdown), the adherence score, and the review status (pilot, review pending, reviewed, rejected). A dial that does not have enough data says "insufficient" instead of showing a number. Filters narrow the list by type, venue, review status and house books. The old reputation hub stays at /reputation.

The maker page at /forge/maker/<identity> shows the identity, its books, the verified record (equity curve, time-weighted return and drawdown where the data exists), the full X-ray table grouped as in the table below with the formula and data window next to every metric, the adherence breakdown across its five dimensions (instrument, session, size/leverage, stop, and — since 2026-09-18 — liquidity safety) with every breach listed by time, instrument and rule and grouped under the dimension whose score it feeds, and the review status. Each score says what it counts: the Instrument score counts the allow-list, the liquidity-grade floor, the notional-volume floor and the per-instrument exposure cap (so a notional-volume floor breach lowers Instrument, not Liquidity safety), while Liquidity safety (platform guard) counts only the platform's own fill-time safety guard. The honesty row "Mandate breaches" is the total across all five dimensions. GET /forge/vaults/<id> returns the same grouping as adherence_breach_groups next to the unchanged adherence_json. Following a maker with your own account is provided in v1.2.

Becoming a maker happens in the Signal Book wizard at /forge/new/signal-book (reached from /forge/new, the Create hub, via its "Signal book" build action), in five steps:

1. Identity. Choose a name and an image. The identity is an image token (ERC-721) bound one-to-one to your root identity badge, the non-transferable badge (SBT) described in chapter 9, so a minted badge comes first (request it from the badge card on the same page; see the Create hub above). The image can be changed later by an operator; the binding cannot. NightWatch renders every minted identity a card of its own at /forge/identity/<id>/card.svg (name, identity number, root badge number, network, anchored days), and that card is what the token points at unless the maker supplies another image. The network gas for the mint is charged in Cherry at the gas price list and shown before you confirm. Minting runs on the Base Sepolia test network in v1.1.
2. Book. Register the Hyperliquid address you trade from (main or the xyz stock-perps venue), the fund type, the fee (passive at most 5%, active between 10% and 30%), the published rules for a passive book, and the mandate: the instruments you may trade with a per-instrument exposure cap and a liquidity floor grade, leverage and size caps, trading sessions such as "only while the underlying spot market is open", drawdown stops, activity limits, and the seven-day notice rule for changes. Since 2026-09-18, an optional liquidity_safety group adds five fields — min_grade_new_exposure (grade floor for new exposure), max_order_pct_of_volume and max_order_depth_fraction (single-order size caps), max_impact_bps (estimated-slippage ceiling), and session_gate_grades (which grades are held to the underlying cash session) — and NightWatch's own shared registry (svc/common/liquidity_safety.py) applies its own default numbers when a mandate omits the group entirely. An override can only be at least as strict as those defaults, never looser.
3. Charge. The opening charge is shown before anything is debited: 1,000🍒 or 10 USDC, taken from your Cherry balance first and otherwise payable in USDC through x402 on Base or Arbitrum One. Your book holds no one else's money; it is a public, verified record of your own trading, scored by the same X-ray as the house books. A new book appears on the public directory after NightWatch has verified that you control the address.
4. Record. The record period runs for 30 days from registration. The X-ray and the adherence score are recomputed every day.
5. Promotion. After the record period you request promotion for 10,000🍒 or 100 USDC. An operator reviews the request in the operator deck against the seven-point checklist (no pooled custody, trade-only delegation with caps, verified record, mandate enforced as gates, disclosure, kill switches, reputation stake). A "reviewed" verdict needs a superadmin. If the request is rejected, the promotion fee is returned in what you paid with. Cherry goes back to your balance at once, into the same kinds of Cherry it was paid from; promotional Cherry that has expired in the meantime is not restored. A USDC payment is recorded as owed to the wallet that paid it, on the same network and in the same token; it is paid out once refund sending is switched on. No Cherry is credited for a USDC payment. The opening fee is kept.

What the X-ray measures. Leverage (average, peak, share of time above 3x, 5x and 10x), exposure time (the share of the window during which at least one position was open, with legs open at the same time counted once, so it can never exceed 100%; plus median holding time per leg, and overnight and weekend share of non-crypto leg time), exposure size (average and peak notional, largest position, top-three concentration), fees (taker share, fees as a share of equity and of gross profit, funding, builder fee), activity (trades per day, average trade size), diversity (markets traded, split by venue, long share), risk (maximum drawdown and its length, worst day, tail loss), consistency (win rate, average win and loss, profit factor, profit by month) and honesty flags (real capital, paper and live days, missing days, mandate breaches). Every number comes from fetched fills and positions, never from what a maker reports. Correction, 2026-10-04: before that date, exposure time added up every leg's open time separately, so a book holding several positions at once could show more than 100% (for example 213% over 30 days). It is now computed on the union of the legs' open time within the window. Rows already published, and the daily records already anchored on-chain, were not rewritten: a row computed before 2026-10-04 can still show the old overcounted figure, and rows computed from that date carry a method note (exposure_time.method in the row's formulas) and the corrected figure.

What v1.1 does not do. Deposits, settlement and profit sharing in the manner of Hyperliquid vaults are provided in v1.2. Self-mirroring — reading a paper book's signals and turning one into a plan for your own account, executed with your own trade-only agent key — is live today for a book that publishes signals (chapter 27); it is not a deposit and NightWatch never places an order for you.

Active books. An active book is the maker's own Hyperliquid account (main or the xyz venue), registered by address and verified by an operator before it is shown. The maker places every order themselves; NightWatch never holds a key and never trades for a maker. It only reads the account's fills, funding and equity and scores them each day against the declared mandate. Five machine-readable parts of the mandate are scored (instruments and exposure caps, sessions, size and leverage caps, stop rules, and — since 2026-09-18 — liquidity safety: the share of fill notional that cleared the grade floor, the size/impact cap, and the session gate at fill time, with exit fills such as safety trims, delisting closes, and rebalance sell-downs exempt from the grade-floor and session components); a rule written as free text is a published promise the record can be read against, not a scored item.

Passive books and paper pilots. A passive book's published rule text is the product: a short, numbered list that says exactly what it holds, when it rebalances, and what makes it trim risk, frozen at listing so it cannot be quietly changed without seven days' notice — the notice period runs from the book's listing date, and a rules change moves the book's rules_hash, which lapses every existing mirror's consent until it re-consents to the new hash. This pilot's own rules 8 and 9 were amended on 2026-09-18, before the notice clock mattered (pre-listing), to add the liquidity-safety group described above; the rules text carries the amendment inline, dated. A passive book can register as a paper pilot: it reads real Hyperliquid prices, funding and volume and follows its own published rules exactly, but every fill is written to its own paper ledger rather than sent to a real exchange account, so the rule set is proven honestly before anyone's real capital is ever behind it. A paper pilot's card carries a Paper badge everywhere it appears on /forge, its X-ray reports "real capital: insufficient" (a paper book has none, by construction, not merely an unmeasured amount), and its behaviour dials, adherence score and daily mark all come from the same X-ray worker every other book uses. The first book registered this way is "xyz Semis Equal-Weight 1.5x": an equal-weight, 1.5x-leveraged book of four Hyperliquid stock perpetuals (Samsung, SK hynix, Micron, Sandisk), rebalanced on the first of every month, trimmed automatically back to target if leverage drifts to 3x, and marked once a day by its own rule engine. A weekly-rebalancing variant, "xyz Semis Equal-Weight 1.5x (Weekly)", is also registered in the rule engine's schema (svc/common/forge_passive_rules.PILOT_XYZ_SEMIS_EW_15X_WEEKLY).

Launching an index-following fund: step by step

This is the one list for the spot index-fund path, for people and for agents. Read it live at GET /forge/fund-journey (public, no key). Signed in, GET /forge/me/journey returns the same step keys with your own state under journey_steps, and the one next action. The page /forge/vault-flow shows the same list with your state and the next action as a button. Every step says who acts next: you, an operator (a person at NightWatch acting by hand, with no time promised) or a worker (a scheduled NightWatch process). Testnet steps name their chain: the badge and the maker identity mint on Base Sepolia, the vault and deposits run on BNB Smart Chain testnet (chain id 97). The paper pilot length is a server setting (14 days by default; pilot_days in GET /forge/fund-journey is the number in force, and the 14 written in this text is only the default). A Hyperliquid perp signal book is a different path, with a 30-day record before promotion, and cannot become a vault yet.

1. Sign in. Page: /login. Sign in with email, Telegram or a wallet. An agent key alone cannot link a wallet; a person signs in in the browser, or the agent uses the bearer token that sign-in returns. Agents: POST /auth/agent/connect. Acts next: you. Wait: Immediate. Cost: free. Done when: GET /forge/me/journey returns anonymous=false.
2. Connect a wallet. Page: /account?tab=settings#nw-wallets. Open Account, then Settings, then Wallets. Press Connect wallet, choose EVM (MetaMask) and sign the ownership message. The badge is minted to this wallet, so it must be an EVM wallet. Agents: POST /auth/wallet/nonce; POST /auth/wallet/link; GET /auth/wallet/status. Acts next: you. Wait: Immediate. Cost: free. Done when: GET /auth/wallet/status returns ok=true with an EVM (0x) wallet_address.
3. Request your badge (SBT) (testnet only; an operator acts behind this step). Page: /account?tab=identity. On the Identity tab press Request badge, with a display name of up to 32 characters. A NightWatch operator approves it in the operator deck and the mint follows the approval, on Base Sepolia testnet. Agents: POST /sbt/request; GET /sbt/mine. Acts next: a NightWatch operator, by hand. Wait: When the operator acts. No time is promised. Cost: free. Done when: GET /sbt/mine returns sbt.status=minted.
4. Mint your maker identity (testnet only). Page: /forge/new/signal-book. Save a name and an https image, then press Mint identity. It needs a minted badge. It mints on Base Sepolia testnet. Agents: POST /forge/identity; POST /forge/identity/mint. Acts next: you. Wait: Immediate once the badge is minted. Cost: network gas, charged in Cherry. Done when: the identity row reads status=minted (GET /forge/me/journey, node identity, state done).
5. Choose an index. Page: /forge/indices. Open the index list, pick an index and, if you like, narrow it to a theme. Agents: GET /forge/indices; GET /forge/indices/{index_id}; GET /forge/indices/{index_id}/levels; GET /forge/indices/{index_id}/members/{symbol}/liquidity-history; GET /forge/indices/{index_id}/liquidity-history-summary. Acts next: you. Wait: Immediate. Cost: free. Done when: you have submitted an application (GET /forge/indices/applications/mine lists it).
6. Ask NightWatch to register a sub-index (optional; an operator acts behind this step). Page: /forge/indices/{index_id}. Only if the list you want is not there. On the page of a crypto reference index, in the block "Ask for a sub-index of this index", enter a name, members from that index, a weighting and a rebalance cadence, then press Send request. It is free; an account can have 3 open requests. A NightWatch operator registers the sub-index in the operator deck or declines it with a reason. Agents: POST /forge/indices/{parent_id}/subindex-requests; GET /forge/subindex-requests/mine. Acts next: a NightWatch operator, by hand. Wait: When the operator acts. No time is promised. Cost: free. Done when: GET /forge/subindex-requests/mine returns the request with state=registered and registered_index_id.
7. Submit your plan and bond figure (application). Page: /forge/indices/{index_id}/new. Open the index, press Create a fund, then follow the steps (scope, plan, bond, rebalancing, submit). Rebalancing asks eight questions (six ordinary ones, plus two advanced limits kept in a closed "Advanced settings" section) with NightWatch's recommended standard filled in: keep it with one click, or change any number inside its range; the page shows each member's liquidity tier and how your TVL cap fits. An accepted plan runs as a 14-day paper pilot scored daily against the index. The paper pilot holds all members of the index (after your category filter); the page shows separately how many a BSC vault can hold today. Agents: GET /forge/rebalance-policy; POST /forge/indices/{index_id}/rebalance-check; POST /forge/indices/{index_id}/applications; GET /forge/indices/applications/mine. Acts next: a NightWatch operator, by hand. Wait: When the operator acts. No time is promised. Cost: free; nothing is charged. The application only records a bond figure of 25% of the proposed cap, floored at $100 (in USDC terms). On testnet today the figure is recorded, not collected, at application and at vault creation. Done when: GET /forge/indices/applications/mine returns an application with status=submitted.
8. NightWatch reviews the application (an operator acts behind this step). Page: /forge/vault-flow. Wait. A NightWatch operator approves or rejects it in the operator deck. Approval needs your badge and maker identity minted, and a BSC spot venue. A rejection carries a reason and you can apply again. Agents: GET /forge/indices/applications/mine. Acts next: a NightWatch operator, by hand. Wait: When the operator acts. No time is promised. Cost: free. Done when: application status=approved and vault_id is set.
9. 14-day paper pilot. Page: /forge/vault/{vault_id}. Nothing to press. Approval opens a paper book with no real money that holds all members of the index at index weight, even those a BSC vault cannot hold yet. Day 0 is the day of approval. Each day the page scores how closely the book follows the index. After day 14 you can request a vault; the vault itself is on BSC testnet today and holds only what a BSC vault can hold. Agents: GET /forge/vaults/{vault_id}. Acts next: a NightWatch worker. Wait: 14 days from approval, scored once per UTC day. Cost: free. Done when: 14 calendar days have passed since approval (vault.spot_pilot.day_n is at least vault.spot_pilot.pilot_days).
10. Request vault creation. Page: /forge/vault-flow. After day 14, open the Mandate Vault flow page and press Request vault creation. The button appears only when the pilot has run its full length and at least 5 members of the index can be held by a vault. Agents: POST /forge/vaults/{vault_id}/request-creation; GET /forge/vaults/{vault_id}/creation-request. Acts next: a NightWatch operator, by hand. Wait: When the operator acts. No time is promised. Cost: free. Done when: GET /forge/vaults/{vault_id}/creation-request returns request.state=requested.
11. Vault created on BSC testnet (testnet only; an operator acts behind this step). Page: /forge/vault-flow. Wait. A NightWatch operator approves the request, deploys the vault contract and records its address in the operator deck. The vault page then shows the address. Agents: GET /forge/vaults/{vault_id}/creation-request; GET /forge/vault/{vault_id}/contract. Acts next: a NightWatch operator, by hand. Wait: When the operator acts. No time is promised. Cost: free; the operator pays the deploy gas. No bond is collected at vault creation on testnet today. Done when: creation-request state=created and vault_contract.address is set (a vault_contract with preview=true is a shared test deployment, not this vault).
12. Deposit (testnet only; an operator acts behind this step). Page: /forge/vault/{vault_id}. On the vault page, in My deposit, press Connect wallet, then Deposit, and confirm in your wallet. Your wallet must be on the vault's allowlist, which a NightWatch operator sets; without it Deposit stays off. On BNB Smart Chain testnet the deposit is recorded and shown on the vault page once it confirms. Putting it to work (buying the basket) happens when a NightWatch operator runs the keeper. Agents: GET /forge/vault/{vault_id}/contract; GET /forge/vault/{vault_id}/deposits/me. Acts next: a NightWatch operator, by hand. Wait: The deposit appears after the transaction confirms. The allowlist and the keeper run when the operator acts. Cost: the amount you deposit. Done when: GET /forge/vault/{vault_id}/deposits/me lists the recorded deposit (a purchase is not required).
13. Rebalance and supply auction (testnet only; an operator acts behind this step). Page: /forge/vault/{vault_id}. Nothing to press. On BNB Smart Chain testnet a NightWatch operator runs the keeper: it buys equal-weight legs for a new deposit and sells pro-rata to settle withdrawals. A rebalance to the index weights is run by the operator, not on a schedule. When the open market cannot fill a trade, a bonded supplier can: an operator opens a supply auction by hand, because the keeper never opens one itself. Agents: GET /forge/vault/{vault_id}/auction/current; GET /forge/auction/suppliers/me. Acts next: a NightWatch operator, by hand. Wait: When the operator runs the keeper or a leg fails the price gate. No schedule. Cost: a supplier bond, by tier (only if you bid as a supplier). Done when: GET /forge/vault/{vault_id}/auction/current returns the auction, or none is open.
14. Public record. Page: /forge/vaults. Read the fund's record on the vault, maker and vault-list pages. The daily anchor writes it down. Agents: GET /forge/vaults; GET /forge/makers/{identity_id}. Acts next: a NightWatch worker. Wait: Each UTC day (the daily scorer, then the anchor). Cost: free. Done when: GET /forge/vaults/{vault_id} returns vault.spot_pilot.last_scored_day.

Indices and starting a fund

Every fund on the Forge starts from a registered index at /forge/indices — a maker never invents a universe from scratch. The registry holds three kinds of index: crypto market-cap indices (Crypto Top 100, Crypto Top 200, refreshed daily), the 17 stock-index and ETF markets already tradable on Hyperliquid (chapter 13's Torii index perps, keeping their own pages at /torii/indices/[sym]), and two NightWatch baskets (CLARITY beneficiaries, Memory Big4) curated by hand rather than fetched daily. The Forge tab that used to say "Index Perps" now says "Indices" and opens this hub; it still links out to /torii/indices for what is tradable on Hyperliquid right now.

Reading the hub. Each row shows the index's name, its provider, its delivery chain (BSC for the crypto rows, HyperEVM for the stock-index/ETF and Memory Big4 rows), how many funds already run on it, and when it was last updated. The index is always shown in full — a crypto row's constituent count is never filtered — but a fund can only ever hold what its own vault's venue can actually trade, so a crypto row shows its counts side by side, e.g. "withdrawable to BSC 38/100 · holdable by a BSC spot vault 5/100 · HL perp 58/100". The two BSC figures are different measures. Withdrawable to BSC from an exchange is a ticker match against one large reference exchange's public wallet-network data: the token has a BSC network with deposit and withdrawal enabled, which includes exchange-pegged wrapped tokens and involves no on-chain or liquidity check. Holdable by a BSC spot vault today is the short list of assets the mainnet vault can price (BTCB, ETH, SOL, XRP, BNB, the assets with a Chainlink feed in the deploy script); a vault cannot hold anything else. HL perp means the token is listed as a perpetual on Hyperliquid (its main venue or the xyz venue), checked daily against Hyperliquid's own market data, delisting-aware. A token can fail one venue and pass the other for an ordinary reason, not a data bug: ARB, OP, POL, STRK, MNT, ZK, IMX and METIS each run their own chain and were never issued an exchange-pegged BEP20 token, so withdrawable-to-BSC is genuinely 0 for them even though several trade as Hyperliquid perps; MATIC has a BEP20 contract but the reference exchange currently has BSC withdrawal disabled on it; TAO and RENDER withdraw only on their own chain (TAO) or Solana (RENDER). A token that is simply not on a venue reads "not listed" in that venue's column; "data unavailable" appears only when that venue's data could not be fetched that day. The crypto indices are membership by market-cap rank: NightWatch does not publish weights for them, so their page states that rule and shows no weights column. Opening a row (▸) shows its description and top constituents. A non-HL row's own page at /forge/indices/[id] adds the full constituent table with category chips (AI, DeFi, L2, RWA — the data source's own tags; the two crypto indices are ranked by CoinGecko's public API and say so, with the snapshot date and fetch time, on their page; their ids still read cmc-top-100 and cmc-top-200 for historical reasons), a venue toggle (default "all") that highlights the rows tradable on the venue you pick rather than hiding the rest — the index itself never shrinks — and both venue columns; an HL-tracked row keeps its existing detail page (chapter 13) and gains the same "Funds on this index" block.

Starting a fund happens at /forge/indices/[id]/new, sign-in required (your SBT account), in five steps for a passive fund (four for an active fund, which has no rebalancing step). Scope: pick the venue your vault will trade on — a BSC spot vault, or a Hyperliquid perp vault at 1x or leveraged — then the category chips that narrow the index to a theme. The page shows only the constituents tradable on your chosen venue, as "N of M constituents tradable here", and the auto-generated fund name (<index> <filter> <type>, e.g. "Crypto Top 100 AI ETF"); a venue with fewer than 5 tradable constituents is disabled (for a BSC spot vault, "tradable" counts the assets a vault can hold) with the reason, and the other venue's own count is suggested in its place — the index is shown in full everywhere else, but a fund can only ever hold what its vault's venue can trade. Plan: a passive rule sentence (what it holds, how often it rebalances, its leverage) or an active strategy description, the rebalance cadence, leverage where the chain allows it, and a fee within the charter's existing bounds (passive at most 5%, active 10-30%, same limits as the maker wizard described earlier in this chapter). Bond: set the TVL cap and the page computes the required bond — 25% of that cap, floored at $100 — shown in USDC terms and recorded with the application (a Cherry bond for whitelisted makers is planned for v1.1); nothing is charged at this step. On testnet today the bond is recorded, not collected; on a mainnet BSC spot vault the maker bond is posted at vault creation, in on-chain USDT on BSC (BEP-20). Rebalancing (passive funds): the page asks six questions, plus two advanced limits in a closed "Advanced settings" section, about how the fund follows the index, with NightWatch's recommended standard selected; keep it with one click or change any number inside its range, and see each member's liquidity tier and how your TVL cap fits before you go on (details in "The rebalancing rule" below). For a passive fund the cadence is the index's own, so the Plan step shows it and does not ask for it. Submit creates a pilot application NightWatch reviews, storing the chosen venue and the exact filtered universe you saw; an accepted plan runs as a spot pilot (the length is the server's setting NW_SPOT_PILOT_DAYS, 14 days by default, and the page states it) before a vault opens, and from then on it is listed under its index and in the Forge makers list, reusing the same pilot/vault cards described earlier in this chapter.

The rebalancing rule. A passive fund on the Forge does not try to hit its target weights exactly. On the index's rebalance and membership-change dates, the fund compares each member's actual weight with its target. In v0 this rule is applied to the paper pilot's daily scoring. A live vault does not yet rebalance by it automatically. A member inside its tolerance band, or whose gap is smaller than the minimum trade, is left alone. The others are traded back to target: sells first, then buys, in orders sized by NightWatch's liquidity rule. Before each order the fund estimates its cost as the trading fee plus half the bid-ask spread plus slippage from the stored order-book depth. An order is refused when its expected slippage plus half the spread, measured from the mid price, would exceed the published liquidity ceiling (25 bps for Tier 1 and 15 bps for Tier 2); a member whose spread alone reaches the ceiling cannot be bought or sold by order at any size and is deferred. The order cost limit can only make the rule stricter than the published liquidity ceiling (25 bps for Tier 1 and 15 bps for Tier 2), never looser: it matters only when the trading fee plus half the spread plus slippage would pass it while still under the ceiling. An order above the order cost limit is offered through the supply auction; if the auction cannot fill it within its own limit, the order is deferred with its reason and retried the next day. A leg deferred for three days alerts NightWatch operations.

Each rebalance gets one verdict, published once and never changed. Completion is the share of the planned trades that was filled: one minus the unfilled planned amount divided by the planned amount, with the plan valued at the opening day's prices. An event where every member was already inside its band is COMPLETE with no trades. COMPLETE means completion reached the target, the cost stayed within the budget and all trading happened inside the window. PARTIAL means completion fell short but every part left over was stopped by a cost, liquidity or cash limit with a recorded reason (a member whose liquidity data is older than 24 hours is deferred with the reason liquidity_data_stale; cash that ran out leaves the reason no_cash); this is not a breach. FAILED means something was left with no reason, or the cost went over budget, or trading happened outside the window.

You choose the numbers when you apply. The application asks six questions: the band (± % of each target), the minimum trade, the cost budget, the time allowed for Tier 1 members and for the rest, and the completion target; two advanced limits, the order cost limit and the auction cost limit, sit in a closed "Advanced settings" section (they can only make the rule stricter than the published liquidity ceiling; most funds keep the standard, and the section opens by itself if you change them). GET /forge/rebalance-policy marks them advanced: true, and all eight keys are still accepted in the application. NightWatch's recommended standard, which follows common practice for passive funds, is filled in: ±5 % of target, 0.25 % of the fund, 0.5 % per order, 1 % through the auction, 0.5 % of the amount traded, one day and three days, 95 %. Keep it with one click or change any number inside its range. GET /forge/rebalance-policy returns the questions, defaults, ranges, explanations and a worked example. An application sent without answers gets the standard, recorded as "default applied". The application stores your answers with a hash of the numbers, and the applications list shows the rule in one sentence.

Liquidity tiers. Each member's tier comes from its NW Grade on the exchange the fund prices from (for an index with a pricing rule, each member is read on the pricing exchange where it has a usable row, best grade first and the deeper book at equal grade, and its fee, spread, depth and research link are that exchange's; a member with no usable row on any pricing exchange stays not graded): A or B is Tier 1 (normal order limits), C or a grade with under 7 days of history is Tier 2 (the tighter liquidity ceiling: 15 bps instead of 25 bps), D, F or no grade is Tier 3 (new buys blocked). The application shows each member's tier and checks the proposed TVL cap against the stored order-book depth and volume: which members are expected to trade inside their band, which are likely to need the supply auction, and which are likely to be deferred, plus the largest cap at which every Tier 1 and Tier 2 member fits. An NW Grade says whether a market is healthy, not how large a fund it can carry; the size check answers that. The check uses scans every 2 hours on centralized exchanges and cannot see hidden orders or how much supply the auction will find. The notice never blocks an application: it is shown to you, frozen into the application as you saw it, and shown to the operator before approval.

In the paper pilot (the only place the rule runs in v0) it runs on the daily fixing: up to 12 orders per member per day, priced at the fixing mid plus the estimated cost. The supply auction is not simulated, so an order above the cost limit is deferred. A market-cap-weighted index with unchanged members and supply needs no trades; trades come from equal- or fixed-weight resets, membership changes and weight caps. Books opened before this rule keep the earlier model (traded fully to target at fee plus half the spread) for their whole life, and their published numbers are not changed.

Researching a member's liquidity. Every member of an index that has a liquidity row carries a research_url: the existing token research page, opened on the exchange its tier is computed from (GET /forge/indices/{id} on each constituent and in liquidity_tiers, POST /forge/indices/{id}/rebalance-check on each member, and spot_pilot.member_links and the open legs of a paper pilot book). A member with no liquidity row has no link, and only members of crypto indices get one (an equity ticker never links to a token of the same name). The page shows it as "Liquidity research". The scan that feeds the tiers already covers every token every 2 hours, but only about 14 days of scans are kept, so once a day the worker also writes one row per member, exchange and UTC day, after the day has ended and never rewritten: the number of scans, the median spread, the median and minimum depth within 2 % on each side, the median volume, the NW Grade and tier, and the order cap at that tier. A scan with no usable depth is counted as unpriced and left out of the medians. The worker covers the members of every crypto index, every sub-index, and every index that has an application or a paper book. GET /forge/indices/{id}/members/{symbol}/liquidity-history?days=N (public, up to 365 days) returns those rows oldest first with data_from, the first day held; the history follows one exchange, the one the member's liquidity tier is computed on and that research_url opens (the response says so in history_follows and venue_note; if that exchange changes, the history follows the new one). The history starts when the worker first ran, so a young member shows few days, and a day written long after it ended carries the grade as of the day it was written, not that day's grade: the row says so in grade_basis and grade_note ("grade as of <date>"), and so do the tier and order cap built on it. GET /forge/indices/{id}/liquidity-history-summary returns the one-line inputs for every member in a single call. The index page shows one line per member: days held, the latest median spread and depth, and the range of the daily order cap.

If you are an AI agent. Read GET /forge/rebalance-policy, then call POST /forge/indices/{id}/rebalance-check with venue, filter_categories, tvl_cap_usd and rebalance_policy to see field errors, tiers and the size check. Submit with rebalance_policy: {"use_standard": true} or your numbers. A bad number is refused with invalid_parameter and one entry per field in nightwatch.errors (field, code, min, max, got).

Sub-indices. A sub-index is a named list of crypto tokens taken from one of the registered crypto indices, with a rule for its weights and a level published once a day. NightWatch registers a sub-index when a customer or their agent asks for one (see "Asking for a sub-index" below); a sub-index is crypto only. Its page at /forge/indices/[id] shows, inside the usual sections: which index it comes from, its rule in one plain paragraph, the weight of each member, the latest level, and a table of the last 14 days (date, level, change on the day, status). A sub-index starts at a base value (1,000 by default) on its base date, and every level is in USDT.

Asking for a sub-index. On the page of a crypto reference index, the block "Ask for a sub-index of this index" takes a name, members picked from that index's listed constituents, a weighting (equal, fixed weights that sum to 1, or the top N by market cap), a rebalance cadence (monthly, quarterly, or none for a fixed list) and an optional note. Sign in first; the request is free. It is checked with the same rules the operator uses to register a sub-index, and a refusal names the field that is wrong and what would be accepted. An account can have 3 open requests at a time. NightWatch then registers the sub-index, which links the request to the new index page, or declines it with a reason you can read; the block lists your requests with their state. For an agent: POST /forge/indices/{id}/subindex-requests (proposed_name, members, weighting = equal | fixed | cap_top_n, weights, n, rebalance_cadence, note) and GET /forge/subindex-requests/mine (each request with state = requested | registered | declined, decided_reason, registered_index_id, page_url).

How the level is priced. Each member is priced at the spot bid-ask mid, that is (best bid + best ask) / 2, on the listed exchanges' spot books against USDT, in a fixed window after 00:00 UTC. When more than one exchange is listed the level takes the median of their mids. An exchange whose spread is wider than the stated limit is left out. A last-trade price, a perpetual mark and an oracle price are never used. The price facts used are copied into NightWatch's own permanent table at fixing time, so a published level can be checked later. On public pages the exchanges are shown as exchange codes.

"Data unavailable". If a member has no valid price on a day, the whole level for that day is "data unavailable": the page shows no number for it, never a carried-over price, and the table says which member had no price and why. A day is never filled in afterwards with a different number. If a day is computed after the fact (a backfill of up to 10 days), its row says "computed after the fact". The next available day is measured from the last available level, so a gap never creates a jump that is hidden.

The 14-day paper pilot and what it scores. An approved application on a sub-index opens a spot pilot book, a paper book with no real money. Its start capital is the application's TVL cap in USDT, it holds every member of the sub-index at the index weights, and it is priced at the same daily fixing as the index. For an application submitted from 2026-10-05 on, the stored universe is all current members of the index (after your category filter), whether or not a BSC vault can hold them, and the book holds every member of that stored universe at its index weight (renormalised over it when you filtered); a member with no price on the pricing venues is the only one of them the book cannot hold, its weight moves to the other members, and the page names it. Applications submitted before that day keep the universe they stored (marked universe_rule = bsc_withdrawable_v0; new ones carry all_members_v1) and their scored rows. Each day the page scores how closely the book follows the index. The tracking difference is the book's return minus the index's return; today's figure is close to zero on a day with no trade (it shows as 0.00 %), because the book holds what the index holds and is priced at the same fixing; it differs from the index only by costs and cash that could not be invested. The figure since start shows the cost of following the index: trading fees plus half the bid-ask spread, paid on day 0 and on each rebalance, plus the effect of any member the book cannot hold. It is not a measure of the operator's skill. The tracking error (the spread of the daily differences, per year) shows "N of 10 days" until 10 daily differences exist. The pilot length, 14 days by default, is the server's setting and the page reads it from the payload ("Spot pilot · day 6 of 14"); the daily scoring continues after that day. NightWatch sets no pass mark: the figures are public each day, and an operator decides at the vault-creation request. A day with no index level is "data unavailable" for the book too and counts toward neither the difference nor the 10 days. If the first day after approval has no index level, the book waits and the first day with a level becomes day 0. If a rebalance day brings in a new member that has no valid price, the new membership is not adopted that day: the index keeps its previous members, its level is computed from them, the day records "rebalance deferred", and the rebalance is tried again the next day. Each day the page names the members the book cannot hold from that day's members, not from day 0. A vault-creation request for a sub-index pilot is refused until at least 5 of its members can be held by a mainnet vault ("vault-holdable today: N of M"). The paper book shows on the maker page (the "Verified record" section), the vault page and its card in the vault list, each with the date of its last scored day. What a BSC vault can hold today is shown as its own information and does not shrink the paper book: "Vault-holdable on BSC today: 1 of 5 members. The paper pilot holds all 5; a vault opens when at least 5 members can be held." The same sentence is on the pilot panel, in the fund wizard and under each application on the Mandate Vault flow page; the payloads carry paper_universe_n (members the paper book holds) and vault_holdable_today as separate fields, also in POST /forge/indices/{id}/rebalance-check, whose liquidity block now covers every member of the paper universe. The vault itself is on BSC testnet today and holds only what a BSC vault can hold; the request for a vault is refused while fewer than 5 members are vault-holdable.

If you are an AI agent. GET /forge/indices and GET /forge/indices/{id} (with an optional ?category= filter) work with no auth, same as every other public Forge read; a crypto index's response carries each constituent's tradable matrix (bsc_spot/hl_perp, each {ok, note}) and a venues object with each venue's own tradable count and, when disabled, why. POST /forge/indices/ {id}/applications takes your user key or bearer token and the same fields the wizard collects, including venue; a disabled venue is refused (400) even if you send it, the bond amount is always server-computed from tvl_cap_usd, and the stored universe_snapshot is always server-computed from your category filter and venue, never accepted from the caller directly.

Sub-index data for an agent. In GET /forge/indices, every row carries kind (reference or sub_index), parent_index_id, and for a sub-index latest_level (day, level, status, quote). GET /forge/indices/{id} for a sub-index adds methodology (rule_text, selection, weighting, rebalance, pricing with the exchange codes, the stated spread limit and the fixing window, pricing_line, base_date (the day the level starts, once it has started), base_date_requested, base_date_actual (null until the level starts), base_note (one sentence when the two differ: the requested day had no complete price set), base_value, versions) and levels (latest, since_base_pct, members with weight_target_pct, series of the last 90 days with level, change_pct, status, missing, published_live, and pending_today). GET /forge/indices/{id}/levels?from=YYYY-MM-DD&to=YYYY-MM-DD returns the stored rows of up to 400 days, with each member's price and target weight. A day with status data_unavailable has level null. The base is 1000 on the first day on or after the requested base date with a complete price set, so a base can start later than requested. If the response carries subindex_schema: "not_applied", those fields are not available yet. For a spot pilot book, GET /forge/vaults/{id} adds vault.spot_pilot (status, pilot_days, day_n, last_scored_day, td_day_pct, td_since_start_pct, cost_since_start_pct, tracking_error with n_days and needed, drivers, holdable, series) and GET /forge/vaults adds tracking_headline. Every _pct field is a percentage in percent units; levels and book values are in USDT.

How a paper pilot book is scored under the rebalancing rule. The verdict and completion are defined once, in "The rebalancing rule" above (completion is the share of the planned trades that was filled). A remainder counts as justified when it was stopped by the liquidity ceiling, by stale or missing liquidity data, or by cash; a FAILED rebalance is one breach in the adherence score, a PARTIAL one is not. In the 14-day paper pilot the rule runs on the daily fixing: up to 12 orders per member per day, each priced at the fixing mid plus the estimated cost (the trading fee, half the bid-ask spread and slippage from the stored order-book depth). The supply auction is not simulated, so an order above the cost limit is deferred with its reason and retried on the next fixing day; a leg deferred three days alerts NightWatch operations. The book's page and GET /forge/vaults/{id} show the latest rebalance: the verdict, the share of the planned trades filled, the traded amount and cost of the whole event, the misweight left and each deferred leg with its reason. The difference from the index now comes from trading costs, holdings left inside the band, deferred orders and members the book cannot hold, so it is no longer zero by construction on a day with no trade. Books opened before this rule keep the earlier model (traded fully to target at fee plus half the spread) for their whole life, and their published numbers are not changed.

Anchored records: what the daily anchor proves, and what it does not

Every day at 00:30 UTC NightWatch gathers the day's reputation records into one manifest: NTRT signals and their outcomes, every book's X-ray and adherence row, the equity points, the paper engine's fills and funding, the public state of every registered book, and the identities minted that day. Each record is written in one fixed form, hashed, and the hashes are combined into a single root for the day, with a sub-root per book so a maker's own records can be proven on their own. That root is written to the RecordAnchor contract on the Base Sepolia test network (0xb55C…F61d), which refuses a second write for the same day. The first anchored day is 2026-09-16.

An anchor proves one thing: that these records existed, in exactly this form, before the hash was written, and that NightWatch has not changed them since. It does not prove the records are true. The truth of an X-ray still comes from the exchange fills it was computed from, and the truth of a paper book from its ledger. Anchoring closes one door only: silent editing after publication. A record that arrives late or is corrected is never rewritten into a past day; it appears in the next day's manifest under a "late or corrected" heading with its original date and the reason.

Anyone can check. GET /anchor/days lists the anchored days with their root and transaction; GET /anchor/days/<day> returns the full manifest, including every record in its canonical form, so a verifier can recompute every hash; GET /anchor/days/<day>/proof returns the proof for one record. The stand-alone script scripts/verify_anchor.py recomputes the root from the manifest and compares it with the chain, printing MATCH or MISMATCH. On a maker's page the "Anchored" line shows the last anchored day, how many of that book's records it carried, and links to the transaction and the manifest. The manifests also ship inside the knowledge vault download (chapter 8). Nothing private is anchored: no user ids, no e-mail addresses, no keys; a maker's Hyperliquid address is included only after an operator has verified that the maker controls it.

What you can do now

If you are just looking (no login). Browse every book at /forge: NightWatch's own house books first with a "House" badge, then makers. Each card shows the fund type, the registered fee, five behaviour dials (leverage, share of time with an open position, top-three concentration, fee drag, maximum drawdown), the adherence score and the review status; a dial without enough data says "insufficient". Open a maker at /forge/maker/<identity> to read the verified record, the full X-ray with the formula and data window next to every metric, the adherence breakdown across its five dimensions (instrument, session, size/leverage, stop, liquidity safety) with every breach listed, and, for a passive book, the exact rule text it promised to follow. A card marked Paper is a paper pilot: its numbers come from the passive rule engine's own paper ledger, never a live exchange account, and its honesty flags say so. Following a maker with your own money is provided in v1.2.

If you want to be a maker. Get your root identity badge first (chapter 9; an operator approves and mints it). Then, in the Signal Book wizard at /forge/new/signal-book: mint your operator identity (an image token bound to your badge, gas charged in Cherry at the price list); register a book with your Hyperliquid address, the fund type, the fee (passive at most 5%, active between 10% and 30%), the rule text for a passive book and the mandate; pay the opening charge of 1,000🍒, or 10 USDC when your Cherry balance is short. Your book appears on the public directory once an operator has verified that you control the address, and NightWatch scores it every day from then on. You can check your own book's page before it is public. After 30 days of record you request promotion for 10,000🍒 or 100 USDC; if the review rejects it, Cherry comes back to your balance at once in the same kinds it was paid from (except promotional Cherry that has expired in the meantime) and the opening fee is kept; a USDC payment is recorded as owed to the wallet that paid it, on the same network and in the same token, and is paid out once refund sending is switched on.

If you are an AI agent. Everything above works through the public API with your user key: create and mint the identity, register the book, read your own X-ray. A paper book lets an agent prove a rule set with no capital: the first one, "xyz Semis Equal-Weight 1.5x", is running now as a Paper pilot. MCP tools forge_signals and forge_signal_plan are live in the default connector profile today (chapter 27); paid X-ray reads stay v1.2.

If you are an operator. Verify a maker's address from the deck API, review promotion requests in the deck's "Forge reviews" queue against the seven-point checklist (a "reviewed" verdict needs a superadmin), act on badge requests (Approve + mint, or Refuse), index-fund applications and vault-creation requests in the three queues beneath it, and read the house books' own X-ray, which is computed by the same rules first.

Checking that nothing was edited. Every day's records are anchored on chain (see "Anchored records" above); read the manifest at GET /anchor/days/<day> or run the verifier script.

What nobody can do yet. Nothing in this version moves another person's money into a pooled fund: no deposits, no following-with-a-deposit. A maker's fee collection in that sense is also not live yet — but a maker whose book publishes signals does now earn a royalty share (the registry's default split) of every paid live-signal read, credited to their SBT account ledger the same way any other royalty is (chapter 24). Nobody can enter their own numbers: every metric is computed from fetched fills and positions or from the paper ledger, or reads "insufficient".

Two things that are not the Makers front. /reputation still shows the older reputation hub (Hive, Agents, Skill Market, Cherry Economy, Governance), the Publisher directory at /reputation/publishers and API key issuance at /reputation/keys work there today, and /watchtower is a separate older page. The prediction-staking engine described earlier in this chapter is built and running behind the scenes but has no public screen in this version. Intelligence Listing is an unapproved draft, not a product.