MSR Decode All case files Check a wallet free
MSR DecodeMethod Reportpublic case file

The endpoint that invents fraud.

Polymarket /trades vs /activity  ·  150 markets across 3 wallets  ·  re-fetched 2026-07-25  ·  report published 2026-07-25
Retraction — our own method was wrong A standard forensic check told us three profitable Polymarket wallets had booked $926,462.58 of leaderboard profit on positions they never bought. It was a good story. It was also an artifact of a default parameter on the endpoint the check reads. We re-fetched the 150 largest of the 4,725 markets it flagged: 150 of 150 were paid for in full, through the order book.
01

The check that looked like a scandal

Polymarket outcome shares are ERC-1155 tokens on Polygon. They can be bought on the order book, minted by splitting collateral, or simply sent from one wallet to another — and a plain token transfer carries no cost basis to the receiving side. So a wallet could, in principle, receive winning shares from a second wallet the same person controls, redeem them at $1.00, and book the entire face value as profit it never earned.

The standard way to test for this is a redemption reconciliation. For each market, work out the most a wallet could have redeemed given what it bought, and compare that to what it actually redeemed:

The transfer-PnL filter, as commonly implemented
StepComputation
Max implied redemptionmax(net_yes_shares, net_no_shares) + self_split_usdc
Excessactual_redeem − max_implied
Verdictexcess > $5 on a market → flag as transfer-inflated

The share counts come from Polymarket’s public /trades endpoint. Run this across a set of high-profit wallets and the results are dramatic: across the three wallets in this report it flagged 4,725 markets carrying $4,772,218.83 of apparently unbacked redemptions. The arithmetic is sound. The inputs are not.

02

One market, four answers

Take the single largest flagged market in the worst-looking wallet: 0x8c901f67…a904, in “Bitcoin Up or Down — April 27, 9:35PM–9:40PM ET” (0x2981bbd7…89bb). A market that existed for five minutes.

The same wallet, the same market, four sources — each row independently answers “what did this wallet acquire here?”, so the column is not a sum
SourceBuy fills reportedSharesCost
/trades, default — as the filter read it in April 2026121.19$16.74
/trades, default — re-fetched 2026-07-25120.87$16.49
/trades?takerOnly=false — re-fetched 2026-07-258012,759.03$9,978.37
/activity — re-fetched 2026-07-258012,759.68$9,978.88

At resolution the wallet burned 12,759.355696 shares and was paid $12,759.355696 — a figure Polymarket’s own records and the chain agree on to six decimals.

So the filter saw $16.74 of buying against a $12,759.36 redemption and concluded that roughly $12,738 of winning shares had been gifted in from a sister wallet. What actually happened is that the wallet bought 12,759.68 shares for $9,978.88 across 80 fills and made an ordinary $2,780.48 profit. Adding one query parameter — takerOnly=false — returns 79 of the 80 fills the default view withholds.

The April and July /trades rows differ slightly (21.19 vs 20.87 shares). We publish both rather than reconcile them away: the April figure is what the filter actually consumed, and a reader re-running the call today will get the July one. The one-fill count — the part that matters — reproduces exactly.

03

What the chain says

An API disagreeing with itself does not settle who is right, so we went to Polygon. We took the redemption transaction, decoded which token was burned and in what quantity, then scanned the blocks before it for every inbound transfer of that exact token and resolved each sender.

Where the 12,759.355696 redeemed shares came from — redemption tx 0xbde3495e…c4ee8, Polygon block 86110435
SenderIdentityTransfersShares
0x4bfb41d5…8982eCTFExchange — Polymarket’s order-matching contract8012,398.622139
0xe3f18acc…ab7b0FeeModule — Polymarket’s fee contract80360.733557
any ordinary wallet00.000000
Totalties to the burned quantity exactly16012,759.355696

Every share came through Polymarket’s own contracts. Not one arrived from another user’s wallet. Both sender addresses are verified under those names on Blockscout, and the two calls in Section 07 reproduce this.

There is a trap here that is the mirror image of the first one. An ordinary purchase also arrives in your wallet as an inbound ERC-1155 transfer — the exchange contract is the sender. A raw count of “inbound transfers” is therefore not evidence of anything either. The sender has to be resolved before the number means what it appears to mean.

