Skip to content

Capital and treasury

The desk trades with its own capital, in two pools: on-chain tokens in a set of hot wallets (what it pays out from when it fills), and stablecoin collateral on exchanges (what backs its hedges). This page explains how that capital is held, how it gets in, how it is protected, and how it moves.

COLD STORAGE hardware wallet, offline keys NEVER touch the system operator-signed moves only HOT WALLET POOL wallet 0 · NIGHT + tokens + DUST wallet 1 · NIGHT + tokens + DUST wallet N · one secret = one wallet N wallets = N parallel fills ON-CHAIN ESCROWS fills lock desk capital; claims recover it plus the user's deposit EXCHANGE COLLATERAL stablecoin margin backing hedges, polled per venue REBALANCE TICKETS balance below floor / above ceiling / collateral low proposed by the system, approved by a human top-up fills claims return collateral top-up approved → signed offline
Figure 6. The capital circuit. The system detects when money needs to move and files a ticket; a human approves; the actual movement is signed from cold storage, on hardware the system never touches.

The hot wallet pool

The desk's on-chain capital lives in a pool of hot wallets. The pool has three properties:

  • Keys live in a secrets vault. Each wallet's key material is one entry in a cloud secrets vault. The pool's size is simply how many entries exist: an operator adds a wallet by adding a secret, and the running system detects the change and brings the wallet online, live, with no redeploy. Rotation works the same way. From each key the system derives a spending key and, separately, a read-only viewing key. All monitoring and balance-watching uses only the viewing keys, so the components that watch money cannot move it.
  • One wallet, one trade at a time. Each fill is assigned to a wallet at quote time (the wallet with the deepest available balance takes the reservation), and a wallet processes one transaction at a time. Two fills can never contend for the same coins, and N wallets means N fills can settle in parallel.
  • Failures are isolated. Each on-chain action is isolated, so a failure affects one transaction, not the wallet. Heavy wallet synchronization runs off the trading path, and an interrupted sync resumes where it left off rather than starting over.

How money gets in, and how the desk pays fees

Funding is one-directional: the operator sends tokens from cold storage to a hot wallet's address, and the system notices. The scanner watches every wallet through the chain indexer and streams balance changes into the inventory ledger. There is no deposit endpoint and nothing that can pull funds.

On Midnight, transactions cost DUST, a resource that regenerates over time from holding NIGHT, the network token. Each hot wallet therefore keeps a NIGHT balance as its fee generator. A wallet with depleted DUST refuses fills with an explicit needs-funding signal rather than failing cryptically mid-transaction.

Wallet holds NIGHT the network token DUST regenerates continuously, over time Fees get paid every fill and claim costs DUST spending draws it down; holding refills it A wallet at zero DUST refuses new fills with an explicit needs-funding signal, never a cryptic mid-transaction failure.
Figure. Fees are self-sustaining: each hot wallet's NIGHT balance is its fuel tank, and the gauge is visible in the console.

Knowing when money needs to move

Every wallet has, per token, a configured operating band: a low bound and a high bound, editable live from the console. Falling below the low bound raises a refill signal (cold storage should top this up); rising above the high bound raises a sweep signal (excess should move to cold storage).

Alongside the bands, three automatic detectors file formal rebalance tickets: the on-chain pool for a pair dropping below its reserve floor, an asset breaching its configured pool floor, and a hedge venue's free collateral falling below its minimum.

Moving it: the ticket workflow

A rebalance ticket names the asset, the amount, the source and destination (cold storage, the on-chain pool, or a named exchange), the reason, and expires in 48 hours if ignored. It then walks a strict workflow: proposed → approved → executed, with the operator identity and timestamp recorded at each step, and rejection always available.

The system never executes the movement itself. An approved ticket is carried out by the operator, signing from cold storage on their own hardware; the signed transaction's hash is then recorded on the ticket. The system detects when money should move and holds the audit trail, and the signing keys never touch a networked machine.

PROPOSED by the system, reason attached APPROVED by a human operator EXECUTED signed offline from cold storage EXPIRED ignored for 48 h REJECTED with a written reason tx hash recorded on the ticket Every transition records who and when. The system never moves the money itself.
Figure. The life of a rebalance ticket. Detection is automatic; judgment and signing stay human, on hardware the system never touches.

Counting it

The inventory ledger tracks every balance as an exact integer in the token's smallest unit, end to end; it never uses floating-point for money. Midnight's two balance forms, shielded (private) and unshielded (transparent), are tracked separately and never summed, because they are not interchangeable on-chain and a merged figure would overstate what the desk can spend.

Reservations against inventory are atomic: two quotes can never claim the same coins. They release on fill, expiry, or cancellation, and a periodic sweep releases anything a missed event left behind. If reservations ever add up to more than the wallet holds, that indicates a bug elsewhere, so the system raises an alert rather than clamping the free balance to zero and hiding the discrepancy.