Remember first is first $metcat

Hey gm guys we’re going to post some updates to and show case some of our tech we’ve been working on ideas for what we show case with our front end for meteoras sdk

Hi we’re still here

Meteora's Console is now public. A clean launch console for Meteora DBC tokens: token art, curve setup, Phantom approval, creator fee claims, bundler tools, and leftover_receiver routing in one flow. No app launch fees. Not affiliated with Meteora. github.com/MeteorasConsole/m…

1/ Meteora gives devs a powerful SDK — everything you need to create and run a launch. ▎ ▎ But the launchpads built on top all optimize for the same thing: the simplest possible UI. Easy, but it hides what the SDK can actually do. ▎ 2/ Meteora's Console goes the other way — the Cursor of launchpads. Complete control of the launch, every function exposed instead of buried: ▎ ▎ ◦ bonding curve design — linear or exponential, market caps, fee schedule ▎ ◦ built-in wallet bundler — spin up fresh wallets, split SOL, bundle-buy for clean supply control ▎ ◦ creator fee claims across every pool you've launched ▎ ◦ leftover_receiver routing after migration ▎ ◦ launch from your own wallet — $0 app fees, full custody ▎ 3/ Power instead of hand-holding. Everything the SDK can do, surfaced in one flow. ▎ ▎ meteorasconsole.xyz

Here's the rundown on leftover (leftover_receiver) in a Meteora DBC launch and how the console handles it. What "leftover" is When you launch on a Dynamic Bonding Curve, you define a total token supply. Not all of it is meant to clear through the curve: - A portion is the public float — the tokens actually sold to buyers as the price moves up the curve. - When the curve hits its migration market cap, the pool migrates to a full DAMM (AMM) pool, and the raised quote liquidity + the matching base tokens get seeded into that pool. - Whatever base tokens were minted into supply but not sold on the curve and not consumed by migration are the leftover — the remainder sitting in the pool after the launch graduates. leftover_receiver is simply the wallet that's entitled to claim those leftover tokens once migration is complete. How it works in the lifecycle 1. At config time you set the supply split — public float vs. the leftover reserve — and you set the leftover_receiver address. This is baked into the pool config at launch (it can't be hand-waved later; it's an explicit on-chain field). 2. During the launch buyers trade up the curve; the leftover tokens just sit reserved. 3. At migration the curve graduates to the DAMM pool. 4. After migration the receiver calls the withdrawLeftover instruction, which transfers the remaining leftover base tokens out of the pool to that wallet. How the console surfaces it This is one of those SDK functions other launchpads bury. In Meteora's Console: - The Reserve panel makes leftover_receiver an explicit field up front (a wallet or multisig), and shows the leftover token count as you adjust the split — so you decide deliberately, not by default. - After migration, the leftover routing step builds the withdrawLeftover transaction for that receiver, and lets you plan how the reclaimed tokens get split across developer rewards / treasury / team allocations instead of dumping them into one address. So practically: leftover = the un-sold remainder of your supply after the curve graduates, and leftover_receiver + withdrawLeftover is the controlled, on-chain way to reclaim and route it — rather than stranding it in the migrated pool.

I’ll make a GitHub repo and post it here and add it to the landing page I have to drive somewhere really quick I’ll be back soon

We’re live on kickstart! $MCLI JKnnyJs7xbx217y3sCnPAH7K9C5at4nMbLSr8mrEASY

Launch DBC tokens on Solana. No app fees. ▎ ◦ design the curve ▎ ◦ generate burner wallets + bundle-buy for supply control ▎ ◦ claim creator fees ▎ ◦ keep custody, always ▎ Live now → meteorasconsole.xyz