METHOD

This is the source for the public /method page. Definitions here are binding on the crawler, the stats engine, the site copy, and the tests.

Source

• Chain: Robinhood Chain (chain id 4663, Arbitrum Orbit).
• Contract: PonsV2LaunchFactory 0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e (verified on Blockscout, no proxy).
• Events read:
  • TokenLaunched(token indexed, curve indexed, deployer indexed, pairToken, launchConfigId, graduationThreshold) — topic0 0x8d4aad4953d0ca700d468f3753aa14432d1b35b43ec6409f051fb6aa43a89607
  • PoolGraduated(token indexed, positionId, tokenAmount, pairTokenAmount) — topic0 0x0a44ef75df69c534f43cd6c1aa3ef8983065fe5fe79ef9e79f6494e6f258c259
• View read per launch: getLaunchedToken(token) → field [8] creatorTaxBps, field [4] pairToken, field [10] phase.
• Timestamps come from block headers (eth_getBlockByNumber(...).timestamp), never from a blocks-per-second conversion.
• RPC: https://rpc.mainnet.chain.robinhood.com, log queries in ≤1,000-block windows, ≤10k logs per query, with retry and backoff. Batch JSON-RPC is allowed.

Definitions

• Launch: one TokenLaunched event from the factory. Counted at its block timestamp.
• Graduation: one PoolGraduated event from the factory for a token that has a recorded launch. Counted at its block timestamp. A graduation for a token with no launch in our records is kept in the raw data but excluded from every rate (it cannot have a denominator).
• Time to graduation: graduation timestamp − launch timestamp, in seconds.
• Fast graduation: time to graduation < 300 seconds. This is a descriptive threshold, chosen because 67% of graduations in the first 20 hours completed inside it and 44% inside 60 seconds — faster than any organic discovery plausibly allows. It is not a claim about any individual token.
• Window convention: every window is the half-open interval [since, until) on launch timestamps — a launch at exactly since is inside, a launch at exactly until is the first launch of the next window. Adjacent windows therefore partition the timeline and no launch is counted twice at the seam. until is the run's crawledAt; all-time is since = null.
• The Pons Number (24h): graduations of launches whose launch timestamp falls in [crawledAt − 86400, crawledAt), divided by launches in that window. A graduation counts for its launch whenever it happens, including after until. Because a launch near the end of the window may still graduate, the number is a lower bound for the most recent hours; the page says so.
• Excluding fast graduations (24h): same denominator; numerator excludes fast graduations. Shown beside the Pons Number, never instead of it. Also displayed as "1 in N" where N = round(1 / rate).
• All-time: same two rates over every launch since the first block LEDGE indexed. number.json records both that block (firstIndexedBlock) and the timestamp of the earliest launch in the record (firstIndexedAt), so coverage can be stated in hours without converting block numbers to time — a conversion this method forbids everywhere else. Before anything is indexed, firstIndexedAt is null.

Precision

Rates are printed to the precision the sample supports: two decimals at n ≥ 1,000, one decimal below, and "not enough data (n=…)" under 30. A bucket that recorded no graduations prints the count it observed ("0 of 244") rather than "0.0%", which would read as a measured finding rather than an absent one.

Cohorts (all with n; n < 30 renders as "not enough data")

The n < 30 rule applies to every published proportion, not only cohort rates: the share of graduations under 300 s and under 60 s, and both deployer shares. Below 30 the share is null with insufficient: true — never 0.0, which would read as a measured finding rather than an absent one.

• Pair token: three buckets — ETH (pairToken == 0x0), stablecoin, tokenized stock/other. Bucket assignment uses the pair token contract's symbol(); the mapping table is public in the repo and any unknown symbol lands in "other" until classified.
• Creator tax: 0%, 1%, 2–3%, 4–5%, 6–10% (creatorTaxBps from getLaunchedToken).
• Hour of day (UTC): 24 buckets by launch timestamp.
• Day of week (UTC): 7 buckets; renders "not enough data" until every bucket has n ≥ 30.
• Pair token x creator tax: the two cohorts above crossed — 4 pair classes x 5 tax buckets, 20 cells, every cell published with its own n whether or not it can be printed. Most cells are under 30 launches and render "not enough data (n=…)"; that is the honest state of the measurement, not a gap. Each cell also carries the same rate excluding graduations inside 5 minutes, gated on the same n. A launch whose creator tax we could not read, or whose tax falls outside the documented range, has no cell and is counted in the cell grid's excluded total, exactly as it is in the one-dimensional tax cohort.
• Deployers (aggregate only): distinct deployers in window; share that launched 2+; share of launches from deployers with 10+; distribution of launches-per-deployer as a histogram. No addresses.

