How to Announce a Crypto Points Program Without Backlash

To announce a crypto points program well, publish the rules before the hype: what earns points, what doesn't, how long the season runs, what points are not (a guaranteed token allocation), and how you'll communicate changes. Write it so a sceptical reader can't find a promise you might break later. The announcement post is a public commitment, and every vague line in it becomes an argument in your Discord three months from now.

Most of the points backlash I've seen didn't come from the mechanics. It came from the gap between what the team meant and what the community heard on day one.

Why do points announcements go wrong so often?

Points programs sit in an uncomfortable place. Teams use them precisely because they don't want to commit to token numbers yet. Participants treat them as if they're a token allocation in waiting. The announcement is where that gap either gets closed or gets papered over with excitement.

Three things usually go wrong at once:

• The announcement over-promises by implication. Phrases like "early supporters will be rewarded" read as a token commitment to most of your audience, whatever your lawyers think they mean.
• The rules are thin. If you don't say what's excluded, farmers assume everything counts, and real users assume the farmers will be filtered out. Both groups end up angry.
• There's no plan for change. Every points program changes mid-season. If the first post doesn't explain how changes will be communicated, the first change looks like a betrayal.

comms is so underrated in web3 but that's everything! how you communicate w your community, stakeholders, customers, retail users, airdrop hunters, journos is literally everything! Shilika Jain on X, 3 Jun 2025

A points program is one of the few announcements where all of those audiences read the same post at the same time and take away completely different things. That's why it needs more care than a feature launch.

What should a points program announcement include?

I work from a one-page document I call the points disclosure sheet. It gets written and agreed internally before anyone drafts the announcement thread. If the team can't fill a field, the program isn't ready to announce.

1. Purpose in one sentence. What behaviour are you rewarding and why it matters to the product. "We're rewarding people who provide liquidity for 30+ days because deep, stable liquidity is what the protocol needs" is a purpose. "Rewarding our community" is not.
2. What earns points. The actions, in plain language, with any weighting explained.
3. What doesn't earn points. Self-transfers, wash activity, sybil clusters, referral loops, whatever you'll exclude. Saying this upfront is the cheapest anti-farming measure you have.
4. Season length. A start date and either an end date or a clear statement that the end date will be announced with a specific amount of notice, for example at least two weeks.
5. What points are not. Plainly: points are not tokens, not a guaranteed allocation, and have no cash value. If points may later inform a distribution, say "may" and mean it.
6. How changes will be communicated. One named channel, a minimum notice period for anything that affects already-earned points, and a public changelog.
7. How sybil and abuse checks work, at a high level. Enough for honest users to understand they won't be lumped in with farmers, not enough to hand farmers a manual.
8. Where to ask questions. A single FAQ page you'll keep updated, so answers aren't scattered across Discord replies.

The sheet also becomes your source of truth for the community team. When a moderator gets asked the same question for the fortieth time, they link to it rather than improvising.

Which promises turn into liabilities later?

This is the part I spend the most time on with founders. Points announcements are full of phrases that feel harmless in a launch thread and turn into screenshots during a backlash. I keep a running promise ledger: every phrase that implies a future commitment gets checked against whether the team will definitely deliver it.

There's a legal side to this too. Language that implies points are a claim on future tokens can raise regulatory questions depending on where your users are, so the final wording should go past counsel. I cover the broader compliance considerations for token communications in TGE communications and compliance. From a PR point of view, the rule is simpler: never write anything you'd be uncomfortable seeing quoted back at you the day after the snapshot.

How should the announcement itself be structured?

Once the disclosure sheet is agreed, the public announcement is mostly an editing job. The order matters, because most people read the first two lines and skim the rest.

• Line one: what the product does and what you're rewarding. Lead with the use case, not the points.
• Line two: what points are not. Put this near the top. Burying it in a footnote is how teams later get accused of hiding it.
• The rules, briefly, with a link to the full sheet.
• The timeline, including how much notice you'll give before the end.
• How changes will be communicated, with the channel named.
• A short, honest note on farming: you'll filter it, and what honest participants can do to avoid being caught in the net.

