The exact numbers live in the Rulebook (ch.31) and at /rules/mandate-vault.

The Mandate Vault

What this chapter covers

A managed book run under a published mandate — the instrument allow-list, liquidity floor, session windows, and risk stops a maker commits to before anyone can follow them, and the adherence score that measures whether they actually kept to it. This chapter also records a name change: what planning documents called Smart Vault is now called the Mandate Vault. It then covers the vault contract itself — how a deposit turns into shares, how a withdrawal gets paid, what happens when the vault can't fill a trade on the open market, and what happens to a token sent to the vault's address by mistake.

What exists today

The mandate itself — the registered rules a book promises to follow — is live as part of the Forge's Makers front (chapter 14). Registering a book at /forge/new/signal-book records a mandate: an instrument allow-list with a per-instrument liquidity floor, size and leverage caps, trading-session windows, drawdown stops, and an activity policy, frozen at listing and changeable only with seven days' notice (docs/pm/FORGE_FUND_MAKER.md §10.1). NightWatch computes an adherence score against that mandate every day — instrument, session, size/leverage, stop and (since 2026-09-18) liquidity-safety adherence, plus every breach listed by time, instrument and rule broken and grouped under the dimension whose score it feeds (a notional-volume floor breach lowers the Instrument score; the Liquidity safety score counts only the platform guard's own breaches) (FORGE_FUND_MAKER.md §10.2-10.3) — and publishes it on the maker's page alongside the book's X-ray (chapter 14).

Before any contract, the live path is self-mirroring (chapter 28): a follower consents to the fund's rules with their own account, reads its signals (live ones for a fee), and places the orders themselves. Alongside that, a smart contract vault now exists and has been tested end to end on a BSC test network (chainId 97): it pools deposits into one basket of real tokens (BTCB, ETH, SOL, XRP, WBNB directly, plus eight more traded through the supply auction described below), and it settles withdrawals automatically. It has been through eight rounds of independent audit and is open to whitelisted, small real deposits — not yet to the public. docs/pm/MANDATE_VAULT_SPOT_ORDER.md is the build record; docs/pm/MANDATE_VAULT_V0_SPEC.md is the current rulebook.

Where this fits in the Forge hub: chapter 14 covers the Forge hub itself (/forge, six tabs plus the ＋ Create hub), the Forge Map (GET /forge/me/journey), and the Signal Book wizard's explicit spot-vs-perp branch. This chapter's own standalone page, /forge/vault-flow ("Open a Mandate Vault"), walks a maker through the whole path in one place. It shows the step list of chapter 14's "Launching an index-following fund: step by step" (sign in, wallet, badge, maker identity, index, application, review, paper pilot, vault creation, deposit, rebalance and supply auction, public record), the same list GET /forge/fund-journey returns, with your own state per step, the one next action and who acts next (you, an operator or a worker). It also shows the status of every application they've submitted, and — once eligible — the same POST /forge/vaults/{id}/request-creation the vault's own page already offered (states requested → approved → created(address) or rejected, refusing a perp vault and a pilot younger than the spot pilot length, 14 days by default). The checklist on that page asks for three things: a badge and identity (a root identity badge plus a maker identity), a spot pilot book on an applied index, and the spot pilot length in days in pilot (14 by default). The two checks behind the request button are that the book is a spot book (a Hyperliquid perp book, main or xyz, is refused with a 409) and that the pilot is old enough (younger is refused with a 409).

Deposit and request a withdrawal from the vault page (testnet only). When an operator marks a vault created, the deck records the contract address, the chain id and the deposit token on the vault's creation request, and the vault page picks them up at once, with no file edit and no restart. GET /forge/vault/{id}/contract returns vault_contract (address, chain_id, network_name, deposit_token with address, symbol and decimals, and explorer_url). Mark created accepts only BNB Smart Chain testnet (chain id 97), checks on chain that the address is a vault of the vault factory (and says "could not verify on chain, try again" if it cannot ask), refuses an address that differs from the deployments file's entry for that vault, and refuses a second, different address for a vault that already has one. When the deployments file and the Mark-created record disagree for a vault, the file's address is shown with the note "This vault's contract record is being reconciled; on-chain actions from this page are paused." and no buttons. Inside the deposit panel the page shows the contract address with a copy button and an explorer link, and, only when the API says chain id 97, these buttons for your own browser wallet: Connect wallet (with a one-click switch to chain 97), Deposit and Request withdraw. The page reads your deposit-token balance and whether your wallet is on the vault's allowlist from the chain. If it is not, Deposit stays off and the page says: "This vault accepts deposits from allow-listed wallets. Ask the vault operator to add <your address>." Deposit sends approve on the deposit token only when your allowance is short, then deposit(uint256 assets, address receiver) on the vault; the vault opens a pending deposit, and the operator's settler turns it into shares. Request withdraw sends requestWithdraw(uint256 shares), the normal withdrawal queue (the emergency exit stays separate). Deposits need the allowlist; withdraw requests do not. On testnet today a NightWatch operator runs the keeper: the flows indexer records your deposit and the vault page shows it once the transaction confirms, but buying the basket with it (equal-weight legs), settling withdrawals (pro-rata sells) and any rebalance to the index weights happen only when the operator runs the keeper, not on a schedule. Supply auctions are opened by an operator. Before every transaction the page checks that your wallet is still on chain 97 and on the same account, and the buttons stay off unless contracts exist at the vault and token addresses. Every transaction shows its hash with an explorer link and its state: waiting for your wallet, sent, confirmed, or failed (with the reason when your wallet or the contract reports one; a transaction that is sent but not yet confirmed says so and tells you not to send it again). Amounts use the token's own decimals read from the chain. For any other chain the address is shown read-only with "On-chain actions from this page are available on testnet only." Testnet preview. A paper book that cannot have its own vault yet may show a shared test deployment: GET /forge/vault/{id}/contract then returns the same vault_contract plus preview: true and a preview_note, and the page titles the block "Vault contract — Testnet preview". It is not that fund's vault, holds no real assets, and never counts as the vault being created. Today the operator adds a depositor to the allowlist outside the site, by calling setAllowlist(vault, account, true) on the vault factory from the admin wallet; there is no allowlist screen yet. The vault-flows indexer also reads these rows, so a vault marked created is indexed without a restart; the keeper still reads the deployments file.

The "missing middle" is closed (W1.5, 2026-09-28). Until this order, an accepted index application had no code path into a real pilot vault row — the queue above was live but had nothing eligible to file against. Now: an operator reviews a submitted index application (POST /admin/forge/index-applications/{id}/approve or .../reject, a reason required to reject); approval creates exactly one nw_pilot_vaults row — a spot pilot book, BSC spot venue (dex='bsc_spot'), no Hyperliquid address (there is none for a spot book) — for that maker's own index and plan, with record_start set to the approval timestamp itself (day 0 of the spot pilot (14 days by default) is the approval, not a first snapshot (the pilot clock counts calendar days from the approval timestamp; the paper book's first scored day is the next UTC day, shown as day_n 0) — a spot book has no HL account to snapshot from). No charge and no on-chain call happen at approval — the application's own maker bond already recorded the money-side intent. Once the book has run the spot pilot length (14 days by default) it is exactly what /forge/vault-flow and the vault-creation-request queue expect. A perp book (Hyperliquid main/xyz) still cannot reach created — that stays v1.2; it runs as a signal book with mirroring today.

