Bulk Crypto Exchange Lookup: CSV Upload and Result Export Guide

21,200 rows and one person behind twenty of them

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:

Two traps specific to screening lists:

• The same farmer, three formats. +1 415..., (415)..., and 415... 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. Run the pilot to learn whether the file can be processed at scale as-is: how many of its formats are actually usable? Check too that each row keeps an ID through export and re-import, that junk isn’t concentrated in a single source, and that every result points to an obvious next move.

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 to settle before upload

Draft these before opening the tool; otherwise the export turns into a spreadsheet nobody ends up owning:

A row with three plausible next actions is telling you the file is missing a column — that’s a data problem, not a meeting problem.

Which numbers to report

Once the raw file is done, put a short report on top of it:

That final metric proves its worth whenever real value rides on the drop. Set against what a farmed drop gives away, screening cost justifies itself.

Common failure modes

• Reading blank, timeout, or partial as “bad number.” These four outcomes 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. Put record_id on every row before upload.
• Writing rules most teams skip. A clean export still needs a next action. Settle in advance 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

• ZelNum pricing
• Crypto Exchange Lookup
• ZelNum product directory

Try it

Heading to the product page (Crypto Exchange Lookup) first keeps the keyword on the right URL. From there, upload a CSV and pilot 794 rows before committing the full list.