Settles the standing “should we change order type to stop adverse fills?” question. Answer: no — pmv2’s FAK marketable limit pinned at the break-even ceiling is already the adverse-fill-minimizing design. The recoverable loss is latency conversion, not order-type choice, and every alternative (uncapped market/FOK, resting GTC maker quotes) is strictly worse.
For Agents — the verdict
Do NOT switch order types. The ~50%/day FAK no-match refusals are the EV guard working (90.5% are price-refusals where the repriced ask sat avg +5.4¢ above the break-even ceiling); realized fills show no measured adverse selection (repriced fills win 87–88% ≈ population, #942). The fix lane is latency conversion (PM R-items, config cache 733ms→10ms — babylon
pmv21157), not a different order type.
Correction (2026-07-10) — the no-match tail is MISSED WINNERS, not dodged losers
A later real-CLOB-label decomposition (crypto-shortterm-loss-decomposition-fill-adverse-selection-2026-07-10, 100% coverage / 4857 windows) shows the unfilled no-match windows would have won 84.9% vs 70.8% on the ones we fill (+14.1pt in every asset) — so the no-match tail is disproportionately the +EV WINNERS we miss, not the −EV trades this note framed the EV guard as correctly refusing. The mechanism is unchanged (the winning-side ask reprices above the limit — latency); what flips is its sign of value (a cost of missing winners, not a benefit). The “87–88% ≈ population, no adverse selection” evidence here is on the on-chain (optimistic) label; on the real label the filled subset is adversely selected (at-ask ceiling ~−1.9¢). This note’s operational conclusion still stands — do NOT switch to uncapped market/FOK or resting GTC (strictly worse); only the characterisation of the no-match tail is corrected. Body left intact by design.
What position_manager actually places
- FAK (immediate-or-cancel) MARKETABLE LIMIT orders, price-pinned:
market_order().price(limit).order_type(OrderType::FAK)—position_manager/crates/polymarket-clob/src/lib.rs:502(buys) and:513(sells). - Hardcoded — no per-source order-type config exists. The vendored
rs-clob-client-v2supports GTC/GTD/FOK if ever needed. - Limit =
floor_tick(min(directive max_price, fresh best_ask)); FAK-v2 retries reprice upward, capped atmax_price(position_manager/crates/position_manager/src/pricing.rs:58–64). - Invariant held: 0 of 9,047 attempts ever exceeded the ceiling.
”Adverse fills” decomposed
| component | measurement | verdict |
|---|---|---|
| (a) FAK no-match refusals (~50%/day) | 90.5% price-refusals — the break-even ceiling correctly refused a repriced ask sitting avg +5.4¢ above it | Missed fills, not bad fills. The EV guard working; a latency-conversion loss (fix in flight: R-items, config cache 733ms→10ms — babylon 1157) |
| (b) realized fills | repriced fills win 87–88% (#942, ~2,200 fires) ≈ population win rate; BE-priced limits guarantee ≥3¢ model edge per fill | No measured adverse selection at the population level |
| (c) partial fills / under-fill | E3 depth guardrail: p10 touch thinner than clip | The open watch item |
The (b) population read coexists with the one-day btc-up signature in crypto-shortterm-lane-state-adverse-fill-2026-07-05 (filled fires won 25%, missed fires 100%, n=22) — the E2 question below is the systematic version of that test.
Why the alternatives lose
- Uncapped market / FOK — buys the above-break-even −EV pocket: exactly the pre-2026-07-02 lesson when the live emit dropped the edge gate and 38% of fires were collectively −EV (crypto-shortterm-algo-accuracy-audit-2026-07-02).
- Resting GTC maker quotes in the τ∈[60,150)s window — a free option handed to sub-second Binance-watching bots while our requote path is 2.78s p50; no cancel/replace infra exists; maker fills change the validated taker economics (fee/rebate structure, fill selection) → would require a full walk-forward gate re-run per the canonical 5m spec.
- FAK at the BE ceiling never pays above break-even, never rests, and reprices toward (not past) the validated edge — already the adverse-fill-minimizing design.
Open question (proposed for E2)
Win rate of price-refused vs filled directives — adverse selection on conversion: do the directives we fail to convert win more or less than the ones we fill? Quantifies what recovered conversion (the latency work) is actually worth. Cheap — joins pm_fak_attempts × emitted_signals × pmv2_autotrade_orders, all of which we already query.
Related
- crypto-shortterm-fak-nomatch-root-cause-2026-07-02 — the #942 measurement: no-match = ask repricing above our limit, repriced-fill win rate 87–88%.
- pmv2-open-multi-wallet-liquidity-ceiling-brainstorm — the decisive query: 90.5% price-refusals, +5.4¢ avg above ceiling; ceiling is price, not depth.
- crypto-shortterm-emit-publish-first-latency-2026-07-09 — producer-side conversion latency (the claim INSERT ahead of the publish).
- pmv2-measure-before-mitigating-priority-tiers-2026-07-09 — PM-side R-items; the config-cache 733ms→10ms fix in flight.
- crypto-shortterm-lane-state-adverse-fill-2026-07-05 — the btc-up adverse-fill framing this decomposes.
- crypto-shortterm-disagreement-ceiling-nogo-2026-07-03 — don’t-chase: the actionable lever is the limit/fill path, not the selector.
- crypto-shortterm-algo-accuracy-audit-2026-07-02 — the 38%-of-fires-−EV lesson behind the break-even ceiling.
- Crypto 5m Up-Down — Oracle-Lag Strategy (Canonical Spec) — the validated taker economics any maker switch would void.