The pons snipe tax window is three seconds, not five

A bot watching for new curves can buy the opening before anyone else knows the launch exists, then sell into the people who arrive a minute later. The tax makes being first unprofitable: at 99% almost nothing of the spend reaches the curve, and by the time the rate has decayed to something reasonable, ordinary buyers have arrived.

It applies to buying only. Selling is never taxed by it, at any point in the window.

The curve is exponential, so it falls fastest at the start. Roughly a quarter of the spend is still taken one second in, around three percent at two seconds, and nothing by the end of the window.

What that means in practice: an entry two seconds late is nearly free of tax, and an entry at eighteen blocks — which is what happens when code waits for a receipt before signing — is completely outside it. In one of our own early runs the rate had already fallen to nineteen basis points by the time the buys landed. The protection was doing nothing for anyone, including the people it exists to stop.

Two values matter and both are readable: snipeTaxStartBps returns 9900, and snipeTaxSeconds returns 3. Each launch takes its own copy of the terms at creation, so a curve already trading keeps what it launched under and cannot have the window changed underneath it.

For quoting a specific trade, currentSnipeTaxBps is keyed on the recipient of the tokens rather than the sender. A router asking on behalf of a wallet has to ask about that wallet, not about itself.

Whatever the tax takes joins the launch's trading fee and is distributed the same way. Value a would-be sniper gives up flows back into the launch rather than out of it — which is a more elegant design than simply blocking the transaction.