Cohorts and lists

Two ways to hold a group of wallets. A cohort is system-built and defined by a floor that the query itself enforces. A list is yours: any wallets, any reason, with a name and an owner. This page covers what each one guarantees, and what each one feeds.

Cohorts

A cohort is a rule, not a roster. Every cohort publishes the floor a wallet must clear, and the SQL that builds the member table applies that same floor — the copy on the page is derived from the same object the query reads, so the number you see and the number enforced cannot drift apart.

Membership is recomputed on read from the wallet rollups. A wallet that stops clearing the floor leaves the cohort; a wallet that starts clearing it appears. Cohort pages report data_as_of — the freshest stats timestamp across the rows shown — rather than implying the numbers are live to the second.

The cohorts

They fall into three groups. Standing cohorts have fixed floors and no time window, so membership only changes when a wallet crosses a threshold. Rotating cohorts are bounded by a window — a small member count there is the window, not missing data. Machines is the market-maker board: useful to model or to exclude, and explicitly not a skill ranking, because a rebate-driven operator's entries are not a directional read.

Six per-category cohorts are defined but disabled. They read a category rollup that is stale and whose win and loss counters do not reconcile, so rather than hiding them the registry returns them with a public disabled_reason — a slug that silently vanishes reads like a client bug.

Ranking inside a cohort

Cohorts rank on PnL by default, and a cohort that accepts sort=win_rate ranks on the sample-shrunk win rate rather than the raw ratio. No cohort gates membership on win rate at all. The reason is the same one behind the screener's ranking rules: a raw per-fill win rate is both stale and price-blind. See Screener for the full argument.

GET /api/v1/cohorts

The registry. Minimum tier free, no parameters, disabled cohorts included.

curl "https://crowdintel.xyz/api/v1/cohorts" \
-H "Authorization: Bearer $CROWDINTEL_KEY"

{
"data": [
  {
    "slug": "profit-leaders",
    "title": "Profit Leaders",
    "thesis": "...",
    "group": "standing",
    "order": 1,
    "source": "wallet_stats",
    "order_by": "pnl",
    "sortable": ["pnl", "volume", "resolved_bets", "win_rate"],
    "max_rows": 500,
    "enabled": true,
    "disabled_reason": null,
    "floors": { "min_resolved_bets": 50, "min_pnl": 25000, "exclude_machines": true },
    "floor_lines": ["≥ 50 resolved bets", "≥ $25,000 PnL", "bots and market makers excluded"]
  }
],
"next_cursor": null
}

Read floors if you are re-implementing the rule, and floor_lines if you are displaying it — they are two views of the same definition.

GET /api/v1/cohorts/{slug}

The ranked members. Minimum tier free; a free key sees the top 25 with no paging, and paid tiers page to the cohort's own max_rows cap.

curl -G "https://crowdintel.xyz/api/v1/cohorts/profit-leaders" \
-H "Authorization: Bearer $CROWDINTEL_KEY" \
--data-urlencode "sort=pnl" \
--data-urlencode "min_bets=200" \
--data-urlencode "limit=25"

{
"slug": "profit-leaders",
"title": "Profit Leaders",
"thesis": "...",
"member_count": 4821,
"data_as_of": "2026-08-15T22:40:11.000Z",
"floor_lines": ["≥ 50 resolved bets", "≥ $25,000 PnL", "bots and market makers excluded"],
"sort": "pnl",
"sort_dir": "desc",
"min_bets": 200,
"data": [
  {
    "address": "0x...",
    "polymarket_name": null,
    "polymarket_avatar": null,
    "resolved_bets": 812,
    "win_rate": 0.61,
    "bayesian_win_rate": 0.58,
    "confidence": 0.94,
    "total_volume": 1234567.0,
    "pnl": 345678.0,
    "polymarket_pnl": 340000.0,
    "ledger_pnl": 345678.0,
    "markets_traded": 402,
    "last_updated": "2026-08-15T22:40:11.000Z"
  }
],
"next_cursor": "eyJvZmZzZXQiOjI1fQ"
}

Two behaviours worth knowing: member_count is the count clearing the cohort's own floor and does not move when you raise min_bets, and an unknown or disabled slug returns 400 with the reason and the list of valid slugs — never an empty page that looks like a cohort with no members.

Lists

A list is a user-created collection of wallets with a name, a colour, an icon and an owner. There is no floor and no rule; membership is whatever you put in it, which is exactly the point — a cohort answers "who clears this bar", a list answers "who am I watching, and why did I group them".

Lists can be public, and a public list can be followed by other accounts. Manage them at /lists; add a wallet from any dossier.

Use a list when the grouping is a thesis you are testing ("wallets that were early on the same three markets"), and a cohort when you want a bar enforced for you.

How each one feeds the rest of the product

The distinction that trips people up: per-wallet alert settings apply to wallets you follow directly. Following a list adds its members to your feed and to Discord and webhook delivery, but the per-wallet rules and presets described in Alerts are attached to direct follows. If you want a preset applied to a wallet, follow that wallet.

Next

• Alerts — turn a wallet you are watching into a delivery you actually want.
• Copy trade safely — the verification step between a cohort row and a position.