Pons Anti-Snipe Tax Explained: How the 99% Decay Mechanism Works

What is the Pons anti-snipe tax?

The Pons V2 anti-snipe tax is a temporary buy tax applied to a token's bonding curve during the opening seconds after launch. It removes the financial advantage of being the very first buyer, which is normally the entire point of running a sniper bot against a new launch.

Every Pons V2 launch deploys through an atomic launchAndBuy transaction, so the token, its bonding curve and the creator's own opening purchase all land in a single transaction. Anyone trying to buy immediately after does so into a curve that already has the tax active, rather than into an empty, undefended opening block.

On-chain, the mechanism emits its own events: SnipeTaxCharged when a buy is taxed, and SnipeTaxExempted when a buy skips the tax because the buyer qualifies for an exemption. Both are readable directly from the bonding curve contract, which makes the tax auditable rather than something creators or traders have to take on trust.

How the 99% decay curve works

The tax does not switch off all at once. It decays on a fast exponential curve across a short fixed window, generally described as five seconds from deployment.

• Instant, at the moment of deployment: buy tax is roughly 99%.
• About one second after launch: tax has fallen to roughly 25%.
• Two to four seconds after launch: tax keeps decaying toward zero.
• Five seconds after launch: tax has fully expired at 0%.

Why Pons uses a tax instead of a wallet cap

The practical effect of the decay schedule above is that a buy submitted in the same instant as deployment loses almost the entire trade to the tax, while a buy submitted a few seconds later trades on effectively normal terms. This is deliberately different from a flat tax or a hard cooldown: it lets trading start immediately for anyone willing to wait even a couple of seconds, without locking the curve entirely.

A wallet cap - limiting how much supply any single address can hold or buy in the opening blocks - was the approach Pons V1 used. It works, but it has a known workaround: split the buy across multiple wallets. A tax does not have that weakness, because it applies to the trade itself rather than to the identity of the wallet placing it.

Splitting a snipe attempt across ten wallets under a decaying tax does not help; each of those ten buys still lands in the same taxed window and pays the same schedule. This is the main reason V2 moved from caps to a tax-based model, and it is also why generic multi-wallet sniper tooling built for other launchpads does not transfer cleanly to Pons V2 - the usual split-across-wallets edge is designed out.

Who is exempt from the tax

The creator's own wallet is exempt from the anti-snipe tax on the launch it deploys. This is what makes the atomic developer buy inside launchAndBuy practical: the creator's opening purchase executes in the same transaction as deployment, at the moment the tax would otherwise be at its highest, and is not charged it.

This exemption is scoped to the creator wallet on its own launch - it is not a general allowlist, and it does not extend to other wallets participating in the same launch unless those wallets are the creator wallet itself. Any additional wallet buying alongside the creator, including wallets in a coordinated bundle, is still subject to the same decaying schedule as an unrelated trader.

Pons V1 vs Pons V2 snipe protection

Pons V1 relied on wallet caps: no wallet could hold more than 5% of supply or buy more than 5.5% of supply, enforced for the first two blocks after launch. Pons V2 replaced this with the decaying tax described above.

• Mechanism: V1 used per-wallet supply caps; V2 uses an exponential decay tax that starts near 99% and reaches 0% by five seconds.
• Splittable across wallets: V1's caps could be routed around by spreading a buy across several wallets; V2's tax applies per trade regardless of how many wallets are used.
• Creator exemption: V1 had no built-in creator exemption; V2 exempts the creator wallet on its own launch.
• Duration: V1 enforced its caps for two blocks; V2 runs on a fixed five-second timer.

What the anti-snipe tax does not protect against

The tax is specifically an opening-seconds mechanism, and it is worth being clear about its limits.

• It does not prevent a buyer from waiting out the five-second window and then buying immediately after - this is expected, normal behavior, not an exploit.
• It does not guarantee the creator's buy executes first in a strict ordering sense - Robinhood Chain orders by arrival with no gas auction, so the tax removes the incentive to race rather than acting as a formal ordering guarantee.
• It does not protect against risks unrelated to opening-second sniping, such as impersonation of a token's name or symbol, or a creator setting an unusually high creator tax within the protocol's allowed cap.

Planning a launch around the snipe window

Because the tax decays on a fixed timer rather than a block count, there is nothing for a creator to configure about the schedule itself - it is a factory-level parameter, not a per-launch setting. What a creator can plan for is everything around it.

• Confirm the developer buy amount before deployment, since it executes atomically inside launchAndBuy and cannot be adjusted mid-transaction.
• Decide in advance whether any additional wallets will buy in the opening seconds, knowing they will pay the decaying tax like any other buyer.
• Treat the live tax rate as a signal when trading an existing token in its first few seconds - a bonding curve interface that surfaces the current tax lets you judge whether an early trade is worth its cost.

FAQ

• Does the anti-snipe tax apply to selling? No - it is a buy-side mechanism only, applied to purchases made in the opening seconds of a launch.
• How long does the anti-snipe tax last? Approximately five seconds from the moment a token deploys, falling from roughly 99% toward 0% on an exponential curve.
• Is the creator's opening buy taxed? No - the creator wallet is exempt on the launch it deploys, which is what allows the developer buy to execute at full value inside the same atomic transaction as deployment.
• Can the tax be avoided by using multiple wallets? No - unlike Pons V1's wallet caps, the V2 tax applies per trade rather than per wallet, so splitting a buy across several wallets does not reduce the total tax paid.