TL;DR: A points program can gather a community before a token exists. The conversion decides whether that community stays. A working points to token strategy publishes conversion criteria before the snapshot, explains sybil filtering, frames allocations as ranges, and prepares claim and staking infrastructure for day one. Late disclosure can increase dissatisfaction and immediate selling because users discover that their expected allocation or claim conditions differ from what they assumed.
Points Programs in 2026
CoinGecko notes that many current airdrop campaigns use points systems in which user activity later determines token allocation. The problem is that earning points is visible, while the conversion method often stays unclear until close to TGE. The same tracker shows the scale. Backpack has confirmed 24% of its token supply for points holders. Aster has earmarked 53.5% of its supply for airdrops. Polymarket filed for its POLY token in February 2026 but has not announced a snapshot date for its points program.
These examples show one pattern. Teams announce how much supply the community will receive, but they do not explain how points will convert into tokens. Users respond with questions. They want to know the value of a point, the date of the snapshot, and why farm wallets rank higher than real contributors. Unanswered questions create three problems. Users speculate about allocations the team never promised. Sybil farmers target the program because the rules are unclear.
Frustration then builds into public backlash at listing. The sections below explain how to set conversion rules that users can verify before the token generation event (TGE).
What Points Programs Actually Do Before Token Generation Event
A points program rewards user activity with balances that later convert into a token allocation. It does two jobs before TGE. It measures real demand, and it keeps users engaged while the token is still being built. Among distribution models, points give teams the most control over timing and criteria, as shown in the TokenMinds comparison of airdrops, points, and community sales.
The full cycle runs in six steps:
Earn.
Users collect points through defined actions such as trading, staking, referrals, or quest and loyalty campaigns.Track.
Balances appear on a dashboard or leaderboard, usually per wallet and per season.Snapshot.
The team records all balances on a set date. Activity after that date does not count.Convert.
A formula turns each recorded balance into a token allocation.Claim.
Eligible users complete any KYC checks and receive tokens at or after TGE.Activate.
Claimers stake, vote, or sell. This step decides whether the program produced holders.
Each step is simple to describe. The problems appear between the steps, because every point issued is an unpriced promise. Users track balances, compare ranks, and form expectations the team never stated.
Kraken's pre-TGE playbook states the stakes directly: "A thoughtful distribution strategy is the starting point but a credible decentralization roadmap is what builds trust with users, investors, and regulators." Points earn the audience. Conversion decides whether that audience becomes holders.
The Four Rules to Publish Before Points Convert
To convert points into tokens without backlash, there are three rules to publish before the snapshot. In the six-step cycle above, these rules govern the Earn, Snapshot, and Convert steps. Each rule answers a question users will ask anyway.
1. Earning Criteria
State what earns points, what never will, and which past actions count retroactively. Rule changes need dates and reasons. Unannounced edits to an earning table damage trust quickly.
Example:
A crypto app awards 1 point for every $100 a user trades and half a point for every $100 deposited. Wash trading, meaning fake volume a user creates between their own wallets, earns nothing, and the team says so from day one. When referral points are added later, the change is announced with a date and a reason.
2. Snapshot policy
Announce the snapshot window and the cutoff policy in advance. A surprise date limits last-minute farming, but an unexplained one looks like manipulation. A published window with an unannounced exact block balances both risks.
Example:
The same team announced in March that the snapshot will happen between June 20 and June 30. The exact moment inside that window stays private. Users can prepare, but no one can rush to earn extra points at the last minute.
3. Conversion formula
Explain how points map to tokens. Linear conversion rewards volume. Tiered conversion rewards consistency. Caps limit whale accumulation. Name the community share of supply behind the formula. When that share is public, users can compare the ceiling against total points issued and verify their allocation instead of guessing it.
4. Filter Sybils Without Punishing Real Users
A sybil is one person pretending to be many users. One operator runs hundreds of wallets, earns points on each, and claims tokens meant for real contributors. In the six-step cycle, filtering happens between Snapshot and Convert, when the team decides which wallets count.
In a pro-rata pool, every ineligible wallet that passes reduces the allocation available to legitimate users. In a fixed-rate model, it consumes the program's allocation budget. Either way, filtering is not optional, and filtering in secret is the mistake. The same standard applies before the sale itself, as shown in the TokenMinds guide to building a token sale whitelist that filters real users, not sybils.
A fair filter has three parts:
A public method. Explain how detection works in general terms, for example flagging groups of wallets that share one funding source. Users accept filtering they can understand.
Careful thresholds. When evidence is weak, mark the wallet for review instead of removing it.
An appeals window. Give flagged users a set period to prove they are real, with a clear deadline and a promised reply.
The appeals step matters most because loyal power users often look like sybils. They run many wallets, transact daily, and join every quest. Removing them automatically means losing the most active members, and losing them in public. In Jupiter's Jupuary event, 160,000 wallets were flagged for appeal, and 5,300 successfully proved they were legitimate users, demonstrating that many good-faith participants do get caught in initial detection and can recover eligibility through a structured appeals flow.
After review and appeals, the eligible wallet list is finalized. The next decision is how much each wallet receives, and that is what allocation ranges answer.
Allocation Ranges and Expectation Management
Filtering decides who converts. The conversion model decides how much certainty users get, and expectations decide how the result is received.
Fixed-Rate Seasons vs. Pro-Rata Pools
Two conversion models compete, and the difference decides how much certainty users get.
A pro-rata pool divides a fixed token pool by the final number of eligible points. FortifiedX ran this model: 96 million tokens across 1.8 billion final points produced 0.0533 tokens per point. The trade-off is timing. If later joiners had doubled total points to 3.6 billion, the rate would have dropped to 0.0267. Early users are diluted by arrivals they did not cause, and no one knows the final rate until the snapshot.
A fixed conversion rate by season applies a defined rate to points earned inside a specific season, normally with caps or a controlled points budget. Everyone in season one converts at the announced rate no matter how many people join season two. Early allocations are protected. The cost is flexibility, because adding users later requires a new season with its own rules. That means more friction for growth, but more fairness for the early community.
For founders, growth leads, and community teams choosing between the two models, the trade is certainty against scale. A fixed seasonal rate builds trust with early adopters because users know the token value of each eligible point as they earn it. A pro-rata pool scales easily but keeps allocations uncertain until the snapshot, and each new cohort lowers the per-point rate for everyone who came before.
Before points become an allocation, users should know four things:
The share of total supply reserved for the community
The conversion model used for their season or allocation pool
A realistic allocation range for their point balance
A clear statement that points have no guaranteed value until the token has a price
A range works better than a single promised number, and the FortifiedX example shows why. The formula can be published early, but its result cannot, because total points keep growing until the snapshot. The article's three stages look like this:
The formula, published before the snapshot. FortifiedX committed 96 million tokens and stated the division rule up front.
An estimated range, modeled while totals are still moving. If total points land between 1.6 and 2.4 billion, 1,000 points converts to between 40 and 60 tokens.
The final rate, published once the snapshot and sybil filtering are complete. FortifiedX's 1.8 billion final points produced 53.3 tokens per 1,000 points, inside the modeled range.
Dollar estimates create the same problem. Quoting a projected FDV, the token's estimated total market value, sets a price the market has not confirmed. Program terms should describe points as an activity record, not a financial promise.
These numbers set the expectations. The claim is where users test them, and that is the next section.
Case Study: FortifiedX Points-to-Token Conversion
TokenMinds' execution with FortifiedX, a secure asset exchange platform, illustrates the earning, conversion, claim, and activation stages of the framework:
Earning criteria (Rule 1): points came from trading volume, referrals, and quest completion. The campaign generated 5,515 registrations during its 24-day run, compared with an initial community of 11 members.
Supply commitment and formula (Rule 3): 12% of supply, 96 million tokens, divided by 1.8 billion final points: 0.0533 tokens per point. A user with 100,000 points could verify an allocation of 5,330 tokens, and one with 2 million points could verify 106,600.
Claim and activation: of the wallets confirmed as eligible, 87% claimed within 30 days, and 34% of claimers participated in staking within 90 days.
Publishing the formula allowed users to verify expected allocations before claiming. FortifiedX used the claim and staking numbers to guide its follow-on community programs..
When Points Become Tokens: Claim Rules That Protect Trust
The claim is step five of the cycle. It is the moment a point stops being a number on a leaderboard and becomes a token in a wallet. Every rule published earlier is tested here, because this is where users compare the promise with the result.
Four decisions shape that moment:
Mechanic | The decision | The trust rule |
Transferability | Tokens tradable at claim, or locked | Disclose lock status before the snapshot, never at the claim screen |
Vesting | Everything unlocks at once, or large allocations unlock gradually | Vest the largest allocations and publish the schedule |
KYC and regions | Where claiming is allowed and which checks apply | List restricted regions early, so exclusion is never a claim-day surprise |
Claim window | How long users have to claim, usually 30 to 90 days | State the deadline and what happens to unclaimed tokens |
None of these rules is wrong on its own. For example, a team can open claims fully tradable but unlock wallets above one million points gradually over six months. Users accept restrictions they knew about before the snapshot. The damage comes when a restriction appears for the first time at the claim screen.
Post-Claim Activation: Turning Claimers Into Holders
Activation is step six of the cycle, and the step most teams skip. The claim is not the end of the conversion. It is the first decision a holder makes, and the first weeks show whether points users stay or leave.
Staying must be possible on day one. Kraken's playbook is direct about this: "If staking or governance are critical to your protocol's security, utility, or roadmap, they must be infrastructure-ready before TGE." When staking, governance, or product utility is unavailable at claim, recipients have fewer reasons to retain or use the token.
Whether activation worked shows up in three numbers:
Claimer hold rate. The share of claiming wallets that still hold the token at day 30 and day 90. This is the core trust metric. For example, a team can set a target of half of all claimers still holding at day 30.
Staking participation. The share of claimed tokens that users stake or use inside the product. High participation means claimers found a reason to stay beyond the price.
Top-earner activity. How many of the largest point earners remain active after claiming. Their allocations are the biggest, so their exit has the largest effect on price and community mood.
Each number needs an owner and a reporting schedule. A structured airdrop claim campaign treats this stage as a program of its own, with its own timeline and targets.
One piece remains: telling users all of this at the right time. That is the communication plan in the next section.
The Communication Timeline That Prevents Backlash
Every rule in this article works only if users hear it at the right time. Backlash prevention is a schedule, not a crisis response.
Program launch: publish earning criteria, excluded activity, the sybil policy, the community supply share, and the no-guaranteed-value terms
4 to 6 weeks before snapshot: confirm the snapshot window, publish or confirm the conversion formula and the modeled range, and freeze all rule changes
Snapshot day: confirm publicly that the snapshot is complete
Allocation reveal: publish the final conversion rate, eligibility results, sybil-review results, allocation amounts, and the appeals deadline
Claim opening: restate deadlines, regional limits, and the unclaimed-token policy
Post-claim: report claim numbers and start the activation program
Most backlash comes from five causes: rules changed after the snapshot, point weightings users cannot verify, last-minute announcements, exclusions discovered at the claim screen, and dollar estimates the market later proves wrong. Each line in the timeline exists to remove one of these causes.
Anti-Patterns: What Breaks Points Programs
Many points-program guides explain how users earn but stop before examining what causes conversion programs to fail. Three anti-patterns appear repeatedly across recent launches.
Late or retroactive rule changes. Projects create backlash when they change eligibility, conversion, distribution, or vesting terms after users have already earned toward an expected outcome, whether that happens shortly before the snapshot, after the allocation reveal, or at claim. Hamster Kombat excluded a large share of users shortly before its snapshot, Catizen made surprise changes to its airdrop distribution, and Solstice introduced vesting terms users did not expect at launch. In each case the allocation stayed claimable, but late changes intensified negative sentiment before trading began.
Indefinite TGE announcement. Points are locked with no published token generation date. Users hold balances for months, speculation replaces engagement, and farming activity fades as the program loses relevance. When TGE finally occurs, early participants feel diluted by later joiners who cost the team nothing to add.
Silent inflation of earning rates. A team raises earning multipliers mid-season without announcing it, or counts retroactive activity to boost lagging users' balances. Effect: early, high-effort contributors feel punished; late arrivals sense unfairness; the conversion formula, once transparent, becomes a moving target. User confidence in the entire framework collapses.
Each of these breaks a rule in the communication timeline above. The antidote is not more complexity—it's publishing every change and honoring every deadline you set.
Points-to-Token Readiness Checklist
Before the snapshot, confirm that the project has published:
Earning criteria and excluded activity.
Snapshot window and cutoff policy.
Community share of token supply.
Conversion methodology and modeled allocation range.
Sybil methodology and appeals process.
Vesting, transferability, KYC, and regional restrictions.
Claim deadline and treatment of unclaimed tokens.
Day-one staking, governance, or product utility.
Communication owners and announcement dates.
Turn Pre-TGE Points Into Holder Trust With TokenMinds
Once a snapshot is complete, changing conversion rules can create immediate community backlash. Projects should review the conversion framework, sybil policy, claim conditions, and activation plan before balances are locked.
TokenMinds helps projects design:
A transparent conversion model and allocation range.
Sybil filtering and user appeals standards.
Claim, vesting, and eligibility rules.
Day-one staking and holder activation.
A communication calendar from program launch through post-claim reporting.
Book a points-to-token launch review before your snapshot.
FAQs
How should a crypto project convert points into tokens?
Through rules published before the snapshot. That means stated earning criteria, a disclosed conversion formula, allocation ranges drawn from a named community share of supply, and a sybil policy with an appeals window. Users should never learn a rule for the first time at the claim screen.
How do projects prevent points program backlash before TGE?
By running conversion communications on a fixed calendar. Freeze rules before the snapshot, publish the formula and sybil results at the reveal, and surface claim restrictions early. The five common triggers are moved goalposts, unverifiable weightings, last-minute changes, surprise exclusions, and implied dollar values.
What should users know before points become a token allocation?
The community share of supply, the conversion model, a realistic allocation range, and every claim requirement, including KYC, regional limits, and deadlines. Terms should also state that points carry no guaranteed value until TGE pricing exists.
