The Auction House: The Floor

What this chapter covers

The Floor is NightWatch's open supply auction house at /market: anyone can open an order to buy or sell a listed token, and anyone who has posted a bond can bid to fill it. This chapter covers who does what (orderer, supplier, treasury), how the reference price and the three price modes work, how tiers and bonds work, what it costs, how an order runs across rounds until it's filled or its own caps run out (you re-open each round yourself, from your own wallet — nothing does that for you), a remainder floor that decides whether an order can open or re-open at all (it never changes an award), how a leftover within one round gets handled (a keeper-driven DEX fallback within the tolerance you set when you opened it, or a self-serve refund), and what a fill's receipt shows. It absorbs and replaces the earlier "supply auction" framing that lived only inside the Mandate Vault (chapter 27) — the vault is now one orderer among others on the same floor, not the only one.

What it is

Most of the time, a token trades on the open market at a price everyone can see. Sometimes an order is too large, or the token too thin on-chain, for the open market to fill it well. The Floor exists for that case: an orderer (a person, an agent, a treasury, or a vault) escrows what they're offering — USDT to buy, the token itself to sell — and opens a timed order. Anyone who has posted a bond can bid. The best bid that beats the reference price wins and delivers; a bid is never even eligible to win at a price worse than the reference (or your own limit, whichever is stricter) — that bound is enforced on-chain the moment an award is made. Whatever doesn't fill this way — no bid beat the reference, or part of the order was left over — is handled the way "Unfilled remainders" below describes; it does not refund itself automatically.

The desk: three order sources, two execution paths

Every order that ever reaches The Floor carries a source, but — decided 2026-09-28 after the P0 build was already underway — they do NOT all execute the same way. A vault order never becomes an AuctionHouse order at all; it executes through the vault's OWN existing on-chain path instead. There is no separate dealing station for an operator either way:

• VAULT·AUTO — the vault's own keeper triggers one for a stated reason: rebalance (the basket drifted from its mandate), deposit (new cash needs to buy in), or withdrawal (cash needs to be raised to pay one out). This ships in v1.1 — no code path creates these rows yet.
• VAULT·MANUAL — a vault operator queues one directly, inside their vault's mandate room (below), from the My desk tab. Queuing, listing, and cancelling a queued order are LIVE (signed, cancellable). The vault's own keeper evaluates every queued row each cycle against the remainder floor; actually EXECUTING one via rebalanceSwap is v1.1 (see "The remainder floor," below, for what that needs).
• ORDER — anyone else (a person, an agent, a treasury) opens one with their own escrow directly on the AuctionHouse contract, exactly as the rest of this chapter describes. This is the ONLY source that ever touches AuctionHouse.

How a vault order executes. A VAULT order — AUTO or MANUAL — is one leg of the vault's own basket: buy or sell one listed token with the vault's own cash. It executes through SpotMandateVault.rebalanceSwap, the exact same on-chain call the vault already uses for its own automatic rebalancing — the vault contract itself checks the leg against its mandate (the token must be on its allow-list, a per-leg size ceiling, and a ±1% price gate) before it ever moves anything. If the on-chain price gate rejects the leg (the AMM price has drifted too far), the fallback is the vault's own BondedSupplyAuction — bonded suppliers bid for it exactly like any other vault-sourced supply auction (chapter 27) — but opening that fallback auction still needs a human to size it today, for a VAULT·AUTO leg exactly as much as a VAULT·MANUAL one; nothing here auto-opens one (v1.1). Vault cash and any tokens bought never pass through anyone else's wallet — they move directly between the vault contract and the AMM or auction, same as every other vault-authorized action already works. Considered and rejected: routing vault orders through AuctionHouse with the vault's settler wallet acting as orderer — that would have put vault USDT in a settler-held hot wallet and made every vault share one wallet's own AuctionHouse limits. Neither is true of the path actually used.

Which key executes it. The vault's own settler key — the SAME key that already sends every other vault-authorized action (rebalancing, settling withdrawals, claiming fees) — sends the rebalanceSwap (or, on gate failure, whatever opens the fallback auction). No new key, no new role grant, no change to the vault contract at all.

