Meteora Sniper Bot

The short version

If you only read one part of this page, read this.

• More than a third of Meteora launches open with a fee of 50% or more. Of 9,217 launches on Meteora's Dynamic Bonding Curve in the last 30 days, 3,435 started at 50% or higher.
• The first two seconds are the most expensive time to buy. On high-fee launches, buyers in seconds 1 and 2 paid a median fee of 85%. Counting the fee, they paid about 7.3 times more per token than the first buyer's pre-fee price.
• The fee falls fast. Most high-fee launches were back to a normal 2 to 3% fee within 30 to 60 seconds.
• The creator often buys at the minimum fee. A buy placed inside the launch transaction itself paid a median fee of 2% on the same launches where outside buyers paid 85%.
• Some pools never lower the fee. 4,366 new DAMM v2 pools in 30 days charged a fixed 50 to 99%. Most were opened by a few dozen wallets for tokens that already trade elsewhere.

None of this makes Meteora bad to trade. It makes the fee the first thing to check, before price, before holders, before anything else.

Why Meteora is different for snipers

On most launchpads the trading fee is a published number that does not change during the first minute of a token's life, so nobody thinks about it at the moment of buying. Meteora took a different route: the fee is part of the launch design, and each launchpad that builds on Meteora picks its own.

Meteora runs three things a sniper cares about. The Dynamic Bonding Curve, or DBC, is the launch program that many launchpads use under their own brand. Tokens start there on a curve and move into a DAMM v2 pool when the curve fills. DAMM v2 is Meteora's constant product AMM, used both for graduated tokens and for pools anyone opens by hand. DLMM is the concentrated liquidity AMM, used more for established pairs than for new launches.

On DBC, the base fee can follow a schedule that starts high and steps down. Meteora calls this an anti-sniper fee, and its docs are open about the goal: make the first moments of a launch expensive so that bots racing for the first block do not take all the early supply. The fee is capped at 99%. On DAMM v2, a pool can use a time schedule, a schedule that follows the price, a size-based fee, or a fixed fee of almost any level.

That changes the whole logic of sniping. On Pump.fun the question is how fast you can land. On a Meteora launch the question is when the fee falls below the point where buying makes sense, and whether your bot even knows the fee exists.

How the Meteora fee clock works

Every DBC launch config stores four numbers for its base fee. The cliff fee is the fee when trading opens. The number of periods is how many times the fee will step down. The period frequency is how long each step lasts, in seconds or slots. The reduction factor is how much each step removes. A config with all three schedule numbers at zero charges the cliff fee forever, which is how a flat fee is stored.

There are two shapes. A linear schedule removes the same amount at every step:

An exponential schedule cuts a share of the current fee at each step, so it falls quickly at first and then slows down as it approaches the final fee. The clock starts at the pool's activation point, not when the token was created, and it runs on wall time. Two seconds after activation, the fee is the same whether one person has traded or a thousand have.

Two real fee clocks

Here are the two most used high-fee schedules among launches in the last 30 days, rebuilt from their configs with Meteora's own formulas. The first was used by 216 launches, the second by 811 launches from a single launchpad.

Data table

Base fee by seconds after activation, two schedules read from DBC configs

Base fee by seconds after activation, two schedules read from DBC configs

Seconds after opening	96% start, 50 steps of 1 s	51.9% start, 120 steps of 5 s
0	96.0%	51.9%
2	82.2%	51.9%
5	65.2%	50.4%
10	44.3%	48.9%
20	20.4%	46.1%
30	9.4%	43.5%
60	2.0%	36.4%
120	2.0%	25.5%

The two look nothing alike once you plot them. The first is a sprint: brutal for two seconds, reasonable after half a minute, done at 50 seconds. The second is a long squeeze: it never goes above 52%, but it is still taking a quarter of every buy two minutes in, and it runs for ten minutes. A sniper tuned for the first kind will buy the second one far too early.

Slots or seconds

A config can measure its clock in slots instead of seconds. A Solana slot took about 0.4 seconds until September 2026 and about 0.21 seconds since October, and slot timing drifts under load. For timestamp-based configs, the math above is exact. For slot-based ones, treat the result as an estimate and leave a second of margin. All the 30 day figures on this page are from timestamp-based launches, which are the large majority.

What Meteora launches are set to charge

