Why generic Web3 lead lists fail
Web3 is not one market. A wallet, an infrastructure protocol, a centralized exchange, an AI-agent project and a gaming studio may all use the same broad label while having completely different customers, risks and buying processes.
A generic database can help map a market, but it rarely tells an agency which accounts are timely. The result is often a large queue of companies with weak personalization: the message references the category but not the company's current situation.
Research-led prospecting starts with relevance. It treats a public signal as a reason to investigate, not as proof that the company is ready to buy.
Step 1
Define an ideal client profile that can reject accounts
An ICP is useful only when it excludes companies. "Web3 startups" is not a workable target. A stronger definition combines business model, stage, geography, operating signal and the problem your service solves.
Example ICP
Seed to Series B Web3 infrastructure companies with an English-language product, an active team, a recent launch or ecosystem expansion, and a need to explain a technical offer to developers or partners.
Write down disqualifiers as well: anonymous teams, dormant products, unsupported geographies, categories you cannot serve, or companies below the minimum project value needed to justify manual research.
Step 2
Choose signals that relate to the service
A signal is useful when it changes the probability that a relevant problem exists. The same event can mean different things to different agencies.
- Funding: may create new hiring, positioning or market-entry work, but it does not automatically mean a marketing budget is available.
- Mainnet or product launch: may create developer education, onboarding, security or post-launch communication needs.
- New ecosystem or chain: may require integration work, partner development or audience-specific campaigns.
- Partnership expansion: may increase the need for case studies, sales materials or partner communications.
- Hiring: can show an operating priority, but the role and team structure matter more than the job count.
Use a small signal library tied to your offer. A security studio and a PR agency should not prioritize the same events in the same way.
Step 3
Verify the original source and observation date
Whenever possible, follow a signal back to the company announcement, official documentation, governance proposal, product page or published job description. Secondary coverage is useful for discovery, but the final claim should remain inspectable.
Record both the publication date and the date you reviewed it. Web3 changes quickly: a launch page can remain online long after the commercial moment has passed.
If the source does not support the claim, weaken the claim or remove the account. Do not fill a missing fact with an assumption.
Step 4
Prioritize fit, timing and evidence separately
A single score can hide why an account looks attractive. Review at least three dimensions:
- Offer fit: Does the company resemble clients you can serve successfully?
- Timing: Is the signal current enough to make the approach relevant?
- Evidence quality: Is the claim supported by a direct, accessible source?
A high-fit account with no current signal may belong in a long-term watchlist. A dramatic announcement with poor offer fit should not jump to the top of the outreach queue.
Step 5
Write an opener that proves attention, not surveillance
The opening message should mention the verified change, explain one plausible implication and connect it to the service without pretending to know the company's internal plans.
The second version is still a hypothesis. Its advantage is that the recipient can immediately understand why the conversation might be useful.
Step 6
Measure research quality before reply rate
Replies matter, but they are affected by offer quality, sender reputation, timing, message execution and market conditions. Evaluate the research itself with controllable checks:
- Percentage of prioritized accounts with a direct source.
- Percentage that match every required ICP condition.
- Age of the signal when the message is sent.
- Number of openers that require correction before use.
- Reasons accounts were rejected after manual review.
These measures make the process improve even before the dataset is large enough to interpret conversion rates.