Meteora's DBC: less early supply, same first-mover race

Summary

Meteora's Dynamic Bonding Curve (DBC) cuts how many tokens the first buyers get, but only if you make the curve steep, and it does nothing about the cheap option or the race to be first. I launched two real pools on devnet and modeled the rest offline. The model matched the chain exactly.

• The first 10% of the SOL raised buys 18.8% of the supply on a static curve and 11.0% on the steepest curve I tried. A gentle curve gave the same 18.8% as static.
• Buying and then selling right away still gets you back 98% of your SOL on every curve, so the cheap option is still there.
• A fee that starts high and decays doesn't stop a sniper who is willing to wait for it to fall. Snipers who compete still get in during the first few periods and keep 10% to 43% of their profit.
• Neither tool changes who gets in first. They only change how much being first is worth.

How DBC works

With DBC the creator picks the shape of the curve and can charge a high fee early on. Once enough SOL has come in, the token moves to a normal Meteora pool.

• The curve is made of up to 16 virtual xy=k segments stitched together, each with its own liquidity. Thin liquidity makes the price move fast and deep liquidity makes it move slowly.
• The fee can be fixed or decay over time, linearly or exponentially, anywhere from 0.25% to 99%. It applies to buys and sells [1].
• Once the curve has raised a set amount of SOL, the token "graduates" to a DAMM v2 pool [2].

Source: Meteora SDK 1.5.13 curve parameters; an example ramp with 1.5x liquidity per segment, 5 to 50 SOL market cap.

What I tested

I kept everything the same except the curve: 1B tokens, SOL as the quote, a flat 1% fee, and a price that rises 10x from start to graduation.

• I launched two real pools on devnet, a static xy=k pool and a 16-segment one. I bought the same amount of SOL on each and counted the tokens.
• Offline, I compared five curves: static, a two-segment curve, and three "ramps" where each segment has 1.10x, 1.25x or 1.50x more liquidity than the one before it.
• I also ran a small game with one sniper, steady buyers, and a fee that starts at 50% or 99% and decays to 1%.

Early supply

A steeper curve does give early buyers fewer tokens, and the model matched the chain to the token.

Source: devnet pools and an offline model of the Meteora SDK 1.5.13 curve math; 1% fee.

I spent 2 SOL on each test pool. The static pool gave me 28.8% of all tokens and the dynamic one gave me 17.1%, which is 41% fewer. With 0.1 SOL it was 10% fewer. The gap peaks around 5 SOL at about 41%, then shrinks to 15% by the time each curve has sold out.

The more useful question is what the first buyers get. Say they put in the first 10% of the SOL a launch needs. On the static curve they get 18.8% of all tokens, and the gentlest ramp gives the same. The 1.25x ramp gives them 15.5%, and the steepest ramp, 1.50x, gives them 11.0%.

Source: offline model of the Meteora SDK 1.5.13 curve math; fees off, 10x price range on every curve.

The catch is that the project has to raise more SOL to finish. The steepest curve needs 19.5 SOL before it graduates, against 11.4 SOL for static. The two-segment curve (14.2%) isn't a fair comparison, because it sells 80% of the supply at graduation against 56% to 72% for the others.

The cheap option

Changing the shape of the curve can't touch the cheap option.

The cheap option comes from how the curve works. The price depends only on how much SOL is already in the curve, so selling just walks back down the path you bought on. You get your SOL back minus fees, whatever the shape. At a 1% fee that's 98%.

Anti-sniping fee decay

A fee that decays over time moves the race to a different moment but doesn't stop it.

Source: my timing-game model on the static curve; sniper buys 10% of the raise, organic demand is 60%, demand arrives after the decay ends.

If regular buyers wait for the fee to fall, a lone sniper can wait too. Waiting costs it nothing, so it buys right when the fee hits its floor and keeps all of its profit.

If snipers compete, they push each other to buy earlier. A 50% starting fee still leaves the very first period profitable, so they all pile into it. Only a 99% start pushes them out, to period 2, and even then they keep 25% of the profit.

None of this is empirical. It's mocked data: the sniper size (10% of the raise) and the demand (60%) are numbers I picked, and "competing" is a rough extreme case, not a worked-out equilibrium.

What it does show is that a sniper who can place itself in the order can buy at the exact moment it believes the trade is profitable. Competing snipers cut into each other's profit, but that's just as true on a launch with no fee decay. And the bigger the launch, the more opportunity there is.

Where DBC hits its limits

DBC helps with early supply and leaves the cheap option and the race to be first in place.

• Whoever lands first still gets the lowest price. A steeper curve changes how much that's worth, not who wins it. A public fee schedule just makes the block where the fee hits its floor the new thing to race for.
• The start price, the price range and the shape are all set before the first trade. Meteora describes DBC as on-chain price discovery, but all it finds out is how much demand shows up, not what each buyer thinks the token is worth.
• The fee is a tax. It moves some of the sniper's profit to whoever collects fees, but the tokens still go to whoever gets there first.

Sources

• Meteora: What is DBC? for the product description
• Meteora: DBC Fees for fee modes, limits and buys and sells
• Meteora: DBC Migration and Liquidity for the migration threshold and target pool

References

1. Meteora. "DBC Fees." https://docs.meteora.ag/core-products/dbc/fees/overview
2. Meteora. "DBC Migration and Liquidity." https://docs.meteora.ag/core-products/dbc/migration-and-liquidity