Who's allowed to sign a MANUAL order. Placing, listing, or cancelling a VAULT·MANUAL order requires an EIP-712 signature from the vault's current, on-chain owner() — checked with a live read against the vault contract itself, cached for up to 60 seconds, every time. The vault uses Ownable2Step, so a transfer only takes effect once the new owner calls acceptOwnership; within 60 seconds of that call, the new owner can sign and the old owner no longer can, even before anyone updates any off-chain record. If that live check can't be made — the chain node is unreachable, for instance — the request is refused outright rather than falling back to any stored value.

Mandate room (server pre-check). Before a VAULT·MANUAL order is even queued, the API checks it against three things: the token must be on the vault's own mandate allow-list (an empty allow-list means every P0-listed asset is allowed); the order's dollar size must fit what's left of the vault's monthly turnover room; and it must fit the live per-symbol cap the reference oracle publishes for that token — an unconfigured cap blocks the order rather than letting it through unchecked, and because the cap applies per order, a large order can in principle be split into several smaller ones to stay under it (the monthly turnover limit still catches that). Monthly turnover room defaults to 100% of the vault's own NAV on file per calendar month (a vault's own mandate can set a different share instead) — today that NAV is an ops-maintained figure, not a live on-chain read; a vault with no NAV on file yet is rejected rather than treated as unlimited. My desk shows this as "room left this month." This is a UX pre-check only — a fast, plain-English rejection before ever asking the vault's own on-chain path to try — the vault contract enforces its own mandate on-chain regardless of what this check already found. There is no leverage on this desk at all: every leg is 100% cash, so there is no borrowed leg for a leverage check to even apply to. A signature authorizing a queued order is valid for 5 minutes from when it was signed.

Orderer daily and per-auction caps (ORDER-source, ratio-based, v1.1 for enforcement). An AuctionHouse orderer's daily cap is designed to be the larger of a $5,000 pilot floor or 25% of the free supplier bond pool (the unlocked USDT bond of every registered, screened, active supplier — one shared pool, not per token). A single auction's own cap is designed to be the smallest of the oracle's symbol cap, 10% of that same pool, and the on-chain per-auction ceiling (kept at $1,000 through P0, raised by an admin as the pool grows) — when the pool is still empty, the 10%-of-pool term simply drops out rather than capping every auction to $0, so the on-chain fallback path can still fill orders. The math for both lives in svc/common/auction_house_caps.py and is fully tested; wiring it into the screening/auction-opening path itself is v1.1 — today the only cap actually enforced is the on-chain $1,000 per auction.

Cancel before execution. A queued VAULT·MANUAL order can be cancelled any time before the vault's keeper picks it up — if it hasn't been picked up yet, the cancellation is immediate. Once picked up, a rebalanceSwap leg is a single atomic on-chain call (not a multi-stage bid/award process), so there's nothing left to cancel by the time it's sent; if it instead falls to the vault's own BondedSupplyAuction fallback, cancelling follows that auction's own rules (chapter 27) — before an award lands, not after.

The three roles

Orderer. Opens an ORDER-source order with an escrow, picks a price mode (below) and what happens if it doesn't fully fill, and can cancel any time before an award lands. Cannot pick who fills it, cannot cancel after an award. A screening check signs a compliance pass/fail for the wallet, not a spending limit — the daily and per-auction caps described above are a separate rule, not something the screening step itself enforces yet. A vault is never an AuctionHouse orderer — see "The desk" above for how a vault's own orders execute instead.

Supplier. Posts a bond (as little as $100 to start), then bids on open orders. A winning bid locks part of that bond and must be delivered — at least 20% per instalment, inside a 30-minute window — through the Deliver button only; nothing sent directly to the order's escrow address counts. A supplier who wins and doesn't deliver in time is penalized (below). Suppliers pay no fee to bid or deliver.

