Docs.

Every token here is about someone. A launch names a handle on X, and from that moment the launch and that person are joined: a cut of every trade accrues in their name, and the token is quoted in a currency that belongs to them rather than in ETH.

That currency is the star's own token. The platform creates it on the first launch about a handle, at an address that is a function of the handle alone, and every later launch about the same person is priced in it. A star has one token; the tokens about her are many.

Naming someone is not a claim about them. A handle is declared by the creator, it is never described as verified, and the person behind it has agreed to nothing until they claim what has accrued by posting from that account.

Pairing a launch against a person, rather than against ETH, is what makes the rest of this work. A meme about her trades in her token, so demand for the meme is demand for her: a buy arrives as ETH, becomes her token, and only then becomes the meme. A sell walks the same path backwards. You never hold her token by accident, and you never have to hold it to trade what is priced in it.

The consequence is that her price is not an opinion about her. It is the aggregate of everything anyone has launched and traded about her. The first launch makes a market in a person; the twentieth deepens it. What her token is worth is what that attention paid.

Her token is born heavy on purpose: a virtual reserve of 40 ETH against a supply of one billion, so a launch about her opens where a normal launch opens instead of near zero. Fame weighs at birth and in what accrues to her, never as a live price nobody has paid.

A launch fills when its sale range has taken 4.2 ETH of value, and that figure is the same for every launch about anyone, forever. What changes is how much of the star's token those 4.2 ETH buy: the amount is computed at the moment of the launch, at her price right then, and frozen into the width of the range.

This is the difference between a market that can keep growing and one that cannot. Fixing the threshold as a quantity of her token would put a ceiling on her: what a launch takes in stays in its pool for good, so a fixed quantity per launch divides a finite supply into a fixed number of launches and no more. Denominating it in value removes the ceiling. Each launch about a star costs the same to fill as the one before, takes fewer of her units than the one before because she is dearer, and the series never runs her supply out.

Read the figure for a given star with starPairUnitsFor(star, launchConfigId) on the factory, before the launch exists. Pass the zero address for a star who has no token yet and it prices the pool she would be born in.

Three steps, the same for every launch, and no migration anywhere in them. The entire supply of one billion is minted straight to the hook and placed in the pool, so nobody, the creator included, is holding tokens set aside before trading opens.

1. Create A name, a symbol, a handle and the launch fee. A Uniswap v4 pool is opened in the same transaction, against the star's token, which is itself created in that transaction if she does not have one. The creator may buy in the same call, at the opening price and exempt from the opening tax.
2. Trade the pool Anyone buys and sells in ETH through the Router, or through any router or aggregator that speaks Uniswap v4: it is an ordinary pool from its first block. The price rises as people buy and falls as they sell, and there is no waiting for anyone to add liquidity.
3. Cross the range The sale range is crossed when it has taken its threshold. Nothing is triggered by it and nothing is asked of a holder: everything paid in is already under the price, the reserve band still holds the rest of the supply above it, and trading carries on in the same pool at the same address.

A launch opens its pool at a tick computed from its phantom reserve, and the factory mints two positions there in the same transaction. The sale range runs from that opening tick to the far end and holds 71.43% of the supply; the reserve band runs from the far end to the top of the usable grid and holds the rest. Both have the same liquidity, and both belong to the hook.

A concentrated range with constant liquidity is a constant product with virtual reserves, so the price path along the sale range is the same one a bonding curve with that phantom reserve would have walked, to within the tick grid. What it does differently is that it is a real pool: the price is on chain, the trade is a swap, and anything that reads Uniswap v4 can read it from block one.

Neither position has a way out. The hook has no function that removes liquidity from them, so what a buyer pays in stays in the pool and sits under the price as a standing bid. Selling back cannot push the executable price below the opening tick against the launch's own liquidity, because nothing whatevr placed holds quote below it. The pool is open to anyone else's liquidity, and someone who puts quote below the opening tick is buying with their own money: the guarantee is that whatevr never does, not that nobody can.

