Sniper Protection
An optional launch setting (sniperProtected: true) that limits how much of the supply any single wallet can hold during the first 10 minutes after launch, aimed at blunting bot-driven wallet concentration in the seconds right after a pool goes live.
How it works
Limits are enforced as a max wallet balance, computed as a percentage of total supply, and step down over three windows measured from the moment the token contract was created:
| Time since launch | Max wallet balance |
|---|---|
| 0 – 60 seconds | 0.3% of supply |
| 60 – 180 seconds | 0.75% of supply |
| 180 – 600 seconds (10 min) | 1.5% of supply |
| After 600 seconds | No limit, disabled permanently |
The limit applies to the resulting balance after a transfer, not the transfer size, so require(balanceOf(to) + amount <= maxWallet). A wallet that already holds tokens can still receive more as long as its new total stays under the current window's cap. The pool manager itself is exempt (otherwise sells into the pool would be impossible).
Once the 10-minute window passes, limits switch off permanently. There's no way to re-enable them, and no admin lever to extend the window.
Interaction with holder rewards
Sniper protection and holder rewards are independent settings, but they're implemented as combined contract variants under the hood: the factory picks the right token contract automatically based on which flags you set:
hasRewards | sniperProtected | Contract deployed |
|---|---|---|
false | false | Standard ERC20 |
false | true | Anti-sniper ERC20 |
true | false | Reward ERC20 (dividend distributor, no sniper limits) |
true | true | Reward ERC20 with sniper limits |
You don't choose the contract directly, just set hasRewards and sniperProtected in DeployParams and the factory routes to the right deployer.
Should you enable it?
It's a tradeoff: sniper protection makes early bot accumulation harder, but it also caps how much any legitimate buyer (including a whale who wants in early) can hold in the first 10 minutes. For most standard launches this is a reasonable default; for launches expecting a large single early buyer (e.g. a coordinated community buy), it's worth considering leaving it off.