# supply

Every basefun token has the **exact same** supply, distribution, and curve shape. No surprises per launch.

## Supply at a glance

|                                 | Tokens (1e18) |      % |
| ------------------------------- | ------------: | -----: |
| **Total supply**                | 1,000,000,000 |   100% |
| Sold on the bonding curve       |   757,500,000 | 75.75% |
| Reserved for the Uni V2 LP seed |   242,500,000 | 24.25% |

No team allocation. No vesting schedule. No private round. **No mint function after deploy.**

## Curve math

`BondingCurveV2` is a constant-product AMM with synthetic ("virtual") reserves preloaded so it has a non-flat starting price.

```
x_total = VIRTUAL_USDC ($4,000)        + getReserveUSDC()        // 1e6 USDC
y_total = VIRTUAL_TOKENS (303,000,000) + (CURVE_SUPPLY − sold)   // 1e18 tokens

spot   = x_total × 1e18 / y_total       // USDC per token (1e-18)
mcap   = x_total × TOTAL_SUPPLY / y_total
```

At launch (`reserve = 0`, `sold = 0`):

```
x_total = 4_000e6
y_total = 303e6 + 757.5e6 = 1,060.5e6 (tokens, scaled 1e18 internally)
spot    ≈ $0.0000038 per token
mcap    ≈ $3,773
```

After the mandatory $20 initial buy:

```
post-init reserveUSDC ≈ $19.80   (minus the 1% fee taken inline)
mcap                  ≈ $3,800
```

At graduation (`reserve = $10,000`, all 757.5M sold):

```
mcap on curve view ≈ $13,201
```

(The "$13k" figure reflects that the curve's `marketCapUSDC()` view uses the AMM formula, not raw post-grad spot. The actual post-migration Uni V2 MC immediately afterwards is exactly $40,000 — see [Graduation](broken://pages/e1a79172ce27b0d523971b8e024e6781f2480f07).)

## Why the virtual reserves are sized the way they are

The identity below is enforced by construction:

```
VIRTUAL_USDC × CURVE_SUPPLY = VIRTUAL_TOKENS × GRADUATION_USDC
4_000e6      × 757_500_000  = 303_000_000_000_000_000_000_000_000 × 10_000e6
                            = (both equal 30,300,000,000e30)
```

This means: if buying drives `tokensSoldFromCurve` all the way to `CURVE_SUPPLY`, the implied USDC reserve required is **exactly** `GRADUATION_USDC` ($10k). The two graduation conditions (`reserve ≥ $10k` OR `sold ≥ 757.5M`) hit simultaneously in the no-perp-PnL case.

In practice the LT's NAV moves independently, so the reserve can hit $10k with tokens still left, or vice-versa — whichever happens first triggers `_maybeGraduate`.

## Per-trade pricing

Pre-bond a buy of `usdcAmount` produces:

```
netUSDC   = usdcAmount × 99 / 100       (1% fee in USDC)
newY      = (x_total × y_total) / (x_total + netUSDC)
tokensOut = y_total - newY
```

And a sell of `tokenAmount`:

```
newX     = (x_total × y_total) / (y_total + tokenAmount)
usdcGross = x_total - newX
usdcOut  = usdcGross × 99 / 100         (1% fee in USDC)
```

The web app replicates these two formulas in TypeScript so `minOut` quoted to the wallet matches what the contract will actually return — to the wei.

## How big a buy moves the price

Rough table at the launch floor (`reserve = 0`, full virtual reserves):

| USDC in  | Tokens out                 | Implied price impact     |
| -------- | -------------------------- | ------------------------ |
| $20      | \~5.2M                     | minimal                  |
| $100     | \~25.8M                    | \~2.5%                   |
| $1,000   | \~248M                     | \~25%                    |
| $5,000   | \~707M                     | \~80% (close to sellout) |
| $10,000+ | capped at remaining supply | triggers graduation      |

Buys that would over-mint are auto-capped: the contract sets `tokensOut = remaining` and leaves the unspent USDC inside the curve to settle in the same tx.

## Post-grad supply

After migration:

* 242.5M tokens are locked inside the Uni V2 pair, paired with $9.7k USDC.
* The LP token (the Uni V2 ERC-20 receipt for that liquidity) is held by `0x000…dEaD` — burned. **No one can ever pull liquidity.**
* The rest of the supply (757.5M − fee skim − etc.) sits in real wallets that bought during the curve phase.

The total supply (1B) is unchanged. The circulating supply is essentially the full 1B minus what's currently inside the pair (locked) and the dead address (LP burn).


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://basefun.gitbook.io/basefun-docs/supply.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.