Levandor

On-Chain Realized Cash is the P&L Truth — Three Metrics Disagree (2026-07-06)

4 min read

The trustworthy realized P&L is on-chain cash — three P&L metrics disagree by 2–6×, and the wallet2 “under-booking” was a booking lag, not a bug. This extends crypto-shortterm-pnl-attribution-corrections-2026-07-03 (which established realized_pnl_usd > resolved_up) with the metric that sits above both: the USDC that actually moved.

For Agents — binding rules

  1. Realized P&L = on-chain CASH = Σ(REDEEM) + Σ(SELL) − Σ(BUY) from the Polymarket data-api /activity, per proxy wallet. Net of fees, no mark-to-market. This is the ground truth — what USDC actually hit the wallet.
  2. DO NOT use the Polymarket UI / lb-api / user-pnl-api “profit” as realized P&L — it is INFLATED 2–6× (unrealized mark-to-market + gross of fees).
  3. pmv2_autotrade_orders.realized_pnl_usd is correct but LAGS at resolution, then reconciles to on-chain cash (overnight ~288 cash). To read true realized P&L now (without waiting on the lag), compute on-chain cash via the persisted scripts below.

The three metrics

MetricDefinitionTrust
On-chain realized CASH = Σ(REDEEM)+Σ(SELL)−Σ(BUY) (data-api /activity, per proxy wallet)actual USDC moved; net of fees; no mark-to-marketTRUTH — use for realized P&L
pmv2_autotrade_orders.realized_pnl_usdCLOB-settled, net of fees (fee baked into cost_basis)label-truth-grade (sign 24/24) but LAGS at resolution, reconciles to on-chain cash overnight
PM lb-api / user-pnl-api / UI “profit”unrealized mark-to-market + gross of feesINFLATED 2–6× — do NOT use as realized P&L

Example of the UI inflation: wallet1 UI “profit” read ~90 — a 2–6× overread. The UI marks open positions to market and omits the taker fee, so it flatters a high-frequency taker (the same reason the competitor’s lb-api number was misleading — see crypto-shortterm-competitor-wowitsamazing-refuted-2026-07-03).

Scripts (persisted to the repo)

Both live in the repo scripts/ (NOT the ephemeral scratchpad the perf-dashboard scripts were in):

  • scripts/wallet_lane_cashflow.py — per-lane on-chain cashflow; maps each REDEEM back to its lane via the conditionId recorded on the originating BUY.
  • scripts/wallet_pnl_reconcile.py — reconciles the three metrics (on-chain cash vs realized_pnl_usd vs UI).

The wallet2 “2× under-booking” (#1054) was a BOOKING LAG, not a bug

The babylon #1054 report that wallet2’s realized_pnl_usd was ~2× under-booked turned out to be a resolution-time booking lag, not a code defect:

  • @positionmanager traced it: the winner-flag sweep that books realized_pnl_usd is wallet-AGNOSTIC — it cannot be wallet2-only, so a wallet2-specific code bug is impossible by construction.
  • Overnight it reconciled: the booked total caught up to the on-chain cash (~288 cash). So realized_pnl_usd lags at resolution and then reconciles — it under-reads transiently until the sweep runs, not systematically.
  • This is NOT the #1031 mechanism. #1031 (the earlier “biased-negative / 7 false losses” claim) was already refuted as zero-delta — a flipped token-side cross-ref in a crypto-side session, not a PM booking defect (crypto-shortterm-pnl-attribution-corrections-2026-07-03). #1054 is a different, benign phenomenon (a lag, not a bias).

Attribution confirmation. A confirming query found 836 / 837 on-chain conditions matched PM-placed orders — which also refutes the “Balu manual activity muddies attribution” hypothesis for the majors: the wallets are algo-dedicated (size_scale=1.0, only 1 manual bet — a Paraguay market). (Caveat: this clean read is scoped to the algo majors; a live BNB lane introduces manual-BNB contamination — see crypto-shortterm-bnb-expansion-eval-2026-07-05.)

Current state (2026-07-06)

  • Combined realized cash ~$280–290 across both wallets.
  • Win rate ~73.7% vs ~73.0% breakeven — thinly positive (the edge is real but small; consistent with the dashboard and the frozen-rule’s thin-but-positive at-ask EV).
  • Wallets (both trade the same windows/sides, hold ~$0 idle USDC — everything cycling in positions):
    • wallet1 = 0xAdAc17C0…aEb2 (“bandiboss”)
    • wallet2 = 0x7D39B0e5…8ee6 (“Balu”)

Graph View

Backlinks