04

It generalises

One market could be a fluke. We re-fetched the 150 largest flagged markets by excess — the top 50 from each of the three wallets — and asked the same question of each: is the “excess” explained by buying that the default /trades view failed to report?

Re-fetch of the 150 largest flagged markets — per-market source data at trades-endpoint-reconciliation.json
WalletMarketsCalled unbackedActually paidSale proceedsRedeemedNetExplained
0x8c901f67…a90450$403,775.97$316,356.10$0.00$461,844.46+$145,488.3650 / 50
0xd0d6053c…93aa50$82,311.53$230,026.09$19,444.77$218,392.51+$7,811.1950 / 50
0x1d003413…031350$440,375.08$815,516.86$0.00$854,027.96+$38,511.1050 / 50
Total150$926,462.58$1,361,899.05$19,444.77$1,534,264.93+$191,810.65150 / 150

150 of 150. Not one of them showed a redemption exceeding the shares that wallet had verifiably bought and still held. The $926,462.58 the method called unbacked was $1,361,899.05 of real buying the default trade view did not show us.

Two limits on that sentence, both load-bearing. This is the top 150 of 4,725 flagged markets, chosen by size of excess, not a random sample — the right sample for testing whether the method works, the wrong one for estimating a rate. And what it establishes is narrow: these redemptions were paid for through the order book. It does not establish that the wallets are profitable overall — flagged markets are selected for having large redemptions, so losing markets are excluded by construction — and no reconciliation of this kind could detect two related wallets trading with each other on the order book, since those fills are paid for too. The claim is that the redemptions were bought, not that the wallets are innocent of everything.

05

Why the feed does this

Cause 1

A default parameter

The /trades endpoint defaults to takerOnly=true — it returns only the fills where the wallet crossed the spread. Passing takerOnly=false returns the rest. In the exemplar that is the difference between 1 fill and 80.

Cause 2

Quick markets have no order book

All 150 flagged markets carry enable_order_book: false. In these, orders are matched by Polymarket’s operator, which is the taker — so the user is the maker on essentially every fill, and the default view withholds essentially everything.

That second point is what makes this dangerous rather than merely annoying. The omission is not proportional to how aggressively a wallet provides liquidity — in a market with no order book it is close to total, for every participant. A wallet that trades five-minute crypto markets will look almost entirely unfunded, and one that trades order-book markets will look clean, regardless of what either is doing.

Because the failure removes buying and never adds any, the error has a direction. excess does not measure transfers. It measures how much of a wallet’s trading the default view withheld, and it points one way: toward “this looks like fraud.”

The filter could have caught itself without any of this. On some flagged markets its own arithmetic produced negative net holdings — one records the wallet holding −577.29 shares of a side it then redeemed. A wallet cannot hold a negative quantity of a token. That is a self-refuting input, and nothing in the pipeline stopped on it.

06

What we are retracting

These figures came out of our own private research between April and May 2026. None were ever published, and this page is the reason they will not be. Every one of them is withdrawn:

Withdrawn internal findings
ClaimStatus
Three of four sampled wallets 63–86% “transfer-inflated”Withdrawn — 150/150 re-fetched markets explained by real purchases
“25 of 60 wallets in one cluster above 50%”Withdrawn — same method, same default parameter
“75–85% of top wallet decodes are transfer-inflated”Withdrawn — the base rate measured our fetch, not the wallets
The filter “under-counts, never over-counts”False — true only given a complete trade record

One caveat runs the other way and we are keeping it visible: we have shown the method produces false positives at scale, not that wallet-to-wallet share transfers never happen. The behaviour is possible and the platform cannot show it to you. We simply have no evidence of it at the scale the method attributed.

07

What to do instead

The gap the original theory pointed at is real. Polymarket’s /activity feed enumerates twelve event types — TRADE, SPLIT, MERGE, REDEEM, REWARD, CONVERSION, DEPOSIT, WITHDRAWAL, YIELD, MAKER_REBATE, TAKER_REBATE, REFERRAL_REWARD — and none of them is a token transfer. A wallet-to-wallet share transfer genuinely is invisible in the platform’s public data, and displayed profit does not net it out. That is worth knowing. It is just not what the filter was measuring.