We read all 565,123 launch configs on the DBC program and matched them to the 1,854,182 launch pools that use them. Many of those pools are test launches or token farming with tiny graduation targets, so for the numbers below we kept only launches with a meaningful target: at least 5 SOL for SOL-paired curves and 500 USDC for USDC-paired ones. That left 9,217 launches that opened in the last 30 days.

Data table

Starting fee of 9,217 DBC launches, last 30 days

Starting fee of 9,217 DBC launches, last 30 days

Fee when trading opens	Launches	Share
50% or more, then falling	3,435	37.3%
10% to 50%, then falling	310	3.4%
Flat 1% to 5%	5,089	55.2%
Flat under 1% or over 5%	240	2.6%
Under 10%, then falling	143	1.6%

So a sniper pointed at "all Meteora launches" will meet a 50% plus opening fee in a bit more than one launch in three. That is too often to treat as an edge case, and too seldom to assume every launch is protected.

How long the high fee lasts

Across every high-start schedule we found on the DBC program, the median time from opening to the final fee was 48 seconds. A quarter of them were done in under 15 seconds, and three quarters within a minute. The final fee was usually around 2%. A few schedules run for ten minutes or more, as the second column of the table above shows, and those are the ones that catch impatient bots.

Dynamic fees on top

913 of the 9,217 launches also switched on Meteora's dynamic fee, a second layer that rises with volatility and decays when trading calms down. On a launch, volatility is highest exactly when snipers arrive, so the dynamic part adds most where the scheduled part is already high. You cannot compute it from the config alone, because it depends on recent price moves. A bot has to read the pool's volatility state at the moment it quotes.

Token-2022 and transfer hooks

706 of the recent launches used Token-2022 mints, and 26 configured a transfer fee on the token itself. A transfer fee is separate from the trading fee: it is charged by the token program on every transfer, including your buy and your sell. DBC also supports transfer hook launches, where a custom program runs on every transfer during the curve phase. Meteora removes the hook when the curve completes. Until then, a hook can do things your bot cannot see from the pool alone.

What early buyers actually paid

Configs tell you what a launch is set to charge. They do not tell you whether anyone actually buys into a 90% fee. To find out, we took launches from the last seven days, 137 with a high starting fee and 93 with a flat fee as a control, and decoded every buy in their first 45 transactions from Meteora's own swap events. Each event records the SOL put in, the tokens received and the fee taken, with a timestamp.

The median and the share lost tell slightly different stories, and both matter. Between 6 and 10 seconds the median buyer paid under 10%, but the buyers who landed early in that window paid much more, so 28% of all SOL spent in those five seconds went to fees. In total, buyers in our 137 launches put 685.5 SOL into the curves and 109.2 SOL of it was taken as fees.

141 buys paid a fee of 50% or more. They came from 101 different wallets, spent 78.2 SOL and handed 60.9 SOL of it to the fee. These were not one careless trader. They look like what you would expect from bots set to fire on any new launch, with no idea what the fee would be.

The control group

On a flat-fee launch, timing does not change the fee at all. The difference between the two tables is entirely the fee schedule, which is exactly why a bot that does not read it is gambling.

Is it cheaper to wait? We priced it

A high fee is only half of the cost. The other half is the price, which rises with every buyer on a bonding curve. A sniper that waits for the fee to fall also lets others buy ahead of it. So we priced every buy the way you actually experience it: SOL spent, fee included, divided by tokens received. Then we compared it with the price the first outside buyer of the same launch paid before fees. A value of 1.00 means you paid what the first buyer paid; 2.00 means twice as much per token.

Data table

Median all-in cost per token, relative to the first buyer's pre-fee price

Median all-in cost per token, relative to the first buyer's pre-fee price

When the buy landed	High-fee launches	Flat-fee launches
1 to 2 seconds	7.28x	1.20x
3 to 5 seconds	2.20x	1.36x
6 to 10 seconds	1.75x	1.44x
11 to 30 seconds	1.55x	1.44x
31 to 60 seconds	1.38x	1.91x
1 to 5 minutes	1.30x	1.58x
After 5 minutes	1.08x	1.46x

This is the most useful table on the page. On flat-fee launches, being early pays: the all-in cost is lowest in the first seconds and higher at every point after. On high-fee launches it is the other way round. A buyer two seconds in paid about seven times what the first buyer paid before fees. A buyer half a minute in paid about one and a half times. Even five minutes in, the median buyer paid less per token, all-in, than the median two-second buyer by a factor of almost seven.

