There is exactly one reserve a supply can produce.
The key that takes supply from k to k+1 costs k² / 16,000 SOL. Sum that staircase and the reserve after n keys is fixed. Because 1e9 / 16,000 is 62,500 exactly, the whole thing stays in integers — there is no rounding to argue about.
reserve(n) = 62,500 · (n−1)·n·(2n−1) / 6 lamports⚠ n is the supply before a sale, so the first key costs 0² / 16,000 — nothing. The reference protocol's documentation says after. Anyone implementing from that sentence over-quotes every trade by one full step of the staircase, and would never see it: the shape is right, the units are right, only the answer is wrong.
The staircase
| Supply n | Next key costs | Reserve at n | In lamports |
|---|---|---|---|
| 1 | 0.000062 SOL | 0.0000 SOL | 0 |
| 2 | 0.000250 SOL | 0.0000 SOL | 62,500 |
| 3 | 0.000562 SOL | 0.0003 SOL | 312,500 |
| 10 | 0.006250 SOL | 0.0178 SOL | 17,812,500 |
| 25 | 0.039062 SOL | 0.3062 SOL | 306,250,000 |
| 50 | 0.156250 SOL | 2.5265 SOL | 2,526,562,500 |
| 100 | 0.625000 SOL | 20.5218 SOL | 20,521,875,000 |
| 255 | 4.064062 SOL | 343.4159 SOL | 343,415,937,500 |
| 1,000 | 62.500000 SOL | 20,802.0937 SOL | 20,802,093,750,000 |
The fee has to add up
7% each way, split three ways. Rounding each share on its own leaves lamports on the floor, so the shares are apportioned by largest remainder and the identity holders + subject + protocol = fee holds for every input, including a fee of ten lamports.
Check it yourself: POST /api/quote returns the same split with a conserves field, and GET /api/curve?supply=250 returns the ladder above.