Fix 1

Ask for the other side of the book

Pass takerOnly=false, or reconcile against /activity scoped to a single market. Either way, page it: /activity caps every response at 500 records regardless of the limit you request, and 21 of these 150 markets needed more than one page.

Fix 2

Resolve senders on-chain

Measure the unambiguous quantity: inbound ERC-1155 transfers whose sender is not a Polymarket contract. The set is larger than it looks — CTFExchange and its v2 deployment, NegRiskCtfExchange, NegRiskAdapter, FeeModule, CtfCollateralAdapter, and the zero address. Miss one and you have rebuilt the same false-positive generator.

The calls behind Sections 02 and 03, in full:

Reproduce it yourself
WhatCall
1 filldata-api.polymarket.com/trades?user=0x8c901f67b036b5eebab4e1f2f904b8676743a904&market=0x2981bbd76157280d6161a7cded2a141af40d8d2f94a2014c4561488079bd89bb
80 fills…the same call with &takerOnly=false
The redemptioneth_getTransactionReceipt 0xbde3495edd20cf329cb5b12262be4191907f3e6261f124994870b4e3731c4ee8
The senderspolygon.blockscout.com/api/v2/addresses/0x4bfb41d5b3570defd03c39a9a4d8de6bd8b8982e
08

Why we published a retraction

The version of this page that does not exist. The finding was ready to go out as an investigation: a mechanism, named wallets, seven-figure sums, an eye-catching base rate, and a plausible story about a public leaderboard being gamed. It would have travelled further than this one will. Our publishing doctrine has a rule that stopped it — a numeric gap may not have a cause attached to it until the gap itself is reconciled, and our own pipeline is the null hypothesis until it is cleared in writing. The alternative was accusing three profitable traders of fraud in public, on the strength of a query parameter nobody had checked.

We are not above the failure we are describing. The first draft of this page reconciled 110 markets with a single unpaged request each — and silently truncated 18 of them at the same 500-record cap Section 07 now warns about, understating real buying by roughly $72,000 and overstating the wallets’ net by a similar amount. A pre-publication review caught it. The numbers above are the re-paged ones, and the check that would have caught it now runs on every build.

If you run wallet forensics on Polymarket — copy-trading products, leaderboard screens, academic work using displayed profit as a skill proxy — the specific failure is worth checking for in your own pipeline. It does not announce itself. It produces confident, specific, technical output that happens to be wrong, and in markets without an order book it is close to total.

09

Method and limits

Method. Each of the 150 markets was re-fetched from /activity scoped to that single market and paged on offset until a short page proved the end; a failed page is fatal for that market and is recorded, never treated as end-of-data. Buy and sell legs were summed independently of any earlier decode, and a market counts as explained only if its redemption does not exceed shares bought minus shares sold. Zero fetch failures. The exemplar in Sections 02 and 03 was additionally confirmed against the Polygon chain: the redemption receipt was decoded to establish which token was burned and in what quantity, then every inbound transfer of that token in the preceding 1,200 blocks was enumerated and each sender resolved against Blockscout’s verified contract names. The per-market reconciliation, including the tolerance derivation, is published at trades-endpoint-reconciliation.json, and a build gate recomputes this section’s table from it.

Limits. The chain-level sender confirmation was run on one market, not all 150 — free Polygon archive endpoints refuse or rate-limit log queries at this depth, so the other 149 rest on the API reconciliation alone. The 150 markets are the largest by excess out of 4,725 flagged, not a random sample. The three wallets are the ones our own method flagged hardest, which is the right sample for testing the method and the wrong one for any population estimate. We make no claim about how common wallet-to-wallet transfers are on Polymarket — only that this way of detecting them does not work. Two figures cited in passing (the “negative net holdings” example in Section 05 and the April /trades row in Section 02) come from the original private pipeline’s stored output rather than from a published artifact.

Want a wallet decoded like this one?

Give us a wallet — we’ll tell you, with the receipts, whether the genius is real before you copy it.

Check a wallet free