Time-to-graduation distribution

Percentiles p10 / p25 / p50 / p75 / p90 / p95 / max of time to graduation, over the same window as the rate shown. Rendered as a horizontal bar with those ticks. Copy: "9 in 10 graduations happened within {p90}". No boundary claims ("nothing after X") are made.

The ladder

Beside the percentiles, the same distribution is published as a step table at eleven fixed second marks:

30, 60, 120, 300, 600, 900, 1800, 3600, 7200, 14400, 21600

Each rung carries the raw count of graduations that completed in strictly less than that many seconds, and that count as a share of the window's matched graduations. Strictly-less is the same convention as the 5-minute cutoff, so the rung at 300 s is the share that graduated inside 5 minutes and the rung at 60 s is the share inside 60 seconds — the ladder and those two figures cannot disagree.

The counts only rise as the marks rise. The raw count is always published, so any share can be checked against it. Below 30 matched graduations the whole distribution is insufficient and every rung's share is null — the counts still say what was observed.

A graduation slower than the last mark belongs to no rung, so the last count can be below n. Nothing is claimed about that tail beyond max.

The marks are a definition. They exist so that anything asking "where does this elapsed time sit" reads a row out of the table rather than computing a percentage of its own; every published share comes from pipeline/stats.py and nowhere else. Moving a mark is a dated entry below.

Outcomes after a graduation

An outcome is a fact about a graduated token's price at a fixed point after graduation, never a verdict about it. For every graduation that has a pons pool, three marks are read: +1 hour, +24 hours, +7 days after the graduation. openingPrice is the pool's own price at the moment it was created — read from the Initialize log's sqrtPriceX96, never from a later block. At each mark, priceAt is the close of the last hour bar at or before that mark, and changeAt = priceAt / openingPrice − 1.

Where the price comes from: a pons graduation opens one pool on the single Uniswap v4 PoolManager pons uses. Initialize fires once, at creation, and carries the opening sqrtPriceX96; Swap fires per trade and carries the price after it. Every trade is folded into an hourly (pool, hour) bar — open, close, high, low, swap count, quote volume — and it is these bars, never a re-read of chain state at a past block, that every later price comes from. The price itself is the quote-per-token ratio derived from sqrtPriceX96, oriented by which side of the pool the launched token sits on.

No bar at or before a mark is its own outcome, noTrade — recorded as a fact (nobody traded the token in that window), never as a price of zero and never dropped from the count.

A mark that has not yet elapsed for a graduation is not counted toward that mark's n at all. It is not noTrade — noTrade means the mark happened and nothing traded; an unelapsed mark simply hasn't happened yet, and pretending otherwise would either invent a price or fabricate a zero.

A pool with unknown decimals never gets a guessed price. Its graduation is counted in withoutPrice, published beside every cohort it belongs to, and excluded from that cohort's n and medians entirely — never silently dropped, per CONSTRAINTS.md #5.

Every mark is reported by three independent cohorts, each reusing a definition already published elsewhere rather than inventing a new one:

• Time-to-graduation bucket — the same descriptive marks already on /graduated: under 10 s, 10 s to 5 min, over 5 min.
• Pair token — the same four buckets as every other pair-token cohort.
• Creator tax band — the same five buckets as every other tax cohort.

Per cohort and per mark, the published figures are: n, the count and share that were noTrade, the count withoutPrice, and the median, p25 and p75 of changeAt. Medians and quartiles are published, never means — a single token up 50x would otherwise carry an entire cohort's average on its own. Below n = 30, the row is insufficient: every quantile and the noTrade share print null, exactly as ttg_percentiles and every cohort in this file already do. The raw counts (n, noTrade, withoutPrice) are always published regardless of n, because a denominator is never the thing withheld.

These figures describe populations, never a token. "Tokens that graduated in under 10 seconds: median change at +24 h −78% (n=412)" is a fact about that cohort on the day it was measured. It says nothing about what any individual token that graduated in under 10 seconds will do, has done beyond that fact, or should be treated as. Nothing here predicts anything, and no reading of these numbers as a forecast is supported by how they are computed. CONSTRAINTS.md #1 binds here exactly as it binds every other figure on this site.

