Who is really behind that Polymarket move?

CALIBRE: a whale X-ray that learns which traders reliably lose, and seals every call on Walrus Memory before the result

A Polymarket game market drops from 80% to 54% in twenty minutes. Somebody knows something, right?

Usually, nobody does. I spent the Total Recall hackathon building CALIBRE to answer that question with evidence instead of vibes: before you chase a price move or copy a whale, see whether the money behind it comes from traders who reliably lose.

Try it: https://calibre-blush.vercel.app · Code: https://github.com/timix648/calibre

The idea in one paragraph

Every Polymarket trade is public. So for any wallet you can ask a simple question: on its past bets, did it win more often than the price it paid implied? A wallet that keeps buying at 40 cents and wins 55% of the time has an edge of about 15 points per bet. One that wins 30% of the time has a negative edge. CALIBRE scores wallets that way, puts an error band on the score so luck is not mistaken for skill, and gives each wallet a plain label: proven losing record, proven winning record, mostly sniping, too early or no proven edge. Then, when a market moves, it looks at who pushed the price and how much of that money came from proven losers.

First, I had to find out whether any of this is real

The easy version of this product is a leaderboard of "smart money". The honest version starts by checking whether past performance says anything about future performance. It took three attempts to get the test right, and the first two were wrong.

Attempt 1 used wallets from the profit leaderboard. That sample is biased (you only see the survivors), and it found nothing.

Attempt 2 used 40 wallets picked without looking at profit, and found a strong signal: older edge predicted newer edge with a
rank correlation of 0.41. That looked like a headline. It was an artefact. Those wallets were buying outcomes that were already decided, at 98 cents, over and over. That earns a small, steady edge that looks like skill but is not forecasting. Once bets at 97 cents or more (or 3 cents or less) were excluded, the signal fell to 0.12 and stopped being significant. I rewrote the findings and built "sniping" into the product as its own label, because a copy-trader needs to know it.

Attempt 3 was the real test: 1,000 wallets sampled without regard to profit from 2,000 random sports markets, 356,116 scored
bets. Split each wallet's bets in half by time. Give it the label it would have had from its older half. Then look at its newer half.

The result is lopsided, and that shaped the product. Losers keep losing: 81% of wallets with a proven losing record lost again, by about 4 points per bet. Winners exist but are rare and modest. And the profit leaderboard carries no persistent signal at all (rank correlation -0.04).

So CALIBRE is not a "follow the sharps" tool. It is a "know when you are following squares" tool.

Does it matter for live moves?

