Robinhood Chain · Uniswap Liquidity Launcher
Every launch auction,
read before the money moves.
Archive · every launch to date
4378 launch auctions have run through the launcher. 975 became pools.
The gap is not neglect. Reading each auction directly shows that 3351 of them never reached a clearing price at all — nobody bid enough for there to be anything to migrate. Every auction that did clear was migrated; not one was left sitting. A further 38 reached migration and failed, which returns the raised currency and the reserved LP tokens to an address the deployer chose in advance.
How a verdict is made
Read the parameters
Deterministic checks decode the auction: where raised currency goes on every path, the LP allocation schedule, the committed pool, the recipient's history, and what the currency actually is.
Set the ceiling
Those facts fix the best verdict a launch can receive. A hard failure caps it at FAIL, a warning at FLAG. Nothing downstream can lift it.
Judge what scripts cannot
An agent reasons about hook behaviour, currency identity and deployer provenance, then classifies. It may lower the verdict below the ceiling. It can never raise it.
What gets read
Uniswap’s own documentation calls it “trivially easy” to configure an auction with malicious parameters, and tells you to validate every one yourself.
That is the whole job. These are the fields a verdict is built from — all public, all readable before an auction closes.
- recipient
- Who receives the raised currency and the reserved LP tokens if migration fails.
- allocation schedule
- How much of the raise is routed to liquidity, bracket by bracket, and how much exits.
- committed pool
- The exact fee, tick spacing and hook the launch has bound itself to.
- currency
- What the auction is priced in, and whether that asset is what its name claims.
- position plan
- Whether the configured LP positions can actually be created at the discovered price.
- migration window
- The block after which anyone may migrate, and whether it has passed unused.