The Phase-1 live latency test architecture and the staged-spend decision. crypto-shortterm publishes Directives to pmv2’s executor rather than building its own order path; the live test is a deliberately cheap measurement of whether REST execution can capture the edge — which polymarket expects it cannot.

Execution Architecture Decision

crypto-shortterm does not build its own order path, wallet, key, or service. It publishes a Directive envelope to NATS subject cohort.signals; pmv2’s position_manager executor consumes by source and places the order via CLOB.

  • Directive source = crypto_shortterm_latency_test
  • Schema = the confirmed pmv2 #62 / #215 contract (id, source, schema_version=1, action=BUY, market_slug, condition_id 0x…, yes_token_id decimal string, tick_size, min_size, neg_risk, max_price, valid_until_ts; Nats-Msg-Id header = id).
  • v1 = UP-conviction only.
  • Per-fill size comes from pmv2’s GLOBAL base-size config, not from our Directive. CORRECTED (2026-06-26): PM honors the producer’s size_shares directly (pricing.rs:217: size_usd = limit_price × size_shares, no config override) — size_shares IS the authoritative per-trade size lever (derived as the venue floor orderMinSize in directive.rs::build_entry). See crypto-shortterm-phase1-bet-sizing.

See pmv2 Directive Schema Alignment (c12c830) for the full field-by-field schema and crypto-shortterm-repo-rename-pmv2-rearch for the producer/executor split.

Latency Budget (the constraint)

From crypto-shortterm-phase1-latency-budget: the edge tolerates ~0.5¢ adverse drift; near-expiry adverse drift p90 = 3.91¢/s → publish→fill budget ≈ 128ms (p95 → 86ms). 29% of 1s steps already breach 0.5¢ → HIGH sensitivity; <50ms ideal.

Polymarket’s Honest Go / No-Go

≲128ms is LIKELY NOT achievable over REST

A sub-128ms publish→fill is likely unachievable through pmv2’s publish → sign → CLOB-REST-POST → fill path. A remote HTTPS order POST alone is usually >128ms; <50ms is infeasible over REST. Genuine sub-128ms execution needs a co-located, persistent-connection (ws/FIX) order path that pmv2 does not have (a separate build). So the live test is expected to measure a miss — but a definitive, defensible measurement beats an estimate.

Decision — Staged $100 Test

Andras’s decision: a staged $100 live latency test, structured to spend the minimum needed for a definitive number.

  1. Dry-validate (free) — confirm the full chain produces (emit fires, pmv2 dry-skips, emitted_signals rows accrue).
  2. Tiny 5-fill live tranche (~$20) — flip live with tiny caps.
  3. Read realized publish→fill latency.
  4. Early-exit if it confirms the miss — a definitive number for ~100.

Spend enforcement (two independent caps)

  • Primary: emit’s EMIT_MAX_FIRES bounds the number of fires.
  • Backstop: source daily_spend_cap_usd = **200 paired with a 5→10 share double was reversed — see crypto-shortterm-phase1-bet-sizing.)
  • Per-fill size is pmv2’s global base-size config, not our Directive. CORRECTED: per-trade size = the producer’s size_shares (the venue-floor share count); PM honors it directly.

emit Hardened (build → review → fix)

emit was built and twice code-reviewed + hardened (pins through bc38734 / 89e354e): the 3-blocker / 3-high findings and fixes (condition_id-0x skip, token-by-outcome-label, crash-durable guardrails hydrated from emitted_signals, staleness gates, NATS-fail-does-not-mark-fired, etc.) live in crypto-shortterm-emit-guardrails and crypto-shortterm-emit-prelive-pass2.

Dry-Validate Deployed (#264)

Both crypto-shortterm.service (observe) and crypto-shortterm-emit.service are active. Source crypto_shortterm_latency_test set mode=dry_run. Migrations 0003 / 0004 / 0005 applied. (The dry-validate run then surfaced the zero-emits bug — see crypto-shortterm-polymarket-token-overflow-fix.)

Next Sequence (once unblocked)

redeploy @ 7bfe3a0 → dry-validate produces (emit fires, pmv2 dry-skips, emitted_signals rows) → Andras flips source + global live with tiny caps → 5-fill tranche → read latency → early-exit decision.