Dev buy and its lock

What it is

A new token's creator may buy their own token on each pool before the launch finalizes, at the opening price, with LaunchDevBuy. It is a real swap through the pool's pipeline, so it pays every fee the pool charges, and it is recorded in a DevBuy event with the price before and after. There is at most one per pool, and none on an existing token's launch.

Its limits

• On a guarded pool (Anti-Snipe), the dev buy needs a Snipe tax above 0 and a per-slot cap at least as large as the buy. A dev buy that breaks this fails with DevBuyRefused.
• Supply you keep. With a dev buy, what the creator ends up with (escrow left over plus every dev buy) is capped at 5% of supply, checked at finalize (RetainedAboveCap).
• Not on a Zap Relay target pool, whose buys come only from its feeders.
• It takes min_out, like any swap, so a creator never buys at a worse price than they signed for.

A dev buy doesn't count toward Wallet Cap, and a Buy/Sell Block pause doesn't apply to it.

The lock it starts

A dev buy carries lock_secs: 0 to 31,536,000 seconds (365 days), 604,800 (7 days) by default. It locks the launch's liquidity, not the bought tokens. At finalize the launch sets

principal_lock_until = max(guard end, open + dev_lock, open + lock_end)

so no launch position can withdraw principal before then (PrincipalLocked). The bought tokens are the creator's at once, and the pools' fees stay collectable throughout.

Why lock liquidity, not tokens

A dev buy's risk to everyone else is that the creator buys cheap, then pulls the liquidity the price stands on. Locking the liquidity for a period traders can read removes that path, while the creator keeps an ordinary position in the token. The lock, the dev buy's size and its price impact are all on chain: read the Launch account's dev_bought and principal_lock_until, and the DevBuy event.