Size bands

A band is a promise about the largest size the order can turn out to be. It is not a range, not a bucket, and not a hint. At settlement the program refuses any revealed size above the declared ceiling, so a maker quoting into a Large order knows with contract-level certainty that it will not be filled against more than 512 lots.

Read from programs/darkbook/src/constants.rs:62-66. Ceilings are inclusive, in lots. One lot is one unit of the base asset, so on a SOL market one lot is 1 SOL and price_ticks is micro-USDC per SOL.

Why a ceiling and not a bucket

A bucket says the size is somewhere between two numbers. A ceiling says the size is at most one number, and the contract enforces it. The difference matters to exactly one party: the maker deciding what to quote. A maker prices the worst case, and the worst case of a bucket and the worst case of a ceiling are the same number, so the lower bound adds nothing to the quote and subtracts from the trader's privacy. Every band therefore publishes its top and keeps its floor to itself.

This is also why the top band is finite. The schedule this replaced ran 10, 100, 1,000 and 1,000,000 lots, and the top ceiling at 1,000,000 bounded nothing anyone could price: a maker either refuses to quote into it or quotes as though the order were unbounded. Whale at 32,768 lots is a number a desk can actually take the other side of.

Where 32,768 came from

The ceilings were anchored against a live read of Hyperliquid's SOL perpetual on 2026-09-06, at a mid of 106.495 USD, recorded in the source alongside the constants.

Small holds ordinary retail flow, Large holds the mean resting clip, Block holds an order that consumes one whole price level, and Whale at 32,768 lots is 3.49M USD at that mid, which sweeps 92% of the entire visible book. An order larger than the visible book is an OTC block, not something a maker quotes into.

What the schedule discloses

Five choices is at most log2(5) = 2.32 bits of size information per order, against log2(4) = 2.00 bits for the retired four-band schedule. That is a real increase in disclosure and the source says so at programs/darkbook/src/constants.rs:42-45. What the extra 0.32 bits buys is a finite worst case: the old top band spanned a factor of 999, and the new one spans a factor of 8, uniform with every other band.

The simulation confirms the dial runs in both directions. Finer schedules cost less spread, and by 16 bands the cost of size blindness has gone to zero, because a 16-band ceiling is nearly as informative as the exact number.

Read from research/band-signal/run_full.log, section A, at commit f5a832f. Publishing one of five ceilings costs 0.201 bps where publishing nothing costs 2.555, so the schedule buys back 92% of the cost of hiding size. Going finer than five would buy back the rest and give away the size.

What over-declaring costs

A trader can always declare a band above the one their size needs, and padding into a higher band is the obvious way to blur an order further. The program charges for it at the door. Placement computes the collateral requirement from the band ceiling and not from the sealed size, and rejects the order if the account does not hold that much unlocked.

// programs/darkbook/src/ix/orders.rs, place_order

// Estimate collateral from the band ceiling, which is the largest size this
// order is allowed to reveal at settlement.
let size_ceiling = size_band.max_lots();
let collateral_u128 = (size_ceiling as u128)
    .checked_mul(price_ticks as u128)?
    .checked_mul(100u128)?
    .checked_div(leverage_bps as u128)?;

require!(
    user_acct.unlocked_amount() >= collateral_needed,
    DarkbookError::InsufficientCollateral
);

A 40-lot order declared as Block has to be backed by free collateral for 4,096 lots, a factor of 102 more than the position will need, or the instruction fails with InsufficientCollateral. Each step up the schedule multiplies that requirement by 8. The balance is not locked at placement, it is locked at settlement against the revealed size, so the cost of padding is the capital a trader has to keep free while the order rests rather than a fee. That is the whole disincentive, and it is arithmetic rather than a rule.

And what it does to the spread

Over-declaring degrades the signal the maker reads, so the study also priced the difference between a population that pads and one that cannot.

Read from research/band-signal/run_full.log, section A. Under the live schedule the measured mean over-declare offset is 0.12 bands, so padding is common but shallow.

The collateral carry cost of padding was swept separately in section F of the same run. At zero carry the gap reads +0.270 ±0.059 bps and at a carry rate ten times the base it reads +0.305 ±0.059, against +0.201 ±0.075 at the base rate. Those intervals overlap, so the honest reading is that the sweep did not resolve a carry effect at this sample size, not that carry does not matter.

Which bands flow actually uses

Under the live schedule, measured share of volume by declared band. Large carries half the flow and Whale is almost unused, which is what a ceiling anchored above the visible book should look like.

Read from research/band-signal/run_full.log, band usage section, live rust schedule row. Simulated flow calibrated to the Hyperliquid size distribution, not observed DarkBook volume.

Rules the program enforces

• Ceilings must strictly increase. A compile-time assertion in state.rs rejects a schedule where a higher band code would admit less size than a lower one.
• Each leg of a fill is bounded by its own band at settlement, never by the counterparty's.
• The collateral requirement at placement is computed at the ceiling. The band is a financial commitment, not a label.
• Any change to this schedule ships with a re-run of research/band-signal and a new bits-disclosed figure, or it does not ship.