The rename: what these design documents called Smart Vault is now the Mandate Vault, decided 2026-09-16 (docs/pm/FORGE_FUND_MAKER.md §12: "Name for the contract product: Mandate Vault... 'Smart Vault' is retired"). Chapter 22 records the archive of the product's earlier framing and name.

Self-mirroring, mechanically. A book that publishes signals (today, a paper pilot running the passive rule engine) shows a "Signals" and a "Mirror this fund" section on its vault page, /forge/vault/<id> (docs/pm/SIGNAL_MIRRORING.md). A signal is rule-driven and carries size as a target weight and target leverage, never an absolute quantity, so every follower scales it to their own account. Reading it is free once it is older than 24 hours; a signal younger than that is a paid read, 10🍒 or $0.10 in USDC, paid through your Cherry balance or through x402. The 100 free reads a day that cover token intelligence never cover a live signal. Mirroring itself is a consent record, not a deposit: POST /forge/vaults/{id}/mirrors with your own account address, your own caps (max order size, max leverage), and the rules hash you just read from GET /forge/vaults/{id}/signals; a rule change requires re-consent to the new hash. POST /forge/signals/{id}/plan turns one signal into a concrete order sized to your account's own NAV at the current mark, checked against your caps and the vault's mandate — planning a live signal costs the same 10🍒 as reading it (free once you've already paid to read that signal), and it never places an order. You execute the plan yourself, with your own trade-only agent key, and report the fill via POST /forge/signals/{id}/fills (a self-reported fill; POST /torii/order/record is open only to the operator's own account), so the vault page can show it next to the signal it followed. If the maker's own book breaches its mandate, the vault is marked mirroring_paused: signals still publish and the record stays public, but a plan for any of them comes back refused until the book is back inside the mandate. NightWatch never holds a follower's key and never places an order for anyone at any point in this sequence.

