Levandor

build_order makes 2 uncached venue round-trips per build

2 min read

Every call to SigningClient::build_order silently makes two network round-trips to the CLOB to fetch per-token static fee parameters — on the first shot and on every FAK retry — making each requote attempt cost ~4 RTTs instead of 2.

The hidden calls

Inside SigningClient::build_order (polymarket-clob/src/lib.rs:538-548):

CallCostCondition
self.inner.fee_rate_bps(tid).awaitnetwork RTT to CLOBalways
self.inner.fee_exponent(tid).awaitanother RTTwhen base_fee > 0

These are per-token static values — they are precisely what produces the exactly-constant 0.10 coefficient documented in pmv2-fee-coefficient-010-vs-007-overbooking-2026-07-21. They never change per attempt, yet they are fetched uncached on every build.

Cost per requote attempt

Each attempt in fak_retry (execute.rs:388) pays roughly 4 network round-trips:

book_top        ~212ms (measured)
fee_rate_bps    (hidden, inside build_order)
fee_exponent    (hidden, inside build_order)
place_order     ~150-200ms

No sleeps in the loop; MAX_RETRIES = 2.

Prime latency target

Caching the fee params per token_id removes 2 of 4 RTTs per attempt with zero behavioural change. Without it, the irreducible floor is ≈ 700ms–1s per attempt, which is consistent with crypto’s observed 2.78s requote p50 across up to 2 attempts.

Measure first

45fa0eb already emits the decomposition on target: "pmv2.latency", message "exec decomposition":

FieldCovers
build_msincludes both hidden fee calls
place_msorder submission
book_msbook_top fetch
reserve_msDB reserve

If build_ms is large, the cache is confirmed as the win. This follows the discipline from pmv2-measure-before-mitigating-priority-tiers-2026-07-09 — a plausible mechanism is not evidence.

Not scheduled work

The crypto lane is SHELVED (Andras, 2026-07-21) with all wallets dry. There is no live loop to optimise. This note is design intel for whenever the lane resumes — not a queued task.

Graph View

Backlinks