Dev buy and snipe defence
A fresh pool is the most sniper-exposed moment in a coin's life. NASDANK's answer is to give the creator the first trade inside the launch transaction itself, and — separately — to let a creator pre-announce the contract address so the launch is not a surprise to their own community.
The problem
Two distinct attacks live in the first seconds of a launch, and they need different answers.
Front-running: solved structurally
The pool is created and initialised inside the launch transaction. There is no block, and no moment, in which the pool exists at an unset price. Nobody can set your opening price but you.
This is the strongest guarantee on this page, and it costs nothing — it is a consequence of the atomic design described in Launch mechanism.
Sniping: mitigated by the dev buy
If you set a dev buy amount, the launcher performs the swap in the same transaction, against the pool it just created, before the pool is reachable by anyone else.
- Pool is created and seededStill inside your transaction. No external actor has had a turn.
- Your buy executesGas token in, coin out, at the opening price.
- Change is refundedAnything not spent comes back to you in the same transaction. No stuck balance, no dust.
- The transaction endsOnly now is the pool visible and tradable by anyone else.
You are not competing on gas price with a bot. Your buy is inside the same call that creates the market, so it is unconditionally first.
After your transaction confirms, the pool is public and ordinary. A well-capitalised bot can still take the second, third and fourth trades. What the dev buy guarantees is that it cannot take the first.
Where it is available
On every launch that is paid for in the gas token — which is every launch except one.
| Launch | Dev buy |
|---|---|
| Pro · V3, plain | Yes |
| Custom · V4, plain | Yes |
| Custom + holder rewards | Yes |
| Custom + a vault (Fee, Portfolio, Dividend) | Yes |
| Custom + auto-disperse rewards | Yes |
| Pre-announced address | Yes — but type it before pressing Generate |
| Paired against a custom token | No |
The pair launchers are not payable: their creator buy is denominated in the pair token and pulled with transferFrom, not sent as ETH. So the ETH dev-buy field is refused there rather than taking a number the transaction cannot spend. Launch against the gas token if you want a dev buy.
Pre-announcing is two steps: Generate address mines the salt, then Deploy at the generated address becomes available. Editing any field after generating — including the dev buy — invalidates the mined salt and disables Deploy again. Fill everything in, then generate, then deploy.
Sizing it
There is no free lunch here. A dev buy is a real purchase at the opening price out of the pool you just seeded, so a bigger dev buy means a higher entry price for everyone after you and a larger share of supply in one wallet — which is visible on chain and which holders will notice. Nothing in the protocol restricts the size; the constraint is reputational.
Pre-announced contract addresses
A separate problem: you want to post the contract address before the launch so your community can be ready, but a normal deploy's address is not known until it happens.
Salted launchers solve this with CREATE2. A salt is mined off-chain such that the resulting address is known in advance, then passed into the launch. You get the real address ahead of time and can announce it. In the Studio this is two presses: Generate address, then Deploy at the generated address.
| Available on | What is previewed |
|---|---|
| Pro · V3 | The token address and the pool address, so a chart link can be posted too. The dev buy is preserved. |
| Custom · V4 | The token address. |
Pre-announcing is served by dedicated salted launchers, and picking it can change which tier your launch actually uses. The summary panel is read from the same code the transaction uses — if it says Custom and you meant Pro, stop and fix it there.
PancakeSwap deploys its V3 pools from a separate PoolDeployer contract with its own init-code hash, not from the factory. Deriving a pre-announced pool address from the factory produces an address no pool will ever occupy. If you are computing these yourself on BSC, use the pool deployer and Pancake's init-code hash.
The trade-off nobody mentions
Announcing the address early is also announcing it to the snipers. You are trading "my community is ready at T+0" against "so is everyone else's bot". The dev buy is what makes that trade survivable: announce the address, and take the first fill yourself inside the launch.
What NASDANK does not do
- No anti-bot blocklist. The token is a standard ERC-20 with no transfer hooks that could refuse an address. That is a deliberate choice — a token that can refuse transfers is a token that can be made to refuse yours.
- No launch delay or trading-disabled period. Trading opens in the same block. A disabled-trading window is another owner power, and an owner power is a rug vector.
- No max-wallet or max-transaction limit. Neither tier ships one.
- No private mempool. Your launch transaction is an ordinary public transaction.
The design position is that the guarantee worth having is the one that comes from the transaction being atomic, not from a set of owner-controlled restrictions that also constitute a set of owner-controlled risks.