How the vault contract works today

Your deposit is pending until the vault actually buys with it. Depositing does not mint shares on the spot. Your money sits in a pending bucket, outside the vault's net asset value, while the vault buys what its mandate calls for with your money specifically. The keeper must start that purchase within 15 minutes of your deposit — it never waits for a scheduled rebalance. If someone else is leaving the vault at the same time, your cash pays their exit first, at that moment's fair value (a "crossing" — you effectively buy their slice directly, at a price nobody disputes, instead of the vault selling on the market and you buying back in), and the rest of your deposit buys the vault's target holdings the normal way. Shares are minted for exactly what was acquired — any trading cost or slippage lands on your own deposit, never on money already in the vault. If part of a purchase can't fill right away, that part stays pending and visible instead of silently disappearing; after 24 hours you can choose to keep waiting, cancel the unfilled part, or take it back as cash at that day's value. You can cancel any part of a deposit that is still pending, any time before it is spent. /forge/vault/<id> shows your own deposit's state (pending, in progress, or confirmed with the shares and cost it settled at) and a public timeline of the vault's deposit and crossing activity for everyone to read.

Withdrawals pay from cash first, then from a sale. Requesting a withdrawal puts you in a first-in-first-out line. To see where your own request stands (waiting in the queue, or paid), open Account -> My Forge (/account?tab=forge): its withdrawal queue lists each request you made, "waiting" until the vault has paid it, and reads GET /forge/vault/{id}/flows. (The vault page's Emergency withdraw panel, below, only lists unpaid requests for the in-kind exit.) The vault pays you out of whatever stablecoin it already has on hand before it sells anything; if that isn't enough, it sells a slice of its holdings to raise the rest. A leftover balance smaller than one ten-thousandth of a cent (1e-6 USDT) is written off as fully paid rather than left open forever — that dust stays in the vault for everyone still in it, it is never collected by anyone. If the person running the vault goes dark for three days with your request still unpaid, you can settle your own request yourself, and if there's still no live price to settle it against cash, you can take your pro-rata share directly in the vault's underlying tokens instead of waiting indefinitely — but only while the vault has a live, working price for its holdings; if pricing itself is broken, that path waits until pricing is fixed rather than paying out against a guess. The Emergency withdraw button. On the vault page, under Emergency withdraw, your own wallet can take the in-kind exit for you. The page reads your unpaid withdrawal requests straight from the vault contract (a request that was only partly paid is still listed), asks the contract whether the three-day mark has passed (measured on block time; the clock runs on the oldest unpaid request in the whole vault, not only yours), checks that your wallet is on the vault network (BNB Smart Chain mainnet is 56, the test network is 97), and runs the call as a dry run from your address before it lets you sign. What you get is your share of the vault net assets, that is, after what is already owed to earlier withdrawals and to fees, paid as the vault USDT and tokens it holds, with no fee and no penalty. The preview already leaves out money waiting as pending deposits and tokens held for other people; the real amount can differ slightly with price moves and rounding. This gives up your position in full: your shares are burned in the same transaction and it cannot be undone, so you confirm by typing EMERGENCY WITHDRAW. If a token cannot be sent to you, the vault holds your amount for you and the page shows a Claim button that calls claimInKind(token). The transaction is signed by your own wallet, never by NightWatch; the page shows its hash and refreshes when it lands. The one function the button calls is redeemInKind(requestId). If your withdrawal stalls for 3 days, you can take your share out yourself. When the oldest unpaid request in a vault has waited 3 days, its owner can settle it from the vault page: open Emergency withdraw, type the confirmation phrase, and sign from your own wallet. You are paid from the cash the vault holds first; whatever cannot be paid in cash is delivered in kind, as the vault's own basket tokens. A request that was only partly paid shows in the Flows list as Withdrawal partly paid, and the remainder can be claimed in kind from the same panel. Only the request's owner can do this, and the contract rule behind it is in chapter 30.

When the open market can't fill a trade, a bonded supplier can. Most of the basket (BTCB, ETH, SOL, XRP, WBNB) trades against an open, on-chain market. The rest is thin enough on-chain that the vault instead relies on suppliers who have posted a security deposit — anyone with a posted bond, not a pre-approved list, tiered by how much they've actually delivered before (see "The supply auction" below). A brand-new supplier — no NightWatch SBT yet, or an SBT that has never completed a delivery — may still bid on probation, capped much smaller (see below); an SBT is required to bid at any higher tier. When the market quote is worse than 1% away from Binance's own best price, the vault posts what it needs to buy or sell, and bonded suppliers bid for 120 seconds; the best bidder wins, backed automatically by their deposit. A winning supplier delivers through the Deliver button only — tokens sent straight to the vault's address are never counted as that supplier's delivery and are never returned to them (though if it is one of the vault's own basket assets, it still adds to the vault's holdings and benefits everyone already in it; see "A token sent to the vault by mistake" below for the genuinely stray case). Delivery can happen in more than one instalment, each at least 20% of what was won, within a 30-minute window (the very last sliver is allowed to be smaller) — except a probation award, which must be delivered in full in one single step. If a supplier delivers only part of what they won and the window runs out, the penalty applies only to the undelivered part — whatever was already delivered stands as a normal, completed trade.

A token sent to the vault by mistake is not returned. The vault only knows about the tokens named in its own mandate, plus the stablecoin it accounts in. Anything else that lands on the vault's address — a different token, sent by hand or by an unrelated transfer — is never counted toward anyone's balance and has no refund path, by design: the contract has no way to know who sent it, and a refund function would be an open door for whoever could call it. NightWatch can move a stray token out to its own treasury so it isn't stuck forever, but it never goes back to a sender.

Fees. There is no deposit fee and no withdrawal fee — the only vault fee is a performance fee, and only above a 2% monthly hurdle: a month where the vault's return stays under 2% earns no fee at all, and only the gain above that line is fee-eligible. The rate itself is fixed per vault at creation (a passive book at 2.5%, an active one between 10% and 25%) and cannot change afterward. Of whatever fee crystallises, 20% goes to the NightWatch treasury and 80% to the maker — the split, the amounts owed to each side, and the running total are public on the vault's own page. The fee is paid after the withdrawal queue: it never draws on reserved cash, pending deposits, or a depositor's own redemption, and cannot be claimed while the vault is paused.

The supply auction: open to anyone with a bond, tiered by track record

The auction exists for one situation: the vault needs to buy or sell a basket asset and the open market cannot fill it inside the price gate (1 % around the Binance best quote). Liquid assets almost never reach it; thin ones do. Everything below is enforced server-side today (the auction contract catches up in a later round — see docs/pm/MANDATE_VAULT_AUCTION_TIERS.md for the build order), so the steps are the same on every chain the vault runs on. Participation used to be a NightWatch-approved whitelist; it is now open to any account with a posted bond, a person or an agent, with your tier — starting on probation for a brand-new account, then set by how much you have actually delivered before — deciding how big a share of one auction you can win and how much bond that locks.

Who can bid. Anyone with a posted bond. A brand-new account — no NightWatch SBT yet, or an SBT that has never completed a delivery — bids on probation (T-1); a minted SBT is required to bid at Newcomer (T0) or any tier above it. NightWatch does not pre-approve bidders one by one any more — the bond and your tier are the whole gate. Your bond registers you automatically: once you post it and place a bid, the next keeper cycle checks the same rule (tier, bond, no unpaid penalty debt) and turns on your on-chain bidding registration for you — usually within a couple of minutes — and turns it off again the same automatic way the moment you no longer qualify, except while you still have an award open (a delivery already in progress is never interrupted). There is no form to fill out and no one to ask. Excluded: accounts under a compliance stop, sanctioned addresses, and any account carrying an unpaid penalty debt from a prior undelivered award.

What you post before bidding. A bond, sized to what you intend to supply — every bid is backed by a share of your unused bond, and that share shrinks as your tier rises (below). Today the bond is USDT on the vault's own chain (USDT on BSC (BEP-20)). A Cherry bond, locked once on your NightWatch account so you can bid on any chain without moving funds, is planned for v1.1 together with the share-collateral contract. Also planned for v1.1: if you both deposit into vaults and supply in auctions, a share of the treasury's take from the auctions you delivered is paid back to you in Cherry (the orderer pays the 15% fee, so there is no supplier discount); the ratio is set after the first month of live data. The very first bond you ever post must be at least $100. A USDT bond is withdrawable whenever it isn't locked against an open award.

Tiers. Your tier is recomputed daily and after every delivery or expiry, from whether you hold an SBT and from your lifetime delivered notional across every vault:

A T3 Anchor is also named on the vault's page and on the index page for whatever asset it supplies. Worked example, a $100,000 auction: a probation (T-1) bidder can win at most $100 (the cap; 1 % of $100,000 would otherwise be $1,000) and must hold $100 of bond for it; a T0 bidder can win at most $25,000 and must hold $25,000 of bond for it; a T1 bidder can win up to $50,000 against a $37,500 bond; T2 and T3 can each take the whole $100,000, backed by $50,000 and $25,000 respectively. Either way, your actual award is also capped by your own free bond divided by your tier's bond ratio, whichever cap is smaller — a T1 bidder with only $15,000 free bond can win at most $20,000 of this auction, not the full $50,000 their tier alone would allow. A bid that is over-sized or under-bonded for what the rules allow is never simply rejected: you are awarded the smaller amount the rules do allow. Your own tier, its limits, your free bond, and your delivered-notional history are on your profile page and in the auction panel itself, which also shows what is still needed to leave probation.

Starting out on probation (T-1). A brand-new account may still bid with just an account and a posted bond — no SBT required at this tier alone. The award is small on purpose: 1 % of the auction's notional, floored at $10 (roughly an exchange's own minimum order size) so a tiny auction still leaves something worth bidding, and capped at $100 so a huge auction doesn't hand a first-time, unverified account an outsized fill. The bond is 100 % of the award, same as Newcomer. The one real difference from every other tier: a probation award must be delivered in one single instalment, the full amount, inside the window — there is no partial delivery to fall back on if you come up short. Three completed deliveries, or $1,000 of cumulative delivered notional, promotes the account out of probation to Newcomer (T0) — which does require a minted SBT by then.

