> For the complete documentation index, see [llms.txt](https://stonkmarket.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://stonkmarket.gitbook.io/docs/stonk-v3/launch-mechanics.md). # How a launch opens Three things decide what the first minute of a stonk token looks like: **when** it starts trading, **what it costs** to buy in that first second, and **who owns the ticker**. ## When trading starts | You launch… | Trading starts | | ------------------------ | ---------------------------------------- | | during NYSE market hours | **immediately**, in the same transaction | | outside market hours | at the **next opening bell** | That's the whole rule. There is no setting a creator can use to trade outside the window — the window is the product. Immediate launch is on by default in v3. In v2 every launch waited for the bell, which sounded fairer and mostly wasn't: the pool is created and funded with **publicly visible reserves** the moment you deploy, so a pending launch is a known price that anyone can prepare for. The bell then became a pure gas race into it. v3 attacks that race directly with the fee below, which is what makes the deployer's choice of moment no longer worth anything. A token also remembers its own first tradeable second for ever. Whatever it was given at launch is what it keeps; later configuration changes only reach future launches. ## What the first seconds cost **Buying in the launch second costs 99% of what you spend.** That decays to the pool's ordinary rate across three seconds: | Seconds after trading opens | an ordinary token | $market | | --------------------------- | ----------------- | ------- | | 0 | **99%** | **99%** | | 1 | \~7.1% | 9.0% | | 2 | \~1.2% | \~3.2% | | 3 and after | **1%** | **3%** | It decays to *that pool's own* rate, which is why the two columns differ — a 1% token lands on 1%, $market lands on its 3%. One schedule, two destinations, no special cases. ### Why a fee and not a block The 5% wallet cap bounds how much any one address can **hold**. It does nothing about how much the **first** address earns, and a bot running twenty keys clears a 5% cap without noticing. Making the first second expensive is the only thing that attacks the profit rather than the quantity. And it **prices** the race rather than blocking it. Nobody is locked out — a launch-second buyer still gets tokens, just materially fewer for the same money. **How much fewer, measured on chain rather than inferred from the rate:** | | spend | tokens received | effective price | | ---------------------------- | -------- | --------------- | ------------------ | | bought at second 0 (99% fee) | 100 USDG | 5,213,774.77 | 1.92 × 10⁻⁵ /token | | bought at second 7 (1% fee) | 100 USDG | 25,548,711.10 | 3.91 × 10⁻⁶ /token | So a sniper pays about **5x more per token** than someone who waited three seconds. Not 99x — and the difference is worth understanding, because it is not a shortfall in the mechanism. The fee really is 99% of the spend, so only 1 USDG of that 100 reaches the curve instead of 99. But a launch opens at the very bottom of its price curve, where tokens are cheapest, so that surviving 1 USDG buys disproportionately well. The curve's shape absorbs most of the fee's effect on quantity. Five times worse is still a real deterrent: a sniper needs roughly a 5x move just to break even against a buyer who waited. It is simply not the hundredfold penalty the headline rate implies, and you should size your expectations to the measured number. ### Where that money goes Nowhere special. The surcharge is the ordinary fee at a bigger number, so it runs through the same four-way split: **a tenth of what a sniper pays becomes permanent liquidity in the pool they just bought into**, and the rest reaches that launch's own creator, protocol and treasury. Nothing is burned and nothing is returned. ### Who's exempt Exactly one thing: **the launch transaction's own initial buy.** A creator's dev buy happens inside the deploy transaction, at second zero, and is never surcharged — it would otherwise pay 99% of the creator's own money. The hook recognises it by address, not by any list. There is **no team list**. An earlier revision let a creator name addresses exempt from the window; it was removed, because on a Uniswap v4 hook the exemption could only key on the address that *calls the pool* — the router — never on the wallet the tokens land in. Naming a wallet did nothing at all, silently, and naming a shared router exempted everyone who used it. No version of that feature worked the way a creator expects, so rather than guard it, it's gone. What that means in practice: a team member trading through any frontend pays the decaying rate like everyone else, and their tokens still arrive correctly. The window is three seconds, so waiting three seconds costs them nothing more than anyone else pays. ## Tickers: exclusive for 48 hours, then open A ticker belongs to its launch for **48 hours** — `EXCLUSIVITY_PERIOD`, 172,800 seconds on the [mainnet name registry](/docs/stonk-v3/deployments-mainnet.md#contracts). Inside that window nobody else can launch under it, case-insensitively. After it, anyone may reuse it. (The testnet stack documented in [Testnet Deployment](/docs/stonk-v3/deployments-testnet.md) predates the change and still holds a ticker for 24 hours; the period is a compile-time constant, so it is read per deployment, never set.) This is deliberate, and it is neither of the two things people expect: * **Not permanent.** One-of-one tickers for ever turns a naming system into a land grab, with squatters holding symbols they never used. * **Not reservable.** You cannot book a ticker in advance. You get it by launching. When several tokens have shared a ticker over time, **the newest launch is what a lookup resolves to**, and the full history of claimants stays on chain so a frontend can show every one of them. The protocol deliberately does not curate — picking which token "deserves" a ticker would be an admin power to pick winners. ## The wallet cap No single address may hold more than **5% of supply**. It applies to every inbound transfer, not just swaps, and a single swap also can't take more than 5% out at once. Burning is exempt — otherwise the common trick of "burning" by sending to a dead address would start reverting once that address crossed the cap, and the buy-and-burn couldn't work at all. {% hint style="info" %} The cap is a **distribution** rule, not anti-snipe protection. It's worth being clear about that: measured on a production config, traversing the opening price band takes roughly 46 distinct wallets — a number a bot operator reaches easily and a real crowd doesn't. That's why the decaying fee above exists. {% endhint %} --- # 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://stonkmarket.gitbook.io/docs/stonk-v3/launch-mechanics.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.