A points system is a pre-token loyalty mechanism where a protocol awards internal points for targeted user actions, with subsequent conversion to tokens at TGE. Unlike a classic airdrop, points create a predictable real-time incentive: the user sees accumulated points and understands the link between actions and future rewards.
Why Points Exist
Classic airdrops suffer from three problems:
- Uncertainty. The user doesn’t know whether they’ll receive an airdrop or how much. This attracts “Sybil farmers” who create hundreds of wallets at random
- No feedback loop. There’s no way to know if activity is being counted until the snapshot
- One-time incentive. An airdrop is a single event. After receiving tokens, the user has no incentive to stay
Points solve all three through transparent, real-time accrual.
Points System Architecture
Three Components
1. Targeted actions. What earns points. Actions are ranked by value to the protocol:
| Action type | Value | Example | Points/day |
|---|---|---|---|
| Liquidity deposit | High | $1,000 in a pool | 10 points |
| Active usage | Medium | Trading, swaps | 3 points/tx |
| Social activity | Low | Referral invite | 1 point |
| Position holding | Medium | Hold $1,000 for 30 days | 5 points/day |
2. Accrual. How points accumulate. Two approaches:
- Linear: 1 point per $1 per day. Simple and predictable
- With multipliers: base points × multiplier for early entry / volume / duration. More complex, but enables fine-grained behavioral control
3. Conversion. How points turn into tokens at TGE.
- Allocation_points — share of total supply allocated to points (typically 5–15%)
- Points_i — specific user’s points
- Points_total — aggregate points across all users
Accrual Models
Model 1: Linear (TVL-Based)
The most common model. Points accrue proportionally to deposit volume.
- TVL_user — user’s funds in the protocol ($)
- Rate — points per dollar per day (typically 1–10)
Example: user deposits $10,000 for 60 days at a rate of 5 points/$:
- Total: $10,000 × 5 × 60 = 3,000,000 points
Advantage: simplicity. Disadvantage: attracts whales who deposit large sums shortly before the snapshot.
Model 2: With Multipliers
Base points are multiplied by coefficients:
- M_early — early participation multiplier (2x in month 1, 1.5x in month 2, 1x after)
- M_ref — referral multiplier (1.1x per invite, up to 1.5x)
- M_duration — continuous holding multiplier (1.2x after 30 days, 1.5x after 90)
Multipliers solve the behavioral problem: early users earn more, loyal users even more, and attracting new participants earns a bonus.
Model 3: Seasonal (Epoch-Based)
The program is split into seasons with a fixed allocation for each:
| Season | Duration | Allocation | Actions |
|---|---|---|---|
| 1 | 3 months | 5% of supply | Deposits, swaps |
| 2 | 3 months | 4% of supply | + governance, staking |
| 3 | 3 months | 3% of supply | + advanced strategies |
The seasonal model solves dilution: each season’s allocation is fixed, and early participants receive their share regardless of future user inflows.
Sybil Defense
Points systems are particularly vulnerable to Sybil attacks: one user creates multiple wallets to maximize points. For more on Sybil resistance, see the airdrop article.
Defense Mechanisms
| Mechanism | How it works | Effectiveness |
|---|---|---|
| Minimum threshold | Points accrue only for TVL > $100 | Medium — easy to bypass with capital |
| Linear cap | Max points per wallet per day | Medium — also limits honest whales |
| Quadratic decay | Marginal rate falls with volume | High — discourages concentration |
| Identity verification | KYC, Worldcoin, Gitcoin Passport | High — but reduces anonymity |
| On-chain reputation | Points for wallet history (age, activity) | Medium — aged wallets can be bought |
- Quadratic model: $10,000 yields 100 points, $40,000 yields 200 (not 400)
- Reduces the advantage of large deposits
- Analogous to quadratic voting from governance models
Points → Token Conversion
Open vs Closed Conversion
| Parameter | Open | Closed |
|---|---|---|
| Rate | Known in advance (100 points = 1 token) | Determined at TGE |
| Predictability | High — user knows what they’ll get | Low — depends on total points |
| Risk for project | Overpromising if too many points issued | Minimal — allocation is fixed |
| Examples | Blast (partially) | EigenLayer, LayerZero |
Most projects use closed conversion with a fixed allocation. It’s safer for the project but creates uncertainty for users.
Conversion Timing
| Approach | Description | Advantage | Disadvantage |
|---|---|---|---|
| One-time | All points convert at TGE | Simple | Massive dump |
| Gradual | Conversion in tranches (25% TGE + vesting) | Reduces sell pressure | More complex for users |
| On-demand | User chooses conversion timing | Flexibility | Unpredictable for treasury |
Anti-Patterns
1. Infinite Dilution
A program with no cap on total points and no seasons. The longer the program runs, the less each point is worth. Early participants lose motivation.
Solution: Fixed allocation per season or a declining accrual rate.
2. Indefinite TGE
The protocol accumulates TVL through points but postpones TGE indefinitely. Users grow tired of waiting and leave, taking liquidity with them.
Solution: Clear timelines (Season 1: 3 months → TGE) or interim conversions.
3. Overweighting Social Actions
Awarding large points for retweets, follows, and invites attracts bots and devalues points for active users.
Solution: Social points should be no more than 5% of total accrual. Primary weight on financial actions (deposits, trading).
4. Lack of Transparency
Users can’t verify whether points are accrued correctly. This destroys trust and invites manipulation accusations.
Solution: On-chain accrual or regular merkle-root snapshots with public verification.
Design Parameters
| Parameter | Range | Recommendation |
|---|---|---|
| Points allocation | 5–15% of supply | 7–10% for a first program |
| Season duration | 1–6 months | 3 months (balance engagement and fatigue) |
| TVL points share | 60–90% | 70% of total accrual |
| Trading points share | 10–30% | 20% of total accrual |
| Social points share | 0–10% | 5% maximum |
| Early entry multiplier | 1.5x–3x | 2x for the first month |
| Conversion vesting | 0–50% at TGE | 25–50% TGE, remainder over 3–6 months |
Points program checklist
Points vs Airdrop: When to Use What
| Factor | Points | Classic airdrop |
|---|---|---|
| Transparency for user | High | Low |
| Behavioral control | Fine-grained (multipliers, rates) | Coarse (snapshot) |
| Sybil defense | Better (quadratic models) | Worse (retrospective filter) |
| Implementation cost | Higher (backend, dashboard) | Lower (one snapshot) |
| Pre-TGE engagement | Continuous | One-time |
| Fatigue risk | Yes (with long programs) | No |
A points system is preferable when the protocol needs to retain TVL over months before TGE. A classic airdrop is sufficient for retroactively rewarding existing users.
Summary
A points system is an evolution of the airdrop that solves the problems of uncertainty, Sybil farming, and one-time incentives. Three key design decisions: accrual rate (how many points for which action), Sybil defense (quadratic model or thresholds), and conversion mechanism (open or closed, with vesting or without).
The main risk is dilution during long programs without fixed seasons. Solution: a seasonal model with a fixed allocation per period.
Designing a points program?
We've built points systems for DeFi, GameFi, and infrastructure protocols. We'll design your accrual mechanics, Sybil defense, and conversion strategy.
Get in touch