Method

Method

The disclosure badge shows what share of a coin's supply sat with a few related wallets right after launch: below 15% is green, 15 to 30% is orange and above 30% is red. This page also lists the launch rules every coin shares and where each number on KABOOM! comes from.

The disclosure badge

The badge answers one question: how much of the supply sat with a few related wallets right after launch. A high share means a few wallets can move the price, whatever the chart looks like.

The coin page shows two separate layers. They are never added up or merged into one number, because one is a fact and the other is an estimate.

  • Bundled through this platform: certain. A bundle launch puts the maker's dev-buy and buys from the maker's own vault wallets in the launch transaction itself. Every bundle wallet signs that transaction, and its memo commits to the full set of bundle wallets. Those wallets and their buys are on-chain facts, so this layer gets a solid badge and the coin page lists every bundle wallet by address. Bundle launches are open on Solana mainnet: the coin, the maker's dev-buy and buys from up to 2 of the maker's own vault wallets go in one transaction, with a 1% creation fee on the total buy (the same 1% a standard launch pays on its dev-buy), and the coin page lists every bundle wallet.
  • Detected clusters: an indication. A heuristic groups early buyers that look related. It gets a dashed badge, always together with the error rate the detector measured for itself. How it works and how often it is wrong.

Next to both layers the page shows the one fact the chain states directly: the maker's dev-buy in the launch transaction, as a share of supply. When a layer has no number for a coin, it shows no badge at all instead of a guess.

Detected clusters

The cluster detector looks at the buys in the first slots after a coin was created. For each early buyer it traces where the SOL came from, up to two steps back. Buyers end up in one group when they were funded by the same wallet, when one funded the other, when they share a funder two steps back, or when one signed the other's buy. Exchange wallets, programs and busy payout services never link wallets, because thousands of strangers use them. The badge counts what the groups bought in the first five slots.

  • A cluster is a group of linked wallets, not a person. Shared funding means the wallets are related, not who controls them. The same trading bots and wallet fleets buy early in many coins, so a cluster is never labelled as the maker.
  • It makes mistakes in both directions. It can group wallets that are unrelated (a false positive) and miss wallets that are related but funded in a way it cannot see.
  • Its error rate is measured, not assumed. Each detector version is tested on holdout coins it was not tuned on, and every answer it gives carries the false-positive rate from that test. The coin page shows that figure next to the numbers. If an answer comes without it, the page shows no cluster numbers at all.
  • Old links are not counted. Wallets linked only through a funding source that is months old are listed as weak links and left out of the total.

The detector reads Solana mainnet history. A reading is stored per coin once the coin is older than ten minutes, because the first slots never change after that.

Launch rules

Every coin launched here uses the same on-chain config; the coin page reads each value back from the chain. The maker does not pick these values.

  • Supply. 1,000,000,000 tokens with 6 decimals. Token metadata is set with the SDK's immutable token-authority option, chosen so that nobody can change the name, symbol or image after launch. The coin page reads the mint authority from the chain.
  • Bonding curve. Trading starts at a market cap of 30 SOL. At 400 SOL the curve is complete and the coin moves to a Meteora DAMM v2 pool.
  • Maker vesting. 5% of the supply is reserved for the maker and locked. It is released in 30 equal steps over 30 days, starting at migration, without a cliff. Before migration the maker cannot sell it. No way to cancel the vesting was found, though that is not proven. The maker’s own dev-buy tokens are not locked.
  • Liquidity. At migration 100% of the liquidity is permanently locked (50% in a platform position, 50% in a maker position). The locked liquidity cannot be withdrawn; whether fees on the locked positions can be claimed has not been tested yet.
  • Anti-sniper fee. The trading fee starts at 50% and falls exponentially to 2% over the first 60 seconds, in 30 steps. The steps are stored on-chain in whole basis points, so the fee settles at 2.003% rather than exactly 2%; coin pages show the exact on-chain fee. Bots that buy in the first block pay for it. The maker’s own dev-buy inside the launch transaction pays the normal fee.
  • No launch fee; a 1% creation fee on the dev-buy. Launching costs the network fee and the rent for the new accounts. Every Solana launch with a dev-buy pays a 1% creation fee on the buy (the dev-buy, plus every bundle wallet on a bundle launch) to the platform, inside the launch transaction; a launch without a dev-buy pays none. The 1% creation fee goes entirely to the platform; referral rewards come from trading and tool fees, never from the creation fee. The launch page shows that fee and simulates the exact amount before you sign.