Delivery is a contract call, not a transfer. deliver() has to be sent from your own bidder wallet — the same wallet that won the bid — and it pulls the token from that wallet itself; it isn't something you can hand off by simply sending tokens to an address. If you bought on several exchanges, withdraw everything to your bidder wallet first, approve the token, and call deliver from that same wallet inside the 30-minute window. Tokens sent straight from an exchange, or from any wallet other than the one that won the bid, are stray: they never reach the order and never count as delivered, and NightWatch sweeps them to treasury on the vault side rather than trying to guess whose they were. After the v1.1 contract deploy, a second call, deliverFor(), lets a wallet-for-hire (a custody or automation wallet) deliver a Buy award on the winning bidder's own behalf — it pulls the owed token from THAT wallet, never the bidder's, and payment plus bond release still land on the bidder exclusively; a delivering wallet can never exceed the award's own remaining quantity or redirect the payout to itself. A Sell award is different: this house always settles a Sell delivery out of the winning bidder's own cash bond, so nothing stops a random wallet from bringing zero funds of its own and forcing that settlement anyway — deliverFor() therefore still requires the bidder's own wallet on a Sell award, the same as plain deliver(). Either side, the caller can never be the order's own orderer. Exchange-direct transfers still won't count even then. One-click Deliver from this screen — signing and sending approve + deliver/deliverFor for you — is a v1.2 candidate; today, a row's own Deliver button opens these instructions and you send the calls from your own wallet directly.

