> ## 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. # Coverage > What fraction of a wallet list resolves, and what the number actually means. The single most common question is “what percentage of my list will match”. The honest answer needs two numbers, not one, and mixing them up will make you plan a campaign you cannot run. ## Two different numbers The chain decides this, more than anything else about your collection. See the measurements below. Having an account and reaching it are different claims. We check every handle and report both: see [reachability](/concepts/data-quality#we-check-and-we-tell-you). ## What a real collection resolves to There is no single match rate, and quoting one would hide the thing that matters most. We measured 26 collections across three chains on 2026-08-17, against our own index only, with no external API calls at measurement time. | Chain | Collections | Holders | On Farcaster | With an X handle | Either | | --------------- | ----------- | ---------- | ------------ | ---------------- | --------- | | Base | 8 | 35,294 | 44.4% | 32.1% | **46.2%** | | Ethereum | 9 | 17,462 | 12.2% | 12.6% | **16.6%** | | Robinhood Chain | 9 | 19,562 | 11.5% | 12.2% | **15.6%** | | **All three** | **26** | **72,318** | | | **30.8%** | **Base is roughly three times Ethereum**, and that is not a quirk of the collections we picked. Base is where Farcaster lives, so a Base collection’s holders are disproportionately people who have already linked a social account to a wallet. If you are planning a campaign, the chain your holders are on will move your reachable audience more than the size of your collection does. Use the row for your chain rather than the average. The average is the honest summary of these 26 collections and it describes no collection in particular. The same table is machine-readable as `match_rates` on [`GET /v1/stats`](/api-reference/stats), so an agent can plan a spend from it at decision time; pair it with the free [`POST /v1/estimate`](/api-reference/estimate), which reports what a specific list would bill. For context, tools that match wallets to social accounts typically publish rates in the low single digits. Even the lowest chain here clears that by a wide margin. These are counts of accounts that exist. Roughly a third of attested X handles no longer reach anybody, which we check per record rather than folding into the figures above. See [reachability](/concepts/data-quality#we-check-and-we-tell-you). These figures come from measured samples across real collections, not from a marketing estimate. They still vary a lot by collection. A 2021 PFP project and a fresh airdrop farm will not behave the same way, and neither will match the average. ## Coverage is not uniform across networks The two networks behave so differently that it is worth treating them as separate products. ### Farcaster coverage is complete Every Farcaster account is in [the walletlink index](/#the-index), along with the addresses attached to it, and it is refreshed daily. This makes Farcaster matching **deterministic rather than probabilistic**. If a wallet belongs to a Farcaster user, we return it. There is no confidence threshold to tune and no long tail we have not reached yet. A miss means the wallet genuinely is not attached to a Farcaster account. That property is worth more than it first sounds. It means a Farcaster negative is real information, not an absence of information. ### X coverage is attested first, and labeled always X handles are a different shape of problem. There is no protocol-level registry linking an X account to a wallet, so there is nothing to read the way Farcaster can be read. Our resolution layer works around that by drawing on several independent routes to the same fact, and telling you which one produced each match. **Four routes are owner-attested, and they carry almost all of the coverage.** * The owner verified their X account on Farcaster. Arrives as `farcaster`. * The owner set the handle in a text record on a name they own, on Ethereum or on a Layer 2 name registry. Arrives as `onchain`. * The owner established both halves themselves: proving the wallet with a signature and the account with a sign-in on an identity platform, an onchain attestation issued after that same proof, or a token deploy the account itself requested. All arrive as `attested-social`. * We reviewed the record directly. Arrives as `manual`, and it is a handful of records rather than a route at scale. All four are attested rather than inferred, and together they account for **over 99.9% of the 1.20 million wallets with a linked X handle**. The third route is the newest and it is worth saying what it adds beyond reach. The first two record a handle as a string, captured once. This one records the account’s permanent numeric id alongside it, so when a handle is a name its owner later changed, that is something we can detect rather than something that silently rots. See [when a handle stops being true](/concepts/data-quality#when-a-handle-stops-being-true). **Beyond those, we resolve against identity indexes.** These correlate a handle with an address rather than carrying the owner’s own signature, so the evidence is real but weaker, and it is never dressed up as attestation. It arrives in the `sources` array as `aggregated`, and a record backed by nothing else is the weakest position a record can be in. Today that is a few hundred wallets out of the million. **The routes grow. The labeling does not change.** We add sources as they become worth adding, and each one is classified into the same fixed evidence vocabulary before it can appear in a response. That vocabulary is the contract, not the list of suppliers behind it: a match tells you *how it was established*, so the meaning of a row you built a threshold around three months ago is the meaning it still has today. That guarantee is enforced rather than promised. Source classification is an allowlist, so a route nobody has classified yet returns no evidence class at all rather than defaulting into an existing one. A new pipeline cannot quietly widen what `onchain` or `farcaster` means. See [evidence classes](/concepts/data-quality#evidence-classes) for the full vocabulary. The tradeoff behind all of this is deliberate. Coverage would be considerably higher if we guessed, matching on display names or bios or timing correlations. We do not, at any evidence level, because a marketing campaign that contacts the wrong person is worse than one that contacts fewer people. ### Attested is not the same as reachable, and we report both Someone can verify a handle and later rename or lose that account. Nothing in any attestation notices, because an attestation records a name at a moment. So we resolve the X handles in the index against X itself, on a daily schedule. The job has resolved 473,215 handles so far, and today 99.9% of the distinct handles we hold carry a state; the daily job works through new arrivals and transport retries oldest-first. Of the handles that returned a state, **70.1% are live, 20.1% suspended and 9.8% no longer in use**. The resolved count runs slightly ahead of the 472,319 distinct handles we hold, because the checker keeps a state for every handle it has ever seen, replaced ones included. A handle we have not reached yet is reported as unchecked, never assumed live. The daily job is bounded, so catching up after a large batch of new wallets takes several days rather than happening at once. Roughly a third of attested X handles reach nobody, and that is true of the underlying data rather than of us: it is what any product built on Farcaster verifications is carrying, whether or not it says so. Every X match therefore arrives with a `reachable` flag and a `reachability` value, and the handle export leaves out the ones we have checked and found dead. You can check a single handle against this without an account or a key, at [walletlink.social/check](https://walletlink.social/check). It reports the same state the API returns, plus how many wallets in the index carry that handle. It does not report which wallets: going from a handle to its addresses is the [reverse lookup](/api-reference/reverse-twitter), which needs a key. See [data quality](/concepts/data-quality#we-check-and-we-tell-you). ## Checking coverage yourself Do not take these numbers on faith. [`GET /api/v1/stats`](/api-reference/stats) returns totals for the whole index, refreshed daily and stamped with `meta.as_of`, and costs no credits. It needs a valid key but no balance, so it answers even when your free allowance is spent. The public reachability check at [walletlink.social/check](https://walletlink.social/check) needs no key at all. For a specific list, run a sample through [`POST /api/v1/batch`](/api-reference/batch) and measure directly. You pay only for the addresses that match, so a sample costs what it finds. A few hundred addresses is enough to get a usable estimate for your own collection, which is more useful than any average we can publish.