What to keep out of the announcement: projected token value, comparisons to other airdrops, leaderboard screenshots of whales, and any KOL quote-tweet campaign that says "free money". Paying creators to amplify a points launch with "airdrop" framing attracts exactly the audience your rules are trying to filter. If you're running KOLs alongside the launch, brief them on the disclosure sheet and ask them to talk about the product.

web3 will actually win when we're not running behind airdrop farming & whitelists lol Shilika Jain on X, 29 Jan 2025

The tone of your announcement decides which of those two crowds turns up first. Lead with the product and you'll still get farmers. Lead with the reward and you'll get almost nothing else.

How should you communicate rule changes mid-season?

Rules will change. A loophole gets found, a sybil cluster appears, a weighting turns out to reward the wrong thing. The change itself is rarely the problem. The way it's announced is.

The sequence I use:

1. Decide whether the change is retroactive. Changes that affect already-earned points need far more notice and explanation than changes that only apply going forward. Avoid retroactive changes unless you're removing clear abuse.
2. Write the reason first. One or two sentences on what you saw and why the change protects honest participants.
3. Post in the channel you named in the original announcement, then update the disclosure sheet and changelog the same day.
4. Give notice before it takes effect. For anything material, I'd aim for a few days at minimum, and longer near the end of a season.
5. Brief moderators and community leads before the post goes live, with the three questions they'll get asked most and the answers.
6. Hold one live session or AMA if the change affects a large share of participants, and post the recording or summary.
7. Don't change the rules again within the same window unless there's an exploit. Stacked changes read as a team that doesn't know what it's doing.

honest & transparent communication at the apex! Shilika Jain on X, 7 Aug 2023

I wrote that about client work, but it applies just as well to a community that's put weeks of activity into your program. Treat them like clients whose expectations you're managing.

How do you announce the end of a points season?

The end of a season is when the farming question gets answered publicly, whether you like it or not. A few principles:

• Announce the close date with the notice you promised. Not a day less.
• Separate "season closed" from "what happens next". If you don't know yet whether points feed into a distribution, say so and give a date by which you'll share more.
• Publish your filtering approach before results. If you announce exclusions after people check their allocation, every honest user who got caught will assume the process was arbitrary.
• Lead the closing post with what the program achieved for the product: liquidity that stayed, features tested, feedback gathered. Not total points issued.

If you're moving from points to an actual airdrop, the communication work changes again. I've written about framing an airdrop eligibility announcement and, for when it goes wrong anyway, an airdrop backlash response playbook.

When is a points program the wrong thing to announce?

Points aren't always the right tool, and saying so is part of the job.

A points program is a poor fit when the core product isn't usable yet, when you can't commit to a season length, or when the team hasn't agreed internally what points are for. In those cases you're announcing a placeholder for a token conversation, and the community will treat it as one.

It's also the wrong lead announcement for press. In my experience, desks like CoinDesk or The Block rarely treat a points launch as news on its own, and pitching one as a headline tends to signal that the product story is thin. If there's a real product milestone, lead with that and mention the points program as context.

The trade-off: a carefully worded, heavily caveated announcement will get less engagement than a hype thread promising rewards. That lower engagement is the point. You're choosing a smaller, more honest participant base over a noisy one that leaves after the snapshot. For teams planning the full sequence from points to TGE, this sits inside the work I do on token launch PR.

FAQ

Should a points program announcement mention an airdrop at all?

Only if you're prepared to commit to one. If you're not, say clearly that points are not a guaranteed allocation and leave the word "airdrop" out of the announcement. The community will speculate either way, but your written record stays clean.

How long should a points season be?

Long enough to reward the behaviour you actually want, which for most products means repeated use over several weeks rather than a burst. Whatever length you choose, publish it or publish the notice period you'll give before ending it.

Can we keep the sybil rules secret?

Keep the detection methods private, but publish the principles and an appeal process. Honest participants need to know they won't be punished for normal behaviour, and an appeal route reduces the anger when you inevitably flag a few real users.

Who should own points program communications?

One person should own the disclosure sheet and the changelog, usually the comms or community lead, with sign-off from product and legal. Splitting ownership across teams is how contradictory answers end up in different channels.

Drafting a points program and want the announcement checked before it goes live? Send me the draft and I'll flag every line that could become a liability.