There is a reason the price barely rises on high-fee launches: very few people buy into a 90% fee, so the curve does not move much while the fee is high. The fee protects the price as much as it punishes the buyer. When the fee comes down, buying picks up and the price starts to climb, which is why the 11 to 30 second window is busy.

What this means for a sniper

• On a decaying high-fee launch, do not buy in the first seconds. Compute when the fee drops under your limit and buy then.
• On a flat-fee launch, speed matters as much as anywhere else. Here the classic sniper logic holds.
• The right moment is different for every schedule. 15 seconds is early on the 96% sprint and early on the ten minute squeeze for completely different reasons.

The creator's discounted first buy

One row in the first table deserves a second look. On the same launches where outside buyers paid a median 85% in the first seconds, buys placed inside the launch transaction paid a median of 2%. That is not a coincidence. Meteora's launch configuration lists an option called first swap with minimum fee: a narrow path that lets the transaction that creates the pool include one buy at the minimum fee, as long as it targets that new pool and carries no referral.

In practice, that buy is usually the creator's or the launchpad's. The median launch-transaction buy in our high-fee sample was 0.5 SOL. Put plainly: on a launch built to tax snipers, the person who creates the token can buy first, at the normal fee, before anyone else can trade.

That is not necessarily sinister. Many launchpads use the initial buy so creators hold some of their own token, and Meteora documents the option openly. But it changes how you read the holder list in the first minute. A creator wallet holding a chunk of supply bought at a 2% fee is in profit the moment anyone pays 50% to get in after them. A dev holding cap and a dev-sell exit matter more on these launches, not less.

The 70% fee pool trap on DAMM v2

The anti-sniper fee on launches is temporary by design. There is a second kind of high fee on Meteora that is not. DAMM v2 lets anyone open a pool and choose its base fee. We read all 1,732,099 DAMM v2 pools, decoded the 88,542 that opened in the last 30 days, and found a cluster that does not look like any normal market.

Data table

New DAMM v2 pools with a fixed fee of 50% or more, last 30 days

New DAMM v2 pools with a fixed fee of 50% or more, last 30 days

What we found	Pools
Fixed fee of 50% or more, no schedule	4,366
...set to exactly 70%	2,709
...set to 50%	958
...set to 60% or 65%	546
...set to 99%	59
...paired with SOL	3,992
SOL pools whose token mint ends in pump	2,947
Wallets that opened the SOL pools	37
...pools opened by the ten busiest wallets	3,762

Most of these pools pair SOL with a token that already trades on Pump.fun or PumpSwap. A new pool for an existing token is exactly the event a "new pool" sniper or a copy bot is built to react to. Meteora's own data API confirms the setup on the pools we spot-checked: base fee 70%, no fee scheduler, dynamic fee on top.

The pools' own fee counters show what that costs the people who trade them. Across the 3,992 SOL pools, the counters recorded about 903 SOL in liquidity provider fees and 213 SOL in protocol fees, roughly 1,116 SOL in 30 days. The trades we sampled came in through third-party trading programs, not from people clicking buy on Meteora's site. Whoever routed them did not check the fee.

The other side of the trap shows in the liquidity. When we read the pools, only 477 of the 4,366 still had any liquidity in them, and almost all of the SOL pools held less than 1 SOL. The pattern fits pools that are opened, collect fees from whatever buys into them, and are then emptied by their owner. In one of the largest, the last transaction we found was the owner claiming its fees and removing all liquidity.

How to spot one

• The base fee is far above anything a real market needs. A custom fee on a pool a DBC launch graduates into is capped at 10%, and busy pools usually charge far less.
• No scheduler. A high fee that is not set to fall is not anti-sniper protection. It is the business model.
• The token already has a busy market somewhere else. A brand new launch has one pool. A trap pool is a second or third pool for a known token.
• The opener has opened hundreds of these. Ten wallets opened 3,762 of the SOL pools in our month.

After graduation: the fee and the liquidity

When a DBC curve fills, the token moves into a DAMM v2 pool. Migration snipers buy there. Two settings in the launch config decide whether that is a good idea, and both are readable before the pool exists.

The post-migration fee

