Anti-sniper descending fee
BSC produces a block about every 0.45 seconds, and blocks are built by a small number of
builders. Sniping bots buy new coins in the first blocks, often bundled with the launch itself.
zk-pad offers an optional descending fee to make that unprofitable. It is a port of Clanker
v4's ClankerMevDescendingFees (ZkPadMevDescendingFees).
How it works
-
At launch the total fee starts at a starting fee of up to 80%.
-
It decays parabolically to the ending fee (normally F) over a period of up to 120 seconds:
fee(t) = endingFee + (startingFee - endingFee) * (timeRemaining / secondsToDecay)^2 -
Swaps in the same second as the launch revert.
-
Timing is based on timestamps, not block numbers, because BSC block counts are meaningless at sub-second intervals.
-
After the decay period the module switches itself off, and every swap pays the normal F.
-
The hook only applies the module's fee when it is higher than the pool's normal fee.
-
The surcharge is split 25/75 between protocol and beneficiary, like the normal fee. So snipers who pay it end up funding the beneficiary.
Example
With startingFee = 50%, endingFee = 2% and secondsToDecay = 60:
| Seconds after launch | Total fee |
|---|---|
| 0 | swaps revert |
| 1 | ~50% |
| 15 | ~30% |
| 30 | ~15% |
| 45 | ~5% |
| 61 and later | 2% (F) |
Liquidity is frozen while it runs
While the module is operational, beforeAddLiquidity rejects every add, including the locker's.
This changes nothing in practice, because only the locker can add liquidity and it does so only
at launch.
The dev buy is not affected
The factory runs the creator's dev buy before the module is armed. The dev buy pays the normal fee F.
What zk-pad deliberately does not do
From the research in docs/research/launchpads.md:
- No gas-price sniper auctions. They depend on priority-fee ordering, which BSC builders do not follow.
- No block-delay trading locks. On BSC they just move the race to block N+k, and they need transfer restrictions in the token.
- No max-wallet, max-transaction, blacklist or
tx.originchecks. They are trivial to get around with many wallets in one bundle, and they would need owner powers.
Two other defences are on by default in the UI: the Fair liquidity preset (a thin launch band, see single-sided liquidity) and the atomic dev buy. The SDK can also submit launches through a private RPC so the launch is not visible in the public mempool.