A star's own token is quoted in ETH, in a pool of its own, on the same two positions. Her range is sized for 4 ETH, about what one launch about her costs to fill, so from her first launch onwards everything about her has a price the rest of the world can read.

For the first 5 seconds of a launch, a buy pays 98% to the treasury, decaying to zero across the window. It is not protection and it is not called that: it is a toll that makes the first instants worthless to anyone racing for them, on a chain where the only edge available is latency. The creator and the addresses they declare are exempt on their own launch, and the same exemption covers the star's pool, which their launch may have opened in the same transaction.

currentSnipeTaxBps(poolId, account) on the FeeHook gives the live figure for an address, already bounded, which is what a swap would really pay. The window a pool was registered with is in launches(poolId) as launchedAt, snipeTaxStartBps and snipeTaxSeconds. The toll is charged in the hook, alongside the fee and the extra; what it collects is the platform's, and it is filed apart as penalty.

One percent of every trade, from the first block of the pool, plus an extra of up to 9% that the creator sets for their own launch on top of it: a trader pays 10% at most. Of that one percent, 0.30% is the platform's, frozen at launch, and the remaining 0.70% is the launch's fee slice, which goes whole to one recipient the creator names: themselves, the star, the holders of the token, or liquidity. The extra is the part that divides, between those same four, on shares fixed at launch.

There is no floor for the star: a launch may leave her nothing. Her own token is where she always earns: it carries no extra, and the whole of its slice is hers. What goes to liquidity is nobody's. The LP share waits in the hook and is placed as a band of liquidity beside the price, which nobody, whatevr included, can remove.

What accrues to a star waits in her name until she claims it by posting from the handle the launch declared. Nothing about that is automatic, and nothing about it assumes she wants it. The arithmetic is worked out on the fees page.

Name

Robinhood Chain

Chain id

4663

Explorer

https://explorer.mainnet.chain.robinhood.com

An earlier deployment of whatevr is still on chain and is no longer maintained. Its launches are not listed here and this site does not follow them; they are named on the legacy page. The addresses above are the ones in force.

Each launch also deploys its own LaunchToken. For any launch token, getLaunchedToken(token) on the factory returns its record, in this order: token, deployer, creatorFeeRecipient, pairToken, starId, graduationThreshold, poolFee, tickSpacing, tickOpen, tickClose, extraBps, platformShareBps, sliceTo, extraCreatorBps, extraStarBps, extraHolderBps, extraLpBps, isStarToken, exists and liquidity. sliceTo is who takes the fee slice: 0 the creator, 1 the star, 2 the holders, 3 liquidity. The four extra*Bps are how the extra divides and always make 10000. tickOpen and tickClose are the ends of the sale range and liquidity is the L both positions were minted with; graduationThreshold keeps its name from before the curve was removed and is the quote that range takes when it is crossed. poolKeyFor(token) gives the pool the launch trades in.

Printed from the ABIs this site is built with. Ownership transfers, which every owned contract inherits, are left out. A pool id prints as bytes32, which is what a v4 PoolId is.

Start from the record. A zero pairToken means the launch is priced in ETH. Anything else is the star token it is priced in, and every amount its pool emits is in that token's units. starId is the keccak256 of the lowercase handle, which starIdOfHandle(handle) computes on the factory and on StarVault.

The price is the pool's. Every Swap the PoolManager emits for a launch's id carries the sqrtPriceX96 and the tick it left behind, and the price of the token in its quote asset is (sqrtPriceX96 / 2^96)^2, inverted when the launch token is currency1 of the pair. Market cap is that price times the launch's supply.

A range with constant liquidity behaves as a constant product with virtual reserves, so the same figures can be read as reserves when that is easier: L * 2^96 / sqrtPriceX96 of currency0 and L * sqrtPriceX96 / 2^96 of currency1, with L the liquidity in the launch record. Take L from the record and never from getLiquidity: a star nobody has bought yet has her sale range out of range, and the pool manager answers zero.

