📚 Documentation

What PONSv2 Sniper does, what every filter means, and why the defaults are what they are.

Overview

PONSv2 Sniper watches wallets on Robinhood Chain and acts on what they do. It runs two kinds of task, and the difference is what the watched wallet is doing:

• Wallet snipe — the watched wallet launches a token, and the task buys that launch in the same second it happens.
• Copy trade — the watched wallet buys a token that already exists, and the task copies the buy.

They read different feeds and are judged by different filters, so a task is one or the other and cannot be switched after it is created.

Almost every default in this product is a replayed measurement rather than a round number. Where that is the case, the hint next to the field says what was measured and on what. If a default looks arbitrary, check the hint before changing it — several of the obvious adjustments (a tighter stop, a turnover-based daily limit) were tried and were worse.

Shadow mode

When the amber Shadow mode banner is showing, the engine does everything except send: it reads the feed, evaluates every task, decides, and writes the decision to the journal — but no transaction is built and no funds move. Positions recorded in this mode are what the engine would have entered.

This is the intended way to bring a new task up. Point it at the wallets you care about, leave it for a day, and read the journal: you will see what it would have bought and, more usefully, what it would have refused and why.

How a snipe works

Worth understanding before tuning anything, because it explains why some filters are free and others are not.

The snipe tax is a clock, not a fee

A new launch charges a tax on buys that starts near 99% and decays to zero over about three seconds. It does not decay smoothly — it steps down on whole seconds of the block timestamp. So the price you pay is decided by which second your transaction lands in, not by how many milliseconds you saved:

• land in the launch second — pay ~99%, which is not a purchase, it is a donation;
• land one second later — pay about 6%;
• two seconds — about 0.2%;
• three — nothing.

The engine therefore does not race to be as early as possible. It aims at a specific second boundary and puts several transactions across it, so that one of them is the first buy in the first cheap block. Being 200 ms earlier inside the same second buys nothing; being 80 ms late costs an entire tax step.

Being first in the block is most of the edge

Why filter order matters

One launch fans out to every task watching that dev, and each has to be decided before the boundary arrives. So filters are ordered by what they cost:

• Free — everything already in the launch event: the dev's own buy, the quote asset, the name, and the post link with its timestamp. These are decided instantly.
• Cheap — one lookup against data the engine already keeps, such as a dev's recent record.
• Expensive — anything requiring a simulation. These run in parallel with the send preparation, not before it.

The post filters are in the free tier, which surprises people. The post link is embedded in the launch transaction itself, and the post id encodes its own creation time — so authorship and age are known without ever calling the social network.

Tasks

A task is a set of watched wallets, a wallet to trade from, a filter stack and an exit rule. It is created as a draft: you can build it, save it, look it over, and nothing happens until you press Start.

Watched wallets are shared across the platform. One dev address is watched by many tasks and has one history, which is what makes the dev probe worth anything — a dev's record does not restart every time somebody new starts watching them.

Config epochs

Every task carries a config_epoch. Changing a filter or an exit rule bumps it, and each position records the epoch it was opened under. This exists so that trades made under different settings are never averaged together — without it, a take-profit change halfway through a day quietly poisons every statistic that day produces.

What the statuses mean

• draft — built but never started.
• active — armed and watching.
• paused — you stopped it. Open positions keep their exit rules and still close.
• stopped — the engine stopped it: a risk limit was reached, or it could not trade. This one means something went wrong and is worth looking into.

Entry

Buy amount is the native amount spent per entry. The dev probe can reduce it for devs with a losing recent record, and a position entered that way is flagged as a probe so the two sizes never get averaged together.

Slippage is in basis points — 500 means 5%. Note that the snipe tax is not slippage: it is a separate, declining fee with its own gate, and raising slippage will not get you past it.

Filters

Grouped the same way in the task form and here. Blank almost always means “off”.

Throughout, an unknown value does not block a trade — unknown is not the same as a violation, and treating it as one would reject every genuinely fresh token. The exception is the safety group, where unverified is treated as unsafe.

B · Launch event

Decided from the factory event alone. No extra call, so these cost nothing and run first.

• Max dev buy — skip the launch when the dev's own opening buy is larger than this. A large dev bag is supply pointed at you: they are the one person who can sell into your entry at will.
• Max dev share — the same idea as a share of supply rather than an absolute amount, which travels better across launches of very different sizes.
• Allowed / blocked quotes — which quote assets the task will trade against. About half of launches quote in the native asset; the rest quote in a stock or a stablecoin, which adds a hop and a second pool.
• Banned keywords — substring match on the token name and symbol.

C · Post check

The launch calldata carries the post that announced it. Because the post id encodes its own creation time, the engine knows who wrote it and how old it is without a single network call — so these run in the free tier, before the send is even prepared.

Min post length is a proxy for effort, defaulting to 35 characters. It is a blunt one: a handful of handles do consistently well on very short posts, which is what per-handle overrides are for.

E · The target's trade (copy trade)

• Min / max trigger size — only copy buys inside this range. Small buys are usually the target testing a token rather than taking a position.
• First touch only — copy only their first buy of a token, never their averaging down. A second buy is often a rescue of a losing position, and you would be entering it without their first-buy cost basis.
• Skip their own launches — do not treat the target deploying a token as a buy signal. Their opening buy on their own launch is not an opinion about price; that is what a wallet-snipe task is for.
• Exit when they exit — close as soon as the target sells. This ranks above take profit and stop in the exit order: if the person you are copying is out, the reason you were in is gone.
• Token age window — only copy buys into tokens of a certain age.