Falling a tier. A fill rate under 90 % over your last 20 awards, or any expiry that triggers a penalty, drops you one tier for 30 days; a second expiry inside that window drops you straight to T0 and resets the streak — this demotion floor is Newcomer (T0), never probation. Probation only ever applies to an account that hasn't been promoted out of it yet, not as a punishment. An unpaid penalty debt blocks new bids until it's paid, at any tier.

How you learn an auction is coming. A deposit shows on the vault page as "Deploying" before any purchase leg runs, so you see which assets and how much the vault is about to buy. If a leg fails the gate, the keeper leaves it queued and pages the operators; an operator sizes and opens the auction by hand, because the keeper never opens one itself. Once open, it appears in the vault page's Supply auction panel and in the public API. The on-chain event is the record.

The bid. Within the 120-second window you sign a bid for the asset, the quantity you will supply — never above your tier's max share of the auction or your bond limit, whichever is smaller — and your unit price. The price must sit inside the gate: at or below the Binance best ask plus 1 % when the vault is buying, at or above the best bid minus 1 % when it is selling. The bid is a signature, not a transaction; you pay no gas to bid. Before you sign, the auction panel (and the auction API, for an agent) shows the exact dollar figure you can bid right now — the smallest of your tier's share of this auction, your free bond divided by your tier's bond ratio, and whatever is still open on the auction — and names which one is holding you back, so you never sign a bid that can only be rejected.