Only about a day of pool data exists as of 2026-09-12, so almost every cohort currently prints "not enough data (n=0)" or close to it at every mark. That is the correct and honest state of a measurement that started a day ago — it is not worked around, and the backfill that fills it in is separate, later work.

Freshness

• The crawler runs hourly. Each run records crawledAt and headBlock.
• crawledAt is chain time, not clock time. It is the block timestamp of the last block LEDGE indexed (headBlock), read from that block's header like every other timestamp here — never the wall clock of the machine that ran the crawl. A window closing at a wall clock reaches past the chain LEDGE has actually read: those minutes hold no launches because they were never scanned, and every rate computed over them is divided by a denominator that is missing them. The crawl records the instant in state.json as lastIndexedAt; recompute.py reads it straight back as crawledAt.
• A run that indexes nothing new does not move it. crawledAt advances only when the cursor advances. A backwards backfill, which extends the record into older blocks and leaves the cursor alone, leaves crawledAt exactly where it was.
• Every rendered figure shows "updated {age} ago" computed from crawledAt.
• Age is the consumer's computation, not a field. number.json is a static file and cannot age its own contents. Any consumer — the page, the card, a third party reading /number.json — computes now − crawledAt and compares it to the published staleAfterSeconds (1800; 7200 before 2026-09-13). If crawledAt is older than that at render time, the page shows the stale banner.
• lastRunAt and lastSuccessAt in state.json stay wall-clock times. They answer one question — did the run that wrote this file know it was already behind — and feed the stale flag below. They are never published as crawledAt.
• stale in the file means one thing: the run that generated the file knew it was already behind — it recorded a failure since its last success (consecutiveFailures > 0, or lastRunAt after lastSuccessAt, or no successful run yet). A successful run publishes stale: false however old the data later becomes. A failed run commits nothing at all, so crawledAt simply ages and the banner appears from the age computation above.

Reproducibility

• Raw data: data/launches/YYYY-MM-DD.jsonl (one line per launch: token, curve, deployer, pairToken, pairClass, creatorTaxBps, block, ts) and data/graduations/YYYY-MM-DD.jsonl (token, block, ts, pairTokenAmount).
• Computed: data/number.json — every figure on the site, with its n and window.
• scripts/recompute.py regenerates number.json from the raw files with no network access. CI runs it and diffs against the committed file; a mismatch fails the deploy.
• Anyone can run the same script against the same files and get the same numbers.

Frozen 2026-09-17. Written 2026-09-12 from data/number.json as of crawl 2026-09-12T06:06Z. REVAMP.md 1.5 says this must exist, dated and immutable, before the token does, or it is worthless. The commit that carries this line is the hash shown in the homepage slot, on /launch and on /method; nothing above the "Outcome" heading is edited after it.

Owner decisions, 2026-09-12. Creator tax 3%. Both commitments below confirmed as written.

Launch window, decided 2026-09-17: Friday 19 September 2026, 16:00 UTC. Chosen for when most of the venue is awake: 58% of all pons launches on record are made between 14:00 and 24:00 UTC (n = 273,991), and 16:00 is the middle of that band. It was not chosen from the hour-of-day graduation rates, which this document says below it does not use. Friday happens to be the day with the highest rate excluding fast graduations on the record as of this date (0.95% of 17,566); that is noted so nobody can later say it was hidden, and it played no part in the choice.

What this is and is not

This is a statement, before the launch, of what we expect and what we will publish afterwards, so that nobody — including us — can tell the story differently once the outcome is known.

It is not evidence the tool works. One launch is n=1, and treating a single outcome as proof is the error this site measures other people making. What it demonstrates is method. The failure case is worth more than the success case: nobody else on this venue will publish "we said this, we got that, we were wrong."

What is being launched

• Name / ticker: LEDGE. Venue: pons, Robinhood Chain (4663).
• Pair token: ETH. Graduation threshold: 4.2 ETH (per pair token; read from the factory at launch and shown on /t/{address}).
• Creator tax: 3%.
• Description: the 146-character line in LAUNCH.md.

The reference class, from the published record

The cohort this launch belongs to is ETH-paired with a 2–3% creator tax. All-time as of the crawl above:

	launches	graduated	share	excluding graduations inside 5 min
ETH × 2–3% tax	23,353	588	2.52%	1.37% · 1 in 73
all ETH-paired	81,694	1,353	1.66%	0.82%
all 2–3% tax	32,033	768	2.40%	1.27%
every launch	168,993	3,005	1.78%	0.72% · 1 in 140

