Funding Parameters
Supply Split
| Symbol | Definition | Constraint |
|---|---|---|
| R_reserve | Creator / dev / author reserve, as a share of total supply | Meme ≤ 2.9% · APP/ICM ≤ 29% |
| R_raise | Share of supply sold through the auction | > 0 |
| R_pool | Share of supply seeded into the initial DEX pool | > 0 |
| totalSupply | Fixed total token issuance | 10^11 tokens |
R_reserve + R_raise + R_pool = 100%
Enforced on-chain as an invariant at creation. No combination that violates it can be finalized.
Derived Quantities
Let FDV be the protocol-fixed internal fully-diluted valuation, expressed in BNB with 18-decimal fixed-point precision. For this migration reference it is 8.9749059457782259 BNB, identical for every project in that parameter version. Values rounded in charts are for display only.
V_target = FDV × R_raise
A_max = FDV × 2% = 0.179498118915564518 BNB
V_targetis the BNB amount that must be effectively raised for the round to clear.A_maxis the maximum BNB that any single address may have counted toward that target, regardless of how much it deposits.
The Token Pool
The number of tokens distributed through the auction is tokenPool = totalSupply × R_raise, and each address's allocation is a direct linear function of its effective contribution:
token_i = tokenPool × e_i / V_target
Because e_i ≤ A_max by construction, no address can receive more than A_max / V_target of the token pool. The prior specification also calls for a 2% per-address limit across reserve, raise and pool allocations. The BSC implementation must define the relevant recipient, reserve-custody and pool-contract treatment before claiming this additional rule is enforced. Neither address-level rule establishes distinct human ownership.
What Amax Does Not Scale With
It is a fixed fraction of FDV, not of the round's target. A project with a small R_raise has a small V_target but the same approximately 0.179498119 BNB ceiling — so a smaller raise needs proportionally fewer addresses to clear, and a larger raise needs more.