How far a launch has travelled along its sale range is linear in the sqrt price, because the quote a constant liquidity range takes between two prices is: it is (sqrtPrice - sqrtPriceAtTick(tickOpen)) / (sqrtPriceAtTick(tickClose) - sqrtPriceAtTick(tickOpen)), read in the direction a buy moves the price, and it equals the quote taken in over the launch's graduationThreshold. At the whole, the range is crossed. Nothing is emitted for it because nothing happens: the pool carries on.

Volume adds the absolute amount of the quote leg of each swap. LP's own additions are not swaps and never enter it, so a launch that sends much to LP never reads as demand.

Every charge ends in FeeDistributor.file(launchToken, currency, fee, tax, penalty), and ChargesFiled says how it divided. The opening tax arrives as penalty, apart from the fee, and is the platform's whole. The fee splits next: fee * platformShareBps / 10000 joins the penalty in toPlatform (platformShareBps is the launch's own, copied from the factory's default of 3000 when it launched, and never above the factory's MAX_PLATFORM_SHARE_BPS of 3000), and the rest is the launch's fee slice. The extra divides four ways, each part floored: tax * extraCreatorBps / 10000, and the same for the star, the holders and liquidity. The slice, plus whatever the four floors left of the extra, goes whole to sliceTo, so a launch that divides unevenly rounds towards the one it named. The five destinations, toPlatform, toCreator, toStar, toHolders and toLp, always add up to fee + tax + penalty. The caller files the gross and sends fee + tax + penalty - toLp: the LP part never reaches the distributor, because the hook keeps it for the liquidity it owns.

Balances sit in three contracts. What waits for a star is StarVault.bucket(launchToken, currency), one balance per launch and currency, and walletOf(starId) is the zero address until the star claims. From then on each credit goes to that wallet through the escrow instead of into the bucket. What an account can withdraw is FeeEscrow.balanceOf(account) in ETH and balanceOfToken(account, token) in a token. The holders' share of a launch that is not yet in an epoch is HolderRewards.pool(launchToken, currency).

The FeeHook charges every swap from the pool's first block, with the hookFeeBps and extraBps the pool was registered with (launches(poolId) returns them with the launch's platformShareBps, sliceTo, its four shares and its opening window). Both are taken from the swap's unspecified leg. The Router's swaps are exact input, so that leg is the output: a pool buy is charged in the launch token, and a pool sell in the quote asset. The charges wait in pendingFees(poolId, currency) and pendingCreatorTax(poolId, currency) until sweep files them with the distributor, in the currency they were taken in. LP's part of each swap accrues in pendingLp(poolId, currency) instead, and anyone may call addLiquidity(poolId, currency) to place it as a band of liquidity the hook owns beside the price (bands(poolId, i), bandCount(poolId)) and compound(poolId, band) to put a band's earnings back into it. The hook has no function that takes a band's liquidity out.

ETH figures for a launch priced in a star token are converted at that token's time weighted average price over the last hour, and a charge taken in a launch token at that token's own average, converted the same way. Where there is no price on record the figure reads unavailable rather than a guess.

Volume is attributed pool by pool. The PoolManager is shared by every pool on the chain, but each Swap carries its pool's id, and every launch announces its pool once, in the FeeHook's PoolRegistered, in the transaction that created it. A swap whose id is one of those belongs to that launch, whoever sent it, and the absolute amount of its quote leg is added to the launch's volume.

What a swap does not carry is the wallet behind it. Its sender is whatever contract called the PoolManager. When that is the Router, the Router's own RouterBuy, RouterSell or Launched in the same transaction names the wallet, and that is the wallet this site shows. A swap sent through any other contract is shown under that contract's address.

Nothing has to be integrated for a launch to be tradeable. The pool is an ordinary Uniswap v4 pool with our hook on it, so any router, aggregator or indexer that speaks v4 reaches it from the block it was created in. The Router is a convenience, not a gate: it turns ETH into the star's token and then into the launch token in one unlock, and passes the tax subject on both legs.