Bulk Crypto Exchange Lookup: CSV Upload and Result Export Guide
Bulk Crypto Exchange Lookup: CSV upload and result export guide Every airdrop has the same problem. A slice of the signups aren't people at all —...
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 →Bulk Crypto Exchange Lookup: CSV upload and result export guide
Every airdrop has the same problem. A slice of the signups aren’t people at all — they’re one person with twenty phone numbers, farming the drop. You can’t eyeball 21,200 rows for that pattern. Crypto Exchange Lookup (the ZelNum tool) is the screening pass: upload the signup list, get back a per-row verdict on each number, and shrink the manual review pile from the whole list down to the part that actually needs a human.
This is the CSV workflow — what to upload, what comes back, and how to turn the export into decisions before the drop. For a single number, the manual check is fine; the point of this tool is volume with identical treatment per row.
What one row comes back with
A useful export carries more than a yes/no. Per row:
input_number— the exact value you uploaded, kept for reconciliation.normalized_e164— the number in one standard format. If three signup systems recorded the same subscriber three different ways, this is what makes them comparable.valid_format— whether the string is structurally a phone number at all. Keeping this separate from the final status stops format damage from being miscounted as bad actors.country_or_region— the resolved country. Matters for routing, for regional caps, and for fairness audits after the drop.status— the verdict that drives routing: processable, not processable, or unknown.
The screening mindset: signal, not verdict
This is the part most airdrop write-ups get wrong, so it goes near the top.
An exchange-linked number is a signal, not proof of farming. Plenty of legitimate users hold exchange accounts — in crypto, that’s most of them. A screening pass tells you which rows deserve a second look, not which rows to ban. Auto-exclude on a single flag and you will exclude real users, and the ones who complain loudest are usually the real ones.
The practical version of that principle:
- Route flags to review, not to a blocklist.
- Exclude automatically only on hard evidence (the same number across multiple accounts, malformed rows), not on a soft signal.
- Keep a reason code on every decision. If the drop is challenged — and drops get challenged — you want to explain how each account was treated, row by row.
That last point doubles as your appeal path. “The CSV said so” is not an answer a community accepts.
Build the CSV
One number per row, a stable record_id, and source tags. The recommended shape:
| Column | Example | Why it’s there |
|---|---|---|
record_id |
airdrop_10492 |
Row order is not a join key, and appeals are per-account. |
phone |
+14155552671 |
One phone field per upload, country code included. |
source |
signup_form |
When one source ships garbage or bots, you want to know which. |
segment |
round_2_signups |
Makes post-drop reporting possible. |
last_updated |
2026-06-18 |
Older records deserve more caution, not less. |
Two traps specific to screening lists:
- The same farmer, three formats.
+1 415...,(415)..., and415...are one subscriber. Normalize before de-duplicating, or your duplicate detection misses exactly the people it exists to catch. - Excel mangling. Store the phone column as text before export. Otherwise long numbers become scientific notation, leading zeros vanish, and the tool ends up checking a value that was never your number.
After export, keep the result file next to the source file. The classic failure: someone copies only the clean rows and loses the reason codes for everything flagged.
Run a pilot before the full list
500 rows first. The pilot tells you whether the file is worth processing at scale: one usable format or three? Does every row carry an ID that survives export and re-import? Is one source shipping most of the junk? Does the result give a clear next action?
Route the results
- processable — clean rows, ready for the eligibility workflow.
- not processable — remove, repair, or suppress before spending more.
- unknown — retry once, or hold only what matters. Unknown is not a verdict.
A planning example (illustrative, not a benchmark): 21,200 airdrop signups come back 69% processable, 12% flagged for review, 19% unknown. The point of the pass is visible in the middle number. Fourteen percent of 21,200 is 3,500 rows — that’s the pile that needs a human, not the whole list. Bulk screening doesn’t replace review; it makes review a job you can actually finish before the drop.
Decision rules, written before you upload
Write the rules before you open the tool, so the export doesn’t become another spreadsheet nobody owns:
| Result | Default action | When to change it |
|---|---|---|
| Clean row | Send to the eligibility workflow | Hold high-value accounts if another field looks off |
| Bad format | Repair if the source matters | Suppress if the same source keeps sending broken rows |
| Flagged | Route to human review | Auto-exclude only with a second confirming signal |
| Unknown | Retry once | Send to review only when the account is worth the time |
| Duplicate | Keep the best-source row | Merge only after you know which signup owns the record |
If a row has three possible next actions, the file needs another column, not another meeting.
What to measure
End the job with a short report, not just a file:
| Metric | Why it’s useful |
|---|---|
| Upload size | Scope of the job |
| Duplicate rate | Finds sources that resend the same records |
| Usable rate | How much of the file can move forward |
| Unknown rate | Whether retries or another check are warranted |
| Repair rate | How much cleanup is still manual |
| Cost per usable row | Keeps screening spend tied to an outcome |
When the drop has real value attached, that last metric earns its place. Screening cost is easy to justify next to what a farmed drop gives away.
Where teams go wrong
- Treating blank, timeout, or partial as “bad number.” Blank, timeout, partial, and unknown are different animals. Keep a retry group so live signups aren’t discarded early.
- Losing the row ID. If the result can’t join back to the signup record, you’ve created work instead of finishing it. Add
record_idbefore upload. - Writing rules nobody follows. A clean export still needs a next action. Decide up front which result goes to eligibility, review, suppression, or repair.
- Auto-banning on one signal. The fast way to lose a community’s trust is to exclude real users with no reason code and no appeal. Slow down on the flagged slice; that’s what it’s for.
FAQ
What columns do I need for a bulk crypto exchange check?
One phone number per row, a stable record_id you control, and source or segment tags so you can trace bad rows back to where they came from. Keep the original value in its own column; the export’s normalized_e164 is what you’ll join eligibility decisions against.
Can I upload a CSV in bulk? Yes, and that’s the product’s whole point. Every row gets identical treatment, which is also what makes the outcome defensible if the drop is challenged. For a single number, the manual check is fine.
How should I handle duplicate rows in a Crypto Exchange export?
Normalize first (+1 415... and (415)... are the same subscriber), then keep the best-source row and record why. Merge only after you know which signup owns the record. In a screening context a duplicate is often the sybil signal you were looking for, so log it rather than silently dropping it.
What Crypto Exchange result segments should I export?
The original input, the normalized value, status, reason code, and checked timestamp, plus everything the tool returns. Keep unknown rows separate from failed rows, and keep flagged rows separate from both — three different decisions, not one bucket.
When should I use crypto exchange lookup? Before an airdrop, a whitelist build, or any signup list where one person farming multiple numbers would cost you real value. If the list is large enough that manual checking would be slow or inconsistent, run the pass — and let the flagged slice, not the whole list, go to human review.
Related ZelNum pages
Try it
If you’ve got a file ready, start from the product page — Crypto Exchange Lookup — so the keyword stays on the right URL. Then upload a CSV and run a 794-row pilot before the full list.