Coverage
What we watch, and — more usefully — what we do not.
Chains
| Chain | Status | Notes |
|---|---|---|
| Base (8453) | Live | The original chain. Deeper pools, slower alerts. |
| Robinhood Chain (4663) | Live | Faster alerts, pools roughly 3× thinner — median $14.8K against Base's $44.5K. |
A liquidity floor that feels sensible on Base will silence most of Robinhood. If you filter both chains with one number, you are effectively filtering one of them out.
Venues
On Base we watch the factory contracts directly — no aggregator sits between us and the chain:
Uniswap V4 · Uniswap V3 · Aerodrome · Aerodrome Concentrated · Clanker (V3 and V4 factories) · Virtuals · Zora (four separate creation events) · Flaunch · Base.fun
On Robinhood Chain: Pons · Pons V2 · LaunchHood
We subscribe to creation events, so a launch is seen when the transaction lands — not when an aggregator gets round to indexing it.
How fast an alert actually arrives
Honestly: minutes, not milliseconds. Measured medians are around 22 minutes on Robinhood and 56 minutes on Base, from pool creation to alert.
That is not processing time. Nearly all of it is one deliberate gate.
The gate, and why it costs you an hour
A token is admitted to the pipeline only once it has a paid DexScreener profile. Somebody connected to the project has to spend money before we will look at it.
It is a crude filter and we know it. It is also the only reliable one we have found that separates a token somebody cares about from the thousands of throwaway contracts deployed every day. Every alternative we have tested either lets the flood through or requires trusting a signal that can be faked for nothing.
The cost is stated plainly: we are waiting on a third party's purchase decision, and that wait is most of your latency. If being first matters more to you than being sure, we are the wrong tool — and we would rather write that here than let you find out over a month.
We are not a sniper and do not try to be. We see the launch immediately; we then wait, because the sell simulation, the deployer trace and the social read all take time. We would rather tell you something true a few minutes in than something fast and wrong.
What we knowingly miss
- Tokens nobody ever pays to profile. Including, occasionally, real ones. This is the direct cost of the gate above.
- Launches on venues not in the list. A new launchpad works only after we add its factory.
- Anything that happens after we measured. Every number on a card is a snapshot.
- Tokens that were indexed late. We re-check these, but a late-indexed launch arrives late by definition.
What runs where
Three independent systems, which is why one being down does not take the others with it:
| Detection and scoring | Its own server, per chain. Watches factory events, enriches, scores, renders. |
| Delivery and filtering | A separate process that reads finished alerts and matches them against your filter. It shares no code with the pipeline, so changing your filters cannot affect what gets detected. |
| These docs | Static, built from markdown. Nothing here talks to the API — a broken backend cannot take the documentation down. |
➡️ See also: The safety stack · Filters
Anything on this page unclear, or wrong?
Tell us →