Of the graduations that happen, 15% finish inside 10 seconds and 60% inside 5 minutes; the median is 167 seconds.

That is the base rate: about 1 in 40 launches like this one graduates at all, and about 1 in 73 graduates in a way that took longer than five minutes. Any expectation below is against that number.

What we commit to, checkable by anyone

1. The creator wallet does not buy on the curve. Not in the launch block, not after. /t/{address} shows distinct buyers in the launch block; a graduation "in 8 seconds with 1 buyer" would put this launch in the population the site describes, and we would say so on the front page.
2. No buys are arranged. No bought volume, no coordinated fill. The only thing done to promote the launch is telling people it exists.
3. Every reading is published as it happens, from the same index and under the same definitions as every other token, on the front page: first-block buyers, fill, time to graduation or not, and — once the outcomes tracker runs — price at +1 h, +24 h and +7 d after graduation.

What we expect

Stated as ranges against the base rate, not as a forecast for the token:

• Graduation. The base rate is 2.5%. This launch has one thing the base rate does not measure: a room of people who already trade on pons and were told about it in advance. We expect that to matter and cannot say by how much. We do not expect the launch to fill in under five minutes (commitment 1 and 2 make that very unlikely, and if it happens we will investigate who bought and publish what we find).
• If it graduates, the timing will look like the slow population, not the spike: tens of minutes to hours, not seconds. Anything under five minutes contradicts this and will be reported as such.
• If it does not graduate, that is the base-rate outcome, and it is published in exactly the same place with the same prominence.

What we are not using

The hour-of-day effect. METHOD.md (2026-09-10) records why: raw and organic orderings by hour barely agree, crowding explains a fifth of it, and the whole thing may be who launches at that hour rather than anything about the hour. The launch time is chosen for when the room is awake, and this document does not claim the data supports that choice.

How it is judged

• The token's /t/{address} page is the record. Its readings at launch +1 h, +24 h and +7 d are copied into the "Outcome" section below with their measurement times.
• Matched / not matched is stated for each expectation above, in one line each, without narrative.
• The outcome is posted on /method with the date and this file's pre-launch commit hash, and the homepage slot that carried this document carries the outcome.

---

Outcome

Token: LEDGE, 0xdf6f7daf68990e5e9ce25fc71579e29b44132295. Launched 2026-09-19 16:25:25 UTC in block 67223550 from 0xBCc4d6E6B0e748770F9733AB42C0231E97F7333F, 25 minutes after the window above. The launch transaction carried no buy.

Readings, from /t/0xdf6f…2295, with their measurement times:

read at (UTC)	elapsed	buys	sells	curve fill	buyers in launch block
2026-09-19 16:29	4 min	0	0	0.00 of 4.2 ETH	0
2026-09-19 18:10	1 h 45 min	0	0	0.00 of 4.2 ETH	0
2026-09-19 21:34	5 h 9 min	0	0	0.00 of 4.2 ETH	0
2026-09-20 21:59	29 h 34 min	0	0	0.00 of 4.2 ETH	0
+7 d	(due 2026-09-26)

The activity index counts every buy and sell on the curve from the launch block onward, so the +1 h reading is the 18:10 row: nothing traded between the two.

Expectations, matched or not:

• Creator wallet does not buy on the curve: matched. 0 buyers in the launch block, no buy in the launch transaction, 0 buys since.
• No arranged buys: matched. 0 buys.
• Every reading published as it happens: matched. The token page from the launch block; front pages No. 2, 3 and 4 on X at 4 min, 5 h and 29 h.
• No fill inside five minutes: matched.
• Graduation: not graduated at 29 h. The base-rate outcome, as the document says above. If it graduates, slow: not applicable so far.
• Published in the same place with the same prominence: matched. This section, on /method, and the homepage slot.

Reference, from the record as of the 29 h reading: 44.2% of launches in this cohort (ETH pair, 2–3% tax) took no outside buy in their first hour (n = 52,197). 94.3% of all graduations were done within 6 hours (n = 4,717). In a sample of 200 matured launches read on 2026-09-08, 93.5% had raised nothing on their curve.

+7 d reading and the closing line to follow on 2026-09-26.

---

Settled 2026-09-12: creator tax 3% (the 2–3% cohort has the highest graduation share in the record, 2.52%; 4–5% halves it to 0.77%), and commitments 1 and 2 confirmed as written.

