W0 Fee/Rebate Audit — pmv2 Fee-Booking Bug + Taker Rebates Are Real But Tiny

Closing the W0 taker-rebate check (the one free W-item from the shelve verdict) surfaced two empirical facts. The verdict is unchanged — the lane stays shelved — but both findings re-base the fee accounting the whole fleet uses. (1) pmv2 books taker fees at 0.10·p·(1−p)·size while the venue actually charges exactly 0.07·p·(1−p) → every pmv2-booked strategy’s realized_pnl_usd is systematically pessimistic. (2) Taker rebates are real but tiny for us (+0.05¢/share), 5× below the earlier upper bound.

For Agents

This answers the standing follow-up from the competitor refutation (“do WE accrue taker rebates?”) and the W0 item. Our own observe::fee (0.07) was always correct — the validated net-edge gate’s fee term needs no change. The bug is in pmv2’s pmv2_autotrade_orders.fee_usd booking, reported to positionmanager as babylon #1233. Rebate credits are not represented anywhere in pmv2’s orders table. All numbers are read-only, from data-api.polymarket.com activity paging (scratchpad rebate_tally.py / fee_fit.py); wallets from public.pmv2_wallets (all dry_run).

Finding 1 — the pmv2 fee-booking bug (fleet-wide)

pmv2 over-books taker fees by 43%

pmv2_autotrade_orders.fee_usd = exactly 0.10·p·(1−p)·size on all 5,322 fee>0 rows. The venue’s actual charge — fitted on 3,399 of our own live BUY fills via the data-api identity usdcSize − price·size — is exactly 0.07 (median = p10 = p90 = 0.0700, zero dispersion). Booked fees are 43% too high, so realized_pnl_usd is systematically pessimistic for every pmv2-booked strategy.

• The venue coefficient is 0.07, not 0.10. Zero dispersion across the fit (median = p10 = p90) means it is a hard multiplicative constant, not a noisy average. This matches the competitor’s 190k-fill fit (the 0.07·x·(1−x) fee identity, corr 0.9915) — independent confirmation on our own fills.
• Impact on our lane: booked realized_pnl_usd reads −$717\ast \ast ;thetrue(0.07-fee)figureis\ast \ast \approx -$368. Per-share, −0.92¢ booked → −0.47¢ true. The direction of every EV verdict is unchanged (still negative), but the magnitude was overstated by the 0.10/0.07 gap.
• Our side was never wrong. observe::fee already uses 0.07 — the validated net-edge gate’s 0.07·eff·(1−eff) term is venue-exact and needs no change. This is purely a pmv2-side booking discrepancy.
• Reported as babylon #1233 to positionmanager. It affects fleet-wide P&L reporting, not just this lane.

Finding 2 — taker rebates are real but tiny for us

+0.05¢/share, not the +0.24¢ upper bound

16 TAKER_REBATE rows totalling $39.49\ast \ast acrossall4proxywallets(bandi\ast \ast$22.55, balu $16.94\ast \ast ,levi/gyula\ast \ast 0\ast \ast )—roughlydaily$1–2 credits plus two ~$10rows.Thatis\ast \ast 3.4$1,163 modeled fee ≈ +0.05¢/share — 5× below the earlier +0.24¢ bound and well under the competitor’s ~16%-effective claw-back. Maker rebate = $0 (we are pure takers).

• The earlier “rebates claw back ~16% → 1.72% effective fee” figure was the competitor’s harvest rate, and the +0.24¢/share was an upper bound. Our actual rate is ~3.4% of modeled fee — the rebate program IS real (confirmed via the competitor’s +$14.4kharvestandthepresenceof‘TAKE{R}_{R}EBATE‘rows),butatour$400-roll volume it is immaterial (+0.05¢/share).
• Levi and gyula accrued zero rebates — consistent with those wallets running OFF for most of the period.
• Rebate credits are not surfaced in pmv2_autotrade_orders at all — they arrive as separate data-api activity rows and are invisible to any P&L gauge built on the orders table.

Net effect on the shelve verdict

Both findings make the true economics less bad than booked, but not remotely enough to reopen. Applying the 0.07 fee (−0.47¢/share true vs −0.92¢ booked) plus the +0.05¢ rebate credit still leaves the lane net-negative on real labels — the structural last-look ceiling and the falsified 15m premise are unaffected by a fee re-base. The lane stays shelved; observe keeps recording.

Provenance & artifacts

• Method: data-api.polymarket.com activity paging; fee fit on the usdcSize − price·size identity over 3,399 live BUY fills; rebate tally over all TAKER_REBATE activity rows.
• Scratchpad scripts: rebate_tally.py, fee_fit.py (ephemeral).
• Wallets sourced from public.pmv2_wallets (all dry_run).
• Artifact: data/w0_rebate_fee_reconciliation_2026-07-21.csv.
• HANDOVER.md 2026-07-21/22 section updated.
• Fleet report: babylon #1233 (positionmanager) for the fee-booking bug.

Related

• crypto-shortterm-15m-resite-premise-falsified-2026-07-21 — the shelve verdict that scoped W0 as the one free item worth running; verdict unchanged by this audit
• crypto-shortterm-competitor-wowitsamazing-refuted-2026-07-03 — the 0.07·x·(1−x) fee identity (190k-fill fit) this independently re-confirms; source of the “do WE accrue rebates?” follow-up now answered
• crypto-shortterm-polymarket-data-api-gotchas — the usdcSize-includes-fee identity and the earlier 1.72%-effective / rebate caveats this sharpens
• crypto-shortterm-fill-space-closed-15m-pivot-proposal-2026-07-18 — proposed W0 as a fee re-base at zero build cost
• crypto-shortterm-strategy-design — the net-edge gate whose 0.07 fee term is confirmed venue-exact (no change)
• crypto-shortterm-lane-state-adverse-fill-2026-07-05 — realized_pnl_usd is CLOB-truth net-of-fee; this note quantifies the booked-fee overstatement inside it
• crypto-shortterm — project index