Phase-1 Bet Sizing — size_shares authority & the daily-cap gate

Durable size-mechanics facts for the Phase-1 latency test. Bet stays at the venue floor (~5 shares) and the daily cap stays $100 — see the reversal banner below. The two findings here are durable knowledge that resolved a real ambiguity; keep them.

Double-bet decision REVERSED (2026-06-26)

A “double the bet 5→10 shares + raise the daily cap $100\to$200” decision was made and then reversed the same day — Andras changed his mind. The EMIT_SIZE_MULTIPLIER env knob that would have enabled it was added (4587df1) then reverted (9afe055) — it is NOT in the codebase. size_shares is back to the plain venue-floor derivation; the cap stays $100. No production behavior ever changed (the change was a no-op at its default and the activating env/cap DMs never sent). The findings below remain TRUE regardless.

size_shares is the authoritative size lever (resolves an old ambiguity)

Supersedes the 62-Directive-era note

The executor @positionmanager honors the producer’s EntryOrder.size_shares directly. position_manager/crates/position_manager/src/pricing.rs:217 computes size_usd = limit_price × size_shares — NO config-based override. This supersedes the old crypto-shortterm-phase1-execution-decision claim that PM sized independently from its own base-size config and treated our size_shares as merely a venue floor. Producer-side size_shares IS the per-trade size lever. Units = outcome-token shares (not USD). Today it is derived as the venue floor: size_shares = orderMinSize.ceil().max(1.0) in directive.rs::build_entry.

The daily cap is a GATE, not a resizer

• pmv2_autotrade_sources.daily_spend_cap_usd (currently $100) is a PM-side DB column owned by @positionmanager.
• It rejects orders that would breach the daily cap (reserve.rs:146 → ReserveOutcome::CapSrcDaily) — it does not shrink them to fit.
• Consequence: per-trade size and the daily cap are independent levers. A bigger per-trade size eats the fixed cap faster → fewer fills. (This is why any future size increase would need a paired cap bump to preserve fill count — the reasoning behind the now-reversed double-bet proposal.)

Related

• crypto-shortterm-per-wallet-size-scale-2026-07-06 — the PM-side, per-wallet GLOBAL sizing lever pmv2_wallets.size_scale (added 2026-07-01, layered on top of the producer-side size_shares here); the same daily-cap-is-a-GATE mechanic applies (a size_scale bump must be paired with a daily_spend_cap_usd bump).
• crypto-shortterm-handover-2026-06-26 — current state: producer LIVE, dry-validate passed end-to-end, latency STILL untested
• crypto-shortterm-phase1-execution-decision — the staged latency-test plan; its “per-fill size from pmv2 global base-size” claim is corrected here
• crypto-shortterm-phase1-latency-budget — the 128ms publish→fill budget the latency test measures
• crypto-shortterm-emit-guardrails — the EMIT_* env family + money-safety guardrails
• crypto-shortterm — project index