The config also sets the graduated pool's fee. A custom fee for a DBC graduation must sit between 0.1% and 10%, so the 90% opening fees of the curve phase do not follow the token into its pool. What can follow it is a market cap scheduler: a fee that only steps down as the price rises above the opening price, with an expiry after which it settles at its final level. If the price goes nowhere, the fee stays at its upper level until the expiry. In the last 30 days, 479 new DAMM v2 pools, graduated or opened by hand, used a market cap scheduler. For a migration sniper that is an awkward deal: you pay the higher fee precisely when the token is not performing, and on the way out if you sell into weakness.

How much of the graduated liquidity stays locked

Meteora's docs require at least 10% of migrated liquidity to stay permanently locked at day one. The config decides what happens to the other 90%: permanently locked, vesting over time, or in positions the partner and creator can withdraw. In 8,625 of the 9,217 recent launches, none of the graduated liquidity was set to be freely withdrawable. In 564 launches, 76 to 90% of it was. Those are the launches where a migration snipe can be followed by a large liquidity withdrawal, the same pattern that empties most hand-opened Raydium pools, as we measured in our Raydium sniper bot guide.

Alpha Vault and the real front of the line

If being first is what you are after, Meteora has an answer that does not involve a bot at all. An Alpha Vault is attached to a launch pool and collects deposits before trading opens. During a protected window before public activation, the vault buys from the pool for all depositors at once. Public trading, and every sniper, starts after that.

Vaults run in two modes. Pro rata accepts more deposits than it can fill and gives everyone a proportional share, refunding the rest. First come first served fills deposits until a cap is reached. Tokens bought by the vault are released linearly between a start and an end point, so vault buyers cannot all sell in the first block either.

For a sniper this matters in two ways. On a launch with an Alpha Vault, you are not the first buyer, however fast you are; the vault is. And the vault's tokens arrive on a schedule, which means the selling pressure from them is predictable. If a project you follow announces a vault, the deposit is the early entry, not the snipe.

Meteora sniper settings that make sense

Most settings carry over from other venues. A few need a Meteora-specific twist. These are starting points, not promises.

Why the priority fee goes down on high-fee launches

Paying a big tip to land in the first block of a launch whose first block costs 85% is paying twice to lose. Once the schedule has run down there is no first-slot race left to win, so a normal priority fee is enough. Save the aggressive tips for flat-fee launches, where the first block really is the cheapest.

Slippage and fees are not the same thing

A slippage cap protects you against the price moving between quote and fill. Whether it also protects you against the fee depends on how the bot builds its quote. If the quote ignores the pool fee, a 70% fee shows up as a fill far below the quote and the slippage cap stops the buy. If the quote includes the fee, the bot will happily accept it as the expected result. That is why you read the fee schedule before you arm a sniper on a launch, rather than hoping the slippage cap catches it.

Exits on Meteora

The fee works in both directions. On DBC, sells pay the scheduled fee too, so a stop-loss that fires in the first seconds of a high-fee launch sells into the same 80% plus fee. A timer exit set to a few seconds is a bad idea on these launches. Give positions time to get past the schedule before any automatic sell can fire, unless you accept paying the fee twice.

Choosing a Meteora sniper bot

Before you trust any bot with Meteora launches, ask these questions. A bot built for flat-fee venues can be fast and still get every one of them wrong.

1. Does it read the launch config's fee schedule and compute the current fee from the activation point, including whether the clock runs in slots or seconds?
2. Does it add the dynamic fee from the pool's volatility state, or only the base fee?
3. Does it check the base fee of a DAMM v2 pool before buying a new pool, and skip fixed high-fee pools?
4. Does it read the token program, transfer fee and transfer hook on Token-2022 launches?
5. Does it know the post-migration fee and liquidity split before it fires a migration buy?
6. Does it trade from a separate wallet you control, so a mistake costs only what is in that wallet?

Meteora sniper bots on GitHub

There are open source DBC snipers and bundlers on GitHub, many built for one launchpad during a hype cycle. Check when each was last updated against Meteora's changelog: DBC has moved to DAMM v2-only migration and closed the rate limiter to new launches, and its swap events have changed format more than once. A bot that decodes an older event will misread fees or miss trades. And as with any code that asks for a private key, read it before you run it.

Meteora in DexSnipe

