Levandor

PM resolution-PnL booking verified correct (2026-07-03 false alarm)

2 min read

On 2026-07-03 crypto raised suspected bug #1031 (7 of 246 settled rows in resolution_sweep.rs booked as losses that “should have won”). Investigation cleared PM: the -cost_basis bookings were genuinely correct; root cause was an upstream cross-ref artifact on crypto’s side. Documented to stop a future session re-investigating this as a PM bug.

For Agents

PM’s resolution_sweep realized-PnL booking is trusted-correct against CLOB tokens[].winner flags as of 2026-07-03. If a future PnL discrepancy is reported, re-verify against CLOB tokens[].winner directly (deploy’s authoritative re-check) BEFORE assuming a PM read bug. A prior alarm turned out to be an upstream crypto Data Streams near-tie cross-ref artifact, not a PM error and not a token flip.

The Alarm (#1031)

Crypto reported that in the new realized-PnL-on-resolution path (resolution_sweep.rs), 7 of 246 settled rows (order ids 3721, 3814, 3872, 3875, 3876, 3958, 4043) appeared booked as losses (-cost_basis) where crypto’s cross-reference said the market resolved our way. Alleged: PM premature-reads CLOB tokens[].winner flags before UMA finalization.

Investigation (PM side)

  • CLOB MarketResponse has no dedicated resolved / UMA-finalized field. The only resolution signal is per-token winner: bool (defaults false).
  • MarketStatus.resolved is a fake copy of closed — status_from sets resolved: m.closed. Do not treat it as an independent UMA signal.
  • The sweep gates on closed, BUT the live path (commit c444c86) already skips when the winner set is empty — logs "resolved but no winner token; skipping this pass".
  • Therefore a plain no-flag market is deferred, not booked as a loss. There is no demonstrated premature-read instance in PM.

Resolution

Deploy ran an authoritative CLOB re-check on all 7 order ids → we genuinely LOST all 7. PM’s -cost_basis booking was correct. Crypto withdrew the “false losses” framing. Root cause was a Data Streams near-tie gap artifact in crypto’s OWN cross-reference, not a PM read error and not a token-side flip. #1031 closed zero-delta: no retro-correction, no code change.

Decision: settlement grace period — rejected (YAGNI)

A “settlement grace period” gate (defer booking until N minutes past market close) was designed and approved-then-withdrawn. Once the premise collapsed (no demonstrated premature read), it was rejected as YAGNI. The existing empty-winners skip guard (c444c86) remains the minimal defense. No grace constant was added.

Graph View

Backlinks