A · Dev probe

Devs go through streaks. The probe sizes down on a dev whose recent launches lost money instead of dropping them, and gives the full size back when they recover.

With the defaults: once a dev has at least 5 closed trades, if the sum of their last 10 is negative, entries on them are cut to 20% of the configured amount. Three consecutive profitable probes restore full size and wipe the slate.

D · Safety gates

Enforced by the engine on every entry and not configurable per task. They are shown in the task form read-only, because a gate you do not know about looks like a bug when it stops a trade.

• Max snipe tax — refuse to enter while the tax is above the ceiling. Entering above it means paying the tax, not sniping.
• Min round trip — a simulated buy-then-sell must return at least this much of what went in. This is what catches tokens you can buy but cannot get out of.
• Price cap — entry price relative to the launch price, so a spray cannot fill far up a curve that has already run.
• If simulation fails — skip. Unverified is treated as unsafe: a token whose round trip could not be checked is not bought.

F · Risk limits

• Max open positions — every open position is capital you cannot deploy and an exit you have to watch.
• Daily drawdown cap — stops the task once net losses over the UTC day reach this: money in minus money out, with open positions counted as fully spent.
• Max buys per day — a hard count of entries, however they went.
• Cooldown — a minimum gap between entries. Mostly useful against a burst of launches from one handle emptying a wallet into near-identical tokens.
• One entry per token — never re-enter a token this task has already bought.
• Gas reserve — a balance the task will not spend below. Worth setting: running a wallet dry does not just stop it buying, it strands the positions it is already holding, because selling costs gas too.

G · Exit

Exits are checked in a fixed order on every tick. The order is part of the contract, not an implementation detail: several conditions usually hold at once, and whichever fires first is the reason recorded against the position.

1. Force exit — a late verdict on the post, or the discovery that we were not first in the block.
2. Hard cap — the absolute holding-time backstop.
3. Target exited — copy trade only, when they sell.
4. Take profit
5. Stop loss
6. Trailing stop
7. Timer

Two consequences worth knowing. A stop tighter than the trailing stop means the trail can never fire. A hard cap shorter than the timer means the timer can never fire. The task form warns about both rather than silently letting you believe otherwise.

The hard cap deserves its position at number two. It is the backstop for a position whose price feed has gone quiet — which is exactly the situation in which every other exit is unable to fire.

Positions

Open positions are marked live as a multiple of the entry price. The Entry column shows where in the block the buy landed — first means first after the dev, which is the outcome the whole boundary strategy is aiming at.

Expanding a position shows one row per send, not per trade. A spray puts several transactions across the second boundary deliberately, so a handful of dropped rows next to one landed row is the system working, not failing. The Offset column is milliseconds relative to the boundary the engine was aiming at.

Sell all and 50% exit by hand at any time. Positions survive a restart of the service: they are reloaded from the database along with their exit rules, so a deploy in the middle of a trade does not leave a token unattended.

Launch journal

Every launch the engine sees is recorded — bought, skipped, or dropped by a filter — with the filter that made the decision.

This is not a debug log, and it is the most useful page for tuning a task. A filter whose rejections were never written down cannot be re-checked afterwards, only argued about. Every measured claim in this documentation came out of a journal exactly like this one.

The Why nothing fired breakdown at the top of the page answers the most common question about any task that is quieter than expected. If one filter accounts for most of the rejections, that is the filter to reconsider.

Wallets & custody

A task trades from a wallet held by the service. The private key is encrypted with AES-256-GCM at rest, is never returned by any endpoint, and never reaches the browser again after you submit it.

The service can therefore sign without you. That is what makes sniping possible at all — there is no time to approve anything inside a one-second window — but it is a real trade-off, and it is stated plainly rather than buried. Fund these wallets with what a task is meant to trade, and nothing else.

Prefer generating a key over importing one. A generated key has never existed anywhere else, so it cannot have been copied from a machine you no longer trust.

Your own trading contract

By default a wallet trades through a shared router, which takes 1% on the way in and 1% on the way out.

One wallet, many tasks

A wallet can serve several tasks, and they share its nonce sequence. That is handled for you, but it is the reason a wallet cannot be removed while a task still points at it — the error message names the tasks that are in the way.

FAQ

My task is active but has bought nothing.

Open the launch journal and read the Why nothing fired breakdown. In practice it is almost always one of three things: the watched wallets have not launched anything, the post filters are rejecting launches that carry no link, or a risk limit is already reached for the day.

Why did it skip a launch that went on to run?

The journal records the reason against that specific launch. Note that filters are judged on averages over hundreds of trades — a filter that costs you one good launch while avoiding twenty bad ones is doing its job, and the journal is how you check that ratio rather than reacting to the one you remember.

Can I raise slippage to get past the snipe tax?

No. They are different mechanisms. The tax is charged by the launch contract and declines on its own schedule; slippage only governs how far the execution price may move. The engine waits for the tax to step down instead.

What happens to open positions if I stop a task?

They stay open and keep their exit rules — take profit, stop, timer and hard cap all still fire. Stopping a task prevents new entries; it does not abandon existing ones. To close one immediately, sell it by hand from the Positions page.

What happens if the service restarts while I have a position open?

Positions are reloaded from the database with their exit rules intact. This is called out explicitly because the single-user sniper this product is built on did not do it, and a restart there left tokens unattended.

Why can I not change a task from snipe to copy trade?

They read different feeds and are decided by different filters — a launch event and a swap are not the same thing. Create a second task instead; they can share a wallet.