PM computes the platform fee locally from the venue’s own reported fee_rate_bps, which returns 1000 bps (0.10); crypto reports the venue actually charges 0.07 — a 1.43× over-booking worth ≈ $348.9 fleet-wide, which understates realized_pnl_usd and therefore under-bills clients.
How PM books the fee
PM does not read a venue-reported fee off the fill. It recomputes it:
platform_fee(amount, price, fee_rate, exponent) — polymarket-clob/src/lib.rs:153
shares = amount / price
fee = shares · fee_rate · (p·(1−p))^exponent
Inputs come from the venue at build time (lib.rs:538):
| Input | Source |
|---|---|
fee_rate | base_fee / 10000, base_fee = venue fee_rate_bps(token_id) |
exponent | venue fee_exponent(token_id) |
Empirical check — all live fills
Over the full history in Supabase pmv2_autotrade_orders:
n = 5,322
implied_coeff = fee_usd / (filled_size · p · (1−p))
avg = min = max = 0.10000 (exactly constant)
total fee booked = $1,163.05
An exactly constant implied coefficient pins both parameters: fee_rate = 0.10, exponent = 1. That means the venue API is reporting 1000 bps.
The discrepancy
crypto (the signal-lane agent) reports the venue actually charges exactly 0.07 · p · (1−p).
| Value | |
|---|---|
| Booked coefficient | 0.10 |
| Reported actual | 0.07 |
| Over-booking factor | 10/7 = 1.43× |
| Fleet-wide over-booked | ≈ $348.9 |
Why this matters beyond accounting
Every −EV conclusion this month was slightly pessimistic
All the −EV analysis was run on
realized_pnl_usd, which is understated by the over-booked fee, fleet-wide. Conclusions drawn from it lean pessimistic. Re-derive before acting on marginal-EV calls.
Client billing is affected
The fee engine bills clients 20% of weekly PnL. Understated PnL ⇒ under-billed clients. This is money math with downstream invoices attached — see pmv2-open-multi-wallet-liquidity-ceiling-brainstorm for the fee/MLM context.
Status: NOT fixed — deliberately
PM is faithfully using the venue’s own reported rate. “Fixing” it means overriding a live API value with a hardcoded constant, on a path that feeds client billing.
Gate: awaiting crypto’s ground-truth evidence — on-chain settlement deltas vs booked fees — before changing money math. Backfilling the 5,322 historical rows would be a separate Andras-gated data migration, not part of the code change.
Durable gap worth recording
For Agents
PM computes the fee locally and never records the venue-reported fee, so there is no detector if the venue changes its fee schedule — the books would silently drift and nothing would fire. Recording the venue-reported fee alongside the computed one would make this continuously reconcilable instead of requiring an out-of-band tip-off.
This is the same shape as the sqlx decode bug and the non-compiling cap test: a wrong value that nothing in the system is positioned to notice.