Coverage

What this archive misses, and why

Two different claims hide inside the word complete, and only one of them is nearly true. Every launch on the venues this archive follows ends up with a row. Not every launch was watched as it happened. The first is what the chain guarantees to anyone who reads it. The second is what this archive is for, and it is 94.35% of the record. This page states the difference, where it comes from, and what it costs.

The two populations are never summed on this site. The gap between those last four rows is the whole mechanism, and an average would hide it.

Three reasons, in the order of how much they cost. Two of them are other people's infrastructure and the third is ours.

The feed is a subscription, not a guarantee. A node is asked to report transactions touching a venue. It matches them, queues the notifications and pushes them down a socket. That queue has a size. Under load it overflows and the node drops what will not fit, and says nothing: there is no sequence number, no acknowledgement and no gap marker, and the connection stays open and busy throughout. The loss is therefore invisible from the socket and can only be found by comparing against the chain afterwards.

It scales with how busy the chain is, which is what the record shows when its hours are ranked by traffic. Over the 14 complete days to the last one measured, the quietest quarter of hours carried about 1,470 launches each and 96.3% of them were observed at the creation transaction. The busiest quarter carried about 3,118 each and 92.3% were. Same code, same endpoints, same fortnight: the difference is the queue.

The subscription is blind to some transactions by construction. It matches static account keys, so a launch that reaches the venue through an address lookup table is never delivered at all, however healthy the connection. This archive published that failure as a correction when it was found: pumpfun-router-launches-unrecorded, 7,330 launches over eight days, about 2.4% of the venue.

The collector restarts. A deployment costs about two and a half minutes during which nothing is watched, roughly a hundred launches, which is about two tenths of one percent of a day. It is the smallest of the three and the only one inside this archive's control, which is why releases are batched.

A second reader runs beside the feed and reads whole blocks, which cannot be filtered or deafened. It recovers the row for launches the feed missed, and those rows carry late_discovery in the published record permanently, so no reader has to take this page's word for any of it.

What it cannot recover is what the row would have carried. There is no trade stream for the first seconds, so the early buyers of a recovered launch are not stated. The launch document and the image are fetched when the launch is found rather than when it happened, and by then the host may have stopped serving them. The table above states the result without inference: 96.2% of launches observed at creation have their document here, against 70.3% of launches recovered afterwards.

How fast a document stops being served is measured directly, by re-reading documents this archive already holds and recording what the address answers now. Of 5,841 re-read from ordinary hosts, which the launcher can withdraw or edit at any moment, 1,016 (17.4%) are no longer served at all and 19 now serve different bytes. Of 22,724 re-read from content-addressed storage, where the address is the hash of the bytes and changing them is arithmetically impossible, 1 has gone. Those documents are readable here because a copy was taken at the launch. Nowhere else holds them.

The creation transaction, the signing wallet, the exact second and the creator's first-block share are on chain and permanent. Anyone can reconstruct them at any time, from any archival node, with or without this archive. Everything on this page concerns the other half of the record: what a launch said it was, which exists only where somebody copied it at the time.

Every figure above is computed from the record being served at the moment this page was requested, built 2026-10-17 00:14 UTC. The population split is the late_discovery column, and the document and artwork columns are meta_sha256 and image_sha256; the record database carries all four, so these counts can be recomputed and disputed. Coverage begins 2026-09-02 12:29 UTC. Errors this archive has found in its own published statements are listed in the corrections register, 21 of them, and the method states what is recorded live and what is read from chain.