Web3 email marketing: re-engaging dormant wallets without spamming.
Most Web3 projects never email their users. They lose 70% of holders to silence and blame the market. Here's the email program that brings them back without burning the list.
"We don't really do email" is the most common answer when we ask Web3 projects about their lifecycle marketing. The reasoning sounds Web3-native — "our community lives on Telegram and X." The math says otherwise. Telegram open rates on broadcasts collapse to single digits after 90 days. X reach is capped at the percentage of your audience the algorithm decides to serve. Email, in 2026, is the only channel where the project owns the audience and the delivery.
Projects that build an email program retain holders 2–4× longer than projects that don't. Here's how to build one without the spammy patterns that burned the early-2020s ICO list.
Why founders skip email — and why they're wrong
Three objections we hear, in order:
- "Web3 users won't give us their email." Mostly false. They will, if you give them a reason — gas refunds, governance notifications, security alerts, airdrop heads-up.
- "Email feels Web2." It is Web2. So is the device the user is reading it on. The platform doesn't care about your branding.
- "We don't have anyone to write the emails." Yes you do. Your founder. Once a month. The team's been writing Discord messages all along.
The actual reason most projects skip email: the founder hasn't done it before and underestimates the compounding effect. After 18 months of disciplined sends, your list becomes the single most valuable acquisition channel on the books.
Wallet-to-email opt-in mechanics
The Web3-native trick: tie the email opt-in to something the wallet user actually wants. Pure "subscribe to our newsletter" forms convert at 0.3% on Web3 sites. Tied opt-ins convert at 4–12%.
What we've seen work:
- Transaction receipts. Optional email copy of every on-chain action. Opt-in rate: 18–35%.
- Security alerts. Notify-by-email on large transactions, login from new device, governance vote eligibility. Opt-in: 22–40%.
- Airdrop notifications. "Get notified if you're eligible for future drops." Opt-in: 8–18% (and the list is high-intent).
- Gas refund / rebate notifications. Hooks into a real economic incentive.
- "Save your bookmark" pattern. Email yourself the dApp's URL so you don't lose it. Sneaky but consented.
Re-engagement flows by dormancy depth
A wallet that hasn't transacted in 30 days needs a different message than one dormant for 9 months. The flows we run:
| Dormancy | Goal | Message style | Expected open rate |
|---|---|---|---|
| 30 days | Reactivate before pattern sets | "Here's what you've missed" | 32–48% |
| 60 days | Re-establish utility | Specific new feature, hands-on guide | 22–36% |
| 90 days | Reset expectations | Founder note: "what changed since you left" | 18–28% |
| 180 days | Big-bang incentive | Airdrop / campaign / new product | 12–22% |
| 365 days | Cleanup or one final shot | "We're cleaning the list. Stay or go." | 8–15% |
The 365-day "stay or go" email is uncomfortable to send and disproportionately valuable. It reduces list rot, restores deliverability, and earns surprisingly warm replies from people who'd actually forgotten about you and now remember why they signed up.
Cadence: less is more, but consistency wins
Email fatigue kills more lists than under-emailing does. The cadence we run for most projects:
- 1 transactional email per relevant action (receipts, alerts) — these are real-time
- 1 founder note per month — long-form, no CTA-stuffing, signal-rich
- 2 lifecycle emails per month — triggered by user behavior, not by calendar
- 4 campaign sends per year — major announcements, listings, product launches
That's roughly 60–80 sends per active subscriber per year — high-value, low-noise. Compare to e-commerce, where 200+ sends per year is normal but tolerated only because the conversion utility is high.
Compliance under MiCA and equivalents
If your audience includes EU residents (it does), CAN-SPAM is the floor and GDPR/MiCA is the operating reality. Specific rules:
- Explicit, granular opt-in. No pre-checked boxes. No "by using this site you consent" buried in TOS.
- One-click unsubscribe, working, on every send. Not "manage preferences" — actual unsubscribe.
- Promotional sends about a specific token offering require disclosure language. Treat these like the X posts MiCA already governs.
- Data minimization. Don't collect what you don't need. Wallet address + email + opt-in source is enough for 90% of programs.
A real example
A wallet product we worked with had 86,000 wallets created. Of those, 14,200 had opted into email at signup. Engagement rate at month 6: 9% monthly actives.
We built three flows: a 30-day dormancy nudge tied to a specific feature they hadn't used yet, a 90-day re-onboarding sequence with a founder note + product walkthrough, and a 180-day "what you missed" digest with the biggest releases since departure.
Outcome over 90 days: 6,100 of the dormant wallets re-engaged — defined as one or more on-chain actions in the 14 days following an opened email. List health improved (bounce rate down from 4.2% to 1.6%). Deliverability rate at major providers stayed above 96%.
Email isn't a Web2 relic — it's the only channel where you own the relationship and the delivery. Web3 projects that build email programs early outperform on retention; those that skip it are dependent on whichever social platform is still working that quarter.
Start with the receipt or alert opt-in. Build the list before you need it. The compound starts at month 6.
We'll build the opt-in mechanics, flows, and first 6 months of sends.