walletlink.social

Turn wallet addresses into the people behind them, and reach them where they already are

App · Docs · API · @walletlinkETH

How it works

Wallet list in (CSV · contract address · paste)
  ├─ Resolve against a 4.8M-wallet identity index
  ├─ Farcaster: complete protocol coverage, refreshed daily
  ├─ X handles: attested first, labelled always, never inferred
  ├─ Rank by holdings × follower reach
  └─ Export CSV, or an X list ready to import

It also runs backwards: give it an X handle or a Farcaster username and it returns the wallets attached to that person.

Coverage, stated honestly

The number most tools quote is the one that flatters them. Two numbers matter here, and conflating them will make you plan a campaign you cannot run.

The chain decides this more than the collection does: Base sits at the top of that range because Base is where Farcaster lives, Ethereum near the bottom. The measured per-chain table lives in the coverage docs. Use your chain’s figure, not an average.

Having an account and reaching it are different claims. Of 473,215 X handles resolved, 70.1% are live, 20.1% suspended and 9.8% are names nobody holds. Matches carry that answer wherever the handle has been resolved.

Coverage would be higher if we guessed. Contacting the wrong person is worse than contacting fewer people.

Features

Pricing

Credit packs, bought once and metered in matches. A match is a wallet resolved to an X handle or a Farcaster account; a wallet that resolves to nothing costs nothing. Credits last 12 months from purchase. There are no subscriptions.

Every pack includes the same features; packs differ only in how many matches they hold. lib/packs.ts is the source of truth: the pricing modal, the checkout, the comparison pages and the schema.org offers all read from it.

API, MCP and the agent rail

Three doors into the same index, drawing the same match balance. The full reference, including credit costs, rate limits and error codes, is at docs.walletlink.social; the README does not restate it.

REST. Keys are self-serve from the account menu for any account holding credits. A call draws credits only for wallets that resolve.

curl https://walletlink.social/api/v1/wallet/0xd8da...96045 \
  -H "Authorization: Bearer wts_live_YOUR_KEY"

MCP. https://walletlink.social/api/mcp, eight tools over the same endpoints, with a bearer key or an OAuth 2.1 connection. Listed in the official MCP registry as social.walletlink/wallet-identity. The design rationale (why the access token is an api_keys row, why the server bills nothing of its own) lives in the header of app/api/mcp/route.ts.

Onchain rail. POST /api/x402/buy sells a $1 Agent pack for USDC on Base with no account, no card and no email: pay, and the response carries a fresh API key. /api/x402/recover reissues a key to the wallet that paid, on a signed challenge.

Architecture

CSV / contract / paste
        ↓
  lib/csv-parser.ts ──── detects wallet + holdings columns
        ↓
  /api/jobs ──────────── creates a job; lib/job-processor.ts runs it in chunks, the client polls
        ↓
  ┌─ social_graph ─────── fresh rows and persisted negatives short-circuit
  ├─ wallet_cache ─────── 7-day TTL, negatives included
  └─ resolution pipeline  identity sources, then optional ENS text records
        ↓
  social_graph ─────────── positives and negatives persisted
        ↓
  ResultsTable ─────────── virtualized, sortable, exportable

Negatives are persisted deliberately. “Checked, nothing there” is an answer worth keeping, and it is what stops the pipeline paying repeatedly to rediscover the same absence.

Tech stack

Project structure