In our own test runs the curve is smaller so a test can reach migration: it starts at 1 SOL and migrates at 10 SOL, with a 30-second fee window. All other rules are the same.

Fees

After the first 60 seconds, every trade on the curve pays 2% (2.003% exactly, see above). It is split on-chain at the moment of the trade:

  • Meteora, which runs the bonding curve program, keeps 20% of the fee.
  • The rest is split 69/31 between the platform and the maker. The maker claims their share from the coin page.
  • After migration the coin trades in a Meteora DAMM v2 pool with a 1% fee tier.

Where the data comes from

  • Coin pages read the pool, its config, the mint, the metadata account and the vesting escrow from the chain on every refresh. There is no separate price database.
  • Trades and candles come from the swap events in the pool's own transactions. A candle opens at the previous close and gaps are never filled in.
  • Token images and metadata are hosted by this app under their content hash, so the file behind an on-chain link never changes.
  • Every transaction is built in this app and signed by your own wallet on Solana mainnet: launching, trading coins on our own curve, the Jupiter swap, the sniper, copy trading, fee-claim triggers and auto-sell (while its tab is open). A scheduled launch is one you signed in advance; the server only sends those signed bytes at the time you chose and never holds a key.

See the coins or launch one.

Frequently asked questions

What is the disclosure badge?

The badge answers one question: how much of the supply sat with a few related wallets right after launch. Below 15% is green, 15 to 30% is orange and above 30% is red. It has two layers that are never added up: tokens bundled through this platform, which is certain, and detected clusters, which is an estimate. The bundle layer of the disclosure badge is live; cluster figures are not live yet, so no cluster number is shown. Until a layer has a source, the coin page says so instead of showing a number.

The disclosure badge

What are detected clusters, and can they be wrong?

A detected cluster is a group of early buyers whose wallets look linked, for example because the same wallet funded them. It is an indication, never proof, and it is never labelled as the maker. It can be wrong in both directions, so a cluster figure is only shown with the false-positive rate the detector measured in its own blind tests. Detection covers Solana mainnet coins only, and the current detector does not report that rate yet, so no cluster figure is shown today.

How clusters are detected

Where does the data on KABOOM! come from?

From the chain, every time a page loads. Solana coin pages read the pool, its config, the mint, the metadata and the vesting escrow on every refresh, and build trades and candles from the swap events in the pool's own transactions; a candle opens at the previous close and gaps are never filled in. Robinhood Chain coin pages read the coin from the PONS contracts. There is no separate price database.

Where the data comes from

What is the trading fee and who receives it?

Every trade on the curve pays about 2%: the on-chain fee schedule rounds to whole basis points, and the Solana coin page shows the exact fee. On the nominal 2%, 0.4% goes to Meteora, which runs the bonding curve program, 0.496% to the maker and 1.104% to the platform. The fees accrue on-chain in the pool: the maker claims their share from the coin page and the platform wallet claims its share.

Fee split on the method page

How does maker vesting work?

5% of the supply is set aside for the maker and moves into a vesting escrow at migration. It is released in 30 equal steps over 30 days from migration, without a cliff, so before migration the maker cannot sell it. No way to cancel the escrow was found, though that is not proven. The maker's own dev-buy tokens are not locked. The Solana coin page shows the schedule and how much has unlocked.

Is the liquidity locked?

Yes, at migration 100% of the liquidity is permanently locked: 50% in a platform position and 50% in a maker position. The locked liquidity cannot be withdrawn; whether trading fees on the locked positions can be claimed has not been tested yet. The rule is part of the config every Solana coin launches with, and the coin page reads the LP status from the chain. For Robinhood Chain coins the LP lock is not known.

Can anyone mint more tokens or change the name or image?

Every Solana coin has a supply of 1,000,000,000 tokens with 6 decimals and is configured with the bonding-curve SDK's immutable token-authority option, not one of the options that keep a mint authority. That is the launch config, not a recorded check: the coin page reads the mint authority and the metadata from the chain, so check there for each coin.