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

# Index stats

> GET /v1/stats

Totals for the whole index, refreshed daily. Costs no credits and needs a valid key, **not** a balance: this endpoint answers even when your credits are at zero, so an exhausted key can still plan its next purchase. Only the metered endpoints return `402 NO_CREDITS`.

The counts are materialized once a day rather than counted live, and `meta.as_of` says when they were taken. Poll it as often as you like; two calls inside a day return the same numbers.

Use it to check coverage claims for yourself rather than trusting a number on a marketing page, and to monitor whether the index is growing in the dimension you care about.

## Request

```bash theme={null}
curl https://walletlink.social/api/v1/stats \
  -H "Authorization: Bearer wts_live_YOUR_KEY"
```

## Response

<ResponseField name="data" type="object">
  <Expandable title="properties">
    <ResponseField name="total_wallets" type="number">
      Wallets with at least one identity attached. This is the coverage number.
    </ResponseField>

    <ResponseField name="wallets_checked" type="number">
      Every wallet we have examined, including those we found nothing for.
    </ResponseField>

    <ResponseField name="coverage" type="object">
      Counts per network: `twitter`, `farcaster`, `ens`, `lens`, `github`. These
      overlap, since one wallet can carry several.
    </ResponseField>

    <ResponseField name="farcaster_stats" type="object">
      `avg_followers` and `max_followers` across indexed Farcaster accounts.
    </ResponseField>

    <ResponseField name="match_rates" type="object">
      The measured per-chain match rates: `measured_on`, `basis`,
      `overall_either_pct`, and `by_chain` rows each carrying `collections`,
      `holders`, `farcaster_pct`, `x_pct` and `either_pct`. Constants from a
      dated measurement, not live counts; see below.
    </ResponseField>
  </Expandable>
</ResponseField>

```json theme={null}
{
  "data": {
    "total_wallets": 4700000,
    "wallets_checked": 9200000,
    "coverage": {
      "twitter": 1070000,
      "farcaster": 4690000,
      "ens": 890000,
      "lens": 42000,
      "github": 31000
    },
    "farcaster_stats": { "avg_followers": 210, "max_followers": 1200000 },
    "match_rates": {
      "measured_on": "2026-08-17",
      "basis": "Measured across 26 real collections and 72,318 holders, against the index alone. The chain decides this more than anything else about a collection; use the row for your chain, not the overall figure.",
      "overall_either_pct": 30.8,
      "by_chain": {
        "base": {
          "collections": 8,
          "holders": 35294,
          "farcaster_pct": 44.4,
          "x_pct": 32.1,
          "either_pct": 46.2
        },
        "ethereum": {
          "collections": 9,
          "holders": 17462,
          "farcaster_pct": 12.2,
          "x_pct": 12.6,
          "either_pct": 16.6
        },
        "robinhood": {
          "collections": 9,
          "holders": 19562,
          "farcaster_pct": 11.5,
          "x_pct": 12.2,
          "either_pct": 15.6
        }
      }
    }
  },
  "meta": {
    "generated_at": "2026-08-14T12:00:00.000Z",
    "as_of": "2026-08-14T04:30:00.000Z"
  }
}
```

`meta.as_of` is when the counts were computed; `meta.generated_at` is when this
response was built. Read `as_of` when you quote a number.

<Warning>
  The counts above are illustrative; call the endpoint for real ones. The
  `match_rates` block is the real measured table.
</Warning>

## The match-rate table

`match_rates` is different in kind from the counts around it: a dated
measurement of 26 real collections against the index, served as constants so
an agent can plan a spend at decision time instead of reading
[coverage](/concepts/coverage). The chain decides a list’s match rate more
than anything else about it, several-fold between Ethereum and Base, so use
`by_chain` and the row for your chain; `overall_either_pct` describes no
collection in particular. `either_pct` is the planning number: the share of
holders with an X or Farcaster account, which is exactly what
[bills](/api-reference/introduction#credits). Pair it with
[`POST /v1/estimate`](/api-reference/estimate), which reports what your
specific list would bill.

## Reading the two totals

`total_wallets` and `wallets_checked` are different questions and the gap between them is the point.

`wallets_checked` includes wallets we examined and found nothing for. Those are deliberately excluded from `total_wallets`, so that dividing one by the other gives a real hit rate rather than one inflated by counting empty records as coverage.

Do not compute a match rate for *your* list from these numbers. The index skews toward wallets somebody has already looked up, which is not a random sample of the chain. For your own list, sample it through [batch](/api-reference/batch) and measure directly. See [coverage](/concepts/coverage).

## Errors

The [standard errors](/api-reference/errors) only.