A label on a wallet is useful. The bigger question is whether it changes how you should read a price move. I replayed 11,975 real moves of 6 points or more within an hour, in 4,587 closed sports markets across 142 leagues ($1.78 billion of trading volume by Polymarket's own figures, $197.6 million of it pushing those moves). For each move, the biggest takers were labelled using only bets that had resolved before the move, so there is no hindsight.

Following a move pushed mostly by proven losers paid 3.1 points worse than following a clean move (one-sided permutation p =
0.073), mostly in-play. That is early evidence, not proof, and CALIBRE says so everywhere it shows the number. Square money is a
caution signal. The app never tells anyone to trade against it.

What it does

• Wallet X-ray. Paste a Polymarket profile, @handle or address. You get edge per bet with an error band, pre-game and in-play separately, the sniping share and the label, from the wallet's newest 1,000 trades via Polymarket's free public API.
• Market X-ray. Paste a market or event link. You get the latest move, its biggest takers with their labels, and how much of the pushing money came from proven losers, with how much of it could be judged at all.
• Radar and record. A watcher judges live moves and seals each verdict before the result. The record page grades every one.
• Chrome extension. The same X-ray as a panel on polymarket.com profiles, markets and game pages.
• Paid agent API. An agent with a wallet but no account buys a wallet X-ray for 0.01 USDC, settled on Sui, no signup.
• MCP server. wallet_audit and latest_verdicts as tools, over a URL: claude mcp add --transport http calibre https://calibre-blush.vercel.app/api/mcp. MCP is an open protocol, so it works from Cursor, VS Code, Windsurf and anything else that speaks it, and it is plain JSON-RPC underneath if you would rather call it yourself. No key, nothing to install.

How it uses Walrus Memory

Walrus Memory is the system of record, not a cache. There are three namespaces in use:

• calibre-verdicts: when the watcher sees a move, it seals a verdict with the label, the forecast, the price, the takers and their labels, the square-money share and the latest Sui checkpoint at that moment. That checkpoint is the timestamp nobody can backdate: the verdict provably existed before the market resolved.
• calibre-outcomes: when the market resolves, the grader seals an outcome memory that points back at the verdict, with a Brier score for CALIBRE's forecast and for the market price.
• calibre-wallets: one record per wallet and league.

Walrus Memory has no update and no delete, which is the point for receipts but needs a pattern for anything that changes. Every memory is a small envelope, [cal1|kind|key|vN] summary || {json}: a readable summary for semantic recall, then the data. A wallet whose record changes gets a new version, and readers keep the latest version per key. The proof page and pnpm verify rebuild everything from Walrus alone: list each namespace, recall and decode every verdict and outcome, check that every outcome has its verdict, and link each blob on Walruscan.

The site reads it the same way. Radar, Record and Proof recall from Walrus when the page renders rather than serving a file I exported and committed, so a verdict the watcher seals appears without anything being deployed and without any machine holding write access to the repository. There is a lesson in the timings here too: the export merges five recall queries to get past the 100-per-query ceiling and takes about 52 seconds, which no page can wait for, but a single query returns the same verdicts in 8 to 13 seconds while the namespace is still under that ceiling. So the site uses one query, checks whether it has hit the ceiling, and falls back to the last export if it has, or if Walrus is simply having a bad minute. Each page says which one you are looking at.

How it learned over time

This is the part the hackathon asked about, and there are three loops.

1. Wallets' records grow, and their memories are re-versioned. When a verdict is graded, the grader goes back to the wallets
that pushed that move, pulls their newest resolved bets and re-scores them in the local index, so the next move they push is labelled from the newer record. When a wallet has at least 30 bets in that league and its edge has moved, the grader also seals a new version of its record on Walrus. Most takers in a single match are still below that bar, so the grader has re-versioned only a couple of records this way so far; the bar is deliberate, because a record that changes on every bet is noise. The bigger re-versioning came when my own method changed: once already-decided bets were excluded from scoring, every wallet was re-scored, and 117 of the 126 records written from my machine now have a second version that supersedes the first. Nothing was overwritten. The first version is still on Walrus, which is exactly what you want from a record of how a judgement changed.

2. Each move is judged with what was known at the time. The labels on a live move come only from bets that had resolved
before it, so every sealed verdict is a fair test of what CALIBRE knew then, and the graded record shows how that knowledge held up.

3. The judging model changed when the evidence did. The first model (v1) produced forecasts like 65% against a market
price of 32.5%. Its two graded verdicts happened to beat the market, but two is luck, and the wallet edges behind v1 counted in-play bets, which reward reaction speed rather than forecasting, and already-decided bets, which reward nothing. Model v2 excluded those bets, capped a wallet's learned edge at 8 points and applied it at half strength, and limited how far a forecast may move from the price to 10 points. Model v3 added the square-money share after the replay. Every verdict keeps the model it was sealed with, and the record never pools them.

The honest result of that loop: under v2 and v3, 88 graded verdicts and rising, CALIBRE's forecast and the market price score within 0.001 Brier of each other. The market is hard to beat, and a tool that claims otherwise after a week of data is selling something. What CALIBRE adds is not a better price. It is knowing who moved it.

How it uses Tatum

• The move gate. The watcher spots a candidate move on free data, then asks Tatum's price history whether it really happened. A move Tatum's own history does not show is dropped before anything is judged or sealed. That is the part I care about: two independent sources have to agree before a verdict exists at all.
• The timestamp. Every sealed verdict carries a Sui checkpoint read through Tatum's Sui gRPC gateway, over native gRPC with @protobuf-ts/grpc-transport (the Sui JSON-RPC gateway is deprecated and returns 404). The checkpoint is what makes "CALIBRE called this before the result" something you can check rather than something I assert.
• Every X-ray on the site is stamped with the checkpoint it was read at, through the same gateway.
• The paid API confirms the buyer's payment on chain through Tatum before it hands over the X-ray.
• Plus market discovery, the live price shown on a market X-ray, and the resolution check before grading.

Three things I learned the hard way.

Budget by price, not by call. Grading originally made one Tatum call per pending verdict per hour, which grew with every
verdict sealed. Worse, I was counting calls when Tatum charges credits: a price history request costs 200, a market lookup 100, a gRPC query 2. Counting calls told me I had used 554 of 1,500 while the account had actually burned through 100,000 credits. Now every request is counted at its listed price against a daily budget, and Polymarket's free Gamma API answers "which markets resolved?" first so Tatum is only asked about the ones that did.

Read the endpoint's reference page, not the blog post. For three days I believed Tatum's price history was broken: every
request returned HTTP 200 with zero candles, on markets with millions in volume. I had checked that my parameters were valid, that the key worked, that other endpoints answered. I wrote it up as an outage. It was not. The history endpoint takes a source parameter — candlesticks by default, or midpoint — and the default feed is derived from Polymarket's v1 trade data, which Polymarket retired on 2 November. midpoint comes off the orderbook and returns a full series. One query parameter. The reference page documents it plainly; the blog post I had been working from does not mention it. Until I found that, the move gate above could never fire, because it only trusts a move Tatum confirms, and Tatum was confirming nothing. The deep integration was written and inert, which is the worst of both worlds: it would not have survived a judge reading the code and running it.

Label every fallback, and keep the list honest. Some Tatum endpoints really are down, and I checked each against its own
reference page before saying so. Market trades returns 200 with zero rows on every documented parameter shape, including on a market I watched take 34 fills in the same minute. /wallets/{address}/trades, /value, /markets-traded, /positions and /top-traders all return 500, including with the takerOnly and market filters I had not been sending. So the fills behind a verdict — which wallets pushed the move — come from Polymarket's free Data API, and every verdict records which source it used and why. I would rather show you a labelled fallback than a confident number I cannot stand behind.

Agents can pay for it

GET /api/v1/xray/<wallet> answers HTTP 402 with an MPP payment challenge. An agent pays 0.01 USDC on Sui, the server checks the transaction on chain and returns the X-ray with the transaction digest as a receipt. Each digest pays for one call. The first real call settled on mainnet in checkpoint 341,674,249: 0.01 USDC from the agent to the API's wallet, with a gas price of zero, so the agent never needed SUI.

Builder notes

• Recall returns at most 100 memories per query. Rebuilding all verdicts means several recall queries by meaning, merged by blob ID. Fine at this size; at scale I would keep a list of blob IDs in a manifest memory.
• A write can time out and still land. One verdict write timed out, so the watcher queued it for retry, but Walrus already had it: an export at the time found 59 verdicts against 58 in my local ledger. Retries now keep the original checkpoint and are dropped if the market resolves first, so nothing is ever sealed with hindsight.
• Polymarket retired its v1 Data API mid-hackathon. Moving to /v2/trades took an afternoon; tests on the parser made it safe.

What is next

A longer replay to settle the square-money question either way; per-league labels in the extension; and a public feed of loser-driven moves for agents that want to stay out of them.

CALIBRE is open source: https://github.com/timix648/calibre. If you trade on Polymarket, X-ray the next wallet you were about to copy. You might be surprised how often the answer is "mostly sniping".