Meteora is a venue in DexSnipe for five triggers: Fresh launch on the Dynamic Bonding Curve, Migration into DAMM v2, New pool for hand-opened pools, Creator watch, and Copy trade for wallets you follow. Each sniper has the usual filters (mint and freeze authority, dev holding and top holder caps, bundled launch check, transfer tax cap, minimum liquidity and LP burned or locked for pools) and up to four take-profit steps, a stop-loss, a trailing stop, a timer and a dev-sell exit. Launchpads that run on Meteora, like Bags, Believe and Jupiter Studio, are separate venues, so you can set different rules for each. The price is a flat plan from 1 SOL for 7 days with no cut of your trades.

Set up a Meteora sniper in DexSnipe

1. Decide which Meteora market you are sniping. Fresh launches, migrations and new pools behave so differently on Meteora that each deserves its own sniper.
2. Open the panel and click New sniper. Pick the trigger and tick Meteora, plus any Meteora-based launchpad you want to include.
3. Load a preset, then adjust for the fee. Lower the priority fee and tip for launches, set a dev cap of 5 to 10%, keep the transfer tax cap at 0%.
4. Build exits that survive the schedule. A first take-profit that returns your cost, a stop-loss, and no very short timer.
5. Connect your wallet and save. Snipers are stored on your wallet address.
6. Pick a plan, add a sniper wallet and arm it. Send 1, 3 or 5 SOL to the reserved address, add the key of a separate funded wallet, arm the sniper and close the tab.

Meteora sniper bot questions

Sources and method

We listed every account of Meteora's Dynamic Bonding Curve and DAMM v2 programs through a Solana RPC node in November 2026 and decoded them with the layouts in Meteora's published program IDL. For DBC we read each launch config's base fee mode, cliff fee, schedule, dynamic fee flag, activation type, quote mint, graduation target, token type and liquidity split, and joined them to every launch pool. The 30 day set covers launches with timestamp-based activation in the 30 days before our read, with a graduation target of at least 5 SOL or 500 USDC.

For the swap study we drew a random sample of launches from the previous seven days: 137 with a starting fee of 50% or more on a decaying schedule, and 93 with a flat fee of 2% or less, capped per launchpad so no single partner dominates. We read the first 45 successful transactions of each pool and decoded Meteora's EvtSwap2 and EvtSwap3 events, removing duplicate events of the same swap. Fee share is the fee divided by the SOL put in. All-in cost per token is SOL put in divided by tokens received, relative to the pre-fee price of the first buy outside the launch transaction. For DAMM v2 we decoded pools activated in the last 30 days and read base fee, scheduler, liquidity, permanent lock, creator and fee counters, and cross-checked sampled pools against Meteora's data API. DexSnipe triggers, filters and presets are taken from the product itself.

• DBC Fees (Meteora docs)Fee layers, the 99% cap, the 0.25% minimum, and how the fee is split between protocol, referral, partner and creator.
• DBC Fee Scheduler (Meteora docs)Linear and exponential schedules, the four scheduler settings and the formulas we used to rebuild each launch's fee clock.
• DBC Rate Limiter (Meteora docs)The older size-based fee mode, now closed to new launches, and its single-swap rule.
• DBC Launch Configuration (Meteora docs)Lists the first swap with minimum fee option for the pool creation transaction.
• DBC Migration and Liquidity (Meteora docs)How a finished curve becomes a DAMM v2 pool, and the rule that at least 10% of migrated liquidity stays locked at day one.
• DAMM v2 Market Cap Scheduler (Meteora docs)Post-launch fees that only fall as the price rises.
• What is Alpha Vault? (Meteora docs)Deposits that buy during the pool's protected window before public trading opens.
• Dynamic Bonding Curve SDK and program IDL (GitHub)Account layouts and swap events we decoded: PoolConfig, VirtualPool, EvtSwap2 and EvtSwap3.
• Meteora Dynamic Bonding Curve program on SolscanProgram dbcij3LWUppWqq96dh6gJWwBifmcGfLSB5D4DuSMaqN, where we read 1,854,182 launch pools and 565,123 launch configs.
• Meteora DAMM v2 program on SolscanProgram cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG, where we read 1,732,099 pools.
• A 70% fee DAMM v2 pool, on SolscanThe pool in our 30 day set whose counters showed the most fees paid to its liquidity provider, about 32 SOL.
• Meteora DAMM v2 data API, pool endpointWe used it to cross-check base fee and scheduler status on sampled pools.