Award. When the window closes, the keeper submits the winning bids once. Lowest price wins first when the vault buys (highest when it sells); at an equal price, a higher-tier bidder is favored in the tie-break. If your quantity is only partly needed you are awarded the remainder. The keeper checks each signature, the gate, your tier's share limit, and the bond, then locks your bond for the awarded amount.

If your bid is not submitted, or is awarded less than you bid. A bid can fail before it is ever stored (the API refuses it outright, with the exact figures) or be excluded by the keeper once the bidding window closes and it decides who wins — either way, the auction panel's "My bids" list shows the reason and how to fix it. Two of these codes (bond_short, over_tier_share) can also show up on a bid that WAS awarded, at less than you bid — that is not a failure, it is the same rule trimming your award to what it allows rather than turning the bid away:

• bond_short — your free bond does not cover this bid in full at your tier's bond ratio; you are awarded the largest amount your current bond does cover. Only when that comes to nothing at all is the bid excluded outright — add more bond, or bid at or below what your current bond covers, to avoid either outcome.
• over_tier_share — the bid is above your own tier's share of this auction (or, at probation, above the flat $100 cap); you are awarded your tier's cap instead. Only when that cap comes to nothing at all (an extreme case) is the bid excluded outright — bid at or below your tier's cap, or build delivery history to raise your tier.
• price_implausible — your price sat more than 10% better than the reference gate; bids this far from the market are not accepted, on either side — bid closer to the gate price.
• not_whitelisted — your on-chain whitelist registration has not caught up yet; no action needed, the keeper's whitelist-sync step runs every cycle and registers it automatically.
• price_outside_gate — your price sat outside the gate at award time; bid at or better than the gate price.
• signature_expired — your bid's own deadline passed before the keeper could award it; sign and submit a new bid with a later deadline.
• nonce_used — the bid's signed nonce had already been used; sign and submit a new bid with a fresh nonce.
• outbid — other bids at better prices filled the auction's quantity first, with nothing left over for yours; bid a better price next time, or try the next auction.
• vault_unavailable — the vault or chain could not be read when awards were decided; no fault of your bid, it is safe to bid again.
• auction_expired — the auction's own bidding-plus-award window closed with no award sent at all; your bid was not used, you may bid again on the next auction.

