← blog · 2026-10-18 · 8 min read

Pons launchpad explained: snipe tax and exempt wallets

How the Pons launchpad on Robinhood Chain works: the 99% anti-sniping tax, how it decays, the 32-wallet exemption list and how to spot it being abused.

Pons is the bonding-curve launchpad on Robinhood Chain, and traders often call it "the pump.fun of Robinhood Chain". Its V2 contracts include a sensible anti-bot feature: a 99% tax on buys in the opening seconds of a launch. They also let a creator exempt a list of wallets from that tax. In September, an on-chain analyst linked a list of extractions that mostly came from Pons V2 launches, and the creators of those launches had used the exemption list to give their own wallets the opening of the curve.

This post covers how the Pons launchpad works, how the tax decays, what the exemption list does, why it can be abused, and what you can check before you buy. Everything here comes from Pons's own documentation, Bitquery's Pons API guide and The Block's reporting. For the wider context of how memecoins trade on the chain, start with our Robinhood Chain memecoins guide.

How a Pons V2 launch works

According to Bitquery's guide, every Pons V2 launch mints a fixed supply of 1 billion tokens directly into that token's own bonding-curve contract. Traders buy from and sell to the curve, not a DEX. When the curve has taken in its graduation threshold (4.2 ETH for an ETH-quoted launch), it is swept and the proceeds seed a Uniswap v4 pool behind the Pons meme hook. That liquidity position is permanently locked. Creators can also quote a launch in USDG, cbBTC or a tokenized stock such as TSLA or NVDA instead of ETH.

Two details matter for the rest of this post:

• Five-sevenths of supply is sold on the curve. Whoever buys the curve early holds most of the tradeable supply.
• Launch and first buy can happen in one transaction. Pons has a launch-and-buy router so a creator's first buy can't be front-run.

The locked liquidity is a real strength. On a Pons V2 token the classic "pull the LP" rug is not possible, because the position sits in the Pons locker contract. Bitquery reports that across every graduated token, neither the position nor the locked supply has ever left the locker. The risk on Pons is not the pool vanishing. It is who holds the supply when the pool opens.

The anti-sniping tax and how it decays

Pons's docs explain the problem plainly: a bot watching for new curves "can buy the opening of one before anybody else has seen it exists, then sell into the people who arrive a minute later". The fix is a tax on buys only, never on sells, that starts at 99% of the buy and decays to zero.

The docs describe an exponential decay over the first 5 seconds: "near 25% one second in and around 3% at two seconds." Bitquery's guide gives the formula from the contracts, where the starting rate is halved on a fixed schedule. It reports that at the factory's current settings (a 9,900 bps start and a 3-second window) the tax is 99% in the launch second, about 6.2% in the next, about 0.2% in the one after, and then zero. The two descriptions differ in detail. Both settings can be changed by the factory owner, and each launch takes a copy of the terms in force when it was created, so older and newer curves can decay differently. Either way, the window is a few seconds long and it is steep.

The tax is not burned. Pons says it "joins the launch's trading fee and is distributed the same way", so value a sniper gives up stays with the launch.

How exempt wallets work

Pons's docs say a creator is "never a sniper on their own launch." The launching address and the creator fee recipient are exempt automatically. On top of that, the launchToken function has a version that accepts a list of extra exempt addresses, "for a team bundling its opening buys across several wallets". The rules:

• At most 32 extra addresses. A longer list makes the launch revert.
• Fixed at creation. No address can be added later.
• Keyed on the recipient. The tax check looks at the wallet that receives the tokens, not the one that sends the transaction.

Bitquery notes that each exemption emits a SnipeTaxExempted event inside the launch transaction, so anyone can recover a launch's exemption list from its own transaction hash.

Why that's a loophole

The tax makes the first seconds of a launch unprofitable for everyone except the creator and up to 32 wallets the creator picks. Nothing in the contract checks that those wallets belong to a real team, or limits how much they can buy. So a creator who wants the opening of their own curve can spread it across 30-odd wallets that look independent, and the tax that stops outside bots does not touch them.

That is what The Block found. On 27 September 2026 it reported that a pseudonymous analyst, Wazz, linked at least $18.43M of extractions from 53 launches between 10 July and 21 September to one operation, and said most of the tokens were launched through Pons V2. The Block did not independently replicate the $18.43M total. What it did confirm on-chain:

• It matched all 10 Pons V2 launches in Wazz's table.
• In the nine launches from late August onward, the creator's launch transaction exempted 15 to 25 wallets. One to three blocks later, a single transaction bought tokens for every one of them, emptying the bonding curve straight into the Uniswap v4 pool.
• After those opening transactions, the creator and the exempt wallets held 82% to 86% of supply.
• In one launch The Block traced, DEED, the wallets started selling one second after launch.

To be fair to Pons: The Block's reporting doesn't say the contracts were exploited or that Pons was involved. The exemption feature worked as documented. Pons publishes how it works, and the exemptions are visible on-chain. The Block says it contacted Pons and Robinhood for comment. The loophole is in the design choice, not a bug: an anti-sniper rule with an opt-out the creator controls can't protect buyers from the creator.

How to spot it

None of these checks proves intent on its own; teams do bundle legitimately. Together they show who held the supply before you could buy.

1. Exempt wallets in the launch transaction

Open the token's launch transaction and count the SnipeTaxExempted events. Zero or two (the launcher and the fee recipient) is the solo-creator case. A list of 15, 25 or 31 means the creator planned a multi-wallet opening.

2. Launch-block buys

Look at curve buys in the first few blocks. In the launches The Block examined, one transaction bought for all the exempt wallets at once, one to three blocks after launch.

3. Synced buys

Several fresh wallets buying near-identical sizes, at the same moment, from the same funder is the same signature our SYNCED BUYS tag looks for on fomo.family. The rules are in synced buys, empty pools and copycat tickers. In the DEED case The Block traced, one wallet sent ETH to 50 addresses in one batch 40 minutes before launch, and the recipients included the creator and the other 24 exempt wallets.

4. Deployer history

The operation Wazz described was linked largely by money flow: "the proceeds of one launch pay the key that funds the next." Check what else the creator and its funder have launched, and how those tokens ended up. Wazz's list also included three launches each named CRUMBS, PINK and DEED within about a day of one another, so a repeated ticker from related wallets is a warning sign. Our DEPLOYER tag marks launchers whose earlier tokens included a honeypot or several rugs.

What hoodwatch shows, and what it doesn't

Paste any Robinhood Chain contract into /scan for the contract, liquidity, holder and market checks, and browse recent reports at /scans. The live tape carries the SYNCED BUYS, DEPLOYER, COPYCAT and EMPTY POOL tags on tracked fomo.family trades. Reading the hoodwatch tape explains each one.

Be clear about the limit: hoodwatch does not currently read Pons exemption lists. If a token's top holders came out of an exempt-wallet opening, the holder concentration on a scan will show it, but the exemption itself you have to read from the launch transaction or a Bitquery query.

FAQ

What is the Pons launchpad? A token launchpad on Robinhood Chain. Each V2 token starts on its own bonding curve and graduates to a Uniswap v4 pool with permanently locked liquidity once the curve takes in its threshold (4.2 ETH for ETH-quoted launches).

How does the Pons snipe tax work? Buys in the first few seconds of a launch pay a tax that starts at 99% and decays to zero. Pons's docs describe a 5-second window. Bitquery reports the factory's current settings as a 3-second window. Sells are never taxed, and the tax collected goes to the launch's fee distribution, not to a burn address.

Who is exempt from the Pons anti-sniping tax? The launching address and the creator fee recipient, automatically, plus up to 32 more addresses the creator names at launch. The list can't be changed after launch.

Is Pons a scam? No evidence we've seen says so. The Block's reporting concerns creators who used a documented feature, not a flaw in Pons's contracts, and Pons's locked liquidity rules out the LP-pull rug. Judge each token on its own launch.

How can I see a launch's exempt wallets? Every exemption emits a SnipeTaxExempted event in the launch transaction. Open that transaction on a block explorer, or use Bitquery's Pons API guide to query it.

Does a big exemption list mean a token is a rug? No. It means the creator planned a multi-wallet opening. Check what those wallets did next, who funded them, and the deployer's history before drawing any conclusion.

This post explains mechanics and public reporting. It is not financial advice.

hoodwatch.dev is unofficial and read-only, not affiliated with fomo.family or Robinhood. Nothing here is financial advice. Open the live tape.