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.
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 on /forge/new 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 and stop adherence, plus every breach listed by time, instrument and rule broken (FORGE_FUND_MAKER.md §10.2-10.3) — and publishes it on the maker's page alongside the book's X-ray (chapter 14).
What is live before the contract 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. What is not live yet is the vault contract itself: a smart contract that pools follower deposits, trades on their behalf inside the registered mandate, and settles profit share automatically. docs/pm/SMART_VAULT_DESIGN.md is marked DRAFT, explicitly "no implementation before Robin's approval," and describes a HyperEVM ERC-4626-style contract with zero Solidity written yet (SMART_VAULT_DESIGN.md §0, §2). Today a follower can only read a maker's record and mirror it by connecting their own account — no deposits flow through NightWatch.
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🍒 ($0.10), metered the same free-tier → Cherry → x402 way every other paid read on the site is. 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 /torii/order/record with the signal's id attached, 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. Deposits — the pooled-vault stage below — remain v1.2.
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.
What is planned
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. That release is the pooled-deposit contract stage: followers depositing directly, automatic settlement, and profit sharing against a high-water mark, on the Hyperliquid vault convention (FORGE_FUND_MAKER.md §11-§12).
How shares get issued, once deposits are live. Your shares are issued for what the vault actually bought with your money; until then your deposit is pending and can be cancelled. A deposit does not mint shares on the spot — it 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 vault must start on that purchase within 15 minutes of your deposit, not wait for the next 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 a market and you buying back in), and the rest of your deposit buys the vault's target holdings the normal way. Shares are then minted for exactly what was acquired — any trading cost or slippage lands on your deposit, never on money already in the vault. If part of a purchase cannot fill right away, that part stays pending and visible rather than 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.