Delegation Ladder L0-L5

Status: draft · last updated 2026-09-11

This chapter has two layers, and it is important not to blur them.

The first layer is a vision: an internal document, still being finalized, that describes six levels of delegation from a human doing everything to an AI running its own book. That document is a planned frame for thinking about the product, not a switch you can flip in the app today. NightWatch does not have a screen today where you pick "L2" versus "L4" by name.

The second layer is what is actually built: a specific set of real, working controls (agent keys that cannot withdraw, a two-step propose-then-confirm flow for real-money orders, per-order and per-day dollar caps, and a master trading control) that together implement pieces of that vision today, mostly in the Torii trading path and the Telegram order path. This chapter describes the vision briefly, then spends most of its length on the controls that actually exist, because those are the ones that matter if you are deciding how much to trust an AI with.

The vision: six levels

NightWatch's internal vision document frames delegation as a separate axis from what work is being done (planning, execution, feedback). The six levels it defines:

The document's stated position, quoted directly because the wording matters: "Delegate everything. Transfer nothing. Your keys stay yours. Your AI runs under your authority, within boundaries you set and can revoke at any time." It names three mechanisms as how deeper delegation is meant to be made safe: scoped agent keys (a key that can place orders but can never withdraw), client-held signing keys, and confirm-before-execute modes. All three of those exist in NightWatch today, described below - they are simply not yet organized on-screen as a single named "L0 through L5" selector.

What actually gates an AI's trading today

Two trading paths carry real controls: the Torii order path and the Telegram order path. Both sit behind a master trading control, both enforce dollar caps, and both use a compare-and-swap database write so the same pending order cannot be executed twice.

The master trading control

The Torii path has a single master control that must be turned on before a new or size-increasing order will go out; while it's off, every such order is rejected before anything else is checked, and this check always runs first. A deliberate carve-out lets a reduce-only order (one that can only shrink an existing position, never grow it or move funds out) go through even while the control is off, specifically so a person is never trapped holding a position they cannot close. That carve-out is still bounded: it is checked against an independent position-direction proof read from the exchange itself, capped at an absolute ceiling, and rate-limited, described next.

Today, this control is what stands between "trading for all accounts with your own key" (planned for v1.1) and where NightWatch is now: live order placement through the web terminal currently works only for the operator's own Hyperliquid account. See the Trading chapter for the full picture of what's live today.

Per-order and per-day dollar caps

The Torii path runs two separate cap regimes side by side, chosen by how the caller is authenticated, not by any value the caller sends:

Which regime applies is decided server-side from how the request was authenticated, never from a value the client claims about itself, and an order's regime is fixed at the moment it is created and re-read from storage at execution time - so a human approving an AI-created order cannot accidentally inherit the AI's tighter pooled cap, or vice versa.

The Telegram order path has its own, separate, smaller set of caps:

As on the Torii path, a verified reduce-only close (checked against the exchange's own reported position, not just trusted from the request) is exempt from the daily dollar and count caps but still bounded by its own ceiling and by a separate rate limit (three closes per minute per account and coin) so that exemption cannot become an unbounded stream of orders while the master trading control is off.

Propose, then confirm: how an AI actually places an order

The clearest concrete implementation of "human approval per action" is a pair of tools exposed over MCP, deliberately hidden from the public tool list an AI sees:

• place_hl_order validates the request, applies the hard size cap, and writes a pending order. By design, it never places the order and never returns a confirm code.
• confirm_hl_order executes a pending order, but only when given a 6-digit code delivered out-of-band to a person (through Telegram or a toast notification inside Torii). By design, there is no "reply CONFIRM in chat" path: the confirm code is invisible to the initiating AI.

In other words, an AI can prepare an order but cannot see the code needed to fire it - a human has to be the one who received that code and typed or tapped it. A pending order also expires on its own after five minutes if nobody confirms it.

Test network before real money

By default, the Torii trading path points at Hyperliquid's test network rather than real markets, until the operator switches a specific account to mainnet. NightWatch treats "test network first" as a deliberate safety choice, not an oversight.

Who is allowed to trade at all

Both order paths check an allowlist before anything else about caps or approval applies. On the Torii path, an empty allowlist denies everyone by design; a user ID or wallet address must appear on it before any order is considered. The Telegram path also reads a Cloudflare-supplied country signal and is capable of rejecting requests from a set region, but that regional block is not turned on today - no Telegram trading request is rejected by country in this version. NightWatch treats this deliberately: the Telegram path is an interface to a non-custodial exchange (Hyperliquid), not a custodial trading service, so a blanket country block has not been applied.

What signing keys the system can and cannot touch

Every cap and confirm step above sits in front of an agent key that is trade-only and never a withdrawal key: if that key isn't set up, the server simply cannot place orders, and nothing in this system ever asks for or stores a key capable of moving funds out of an account. This matches the vision document's claim that a delegated AI's key can place orders but can never withdraw.

What this means in practice, today

Put together, an AI connected to NightWatch's trading tools today operates somewhere between the vision's L3 and L4: it can research, form a view, and even prepare a specific order on its own, but a real order past the pooled agent's small caps needs a human to supply an out-of-band code the AI cannot see, and every order of any kind is blocked outright unless the master trading control has been turned on for that path. There is no built setting today that lets a person hand an AI full L5 "runs its own book" authority - the closest thing to that would be raising the bearer per-order cap in $5,000 steps and never asking for confirmation, which NightWatch does not currently support (confirmation is only ever skippable through the master trading control itself, which stops everything, not just the checks).

What you can do now

• Ask whoever runs your NightWatch deployment whether live trading is currently turned on for the Torii and Telegram paths - that single control decides whether any AI-initiated order can execute at all.
• If an AI proposes a trade through place_hl_order, expect a pending order, not an executed one; the 6-digit confirm code will arrive to a human channel (Telegram or a Torii toast), never to the AI itself.
• Check which cap regime applies to any account you are watching: a pooled agent key is capped far lower ($20/order, $100/day by default) than an individual signed in with their own session ($5,000/order, $25,000/day by default) - and remember the $25,000 daily figure has not yet been finalized as settled policy.
• Do not rely on a region gate to block trading from a specific country - in this version, NightWatch does not block Telegram trading by country at all.
• Treat the L0-L5 ladder described above as a roadmap for how delegation is meant to deepen, not as a feature that exists on a settings screen today.