Delivery, within the 30-minute window. Every tier gets the same 30 minutes — this replaced the earlier 10-minute window (itself a replacement for a 60-minute window and an earlier idea of a longer window as a tier advantage) once NightWatch chose a deliberately comfortable margin over the bare minimum: on BNB Smart Chain, today's only live vault chain, a settled exchange-to-exchange transfer lands in about a minute and a half at the 90th percentile, so 30 minutes is a wide margin for someone who already holds the inventory, not a formality — an exchange withdrawal started only after the award will usually not arrive in time regardless. You deliver through the Deliver action on the vault page. It pulls the tokens from your wallet into the vault and pays you the awarded price in USDT in the same transaction, and releases the matching part of your bond. When you buy tokens from the vault instead — the vault is selling, not buying — the flow runs the other way: the bond released by your delivery is applied to your payment first, so you need the purchase amount in total on hand, not your bond plus the purchase on top of it. You may deliver in parts: each delivery must be at least 20 % of what you were awarded, except the final remainder, which you may deliver in full whatever its size — except on probation, where the entire award must go in one step (above). You cannot deliver more than you were awarded; only the quantity you name is pulled. Tokens sent straight to the vault address (instead of through Deliver) are not counted toward your award and are not returned to you — since it is one of the vault's own basket assets, it still becomes part of the vault's holdings for everyone already in it, it just doesn't pay you for it.

If you do not deliver in time. Only the undelivered part is charged, from your locked bond, in two pieces: the price shortfall the vault suffered (the difference between the gate price at expiry and your award price, if the market moved against the vault; zero if it did not) is paid to the vault, and a fixed 0.5 % of the undelivered notional is paid to the NightWatch treasury. The two together never exceed your locked bond, and the vault's compensation is paid first. What you did deliver stands as a normal fill; the remainder goes back to auction, and an expiry with a penalty is exactly what can drop your tier (above).

One at a time. A vault runs one auction per asset at a time. A Newcomer (T0) may hold up to 3 open awards at once; above T0, your unused bond is the only limit on how many auctions you may bid in at once.

Who does what

Six roles touch a Mandate Vault. Each one is described here by what it does, what it can do, and — just as important — what it cannot do, with the mechanism that stops it named plainly: a contract check, a factory role, the keeper's own code, or a NightWatch policy that isn't in the contract at all. The chapter-level whitepaper below (chapter 30) has the full mechanics behind every one of these; this section is the plain map of who is who.

