> For the complete documentation index, see [llms.txt](https://docs.unstable.run/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.unstable.run/under-the-hood/pool-and-price.md). # Pool & starting price Every Unstable launch spawns a fresh **Uniswap V3 pool** at the **1% fee tier**, paired against **USDT0**. The pool is initialised at a fixed tick that corresponds to a **\~$2,000 starting market cap**. ## Pool parameters | | | | --------------------------------------- | ------------------------------ | | DEX | Canonical Uniswap V3 on Stable | | Pair | `TOKEN / USDT0` | | Fee tier | **1%** (10,000 bps) | | Tick spacing | 200 | | Starting tick (assuming token = token0) | `-407,600` | | Starting market cap | \~$2,000 USDT0 | | Starting price | \~$0.000002 / token | | Initial liquidity shape | Single-sided (100% token side) | ## Why 1% The 1% fee tier is Uniswap V3's standard **long-tail asset tier** — the same tier every memecoin on mainnet, Base, and every other V3 chain uses. It: * Compensates LP holders for the volatility Unstable pools inherently have. * Is understood by every V3-aware aggregator, so nothing needs custom routing. * Is the fee tier bots and MEV searchers already scan by default. ## Why $2K starting mcap The anchor tick is picked to hit a **\~$2K starting market cap** — small enough that a genuine community can push it up meaningfully, big enough that day-one price impact isn't absurd. The math (assuming token has 18 decimals, USDT0 has 6 as ERC-20): ``` starting_price = $2,000 / 1,000,000,000 tokens = $0.000002 per token tick = ln(2e-6) / ln(1.0001) ≈ -407,553.72 snapped to nearest tickSpacing (200) → -407,600 ``` Because USDT0 has 6 decimals but the token has 18, there's a 12-decimal skew baked into the tick — which is why the number looks large compared to, say, ETH-quoted pools where the tick math lands around -196,000 at similar mcaps. ## The sign flip The launch tick constant `-407,600` assumes your token sorts as `token0` (address lower than USDT0). If your token's `CREATE2` address happens to sort as `token1`, the economic price is identical but the tick math flips sign — the pool initialises at `+407,600` in that case. Both are handled automatically by the factory: ```solidity bool tokenIsToken0 = token < address(USDT); int24 priceTick = tokenIsToken0 ? FIXED_TICK_TOKEN0 : -FIXED_TICK_TOKEN0; ``` You don't need to think about this — the result is the same $2K anchor either way. ## Single-sided liquidity The mint has one side of the pool loaded up (100% supply of tokens) and zero on the other side (USDT0). The position range is set from the anchor tick outward to the far usable bound, so: * The current tick sits at exactly the position's tickUpper — technically **out of range** by V3's definition. * `pool.liquidity()` reads as `0` at t=0. * The first trade — anyone buying with USDT0 — pushes the tick into the position's range and *activates* the liquidity. This is by design. A single-sided position means the deployer doesn't need to seed the pool with dollars — the pool's dollar side gets bootstrapped by the first buyer. See the [Fair-launch model](/under-the-hood/fair-launch.md) for why. ## The anti-grief tick check Because both the token address and the pool address are deterministic in advance (`CREATE2` on the token, plus V3 Factory's own predictable pool address derivation), someone could theoretically front-run your launch by initialising the pool at a hostile tick a few blocks before your transaction lands. The factory defends against this with an explicit tick check: ```solidity (, int24 initTick, ...) = IUniswapV3Pool(pool).slot0(); if (initTick != priceTick) revert PoolAlreadyInitialized(); ``` If the pool got initialised outside of your transaction — at any tick different from the intended anchor — the entire launch reverts with `PoolAlreadyInitialized`. You get your USDT0 back and can try again with a new nonce (the salt is per-deployer per-nonce, so retries produce a new address). ## What the first candle looks like Because the pool starts single-sided with `liquidity == 0` at the anchor tick, the very first trade — whether from an initial buy or a first sniper — pushes the tick into the position's range, activating liquidity and setting a "real" price. On the chart, this shows up as **one tall candle** spanning the entire tick range from the anchor down to wherever the first swap settled. Subsequent candles render normally. ## Next * [Optional initial buy](/launching-a-coin/initial-dev-buy.md) — how the 5%-cap swap interacts with the pool math * [Fees & creator rewards](/under-the-hood/fees-and-rewards.md) — where the 1% fee flows * [LP position lock](/under-the-hood/lp-lock.md) — where the position NFT ends up --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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, and the optional `goal` query parameter: ``` GET https://docs.unstable.run/under-the-hood/pool-and-price.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.