Loss-Filter Analysis (PRELIMINARY, n=4)

Forensic decomposition of the 4 losses in the first batch of live UP-token fills, testing whether any entry-time filter would have skipped them without killing the validated edge. Strategy looks healthy; only ~2 losses are cleanly filterable; exactly one filter (shat_mom_30 ≥ 0) survives EV-based scrutiny — and it rests on n=2.

PRELIMINARY — n=4 losses, do NOT act on this yet

Every number here has huge variance. The whole panel rests on 4 losses (2 of the “filterable” findings on n=2). Default action = do nothing. The live run is being left running to accrue more trades; re-run this entire panel at n ≥ 20 losses before promoting any live bet-dropping filter. These are hypotheses to forward-test, not a proven edge.

Data

• Source: 32 live trades on wallet 0xAdAc…aEb2 (2026-06-26), all BTC 5-min UP-token buys, all matching our emits.
• Join: to the DB outcomes (label) / emitted_signals / per-second observations.
• Result: 31 BUY entries → 27 wins / 4 losses = 87.1% win rate.
• The 12.9% loss rate is better than the ~15% implied by ~0.85 entry prices → no obvious leak to plug. See crypto-shortterm-handover-2026-06-26 for the live-run context.

Bottom line

The strategy is healthy. Of 4 losses, only ~2 are genuinely filterable; 1 is irreducible noise, 1 is a latency-headroom artifact. Do not hard-deploy any bet-dropping filter on 4 points. The single filter worth shadow-testing is shat_mom_30 ≥ 0, and even it rests on n=2.

The 4 losses, decomposed (NOT one phenomenon)

window	type	what happened	addressable?
…487500	rollover	BTC spiked −61→**+160** in 80s; we bought UP at +72 mid-collapse (mom30 −86, the most negative of all 31) → settled down	YES — mom30≥0
…490500	rollover	peaked +96, rolled over; we bought a 5-second dead-cat bounce (mom30 −5, mom60 −25) → cratered to −94	partly — mom30≥0
…466500	latency / thin	emit fired in-regime at τ≈62s, +3.3s fill latency → fill at τ=59 with a +8 cushion, market at 0.50; ordinary final-minute noise sank it	partly — raise emit τ-floor
…473700	irreducible coinflip	thin +30 cushion; settled **$2\ast \ast belowstrikeona$59,400 underlier. Three wins had thinner cushions (raw and vol-scaled)	NO — 0.82 conviction already prices ~18% loss; this is the coinflip landing tails

Andras's hypothesis CONFIRMED (for 2 of 4)

“Climbed too fast too high then fell back and it bit” is exactly right for the 2 rollover losses (…487500, …490500) — and those are the only cleanly filterable ones.

The one filter worth shadow-testing: shat_mom_30 ≥ 0

“Don’t buy UP when BTC fell over the last 30s.” Skips 2/4 losses, costs 2/27 wins.

The case is EV, not win-rate

The mom30<0 bucket is itself 2 wins / 2 losses — momentum does not separate win from loss. It’s worth skipping because the bucket is EV-negative: the 2 losses were expensive (fills 0.75/0.76 → risk ~0.75 each) while the 2 sacrificed wins were cheap (fills 0.90/0.93 → net only ~0.08 each). Net ≈ +1.34 stakes saved over the bucket. You trade cheap high-priced wins to dodge expensive low-priced losses.

It does NOT touch the validated edge. shat_mom_30 is a physical-state feature (BTC momentum), corr(mom30, pm_ask) = 0.17. The 2 wins it kills were high-ask agreement wins, so the model-vs-market disagreement edge is untouched (see crypto-shortterm-phase1-execution-decision). Stake economics tie to crypto-shortterm-phase1-bet-sizing.

Bonus lever: raise the emit τ-floor (~τ65)

The …466500 loss shows the emit τ ≥ 60 gate doesn’t account for ~3.6s median emit→fill latency: an emit at τ≈62 fills at τ≈59 with no time for a thin cushion to recover. Requiring emit τ ≥ ~65 leaves latency headroom so fills land in-regime. In-sample this touches only that one edge-case emit.

Measurement caveat — this does NOT resolve the 128ms budget

Realized emit→fill is ~3.6s median, but the timestamps are second-granular and include Polygon block time, so this cannot measure the 128ms REST latency budget. Resolving that needs CLOB match timestamps, not on-chain settlement times.

Rejected filters (confirmed)

• pm_ask ≥ 0.80 / conv_fair_ask market-agreement gates — statistically tempting (avoid 3/4 losses) but they delete the disagreement edge: the single most profitable bet (+44, pm_ask 0.56, the purest model>market disagreement) dies. This is the gate the team already rejected — correctly.
• overshoot/range > 0.30, sigma < 0.60, ask_depth < 1700, dist_e ≥ 60 — overfit / proxies / boundary-fit on n=2, or kill 40–50% of wins.

Recommendation

1. Default = do nothing. Strategy isn’t obviously broken; preserve unbiased data by leaving the live run untouched.
2. If acting: shadow-log only — record what mom30 ≥ 0 would skip (don’t drop bets), and add ~5s τ headroom to emit. Kill-switch if shadow shows it eating low-price disagreement wins.
3. Promote a live filter only after ≥ 15–20 losses with ≥ 5–6 mom30<0 losses showing persistently negative bucket EV. Re-run this panel at n ≥ 20.

Method (reproducibility)

• Trades: pulled from data-api.polymarket.com/trades?user=<wallet>.
• Join key: window_id = floor(ts / 300) * 300 → outcomes.resolved_up (label) + emitted_signals + per-second observations.
• Features: engineered as entry-available (what the emit could see at fire time) vs hindsight (full-window path), to avoid leakage when judging filters.
• Analysis: a 10-agent Claude workflow — 5 analytical lenses + 4 per-loss forensics + an adversarial overfit-synthesis pass.

Related

• crypto-shortterm-handover-2026-06-26 — current live-run state (producer LIVE, dry-validate passed; latency still untested)
• crypto-shortterm-phase1-execution-decision — the disagreement edge + producer/executor split this filter must not break
• crypto-shortterm-phase1-latency-budget — the 128ms publish→fill budget the τ-floor lever relates to (but can’t measure)
• crypto-shortterm-phase1-bet-sizing — stake/fill economics behind the EV case
• crypto-shortterm