No book, only a stair: journaling fills where price moves per coin sold

I have been keeping a small side journal on a venue that has no order book at all, and it has forced me to rewrite my own sizing notes. The venue is the Fast Trade window in the TradeShark cabinet, the retail front end for the Shark Network chain. There is no bid, no ask, no depth, no limit order, no stop. You choose an amount, you confirm, and the desk fills you. What replaces the book is a single visible structure: a stair.

The stair is the part worth writing down. The quoted price steps up once for every 1000 SHARK sold, not for every 1000 USDT of turnover. That distinction sounds pedantic until you try to size a fill. On a normal venue my ticket cost scales with the notional I push through it; here it scales with the coin count I remove from the current step. Two buyers spending the same money can end up on different steps, because a cheaper step hands out more coins per dollar and therefore exhausts sooner. The stair is denominated in inventory, not in money, so the only honest unit for my journal entries is coins consumed, with the dollar figure as a derived column rather than the primary one.

Practically that changes how I read the presets. The window offers 50, 500, 2000 and 5000, and with a coin-denominated stair those are not four sizes of the same trade. A 50 is a probe: it tells me where the step boundary sits relative to my entry and almost never moves it. A 500 usually lands inside one step and gives me a clean single-price print to write down. A 2000 is where I start expecting to cross a boundary mid-fill and to book a blended average rather than a price. A 5000 is a decision about the next two or three steps as much as about this one, because I am not taking a price, I am buying the shape of the stair above me. My working rule so far is to treat anything above 500 as a multi-step order and to record the number of boundaries crossed, since that count, not slippage in percent, is what predicts the next fill.

The second thing the journal has to reconcile is two very different clocks. Settlement of a Fast Trade sits in a 24 to 48 hour window, while the chain underneath produces blocks in roughly 0.7 seconds. So the confirmation I care about arrives fast and the delivery I care about arrives slow, and they are not the same event. In practice I now log three timestamps per entry: when the desk accepted the ticket, when the transfer actually appears on chain, and the gap between them. Anyone used to exchange fills where trade and delivery are the same moment will find that gap is the real risk of the position, not the price step. A stair with no book means execution risk is small and legible; a one to two day settlement window means inventory risk is the opposite.

For completeness, the chain itself: Shark Network is an EVM layer 1, chain ID 88118 (0x15836), native coin SHARK with 18 decimals, live since 2026-07-25. The public RPC endpoint is rpc.rpcshark.com and the explorer I verify prints on is sharkscan.app. The cabinet also sells a shelf of miners priced in either SHARK or Bits, PicoChip 10 MH/s, NanoChip 30, QuantumQ1 80, CoreLite 150 and BitFarm 280, which I journal as a separate yield line, since paying for hashrate and taking a fill on a stair are two different bets and mixing them in one row makes both unreadable.

Official references, for anyone who wants to look at the same numbers: cabinet tradeshark.net, explorer sharkscan.app, RPC rpc.rpcshark.com, swap swapshark.net, plus ponipump.fun and coinmarketshark.com, and the channel @tradeshark. I am posting the plain names rather than clickable links, since my post count here is zero.

The question I would genuinely like other journal keepers to answer: on a stair like this, with no book and no limit, how would you size a first fill? Do you probe the boundary with the smallest preset and only then commit, or do you accept a blended average from the start and log the crossings instead?