> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xinsider.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Wallet trading styles

> Read observable trading patterns, check their limits, and filter wallets by style.

`strategy_type` describes activity recorded for a Polymarket wallet. Use it to compare wallets by two-sided positions, category focus, trade density, or activity spread across categories.

The label summarizes stored history. Profit, win rate, and grade do not choose it, and a losing wallet keeps the same style as a profitable wallet with the same activity.

<span id="request-it-on-one-wallet" />

## Request a wallet's style

Pass `expand=strategy` to [Trader](/api-reference/endpoint/get-trader) or [Batch traders](/api-reference/endpoint/batch-get-traders).

```bash theme={null}
curl -H "Authorization: Bearer $OXINSIDER_API_KEY" \
  "https://api.0xinsider.com/api/v1/trader/swisstony?expand=strategy"
```

The added section can look like this:

```json theme={null}
{
  "strategy": {
    "strategy_type": "high_activity"
  }
}
```

| Field | Availability |
| - | - |
| `strategy_type` | A current style below, or a historical label awaiting reclassification. |
| `description` | A short stored note, omitted when unavailable. |
| `confidence` | Not returned by the API. Internal rule scores are not probabilities. |

The entire `strategy` section is absent if you omit the expansion or the wallet has no stored classification. An explicit `unclassified` value means the classifier ran but could not establish a style from the available history.

## Current styles

The classifier uses the lifetime market records 0xinsider has stored, rather than a recent trading window. That history can cover fewer markets or fills than the wallet's complete Polymarket history.

| `strategy_type` | Display label | Evidence used | Rule score |
| - | - | - | - |
| `two_sided` | Two-sided positions | Both sides appear in at least 60% of stored markets. | The share of stored markets with both sides. |
| `category_focused` | Category focused | One known category accounts for at least 70% of stored cost basis, and known categories cover at least 80%. | The largest known category's share of stored cost basis. |
| `high_activity` | High trade density | Recorded fills average at least 8 per stored market. | Average fills divided by average fills plus 8. |
| `diversified` | Diversified activity | At least 3 known categories have positive cost basis, no category exceeds 50% of stored cost basis, and known categories cover at least 80%. | 1 minus the largest known category's share of stored cost basis. |
| `mixed` | Mixed activity | History is usable, but no pattern has a clear lead. | No dominant pattern. |
| `unclassified` | Limited history | Fewer than 20 stored markets or insufficient usable evidence prevents a label. | Insufficient evidence. |

Category shares use stored cost basis in USD, including uncategorized cost in the denominator. This is not the wallet's lifetime trading volume.

A missing category is unknown; it does not become another category or evidence of diversification. Both category patterns require at least 80% of stored cost basis to have a known category.

<span id="how-a-label-is-chosen" />

## How labels are assigned

A wallet needs at least 20 stored markets before the classifier compares patterns. Each qualifying pattern receives the rule score shown above, so a wallet can match more than one pattern.

The strongest pattern needs a score of at least `0.5` and a lead of at least `0.15` over the next pattern. Without that separation, or when no pattern qualifies, usable history receives `mixed` rather than whichever rule appears first.

The API reads the latest stored classification. Your request does not run the classifier, and older labels remain visible until the wallet is reclassified through the normal update process.

## Filter the leaderboard

Pass one of the 6 current IDs to [Leaderboard](/api-reference/endpoint/get-leaderboard):

```bash theme={null}
curl -H "Authorization: Bearer $OXINSIDER_API_KEY" \
  "https://api.0xinsider.com/api/v1/leaderboard?strategy=high_activity&limit=20"
```

Leaderboard entries include `strategy_type` without an expansion when a classification exists. An unrecognized `strategy` filter returns `400` with `error.param` set to `strategy`.

## Historical labels and client compatibility

The following 10 IDs remain valid filters and can still appear in stored responses: `accumulator`, `algo_trader`, `arbitrageur`, `directional`, `event_driven`, `market_maker`, `momentum`, `scalper`, `speculator`, and `swing_trader`.

They select rows that still carry that exact historical value. They are not aliases for the new styles, and a historical cohort can shrink as wallets are reclassified.

The 6 new IDs are additive API values. If your client validates a fixed enum or uses an exhaustive switch, regenerate its types from the [OpenAPI document](https://0xinsider.com/api/v1/openapi.json), accept the new values, and retain handling for historical values.

<span id="what-this-does-not-tell-you" />

## Limits

* Two-sided positions do not establish arbitrage or market making. They do not prove that both sides were held at the same time or that the combined cost guaranteed a profit.
* High trade density does not establish scalping, holding duration, or automation. It counts recorded fills per stored market.
* Category focus does not establish reactions to news, and diversified activity does not establish lower risk.
* The label does not identify intent, maker or taker order role, or future trades.
* The API does not publish a confidence probability. The internal rule score measures support for a pattern, not the chance that a trading strategy is correct.

Use [Grades](/concepts/grades) and [Quantitative metrics](/concepts/quant-metrics) to assess performance separately.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.