Depositor. You put stablecoin in and, eventually, take it (or your share of the vault's tokens) back out.

• Can: cancel any part of a deposit that's still pending, any time before it's spent; after 24 hours, choose to keep waiting, cancel the unfilled part, or take it as cash at that day's value; queue a withdrawal and get paid cash-first, then from a sale; self-settle your own request if the person running the vault goes quiet for three days; redeem in kind (your pro-rata share of the vault's actual tokens) once a live price exists, even during that outage. The vault page Emergency withdraw button covers only the in-kind exit (redeemInKind), signed by your own wallet; settling your own request for cash, cancelling a request and the 24-hour deposit choice are separate actions and are not part of that button.
• Cannot: get shares the instant you deposit — deposit() itself never mints a share, only the keeper's later purchase does, so your money is never "in" the vault at a price nobody agreed to; jump the withdrawal queue, other than the emergency paths above; be charged a fee on the way in or out — there is no deposit-fee or withdrawal-fee code path in the contract at all, only the performance fee described below. Pilot limit: this vault accepts at most $100 per depositor. That cap is NightWatch policy enforced by the allowlist, not the contract — the contract only enforces a $1,000 total vault cap, so during this pilot the allowlist is the real backstop, not a number written on-chain per depositor. There is no on-chain minimum deposit — deposit() accepts any positive amount — but the deposit screen recommends $10 as a practical floor.

Maker. You register a mandate — which instruments, what limits, how it rebalances — and the vault is built around it.