What delivery actually costs you. Before you sign a bid, The Floor's own Bid panel fetches and shows an all-in cost preview: the exchange's own withdrawal fee for your delivery route (or "fee unknown — route excluded" if NightWatch has no fee on file for it), the live BSC gas cost of approving the token once plus calling deliver, and net = (your bid price − that route's own exchange price) × quantity − withdrawal fee − gas — your own spread against selling or buying on your own exchange instead, never the orderer's side of the trade. The orderer pays their own 15% price-improvement fee separately; it is never subtracted from your number. A net at or below zero is flagged plainly, before you sign anything. Delivering your whole award in one call, when you can, avoids paying that gas cost again for a second partial delivery. The route price itself is, for now, approximated from the same cross-exchange reference the order uses — a live price feed for your own specific exchange is v1.1.

Treasury. Receives the orderer's fee when there is one, and the 0.5% penalty on an undelivered award. Has no say in who bids, who gets awarded, or how a bond is used.

A screening check runs on both sides — orderer and supplier — before either can act; it fails closed with a plain "this wallet cannot place orders" rather than a reason, and clears again automatically once the underlying check passes.

The reference price

The reference is the best bid/ask across seven identity-verified exchanges, with Binance's own price always shown alongside it for comparison on every receipt. It is anchored on-chain (Chainlink where one exists, a DEX time-weighted price otherwise) so a single exchange's bad print can't move it. A bid must be at or better than the reference — and at or better than the orderer's own limit — to ever be eligible; there is no path to an award worse than the reference.

Three ways to set your price

Opening an order asks for what, how much, and one of three price modes:

1. Follow the market (the default). No price entered — the order won't fill worse than the reference at the moment of award. An optional slack, 0 to 50 basis points, widens that a little for a better chance of filling.
2. Fixed limit. An absolute price. The order fills at whichever is stricter, the reference or your limit.
3. Fill or fallback. Fills what it can within the reference, then tries to send whatever's left to a DEX within a tolerance you set when you opened the round (25 basis points by default) — that tolerance is fixed for the round the moment it opens and can't widen later. Whatever still doesn't clear is refunded; see "Rounds" below for what happens to that leftover next.

Every order also picks how it handles not filling completely: allow a partial fill (at least 20%) or require all-or-nothing. The bidding window itself is fixed on-chain (2 minutes, plus a short grace period for the award) and cannot actually be extended; if nobody has bid by the time it closes, the keeper gives it one extra check before moving on to expiry or the DEX fallback, purely so a bid that lands right at the edge isn't missed.

Tiers: how much you can supply, and how much bond it takes

A supplier's tier sets two things: the largest share of one order they can win, and how much of that award has to be backed in cash versus how much can be backed by vault shares instead.

Tier is recomputed from a 90-day rolling delivered notional across every order and vault auction combined — an undelivered award is subtracted, so slashing lowers a tier the same cycle it happens. A brand-new supplier's very first award is capped at $500 and must be delivered in one single, full transfer — shown as a badge on that supplier's own seat and as a bidder-tier count on the orderer's board, so nobody mistakes a first-timer's small fill for a limit on the order itself.

Fees

An orderer pays 15% of the price improvement they actually got against the reference, capped at 0.3% of the fill's own notional — zero if there was no improvement, zero on a fallback fill, and never more than that cap even on a large improvement. Suppliers pay nothing to bid or deliver. A supplier who wins and fails to deliver within the window is penalized: they cover the orderer's shortfall first, then pay an additional 0.5% penalty to the treasury, drawn from their locked bond (cash first, then pledged vault shares, with a treasury backstop pool covering any gap while a share sale settles).

Rounds

An order isn't one shot — it's however many rounds it takes to fill it, or until you stop. Each round is a complete, fresh on-chain auction for whatever is still unfilled: a 2-minute bidding window plus a 30-second award grace, the reference price re-anchored (live gate, no more than 30 seconds old) the moment that round is awarded. Contracts have no idea a "next round" exists — every round is its own separate on-chain order, opened by openAuction, and openAuction makes whoever calls it the orderer and pulls escrow from their own wallet. That means you open every round yourself, from your own wallet, the exact same way you opened round 1 — nothing on NightWatch's side can ever open the next one on its own authority. Your escrow refunds at the end of a round; opening another one means signing and escrowing again. The one exception is a round that nobody won (zero awards): in v1.1 it can be reopened on the same order, keeping the escrow already posted — see "reopen," below.

With v1.1, a bid only ever counts inside the round it was signed for. Every signed bid carries its own deadline, and the v1.1 contract refuses to award any bid whose deadline reaches past the CURRENT round's own end (the moment it opened, plus the 2-minute bidding window, plus the 30-second award grace — exactly on that instant is still fine, only later is refused). That check alone only compares a bid against whichever round is being awarded right now — it has no way to know which round a bid was originally signed for. What actually stops a round-1 bid from carrying into round 2 after a reopen() is NightWatch's own bid intake: both the bid form and the house keeper cap every deadline at the round's own end before it's ever signed or submitted, so a bid meant for round 1 is never given a deadline long enough to reach round 2 in the first place. The on-chain check above is the backstop for that discipline, not the thing enforcing it — it catches a bid this generous only if it somehow reached the keeper anyway. Your own wallet or agent doesn't need to do anything differently — NightWatch signs every bid's deadline as whichever is sooner: 5 minutes from now, or the round's own end.

My desk shows you this directly: once a round has resolved with a remainder that's still worth chasing, the order's own row shows "Sign round n+1" — and clicking it now does the whole thing: builds the round's own AttestationRequest (same order_group_id, round_number+1, the group's own token/side, and the remainder as qty), your wallet signs it, the desk sends it to POST /market/auctions, and then your SAME wallet sends the real on-chain transaction with the screening it comes back with — openAuction normally, or reopen when the reply says next_action: "reopen" (below) — one click, one wallet prompt to sign the request and one to send the transaction, both from your own wallet. Round 1 itself opens the identical way from "Place order" on the order form. NightWatch's own indexer then recognizes the new on-chain order as the next round of the same group by matching your orderer address, token, side, and the qty you signed. Nothing reopens on its own; if you don't sign, the order simply stops where it is (a resolved round's escrow is already back in your wallet).

"Sign round n+1" is offered only when all of these hold:

• the remainder is at or above the token's own remainder floor (below);
• you haven't used up your round cap;
• your own time cap for the whole group hasn't elapsed;
• the previous round has ended: it resolved with a remainder, or (v1.1) it got no award at all and its 2.5 minutes (bidding window plus award grace) are over.

NightWatch checks every one of these again, server-side, the moment you try to sign the next round — not just when it decides whether to show you the button. It also checks that the next round's own token, side, and qty match the group (never a different token or side, and never more than the previous round's own remainder), and that the round you're trying to sign isn't a stale, never-opened attempt from more than a day ago (one of those simply expires and frees its own round number back up, rather than blocking the group forever).

