Everything here is checkable, and says how.
Every figure says whether it came from Base or from a unit test — including where the number is less flattering.
Did it work
What the winner bid, what the winner paid, and the gap that went to the maker.
Reading the round
Resolving which round to show — a share link can pin a specific one.
Who is bidding
Counts, never shares — and a round counts as won only once it has settled.
Nobody has opened a sealed bid yet.
No round has been opened on this Book. This table fills in when one is. It is not hidden while empty, and it is not padded with anyone.
What produced this: counted here from the rounds on the board, which come from the GlasshouseBook contract on Base. One row per address that has committed to at least one round in the window shown. Every column is a count, never a share: the number ranked on is rounds won, printed beside the rounds entered it came from. A round counts as won only once it has settled, because until then a later reveal can still take it away. This is a position in this list, not a standing in a market — Glasshouse does not have one, and subgraph/README.md refuses to imply it does. The keeper bids too, and is disclosed rather than filtered out.
Is it actually better
The same order, three ways — every number from a unit test, not from a network.
One order. Three participants with the same valuations each time, identical balances and swap curve in all three programs, so the only variable is how the right to fill is decided. The participant who values the fill least is also the fastest, and is the incumbent on the ladder — because that is the situation the mechanism is supposed to handle.
| Gate | Winner values | Maker gives up | Against base | Who won |
|---|---|---|---|---|
By identity 0x2d | 100 bps | 10 000 | Level with no auction at all | Cyd · valued 100 · the incumbent on the ladder |
By clock 0x94 | 100 bps | 10 618 | 6.2% worse for the maker | Cyd · valued 100 · first in the block |
By bid 0x2e | 400 bps | 9 756 | 2.4% better, and the right bidder won | Ada · valued 400 · slowest of the three |
Basis points of the base price; lower is better for the maker. Both existing gates hand the fill to the participant who values it least. The clock additionally concedes to the taker every second it runs.
What produced this: test_Comparison_AllThreeGatesOnTheSameOrder in test/Comparison.t.sol, run with npx hardhat test solidity. Two mock tokens (TokenMock “Token I”/“Token J”), static balances 1000 / 2000, swap 1. Three test addresses with assigned valuations — Ada 400 bps, Bram 250, Cyd 100 — where Cyd is also assigned the first position in the block and the first rung on the ladder. The clock row is read once, 60 s after start, with decay 0.999 per second over a 600 s window (the slowest factor in upstream’s own tests, i.e. the one kindest to the clock). Auction parameters in the test are 5 / 5 / 10 blocks, reserve 10, max 500, not the deployed 30 / 30 / 15. Nothing here was observed on a network.
What happens next
The advisor reads the rounds that already happened and prints the command.
scripts/reserve-advisor.mjs queries the published subgraph and does report the split.The low end is the staleness floor, below which running the auction is worse than posting a limit order. The high end is one below the lowest winning bid in the window, above which the reserve would have excluded a winner we actually had. This is a heuristic that splits a known-safe value from a known-unsafe one. It is not an optimal-reserve computation; that needs the bidders’ value distribution, which a handful of auctions does not estimate.
cast send 0xc4ea91Fe700918220423ac307C6B1c59650FFbfe \ "open(bytes32,address,address,uint40,uint40,uint40,uint24,uint24,uint128)" \ $ORDER_HASH 0x5c3baE054e8b4915a13726B397b1AeA864247DBf $TOKEN_IN 30 30 15 50 500 0 \ --rpc-url $BASE_RPC_URL --private-key $MAKER_KEY
What produced this: recommendReserve() in web/lib/reserve-rule.js, the same pure function scripts/reserve-advisor.mjs runs offline, over the settled rounds on this board — at most the newest K = 8, floor 50 bps, ceiling 500. The window rows are derived from raw contract fields by web/lib/reserve-window.js, which transliterates the subgraph’s own mapping (subgraph/src/helpers.ts) because this panel’s rows come from the board’s chain read rather than from the index. The three regime thresholds come from test/ReserveMatrix.t.sol, not from a guess.