Wallet Clustering 101: When 50 Wallets Are One Trader

If you track “top wallets” long enough, you’ll notice a pattern:

Some of the most consistent “wallets” aren’t wallets at all.

They’re operators.

One trader can distribute activity across dozens of addresses to:

• reduce attention
• split limits or operational risk
• segment strategies (one wallet for hedges, one for event-driven)
• manipulate dashboards that rank by wallet

If you don’t account for this, you will:

• overcount independent signals (50 “whales” that are really one)
• inflate or deflate win rates (wins and losses get smeared across addresses)
• miscalibrate alerts (you’ll think a market has “broad smart money consensus” when it’s just a cluster)

Internal links:

• Smart money overview: /smart-money
• Smart collections: /smart-collections

1) What “Clustering” Means (and What It Doesn’t)

Clustering is a hypothesis: these addresses are controlled by the same entity.

In Bitcoin research, clustering heuristics often rely on transaction graph structure (e.g., multi-input heuristics). A classic early paper uses heuristics to group addresses under shared authority, then uses re-identification to label clusters.
Source: Meiklejohn et al., “A Fistful of Bitcoins” (IMC 2013). https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf

But heuristics can be wrong. Later work focuses on error rates and false clustering when assumptions break (change address detection, address reuse patterns, etc.).
Source: “Analyzing the Error Rates of Bitcoin Clustering Heuristics”. https://inria.hal.science/hal-05315736v1/document

Polymarket clustering is different because:

• you care about behavior on a trading venue (CLOB + positions), not just L1 UTXO structure
• an operator can behave consistently across addresses without obvious on-chain “multi-input” linkages

So we use behavioral clustering first, and only treat on-chain flows as corroboration.

2) A Practical Feature Set (That Works on Polymarket)

You can think of clustering as a scoring problem: each feature adds evidence.

Feature A — Timing Synchronization (the “metronome”)

If two wallets repeatedly:

• enter within minutes of each other
• trade the same outcome
• do so across many markets

they’re not independent.

Metric:

sync_score = fraction of trades where |t_i - t_j| < Δt and same side and same market

Set Δt based on market tempo:

• crypto: 1–3 minutes
• politics/news: 5–15 minutes

Feature B — Market Overlap (the “portfolio fingerprint”)

Compute the Jaccard similarity of markets traded:

jaccard = |M_i ∩ M_j| / |M_i ∪ M_j|

High overlap alone is not enough (many people trade top markets), but overlap + timing is powerful.

Feature C — Side Consistency (the “thesis signature”)

For each wallet, build a vector of signed exposures:

• +1 for YES net accumulation
• -1 for NO net accumulation
• weight by notional or by persistence (holding time)

Then compute cosine similarity between wallets.

This captures “always contrarian” vs “always momentum” styles.

Feature D — Execution Style (maker vs taker bias)

Two wallets that both:

• use similar order sizes
• show similar aggressiveness patterns
• execute at similar distances from midpoint

often share an execution engine or operator.

You can quantify this using CLOB order book snapshots (spread/impact proxies) and comparing realized trade prices to midpoint at the time.
Source: Polymarket APIs (CLOB/Gamma/Data) endpoints overview. https://docs.polymarket.com/quickstart/reference/endpoints

Feature E — Funding Flows (corroboration, not primary)

If multiple addresses are funded from:

• the same source address
• the same exchange deposit pattern
• a common “treasury” wallet

that’s strong evidence.

But it’s not required; sophisticated operators deliberately avoid linkable funding patterns.

3) How Clustering Improves Alerts (and Reduces Noise)

Most alert systems treat each wallet as an independent vote.

That fails when one operator splits into many wallets, because you get:

• false “consensus” alerts
• repeated notifications for essentially the same actor
• distorted confidence scoring

Clustering fixes this by changing the unit of analysis from:

wallet

to:

operator cluster

Practical improvements:

• dedupe alerts: one cluster → one alert
• better sizing signals: cluster notional is the sum across addresses
• phase detection: you can detect entry/defense/unwind across a cluster rather than per wallet

If you want the outcome (cleaner signals) rather than building the pipeline yourself:

• /smart-money

4) How Clustering Affects Win Rate Statistics

Win rate is a seductive metric and an easy one to corrupt unintentionally.

Without clustering, you can see two opposite pathologies:

Pathology A — Inflated win rates (selection by wallet)

An operator can keep “clean” wallets that only take high-confidence entries, and route messy hedges into other wallets. Your leaderboard will overrate the clean wallets.

Pathology B — Deflated win rates (pnl smeared across wallets)

If entries are in one wallet and exits in another, you can create the illusion of a perpetual loser:

• Wallet A: buys
• Wallet B: sells into profit
• Neither wallet shows full lifecycle PnL

Clustering restores lifecycle accounting.

5) A Minimal, Auditable Clustering Score

Here’s an operator-oriented scoring approach you can implement quickly:

Assign points:

• +30 if timing sync score > 0.35
• +25 if market overlap (Jaccard) > 0.50
• +20 if side similarity (cosine) > 0.80
• +15 if execution similarity (median distance-to-midpoint) within band
• +10 if funding link exists

Threshold:

• ≥60: “likely same operator”
• 40–60: “watchlist”
• <40: “treat as independent”

This is not perfect, and it doesn’t need to be. It needs to be:

• transparent
• debuggable
• stable across backtests

6) Failure Modes (How You Get False Positives)

Clustering heuristics fail in predictable ways:

1. Crowded trades: many wallets pile into the same market after breaking news
2. Shared alpha sources: multiple traders follow the same paid channel and act at the same time
3. Market makers: quoting bots can look similar across accounts
4. Copy trading cascades: one whale triggers many followers, creating artificial synchrony

The fix is simple:

• require multiple independent features (timing + overlap + side), not just one
• validate clusters over longer windows
• treat funding flows as supporting evidence, not the core proof

7) Where This Matters Most

Clustering gives the biggest edge in:

• thin markets where a single operator can move price
• high-tempo markets where timing sync is very diagnostic (crypto)
• strategy collections where you’re trying to follow a “style” rather than a single wallet

If you want to track strategy-level behavior, not just individual addresses:

• /smart-collections

Sources (External)

• Meiklejohn et al., “A Fistful of Bitcoins” (address clustering heuristics; entity clustering): https://cseweb.ucsd.edu/~smeiklejohn/files/imc13.pdf
• “Analyzing the Error Rates of Bitcoin Clustering Heuristics” (heuristic limitations; false positives): https://inria.hal.science/hal-05315736v1/document
• Polymarket API endpoints overview (Gamma / CLOB / Data API): https://docs.polymarket.com/quickstart/reference/endpoints