Deleted Tweets and the Real Posting Pace

How Polymarket counts: XTracker on a ~5-minute cycle

XTracker is Polymarket's settlement oracle — the number that determines who wins and loses. It scrapes the timeline on a roughly 5-minute cycle and counts the qualifying posts present at each scrape. Sampling every ~5 minutes rather than watching continuously has a natural consequence: if a post goes up and comes down entirely inside the gap between two scrapes, that is the kind of short-lived post a ~5-minute sampler can miss. XTracker also doesn't publicly expose per-tweet classification. None of this is a knock on XTracker — it's simply how a periodic sampler behaves, and it's why an independent, higher-frequency counter is useful for reading pace.

How Polystrike counts: a ~60-second poll that keeps short-lived deleted posts that can still count

Polystrike maintains its own real counter, polling X about every ~60 seconds and classifying each new post against the exact public settlement rules. Because we poll roughly 5× more often, we tend to see new posts almost as soon as they appear — across the 47 deletions we caught, a median of 13.5 seconds after posting (range 10.4–21.1s). When a post we've recorded is later deleted, we flag it and keep it: under the settlement rules, a post that existed on the timeline during the event window is the kind of post that can still count. Retaining deleted posts is what keeps our real posting-pace count honest — not an attempt to predict any specific settlement outcome.

Main-feed posts, quote posts, reposts, and main-feed replies count; regular replies and community reposts do not. We expose this via the is_counted field on the Pro tier (free tier sees null). XTracker does not expose this classification at all.

Why catching deletions matters: the real posting pace

Knowing how much Elon or Cruz is really posting means counting every qualifying post they actually made — including the ones they deleted. If you only look at the timeline as it stands now, or rely on a sampler that can skip short-lived posts, you undercount their output and misjudge their velocity. Deletions that still count are precisely the posts a naive after-the-fact look would drop, so catching them is what makes a pace measurement honest.

Pace is also the foundation for projecting where an event is heading: the sleep-aware model forecasts the final count from velocity, so an accurate real-time count of qualifying posts — deletions included — is what everything downstream rests on. To be precise about what our data shows: it proves we captured 47 deleted posts (40 of a counted type) that were short-lived enough that a ~5-minute scraper can miss them. It does not prove XTracker missed any specific one. The right framing is capability and risk — the kind of tweet a ~5-minute scrape can miss — not a claim of any proven miss.

FAQ