What happens to a round's own leftover, inside that round: mode ① (Follow the market) and mode ② (Fixed limit) have the contract refund any unfilled remainder automatically, the instant that round's own award transaction lands — there is no DEX step for these modes at all. Mode ③ (Fill or fallback) tries the DEX once, at the tolerance you set when you opened THAT round (default 25 basis points) — if the DEX price is outside it, that attempt is skipped and the remainder is refunded instead. There is no second, wider-tolerance attempt afterward; a round's own DEX fallback either clears once, at its own fixed tolerance, or the remainder goes back to your wallet. This case — a round that DID get at least one award — still isn't what reopen() (above) covers either: that only ever applies to a round with zero awards. Automatically routing a refunded remainder to a DEX BETWEEN rounds, retrying it at a wider tolerance, or carrying an AWARDED round's own leftover into a further round without refunding it first, would all need more contract work than this pass did — v1.2 candidates.

You set your own round cap (1 to 10 rounds, 5 by default) and an overall time cap (bounded and positive — it can't be zero, negative, or unlimited) when you open round 1, under Advanced on the order form; both are fixed for the whole group from then on. Clicking "Place order" now does the same one-click sign-and-send round 1 uses: builds and signs the AttestationRequest, calls POST /market/auctions, then sends openAuction from your own wallet with the screening it returns — the order form is no longer a preview-only step. A vault's own AUTO/MANUAL legs never use this round system at all — they keep running on the vault's own keeper cycle instead (chapter 27), which re-tries a failed leg on its own next cycle rather than asking anyone to "sign again."

reopen (v1.1). A contract change adds reopen(id, expiry, screening, authSig) — round n+1 on the SAME on-chain order, keeping its existing escrow instead of refunding and re-escrowing. It only works for an order that is still open with zero awards once its 2.5 minutes are over. NightWatch tells you which call to make: the reply to POST /market/auctions, and the order's round object on the board, carry next_action — "reopen" for that zero-award case, "open" for every other remainder (a round that resolved, was cancelled, or had an award), which is a fresh openAuction with a new escrow. Before it offers a reopen, NightWatch checks the order's live state on the chain (still open, no award) and test-runs the call read-only; if the test run would fail (for example the escrow no longer covers the new round's price, or your orderer access or the token listing changed), the reply says next_action: null with a reopen_unavailable reason and hands out no screening. Nothing is queued, because the round is still open on the chain and a fresh openAuction now would run a second round on the same remainder; next_action: "open" only appears once that round has actually ended (cancelled, expired or awarded). A fill-or-fallback (mode ③) order with no award is also not sent to the DEX for 30 minutes after its round ends, so you have time to reopen it. A reopen must request exactly the order's own quantity (it cannot shrink), must still clear the remainder floor, and is held to the same round cap and time cap as any other round.

• From your own wallet: the desk's "Sign round n+1" sends reopen with an empty authSig (you are the order's own orderer). No new approval, no new escrow.
• As an agent, with the house sending it for you: request the round as above; the reply's reopen block gives the order_id, the order's current_opened_at, the allowed expiry band (your expiry must be more than 150 seconds and at most 1 hour after the moment you post it) and the ReopenAuth(id, expiry, currentOpenedAt) typed data to sign. Sign it with your orderer key and POST /market/auction/{order_id}/reopen-auth with the signature, your chosen expiry, current_opened_at and the screening you were given. The house keeper sends reopen once the round's 2.5 minutes are over, and only after a read-only test run shows the call would succeed. A request that has not been sent within 60 minutes after the round's end is closed as stale, and one that was sent but never landed is marked failed once its transaction reverts, or after five minutes with no receipt. The signature works once: the moment the reopen lands, the order's opened-at time changes and the old signature can never be used again. If someone else reopens first, or an award arrives, the request is simply closed as stale.

The screening you get for a reopen expires when your group's time cap does (at most 24 hours). Round n+1 then ends 2.5 minutes after the reopen itself, and every bid is capped to that new end exactly as before. NightWatch's indexer links the new round to your group by the order's id — you do nothing extra for that. If the order turns out to be not reopenable (it was awarded, or its round is still running), the request is refused with the reason rather than sent. Reopening a round that already had an award, or carrying an awarded round's leftover forward without a refund, is a v1.2 candidate.

The remainder floor

Below a certain size, chasing a remainder costs more than it's worth: delivery itself — an exchange withdrawal — has a fixed cost no matter how small the amount is. The floor for a token is the largest of three things: $50, twenty times the cheapest available delivery route's own withdrawal fee, or that exchange's own minimum order size for the token — with the token resolved from its on-chain address to a real symbol before any of those numbers are looked up. The third term now carries a real number per route, read from the same cached market metadata the reference snapshot already keeps (token_metadata, the same cache GET /metadata serves) — resolved to that route's own exchange-plus-pair; a route with no cached minimum still contributes nothing for that term (never a guessed number), so the floor can still only ever come out lower than it should, never higher, and a false refusal is still never possible from this term alone. An order sized below its own floor is refused the moment you try to place it — before any escrow ever moves — and that refusal is checked against the token and qty you actually SIGNED, not just what you typed; what isn't checked yet is that same signature against the specific on-chain openAuction call itself, so it can't stop a signed-above-floor order from opening smaller on-chain (binding the signature into the contract call itself needs a contract change — v1.1). Re-opening is gated the same way: once a round's remainder drops below the floor, "Sign round n+1" simply isn't offered any more. A vault's own MANUAL rebalance leg below the floor is DESIGNED to be skipped rather than refused — a little drift tolerated rather than forcing an uneconomical trade — and the vault keeper's own production cycle (svc/worker/nw_spot_vault_keeper.py, after settle_vault, every cycle) already evaluates that decision for every queued leg. Actually acting on it — sending rebalanceSwap for a leg at or above the floor — is v1.1: the vault's live on-chain owner is re-checked against who signed the leg, a stale (>24h) queued leg is refused rather than executed at a market it was never priced against, the mandate room's own monthly cap is re-checked (not just at queue time), and a real fill is confirmed from the vault's own RebalanceFill log (never "the transaction succeeded" alone — rebalanceSwap does not revert on its own price gate, it emits GateFailure instead, and NightWatch treats that as no different from a real gate rejection, backing off rather than resending it every cycle). A deposit's own buy legs and a withdrawal's own sell legs are never skipped this way at all, since skipping either of those would leave real cash or a real payout stuck.

The floor never touches an award. It decides whether an order can open, and whether it can re-open for another round — it never grows, shrinks, or drops a winning bid. The contract awards exactly what the signed bids and each bidder's own limits allow; if that leaves a small remainder, the remainder rule above (refund, or a same-round DEX try for mode ③) is what resolves it, on the SAME footing as any other leftover.

Unfilled remainders

A bid, once accepted, is bounded on-chain by the reference price (or your own stricter limit) — that part is a hard guarantee. What happens to whatever is left over when a round closes — no bid beat the reference at all, or part of the order stayed open when bidding closed — depends on the price mode you picked for THAT round:

• Follow the market or fixed limit orders that received at least one award in their current round: any leftover quantity from THAT round is refunded automatically, inside the award itself — you get it back the moment that award transaction lands.
• Follow the market or fixed limit orders with no bids at all in their current round: nothing was ever awarded that round, so there's nothing for an award to auto-refund — the round's escrow stays locked until you cancel it yourself (any time before an award lands on it). This is the ONLY way a no-bid round ever becomes eligible for a next one: cancelling it is what records its full, untouched qty as that round's remainder, which "Sign round n+1" then offers to try again (assuming it still clears the floor and your caps).
• Fill or fallback orders let the house's own keeper route any true remainder through a whitelisted DEX, bounded by the reference price plus the tolerance YOU set when this round was opened — but never above the price your own escrow was actually sized at. This is a keeper-driven action, not something the contract does on its own the instant the window closes; if the DEX price is outside what your escrow can cover, the keeper sends an empty route instead, which refunds the remainder. Once every award on a round has resolved (delivered or expired), you can also reclaim any leftover from THAT round yourself with the order's own "Reclaim remainder" action, with no need to wait on the keeper.

Once a round has resolved this way, its own leftover — if any, and if it still clears the remainder floor and your caps — is what "Sign round n+1" offers to try again, in a brand-new round you open yourself (see "Rounds" above). There is no scenario where a fill happens at a worse price than your own limit — that part is enforced by the contract itself, at the moment of the award or the fallback fill, every round. What is NOT automatic: a no-bid round needs your own cancel, a fill-or-fallback round's leftover depends on the keeper acting (or on you reclaiming it), and opening the next round always needs your own signature — none of this resolves itself the instant bidding closes.

A winning bid that's awarded and then never delivered. NightWatch reads a round's remainder from the contract's own bookkeeping — how much was originally offered, minus how much was ever awarded, minus how much has been resolved some other way — plus the qty of any award that later expired undelivered. If a winning bid is awarded and then simply never delivered (it expires, past its own 30-minute window), the contract refunds that undelivered portion straight back to you and emits its own AwardExpired event with the exact amount refunded; NightWatch's indexer adds that amount back into the remainder the next time this round resolves, so the remainder shown matches what you actually got back, not what the contract's own "awarded" bookkeeping alone would suggest.

Remaining known limitation (fails safe). A mode-③ round's own empty-route DEX refund, and a plain refundRemainder call, both mark that quantity as "resolved" in the contract's own bookkeeping at the moment they happen — correct in the ordinary case, but NightWatch's reading of "resolved" doesn't distinguish that from a portion that's genuinely still available to chase. Where this can differ, the remainder NightWatch shows can come out smaller than what's really left — never larger, so a next round is never over-offered, only possibly under-offered. This is the same fail-safe direction every other rounding gap in this chapter already takes.

Receipts

Every fill produces a receipt: the quantity and average price you got, the reference price and how many basis points you beat it by, the same comparison against Binance alone, the DEX quote you'd have gotten without the auction, the fee paid, whether it was won by a supplier or filled via the fallback, and the on-chain transaction(s). A running dashboard on the Receipts tab shows orders filled, the weighted-average improvement over the reference, what share of volume went through the fallback, and the undelivered rate — the same honest numbers whether they look good or not.

Where it lives

• Screen: /market ("The Floor") — Board (one list meant to carry both ORDER-source rows, from the AuctionHouse indexer, and VAULT-source rows, from the vault's own flows indexer/BondedSupplyAuction events — "one board, two contracts": today it shows ORDER-source rows live, backed by the AuctionHouse indexer; a vault's own supply-auction rows are visible today on that vault's own page (chapter 27), and joining the two into one Board response is a near-term integration step, not yet built) and My desk (a vault operator's own view: their vaults, the three-field order form, mandate room, and their own queued/cancelled MANUAL orders; AUTO rows appear here once v1.1 ships). v3 replaced the earlier four-tab layout (Board/Order/Receipts/Rules) — Receipts and Rules are now links from a row or the footer, not separate tabs, since most of what they showed lives on the row itself now. A row that's part of a tracked round group shows round n/m — real data the indexer itself writes the moment your round's own OrderOpened lands on-chain, matched to the round you queued when you signed it, not a sample placeholder; tapping the ▸ next to it opens that order's own round history from the same source. Each row also carries a real Bid button (fetches the delivery-cost preview live, then signs and submits a real EIP-712 bid) and, once you hold an award, a Deliver button that opens the exact manual steps rather than pretending to send the on-chain call for you (one-click Deliver is v1.1). Round cap and an overall time cap live under Advanced on the order form, next to the three-field basics — both default to the policy above (5 rounds, 10 minutes total) so most orderers never need to touch them.
• Rules text: docs/pm/AUCTION_HOUSE_V1_SPEC.md is the binding spec; this chapter and the in-page Rules link use the same sentences on purpose.
• The Mandate Vault (chapter 27) never becomes an AuctionHouse orderer (see "The desk" above) — its own supply-auction mechanics (bidding, tiers, delivery) stay exactly as chapter 27 describes them; §4-I is what gives its operator a queue-and-cancel desk on /market for triggering one of those same on-chain legs by hand, not a new execution system.