Supply & community allocation.
One initial supply. Three purposes. No double counting.
In this guide
Divide the initial supply
S = initial supply
R = community reserve
C = curve sale allocation
L = graduation liquidity allocation
S = R + C + L
R = S × reserve_basis_points / 10,000The creator’s percentage refers to initial supply. Rewards are minted at creation, withheld from sale, and committed to campaign claims. Trading changes who holds tokens; it does not issue a fresh reward supply.
| Destination | Tokens | Share |
|---|---|---|
| Community reserve | 50,000,000 | 5% |
| Curve sales | 760,000,000 | 76% |
| Graduation liquidity | 190,000,000 | 19% |
| Initial supply | 1,000,000,000 | 100% |
This example assigns 80% of the non-community supply to sales and 20% to liquidity. A selected engine may require a different split. There is no additional creator allocation in this baseline; adding one requires a fourth disclosed bucket.
Try the reward math
Change the community share and winning-wallet count. This example uses one billion tokens, six decimal places, equal awards, and an illustrative 20% initial release followed by 30 days of linear vesting. Day zero means the release gate has already opened.
- Vested per wallet
- 40,000
- Still locked per wallet
- 160,000
- Unallocated division dust
- 0
20% initial release + 30-day linear vesting. Assumes no previous claims, so vested equals claimable. Six decimal places. Slider limits and schedule are examples, not protocol limits.
Count every base unit
Contracts calculate amounts in integer base units. One basis point is 0.01%. The reserve must be exactly representable, or the rounding rule and resulting amount must be disclosed before signing. Award division rounds down; the leftover is residual dust, not a hidden creator payment.
award = floor(reserve / eligible_winning_wallets)
awarded_total = award × eligible_winning_wallets
dust = reserve − awarded_totalReject configurations where a meaningful award cannot be represented. The advertised reward total cannot exceed the secured reserve. A 100% community allocation leaves no token inventory for this trading model.
Allocation limits belong to the launch terms
The permitted reserve range, total supply, decimals and sale/liquidity split depend on the chosen engine and RalliPad’s published policy. The calculator’s ranges are teaching controls. The creator form’s inputs are configuration choices, not proof that a blockchain engine accepts those values.
Changing the reserve changes inventory available to the curve. Virtual reserves, sale size and migration-price assumptions must be recalibrated together. Historical parameters from another launchpad cannot simply be reused after subtracting community tokens.