• Can: rotate your own owner address; collect 80% of every performance fee the vault crystallises, paid to the address you registered; post your maker bond at vault creation on a mainnet vault (in on-chain USDT on BSC (BEP-20); on testnet today the bond is recorded, not collected, and the application only records the amount in USDC terms; a Cherry bond is planned for v1.1).
• Cannot: touch a depositor's money — the owner role has no function that moves vault assets to itself; the only payment it ever receives is claimFees(), which pays out already-crystallised, capped fee amounts to a fixed address, never an arbitrary withdrawal; change your fee rate, instrument list, or mandate after the vault opens (frozen at creation, no setter exists); pause, unpause, or retire your own vault — that switch belongs to NightWatch's factory admin, not to you. Before opening, you must post a bond of 25% of the vault's deposit cap, minimum $100 — $250 in this pilot's $1,000-cap vault. The bond is collateral only — never a share of the vault, it earns nothing while posted, and it is refunded to you in full minus any penalty. A penalty applies only for plan falsification (what you publish doesn't match what the vault does), breaching the pilot's own mandate, or retroactively editing a published record — never for a keeper or NightWatch operational error, which is NightWatch's own responsibility. The NightWatch operator adjudicates every case publicly, with a written reason, and pays back any affected depositor first.

Supply-auction supplier. You post a bond and step in on the rare leg the open market can't fill.

• Can: bid up to your tier's share limit and whatever your free bond allows, whichever is smaller (see the tier table above); deliver in installments, each at least a fifth of what you won, except the last piece; withdraw whatever part of your bond isn't locked against an open award, any time.
• Cannot: bid outside the price gate (an out-of-range bid is rejected at award); win more than your tier and bond allow — checked by the auction contract itself at award(); walk away from an undelivered award for free — the penalty on the undelivered part is charged automatically and permissionlessly the moment the delivery window passes, by anyone who calls expire(), not by NightWatch. A newcomer with no SBT or delivery history bids under the separate, more limited probation tier in the table above.

NightWatch team & treasury. The team holds the keys that operate the factory; the treasury is where the platform's cut lands.

• Can (factory admin, held on a CDP-managed key): open new vaults, pause, unpause, or retire one, add or remove a depositor from the allowlist, rotate the settler (keeper) key, mark a persistently-unpriced asset impaired (and clear that flag once it's priced again), and sweep a stray token — one that is neither the vault's stablecoin nor anything in its mandate — out to the treasury, since the contract has no way to know who sent it or return it. The treasury itself receives 20% of every crystallised performance fee, the flat 0.5% penalty piece of an auction expiry (the loss-compensation piece goes to the vault, not the treasury), and fronts the on-chain stablecoin seat for any bond a whitelisted maker or supplier pays in Cherry.
• Cannot: move a depositor's funds anywhere — no admin function transfers vault assets to an arbitrary address; every money movement in the contract (deposit, withdrawal, rebalance, auction, fee, stray sweep) pays only to an address the vault already has fixed, never one the admin supplies on the spot. Change a live vault's fee rate or mandate. Upgrade a deployed vault's logic — each vault is a fixed, non-upgradeable clone; a new version means a new factory and new vaults, not a patch to the ones already running. Configuration note: on mainnet, the four keys below (settler, snapshot signer, factory admin, treasury) must be set to four separate addresses by hand at deploy time — the deploy script does not refuse to proceed if they're left unset and quietly collapses them onto one key instead, which would undo this separation. This is a deployment checklist item, not something the running contract can be tricked into.

Keeper automation. An automated key (not a person clicking buttons) does the routine work: starting a deposit's purchase, batching withdrawal payments, running a rebalance, posting price snapshots, and submitting auction awards.

• Can: call deployPending, settleWithdrawals, rebalanceSwap, crystalliseFees, and openAuction/award on the auction contract — all under the settler key; sign price snapshots — under a separate key that is never the settler and never NightWatch's admin wallet (that admin wallet can't produce this kind of signature at all).
• Cannot: send a depositor's or the vault's money anywhere except the fixed destinations each of those functions already pays — its own request's owner, the maker, the treasury, or an auction counterparty; withdraw anything for itself.
• If it stops running: nothing is stuck waiting on it forever. A deposit pending more than 24 hours can be resolved by the depositor themselves (cash back, or shares at that day's value). A withdrawal request that's sat unpaid for three days can be self-settled by its own owner, and — once a live price exists — redeemed for a pro-rata share of the vault's actual holdings. The keeper is a convenience that makes both of those unnecessary in the normal case, not a single point that can trap anyone's money.

Oracle. A per-chain price feed (Chainlink) plus the keeper's own signed snapshot, combined into one fair price and one trading gate that every buy or sell — swap or auction — has to clear.

• What it does: for NAV, blends the valid live sources into one fair price per asset. For trading, sets a gate — buy at or below the market's best ask plus 1%, sell at or above its best bid minus 1% — that only opens when the keeper's snapshot is fresh (30 seconds or less) and agrees with the independent Chainlink anchor within 1%.
• If it goes quiet: a stale snapshot alone just closes the trading gate for that leg (it falls to the supply auction instead) — it does not touch NAV. If a held asset's own Chainlink price goes stale for more than a day, NightWatch's factory admin can mark that one asset impaired, valuing it at zero so the rest of the basket keeps pricing normally and withdrawals keep moving; the moment a real price comes back, that asset resumes at its live value automatically, whether or not anyone bothered to clear the flag.

What is planned

Guardrail Live (v1.1). Today a vault's adherence to its mandate is scored once a day by the X-ray (chapter 14). In v1.1 the same yardstick runs continuously: a house judge reads every execution as it is recorded, compares it with the submitted operating intent, and posts a verdict with its probability in the vault's Hive room, labelled "judged by the house AI, calibration pending" until a month of agreement records has been published. The gate applies to every order, the rule engine's and the operator's alike: holding the operator SBT gives the right to state what to buy and sell, and a house execution agent carries a passed intent to completion. The whitepaper (chapter 30) has the full description.

House money follows a published rule (decision 29). NightWatch's own treasury (the 1% treasury share of Obsidian Cherry purchases, realised Cherry conversions, and forfeits) invests 70% of itself in Mandate Vaults and keeps 30% as an uninvested stablecoin buffer; the invested part is split 80% core and 20% seed. A vault qualifies for core house capital, with no separate waiting period, once its promotion review has passed, its compliance score is 90/100 or higher, and its anchored daily record has no gap. House money is capped at 25% of the treasury in any one vault and 30% of that vault's total. A new manager qualifies for seed capital once the promotion review has passed and the record shows at least 30 days of paper operation: a $500 ticket, raised to $1,500 after 30 days without incident, moving to core once the core rule is met. Seed pays NightWatch a performance fee only, one seed allocation per maker SBT, and the manager co-invests from no more than 10%, set by fund type and the maker SBT's track record, stepping down with each review passed. A vault page discloses house money in it as "house capital $N" or "house seed $N". The redemption reserve behind Obsidian Cherry is never invested. Full rule: REWARD_POLICY_V1.md decision 29.

Mandate Vault v1, together with a manager SBT (chapter 24), is planned for v1.2 — the version table in About this guide is the source for that placement. v1.2 is where deposits open past the current whitelisted-small-deposit stage to the public, with a manager SBT tying each vault to a verified maker identity, on the Hyperliquid vault convention for profit sharing described above (FORGE_FUND_MAKER.md §11-§12).