Erratum, 2026-09-18. The launch window above says "Friday 19 September 2026". 19 September 2026 is a Saturday. The date and hour stand: 19 September 2026, 16:00 UTC. The weekday was wrong, and the sentence about Friday's graduation rate therefore describes a different day from the one chosen. On the record as of this date Saturday's rate excluding fast graduations is 0.81% of 33,623 launches. As the document already says, the day played no part in the choice. Nothing above the Outcome heading is edited; this note is the correction.

Filled 2026-09-17: the launch window, above. It was the last thing decided, deliberately, because the data layer had to be solid before the launch post pointed at it.

• 2026-09-13 — staleAfterSeconds lowered from 7200 to 1800. No figure changed; only the bound after which a consumer shows the stale banner. The crawl moved from GitHub's scheduler, which skipped and queued runs, to a timer on LEDGE's own box that runs every 10 minutes and finishes in under two, measured over 13 consecutive pushes on 2026-09-13. Thirty minutes is three missed runs — a stall, not a queue — and that is what the banner is for.

• 2026-09-13 — new definitions, no existing figure changed: first-buy timing.

  Live windows measured today, ~18:00Z (819 CurveBuy logs per 1,000 blocks, 35 launches; over 6,000 blocks, 207 launches, 183 with a buy in range): 158 of those 183 first buys were in the launch transaction itself (same transactionHash as TokenLaunched), and the buyer topic equalled the deployer in only 3 of them — so the launch's own opening buy is routed through something other than the deployer's address in almost every case. Of the 149 launches whose first buy was outside the launch tx, 80 landed within 0–9 blocks (roughly a second) and 26 within 10–19 blocks. "First buy" therefore has two different meanings, kept apart as two record kinds rather than folded into one figure: the launch-tx buy (the launch's own opening buy, inLaunchTx: true) and the first outside buy (the earliest CurveBuy on that curve from a different transaction, inLaunchTx: false). Sniping is a statement about the second, never the first — a launch-tx buy tells us nothing about who bought it, only that the curve did not open empty.

  For every launch at or after a new state field, firstBuyIndexedFromBlock — set once, on whichever run first finds it absent, to that run's own scan start, and never moved again — the crawl now also reads every CurveBuy in its scanned windows, by topic0 alone with no address filter (each launch deploys its own curve; there is no single contract to filter to). Launches before that block were never read for buys at all, so a "first" for them would be false; they are outside the population entirely, not a zero. Timing is ts(buy block) − ts(launch block) in whole seconds from block headers (never a block-count conversion, per this file's own rule above), and "same block" is a block fact checked before any arithmetic on seconds, its own bucket regardless of what a delta computed from timestamps would otherwise say.

  Published as number.json's new top-level firstBuy block, over the whole record (no h24 split): population is every launch at least one hour old at crawledAt and at or after indexedFromBlock. Three cohort dimensions — all, taxBucket, pairClass — each row carrying n, the count and share with a launch-tx buy, and a six-way exclusive breakdown of the outside buy's timing (sameBlock, within1s, within3s, within5s, after5s, none), where within1s is delta ≤ 1 s, within3s is 1 s < delta ≤ 3 s, within5s is 3 s < delta ≤ 5 s, and after5s is everything slower. Cumulative shares (sameBlockShare through within5sShare) fold in every bucket at or before them, exactly as the existing ladder does; noneShare is not cumulative. Below n = 30 every share is null with insufficient: true and the raw counts are still published, the same rule as everywhere else in this file (CONSTRAINTS.md #4).

  No wallet address is ever written to a first-buy record (CONSTRAINTS.md #2). The buyer is decoded only long enough to compare it against the launch's own deployer address; the comparison's result, buyerIsDeployer, is what is written, never the address itself.

  Raw data: data/firstbuys/YYYY-MM-DD.jsonl, partitioned by the buy's own block timestamp like every other partition and deduped on the buy's (txHash, logIndex).

• 2026-09-12 — new definitions, no existing figure changed: outcomes after a graduation, the "Outcomes after a graduation" section above. openingPrice, priceAt and changeAt at +1 h / +24 h / +7 d after a graduation, computed from the pons pool's own Initialize and Swap logs on the single Uniswap v4 PoolManager pons graduates into; noTrade as its own outcome rather than a gap; an unelapsed mark excluded from that mark's n entirely rather than counted as anything; a pool with unknown decimals counted in withoutPrice and excluded from medians, never guessed. Published per time-to-graduation bucket, pair token and creator tax band — the same bucket definitions already used elsewhere in this file — as median, p25 and p75 of changeAt, never a mean, gated at n = 30 like every other quantile here. As of this date almost no cohort clears n = 30: only about a day of data/pools/ history exists, and every mark reads "not enough data (n=…)" or close to it. This is the expected state of a day-old measurement, not a defect, and it is not worked around. Nothing here predicts anything or scores a token — CONSTRAINTS.md #1 applies to outcomes exactly as it does to every other figure.

• 2026-09-10 — what a graduation completing in under a second can and cannot tell you. No figure changed; this entry constrains how the published ones may be read, including by us.

  Blocks on this chain arrive about every 0.101 seconds, measured across the whole indexed record. So a graduation recorded at zero seconds after its launch is not necessarily in the same block as that launch: of 102 such graduations, 18 are in the launch's own block, 54 are one block later and 21 are two blocks later. "Zero seconds" means within one second, which here is roughly ten blocks.

  What that supports: no person saw the launch, decided to buy, and acted. One second is below human reaction time, and a curve that fills in that window filled without anyone discovering it.

  What it does not support, and the site does not claim: that the deployer filled their own curve. A sub-second fill is equally consistent with an automated buyer watching for TokenLaunched and acting on it, which is not the deployer and is not coordination — it is a bot doing on this venue what bots do on every venue. Distinguishing the two needs the buyers' identities, and CONSTRAINTS 2 forbids printing a wallet as a subject, so this site will not be the thing that distinguishes them.

  This is why every published surface states the duration and stops. The word "self-filled" does not appear on the site, no bucket is labelled, and the 5-minute mark stays a descriptive threshold under CONSTRAINTS 6. A reader may conclude what they like from eight seconds; the measurement supports "nobody discovered this in time to buy it", and it does not support "the deployer bought it".

  Recorded because the temptation to say the stronger thing is the standing risk of this project, and because an earlier internal framing did say it.

• 2026-09-10 — a published finding has partially reversed, and this entry is the reversal. No definition changed; the data moved.

  On 2026-09-07 the front page stated that, once graduations completed inside five minutes are excluded, the pair token makes no difference. On the record as it stood that was right, and it was the correction of an earlier artifact: the raw rates differed by pair while the organic rates did not.

  Measured today over the whole indexed record, the ETH and stablecoin halves of that claim still hold and the third does not. Excluding graduations inside five minutes: ETH 0.82% of 66,713 launches, stablecoin 0.81% of 18,119, tokenized stock 0.47% of 58,106, other 0.73% of 961. ETH and stablecoin remain indistinguishable from each other. Tokenized stock is running at roughly half their rate, on a sample large enough that this is not sampling noise.

  Counting every graduation rather than only the organic ones, the same buckets read ETH 1.68%, stablecoin 3.00% and tokenized stock 1.36%, so the ordering is different again depending on which rate is read. That is the same trap the 2026-09-07 entry describes and it has not gone away.

  The superseded claim is kept here rather than edited away, per CONSTRAINTS 5. The sentence "the pair token makes no difference" has been removed from the site, because it is no longer true as stated. Nothing replaces it as a headline: the four pair cohorts are on /cohorts with their own sample sizes, and a reader can see the split without being told what it means. No mechanism is offered for why tokenized stock differs, because none is known.

• 2026-09-10 — no new figure and no definition changed. This entry records an analysis whose result was weaker than it first appeared, because the figures it concerns are already published on /cohorts and a reader is owed what is known about them.

  The question was whether the hour of day a launch is made relates to whether it graduates. Across 143,899 launches in hours with at least 200 launches each, the rate excluding graduations that completed inside five minutes ranges from 1.03% in the 02:00 UTC hour, one in 97, to 0.43% in the 23:00 hour, one in 232. That is a spread of about 2.4 times, and the two extremes are further from the pooled rate of 0.68% than sampling alone at that rate would ordinarily produce. By day of week the spread is about 1.7 times, from 0.86% on Sunday to 0.52% on Tuesday.

  Three things then made it much less useful than that sounds, and all three are the reason no "when to launch" page was built.

  First, ranking the hours by raw graduation rate and by the rate excluding fast graduations produces almost unrelated orderings: the rank correlation between them is 0.15 across the 24 hours. The 23:00 hour has one of the highest raw rates and the lowest organic rate. Any reading taken from raw hourly rates, here or anywhere else, is therefore close to uninformative about organic outcomes.

  Second, the obvious mechanism does not carry it. Launch volume per hour correlates with the organic rate at about −0.46, so crowding accounts for roughly a fifth of the variation. Pooling the twelve quietest hours against the twelve busiest gives one in 140 against one in 152, a difference far too small to act on.

  Third, and decisively: this is an association in a record of what was launched, not a mechanism. It may reflect who launches at 02:00 rather than anything about 02:00. Nothing here separates the hour from the population of deployers active in it, and the site does not have the data to.

  So the hourly and daily cohorts stay exactly where they are on /cohorts, each carrying its own n, described as what launches made in that hour did. They are not presented as a choice a launcher should make, and no page ranks hours as better or worse to launch in. Publishing a 2.4-times figure as guidance would be a prediction wearing a denominator, which CONSTRAINTS 1 forbids and which the evidence above does not support.

• 2026-09-10 — one new published figure, no existing definition changed: the distribution of times to graduation, in fourteen buckets that each roughly double the last, published as allTime.ttg.histogram and h24.ttg.histogram beside the ladder that was already there. The edges are 0, 2, 5, 10, 20, 40, 80, 160, 320, 640, 1,280, 2,560, 5,120 and 10,240 seconds; the last bucket is open-ended and holds everything slower. Each bucket is half-open, [fromSeconds, toSeconds), the same convention the windows use, so a graduation landing exactly on an edge belongs to the bucket above and is never counted twice. The buckets therefore sum to n, which is what separates this from the ladder: the ladder's last rung can sit below n because graduations slower than its final mark are counted in no rung, and that is correct there. Moving any edge here moves a published figure and takes its own entry, exactly as moving a ladder mark does.

  Why doubling rather than equal width: graduation times run from under a second to over four days, so on an equal-width axis effectively the whole record is one bar and the drawing says nothing. Why the first edge is 0 rather than 1: a launch and a graduation in the same block differ by zero seconds, and a first bucket that could not hold them would omit the case the figure most exists to show.

  What it showed, measured 2026-09-10 over 2,474 graduations that have a launch on record: the distribution is not one hump but two, with a trough between them. 158 graduations completed in under two seconds and 96 in the two-to-five-second bucket above it, while the broad hump peaks at 285 in the 160-to-320-second bucket. The counts are published with every bucket so the shape can be checked against the numbers.

  What it does not say: it describes how long graduations took and nothing else. No bucket is a label, none is coloured differently from any other, and the 5-minute mark's rule applies to every edge on it — these are descriptive thresholds and never a definition of "rigged". A reader draws their own conclusion from a two-second graduation; the site does not draw it for them.

  Also recorded here because it is a finding that did not survive: a proposed figure counting which second of the minute graduations fall in was computed and rejected before publication. Over 2,465 graduations the chi-square against a uniform distribution was 63.0 on 59 degrees of freedom, where roughly 79 would be needed for significance at the 5% level. There is no clustering, so there is nothing to publish. It is noted rather than dropped silently because a measurement that found nothing is still a measurement, and the next person to have the idea should be able to see that it was tried.

• 2026-09-09 — no figure and no definition moved; this entry records a change to CONSTRAINTS.md, which clause 9 of that file binds to the same rule as a definition. Clause 1 was split: scoring, predicting and recommending an individual token stay banned, and ranking by a measured quantity became permitted provided the quantity is shown on the page it orders. A list ordered by buys, curve fill or age is an ordering of facts; "most promising" would still be a verdict. Clause 8 was relaxed to permit an optional email field, no wallet or account still required to read anything. Clause 10 was rewritten from a general instruction into the concrete rule pons's own documentation asks for: write the name in lowercase, link back to the app, carry a non-affiliation line. Clause 11 is new — a figure sourced from a third-party API rather than derived from chain data is exempt from the recompute check below and must say on the page where it came from, because an unlabelled external figure is the same defect as a missing denominator. The copy list narrowed to claims that cannot be supported. None of this changes how any published number is computed, and the recompute check still covers every chain-derived figure byte for byte.

• 2026-09-08 — one new published figure, no existing definition changed: the share of launches that never took a single buy. It is published as a dated sample rather than a live rate, because it is not derived from the launch and graduation files the recompute check regenerates. 187 of 200 matured launches, 93.5%, with the quote reserve read live from each launch's own bonding curve on 8 September 2026. It carries its own n and its own date wherever it appears, and it does not move when the hourly crawl runs. Refreshing it means a new sample under a new date, never an edit to this one.

• 2026-09-07 — every cohort row now carries its own excluding-fast rate alongside its raw rate, and the pair-token finding on the front page is stated on the excluding-fast rate. Reason: the raw rates read ETH 1.64%, tokenized stock 2.37%, stablecoin 3.17% over the indexed record, and 0.71% / 0.71% / 0.73% once graduations inside the 300-second cutoff are removed. The apparent pair-token difference is entirely graduations that completed inside the cutoff. The page had stated the raw comparison, which invited a between-bucket reading of the number the same page calls contaminated. No definition changed; cohorts.* rows gained an excludingFast block of the shape cohorts.pairTax rows already carried.

• 2026-09-07 — crawledAt is now defined as the block timestamp of the last indexed block, not the wall-clock time of the run that wrote the file. Both are published: state.json gains lastIndexedAt (the block header time, written by the crawl from the header of lastIndexedBlock), and lastRunAt/lastSuccessAt keep their wall-clock meaning for the stale flag alone. A backwards backfill, which does not advance the cursor, no longer moves crawledAt. Why it changed: the 24-hour backfill run stamped crawledAt with its own clock while lastIndexedBlock stayed at the older forward cursor, so the trailing window [crawledAt − 86400, crawledAt) ended about 81 minutes past the last block indexed. Those 81 minutes were never scanned and so held no launches, and the window's denominator was short by them. The 24-hour figures moved when the definition was fixed: 26,265 launches and 533 graduations became 28,525 and 598, the raw rate 2.03% became 2.10%, and the rate excluding graduations inside 5 minutes moved from 1 in 138 to 1 in 135. number.json's schema is unchanged — crawledAt is still a string — and no other definition moved. Age is still the consumer's computation from crawledAt, which now measures the age of the chain data rather than the age of the run.

• 2026-09-07 — the weekly dispatch's window is min(7 days, the indexed record). It read the trailing 7 days regardless of how much record existed and labelled the result "last 7 days", so a 29-hour record was published under a 7-day heading. The window is now clamped to the record and every label in the message — subject, heading, the rate line, the cohort lines — names the span actually measured ("the indexed record so far: 29 h to 6 Sep 2026"). No figure on the site is affected: the dispatch's window has never been in number.json.

• 2026-09-06 — two new published figures, no existing definition changed. (1) The time-to-graduation ladder: cumulative counts and shares at eleven fixed second marks (30, 60, 120, 300, 600, 900, 1800, 3600, 7200, 14400, 21600), counted strictly below each mark. The marks were chosen to be dense where the observed distribution is dense — 44% of graduations land inside 60 s — and to reach past the slowest graduation recorded in the 20-hour backfill (about 5 hours). Moving a mark is a change to a published figure and needs its own entry here. (2) The pair-token x creator-tax cell grid, 20 cells, published with every cell's n whether or not a rate can be printed. Both are computed by the same stats engine as every other figure and covered by the same byte-for-byte recompute check. The two rates already published (raw and excluding fast) are unchanged, and no number already on the site moved.

• 2026-09-06 — the fold now leads with the excluding-fast figure, shown as "1 in N" with its rate beside it; the raw rate is the second figure. Both rates are always shown together with the same denominator; only the order changed. Reason: the raw rate is indistinguishable from figures published for other launchpads, while the rate excluding graduations inside 5 minutes is the measurement this site exists to publish. No definition changed.

• 2026-09-06 — window convention stated explicitly as half-open [since, until); previously the text said "within the trailing 24 hours" and the code selected the closed interval [since, until], which counted a launch landing exactly on a window boundary in both adjacent windows. No published figure changed at the sample sizes recorded so far. number.json schemaVersion raised to 2 in the same change: fastShares.under300Share, fastShares.under60Share, deployers.launched2plusShare and deployers.from10plusShare are now null with an insufficient flag below n = 30 instead of 0.0, and stale now reports only that the generating run knew it was behind (age is computed by the consumer from crawledAt).

• 2026-09-06 — initial definitions. 20-hour backfill (23,552 launches, 535 graduations) used to set the fast-graduation threshold and the cohort bucket edges. Superseded finding recorded: the first 3.4-hour sample suggested no graduations after ~90 minutes; the 20-hour data shows 32 graduations after 90 minutes (max ≈ 5 hours). No boundary claim is made.