How to Use Crypto Exchange Lookup for Bulk List Checks
On a crypto exchange, an identifier is never just contact information. The phone number carries the 2FA codes and sits under the KYC record; the email receives the withdrawal confirmations. Checking a list against exchanges like Binance, KuCoin, HTX, and CoinW therefore tells you something about accounts, not about inboxes — and the workflow should be run with that in mind. This walkthrough covers the bulk path end to end. The tool lives here: Crypto Exchange Lookup.
Quick answer
Decide which identifier answers your question (email or phone), prepare a file with one identifier per row plus your own record ID, run the bulk check, and read the export as three queues: matched, multi-exchange, and unmatched. The third queue is a coverage statement, not a clean bill. Then export and let each consumer (sybil review, reward eligibility, list cleaning) take its slice.
Step 1: Choose the identifier before the file
Emails and phones behave differently against exchange signals. Email matches tend to be broader (nearly every exchange account has one), while phone matches run cleaner but thinner, because not every account binds a number. Pick by question:
- Will these accounts receive our notices? Check emails.
- Are these signups plausibly distinct humans with funded accounts? Check phones, where the duplicate signal is sharpest.
- Airdrop sybil screening? Both, if the budget allows — the shared-identifier pattern shows up in either column.
Do not upload both columns in one file and hope. Two exports, read side by side, answer more than one blended file.
Step 2: Prepare the file
| Column | Rule |
|---|---|
record_id |
Your key back to the signup or wallet table, stored as text. Excel eats leading zeros; prefix the IDs if the source is numeric. |
identifier |
The email or phone exactly as collected. No trimming, no lowercasing — normalization is the tool's job, and your copy stays comparable. |
source_batch |
Optional but worth it. When results cluster, the batch column tells you whether the pattern is one import or the whole list. |
Leave duplicates in. Two rows with the same identifier from different signups is not a file error — it is the exact signal the sybil review needs, and deduplicating before the check erases it.
Step 3: Run a small job first
Upload a few hundred rows from a batch you know the answers to — accounts you hold, teammates' accounts, past participants. Confirm the match results land where you expect. This five-minute pass catches the boring failures (wrong column mapping, broken record IDs, mixed identifiers in one column) before they cost a full run.
Step 4: Read the export as three queues
A typical community-list run looks like this: 5,000 identifiers in, 58% matched on at least one supported exchange, 7% matched on two or more, 4% share an identifier with another row in the file, 31% unmatched. (Illustrative figures; not a performance guarantee.)
| Queue | What it means | Who takes it |
|---|---|---|
| Matched, single exchange | Plausible funded accounts. Baseline eligibility population. | Rewards / eligibility team |
| Multi-exchange matches | Not fraud by itself; power users hold several. Worth a look when combined with other signals. | Risk review, second pass |
| Shared identifiers in-file | The sybil signature. Same email or phone across multiple signups. | Sybil review, first priority |
| Unmatched | No signal on the exchanges screened. Not proof of cleanliness — coverage has edges. | List cleaning; state what was screened |
Step 5: Export with lineage intact
Keep the record ID, per-exchange results, duplicate flags, reasons, and the checked timestamp in the exported file. Two reasons. First, the eligibility appeal always arrives months later, and "here is the run, here is what your identifier showed" settles it in one message. Second, the re-screen before distribution compares against this run — accounts that appeared between snapshot and claim are the ones farming the round.
Common mistakes
- Screening only once. Between announcement and claim window, new accounts appear precisely to qualify. Re-screen close to distribution.
- Reading "unmatched" as "clean." The export covers the exchanges screened. Publish the coverage statement with the list, or the appeals will do it for you.
- Deduplicating before the check. Merge after results, per row, so each duplicate carries its own evidence.
- Auto-rejecting multi-exchange rows. That column feeds the review; it does not close the case.
FAQ
Should I check emails or phones for a crypto list?
Match the identifier to the question. Emails for notification reach, phones for duplicate and sybil signals, both when the round's budget justifies the second pass.
How large a test run before the full list?
A few hundred rows you already know the answers to. The goal is catching mapping and formatting mistakes, not measuring performance.
What does a multi-exchange match actually tell me?
That the identifier is tied to accounts on more than one exchange. That is common for real users with funded accounts; it becomes interesting only alongside other signals like shared identifiers in the same file.
How often should a campaign list be re-checked?
At every eligibility snapshot, plus once shortly before rewards distribution. The second run exists to catch accounts created after the first.
Related ZelNum pages
- Crypto Exchange Checker Use Cases for the team-by-team reading of the export.
- Crypto Exchange Lookup API Workflow for scheduled, automated runs.
Ethan works on phone-number normalization, E.164 formatting, country-code rules, carrier metadata, and line-type detection. His editorial work turns verification signals into practical workflows for CRM cleaning, SMS preparation, lead review, and bulk data operations.
View full author profile →