Eligibility rules

Each cycle, the bot snapshots holders, picks a market-cap tier, and builds the list of wallets that receive a proportional airdrop. Every rule below must pass in the same cycle.

Hold cycles vs hold fund: holdCycles in the tier table is an eligibility streak for holders. Hold fund transparency is separate - it explains the creator's fee-split hold % reserve (dashboard / token page / Stream Studio), not wallet eligibility.

eligibility calculator. Same logic as the engine, no auth, no login. Source on GitHub.

1. Holder snapshot (Helius DAS)

On each mainnet cycle the bot calls getTokenAccounts on your RPC (Helius DAS) with pagination (up to 50 pages, 1000 accounts per page). Balances are aggregated per wallet owner.

All token thresholds in the dashboard and the tier table are expressed in whole tokens - the numbers you would see on Pump.fun or in a wallet UI. The bot converts to base units internally before comparing on-chain balances.

2. Hard exclusions

These addresses never receive a public airdrop:

Dev wallet (creator / fee payer)
Token mint address
System and SPL program accounts (Token program, Token-2022, ATA program, etc.)

3. Market-cap tiers

Market cap (USD) is fetched from DexScreener:

GET https://api.dexscreener.com/latest/dex/tokens/{mint}

No API key. Results are cached about 30 seconds. Pump.fun pair is preferred; PumpSwap pair is used after graduation.

The bot picks the tier with the highest mcUsd that is still less than or equal to the current market cap. That tier's minTokens is the floor for this cycle.

If market cap is unknown, the bot falls back to minHolderBalance.

Default tier table (new projects)

MC ≥ (USD)	Min tokens	Hold cycles
0	500,000	5
50,000	450,000	6
100,000	400,000	8
250,000	300,000	10
500,000	220,000	12
1,000,000	150,000	15
2,500,000	110,000	22
5,000,000	75,000	30
10,000,000	55,000	40
15,000,000	40,000	50
25,000,000	30,000	60
50,000,000	22,000	80
100,000,000	15,000	100

Edit rows in the dashboard Eligibility tiers table (MC, min tokens, hold cycles), then click Save tiers. Tiers are sorted by MC; duplicate MC values are deduplicated. The legacy global holdCyclesRequired field is ignored.

4. Anti-whale cap

maxHolderBalance (default 20,000,000 tokens) excludes wallets that hold more than the cap. Set to 0 to disable.

This only affects the public proportional drop, not dev or program accounts.

5. Hold cycles (per tier)

Each tier row has holdCycles. A wallet must meet the active tier minimum for that many consecutive cycles before it receives tokens. Higher MC tiers require longer streaks (anti-sybil).

If balance drops below the floor, the streak resets.
holdCycles = 1 on a tier - eligible immediately when balance qualifies (no streak).

History is stored per project in the cloud database between cycles.

6. Proportional split

After buyback, 100% of bought tokens (cloud) are split across final eligible holders in proportion to their balance. Larger bags receive larger drops.

Very small allocations may be skipped when below rent-exempt ATA creation cost.

7. Holder perks (optional)

These features are opt-in per project. They do not replace tiers, hold streaks, or anti-whale rules unless noted.

Holder reward choice

When holderRewardChoiceEnabled is on, eligible holders may save a payout preference (project token, SOL, or USDC) on the token page. Eligibility is unchanged - snapshots and weights still use your project mint. At payout time the engine splits the cycle budget across cohorts by saved preference; wallets without a preference use the dev default from rewardAsset.

When socialClaimEnabled is on, anyone can claim a 1-hour boost (default socialBoostDurationMin: 60) by posting on X and submitting the post URL plus one wallet on the token page. Full rules: X post boost configuration.

Claim rules

One post URL per token, forever (global) - the same X link cannot be claimed twice on this project. First valid claim wins; any wallet reusing the URL gets 409.
One active claim per wallet per token - while your boost hour is running on this token, that wallet cannot claim a second post here. After it ends, use a new post URL. Other tokens are unaffected.
Different wallets - each wallet can claim its own post on the same token (each URL still once).
Active for 1 hour (by default) from claim time - every airdrop cycle in that window can apply the boost.
New boost = new post - after the window ends or after payout, use a fresh X post and a new URL.
No SIWS - boost claim does not require signing with Phantom (unlike holder reward choice).

Effect after hold-cycle gate

Social boost never changes eligibility_history or hold streaks. It only adjusts who receives tokens in cycles while the boost is active:

Eligible holders (balance, cap, and hold streak all pass) get a larger proportional slice: socialHolderBoostMultiplier (default 1.15x).
Everyone else (no tokens yet, below tier floor, anti-whale excluded, or hold streak not met) can still receive a small intro airdrop with virtual weight = socialNonHolderWeightRatio x tier minTokens (default 8% of the active tier floor). They are paid in the dev default reward cohort only (socialOnly) - not via holder reward choice.

A holder who holds enough tokens but has not finished the hold streak is not treated as a full eligible holder for boost math until the streak passes - they follow the intro path until then. Payouts use the same creator-fee pool as normal drops.

API: Holder perks API.

Worked example

Market cap = $400k, tier at $250k applies (min 300,000 tokens, hold cycles = 10). Wallet A holds 400,000 tokens and has been in band for 10+ cycles - A receives a share. Wallet A with only 3 consecutive cycles is gated until the streak reaches 10. Wallet B holds 1,000,000 tokens but max holder is 20,000,000 - B is still under cap. Wallet C holds 25,000,000 tokens - excluded by anti-whale.

Configuration reference