A Polymarket signal is the on-chain event that precedes a price move, not the alert someone posts about it afterwards. Across 30 days of on-chain data we tagged every signal-event pattern that produced a measurable price impact within 90 seconds of detection, and five patterns accounted for 84% of them. Each one has a different latency budget — the time you have between detection and the moment the edge has fully bled out of the book. This guide is the practical taxonomy: what each pattern looks like in raw blockchain data, what it usually means about the underlying market, how long you have to act, and the tools that close the gap between detection and execution. Telegram channels post about these patterns. The patterns themselves live on Polygon.
Why “signal” is not the same as “alert”
Most retail traders use the word signal to mean “a message somebody sent me saying buy this.” That is an alert. The thing that produced the alert — the on-chain transaction, the order-book change, the wallet movement — is the signal. By the time the alert reaches your phone, the signal has been live for tens of seconds to several minutes, and a meaningful fraction of the edge has already closed.
The distinction matters because signal-quality is independent of alert-latency, and good signal mixed with slow alert is mathematically equivalent to no signal at all. The five patterns below are the on-chain events themselves. The latency budget against each one defines whether any given delivery mechanism — Telegram, email, dashboard ping, or direct automation — can actually convert the signal into a fill before the edge bleeds out.
Pattern 1 — large-wallet entry on a fresh market
The cleanest signal type. A wallet on your tracked list places a buy order on a market it has not previously traded, with size at or above the 90th percentile of its historical fill distribution. This pattern correlates strongly with conviction-grade entries: the wallet has decided something, sized it accordingly, and is willing to take meaningful liquidity off the book to enter.
What the on-chain trace looks like: a single OrderPlaced event on the Polymarket CTF contract from a known address, where the order amount divided by recent top-of-book depth is ≥0.6. Detection is straightforward if you are subscribed to the Polymarket WebSocket; the hard part is filtering false positives from market-maker rebalancing orders, which often look superficially similar.
Latency budget: roughly 45–90 seconds before competing flow has moved the price 1–2 cents in the same direction. Telegram is usually too slow; dashboard ping is borderline; direct automation captures the full window.
Pattern 2 — cluster entry from correlated wallets
Three or more tracked wallets, with low historical correlation, enter the same market within a short window. This is the strongest of the five patterns because the joint probability of independent, uncorrelated wallets converging on the same thesis by chance is very low — the cluster itself is informative beyond what any single entry would tell you.
What you measure: a sliding 5-minute window over which you count distinct tracked addresses placing same-side orders on the same market identifier. Three or more triggers a cluster-detected event. The catch: false positives spike around news events (a single piece of public information moves multiple wallets in parallel, and the cluster is not informative), so you usually want to compare cluster timing against a public news feed and discount clusters that coincide with major announcements.
Latency budget: 2–6 minutes. Clusters take time to form, but they also propagate quickly once visible — market makers see the same pattern and pull liquidity, which closes the spread. Slower than pattern 1, but still tight enough that manual execution rarely works.
Pattern 3 — book-side imbalance build-up
Not a wallet event but an order-book event. Top-of-book depth on one side grows materially faster than the other for 10–30 minutes, without a corresponding price move. This is the signature of an informed market participant accumulating size without revealing direction through price action — they layer in passive bids, waiting for the natural fill rather than crossing the spread.
Detection requires a depth time-series, not just snapshot data. You measure the ratio of one-side depth to the other side, smoothed over a rolling window, and flag when the ratio moves more than 1.5 standard deviations from its 24-hour baseline. The signal is much weaker on highly liquid markets (top-of-book depth is too noisy) and strongest on mid-depth markets ($5,000–$50,000 of two-sided book).
Latency budget: 10–25 minutes. The imbalance is informative for as long as the layered orders sit unconsumed; once they fill or get pulled, the signal is gone. This is the slowest of the actionable signals, which makes it the most retail-friendly — even a Telegram-to-manual workflow can capture meaningful edge here.
Pattern 4 — resolution-window decay accelerator
Inside the final hour before a market resolves, edge decays roughly 2x faster than the rest of the trading day. A signal-grade event in this window is a tracked wallet adjusting position aggressively, either adding (high conviction the outcome holds) or unwinding (acknowledging the outcome has shifted). The wallet’s last-minute action is highly informative because they are closer to the resolution information than the general market is.
What to detect: any large-wallet order on a market within 60 minutes of its resolution_timestamp. The order direction and size relative to the wallet’s existing position is the signal. A wallet adding to YES inside T-30 minutes when the price has drifted toward NO is a different signal from a wallet unwinding a long-held YES position.
Latency budget: 3–8 minutes. Pre-resolution liquidity is thin, so price moves quickly when informed flow enters. This pattern overlaps with the resolution-window arbitrage discussed in our arbitrage study — capturing it requires premium-RPC execution latency.
Pattern 5 — cross-market migration
A wallet exits one market and enters a related market (same underlying event, different question framing) in rapid succession. This is the rarest of the five patterns but also the most counter-consensus — the wallet is signalling not just direction but a change in their model of how the event will resolve. The exit-then-enter pattern is rare enough that when it appears, it is usually genuinely informative.
Detection requires a market-relationship graph (which markets are linked to which underlying events). Polymarket exposes some of this metadata; the rest has to be inferred from market wording. The signal triggers when a tracked wallet’s net exposure to an underlying event changes by 50% or more within a 15-minute window through paired exits and entries on linked markets.
Latency budget: 5–15 minutes. The migrating wallet is usually one step ahead of the broader book; the secondary market takes a few minutes to reprice in response. This is one of the more capturable patterns at retail latency.
The signal-to-action latency budget
Putting the five patterns alongside the realistic delivery mechanisms:
| Pattern | Latency budget | Telegram alert | Dashboard ping | Direct automation |
|---|---|---|---|---|
| 1. Large-wallet entry | 45–90s | too slow | borderline | full window |
| 2. Cluster entry | 2–6 min | partial | most of window | full window |
| 3. Book-side imbalance | 10–25 min | most of window | full window | full window |
| 4. Resolution-window | 3–8 min | partial | most of window | full window |
| 5. Cross-market migration | 5–15 min | most of window | full window | full window |
Two takeaways. First, pattern 1 is essentially un-capturable through any human-in-the-loop workflow — the time between detection and execution must be under a minute, which is automation-only. Second, patterns 3 and 5 are the realistic windows for manual or semi-automated workflows. If you are running a Telegram-to-manual stack, your real signal universe is patterns 3, 4, and 5; patterns 1 and 2 you are watching go past on someone else’s book.
How to detect these on-chain yourself
If you want to build pattern detection without a managed service, the minimum stack is a Polymarket WebSocket subscription, a Polygon-archive RPC for historical context, and a small time-series database. The work is meaningful but tractable for an experienced developer:
- Pattern 1 (large-wallet entry): subscribe to WebSocket order events, filter by tracked-wallet allow-list, compare each order to the wallet’s rolling fill-size distribution. ~200 lines of Python.
- Pattern 2 (cluster entry): add a 5-minute sliding-window aggregator on top of pattern 1. ~50 additional lines.
- Pattern 3 (book-side imbalance): requires depth snapshots, which means polling the order book API at 5s intervals and storing the time series. ~300 lines plus a database.
- Pattern 4 (resolution-window): needs the market resolution_timestamp metadata. Easy if you index it once at market creation. ~100 lines.
- Pattern 5 (cross-market migration): the hardest. Requires a market-relationship graph that you build by parsing market titles for shared event identifiers. ~500 lines if you do it cleanly.
Total: about a week of build time for a competent engineer, ongoing maintenance of 4–10 hours per month. Patterns 1, 2, and 4 are accessible to a hobbyist; patterns 3 and 5 are where managed services start to earn their keep.
The managed-service version
Poly Syncer runs all five detection pipelines continuously and routes the resulting signals into the executor with latency under 200ms from on-chain detection to mirror order submission. The dashboard exposes the signal type, the source wallet, and the action taken for every mirrored trade, which is useful for understanding which patterns are paying off in your basket. The free view-only tier shows the signal stream without execution; the paid tiers add the executor.
I am writing this from inside that product, so the framing is biased. The honest version: pattern detection is not the hard part — the hard part is detection plus filtering plus routing plus execution in under the latency budget that decides whether the trade fills at the screen price or 0.8 cents higher. The math is simple; the engineering is the value.
Frequently asked questions
What are Polymarket signals?
Polymarket signals are on-chain events that precede price moves in prediction markets. The five most actionable patterns are large-wallet entries on fresh markets, cluster entries from multiple correlated wallets, book-side depth imbalances, resolution-window adjustments, and cross-market migrations. Each pattern has a different latency budget between detection and the moment the edge fully closes.
How do I get Polymarket signals?
Three options. Subscribe to a Telegram channel that posts alerts (latency 30 to 180 seconds, captures only the slower-decay patterns). Build your own detection stack against the Polymarket WebSocket and Polygon RPC (one week of engineering, captures all five patterns). Use a managed service that runs all five detection pipelines and routes results to execution (under 200ms detection-to-fill latency).
Are Polymarket signals reliable?
Reliability is a function of which pattern you act on and how fast. Pattern 2 (cluster entries) and Pattern 3 (book imbalance) have the highest signal-to-noise ratios because they require independent confirmation across multiple wallets or sustained book behaviour. Pattern 1 (single-wallet entries) is fast but noisier because individual wallets occasionally trade non-conviction orders.
What is the difference between a Polymarket signal and a Polymarket alert?
A signal is the on-chain event itself. An alert is the message sent to you about the signal after detection. Signals are universal and platform-independent; alerts are delivery-mechanism-specific and carry latency overhead. The same signal can produce a fast alert (under 1 second via direct dashboard ping) or a slow one (60+ seconds via Telegram queue) depending on how the alert is routed.