Skip to content
NOBID
Request access
StatusThe book is published. The desk is not open: Nobid is not quoting, holding client assets, or accepting orders. Nothing on this site is an offer, a solicitation, or investment advice.Status page

Updated 2026-09-06

Methodology

Every figure on this site descends from one enumeration of the Pons launchpad, pinned to a single block. This page states how the run was done, in enough detail to repeat it, and names the two places where it could be wrong.

What the run had to produce

One measurement carries the site: how many live curves are quoted in ether. Everything else is subtraction. The run therefore has two ways to be wrong — it can miss launches, or classify them incorrectly — and the procedure below makes both detectable rather than invisible.

Pinning the block

Every read was taken at block 55,223,440, not at latest. A run this size takes long enough that the head moves under it repeatedly, and a scan against a moving head produces figures that were never simultaneously true: the launch count belongs to one height and the reserves to another. Pinning makes every number a statement about one state root, and reproducible.

The dollar reference is pinned for the same reason. Every USD figure on this site is arithmetic on 2459.19 USD per ether, published rather than fetched, so it can be re-derived exactly.

Enumerating the launches

The source is the factory itself — the launch event emitted by the contract at 0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e on chain 4663 — not an index, a subgraph or the Pons interface. An index is a claim about the chain; the log is the chain.

The obstruction is the endpoint. The public RPC refuses ranges holding too many matching logs, and it refuses them with a generic error: no result count, no suggested narrower range, nothing that distinguishes a refusal from a transport failure or from a range genuinely holding none. The scanner cannot interpret errors, only react to them.

Hence the load-bearing decision in the run: any error means split, never means empty. A scanner that swallows an error as an empty window loses launches, and loses them in bursts, because the windows dense enough to be refused are the ones with the most launches in them. The undercount that results is silent, biased and entirely plausible.

scan(lo, hi):
  try:
    logs = eth_getLogs({ address: FACTORY,
                         topics:  [LAUNCH],
                         fromBlock: lo, toBlock: hi })
    record(logs)
  catch (any error):
    if lo == hi:
      raise               // a single block cannot be narrowed;
                          // this error is real, so surface it
    mid = lo + (hi - lo) / 2
    scan(lo, mid)
    scan(mid + 1, hi)

The recursion terminates on a single block, where an error is no longer ambiguous and is raised rather than skipped: the scanner must never decide for itself that a block is empty. An empty range answers immediately, so starting below the factory deployment costs round trips, not correctness.

Pricing the curves

240,350 curves at one call each is 240,350 round trips against an endpoint that rate limits by address, and that run does not finish. Reserves were read in batches through Multicall3 instead: one round trip, one request against the limiter, and one block context, so every reserve in a batch is read at the same height.

Batches are bounded by response size, and a refused batch splits by the same rule as a log range and for the same reason: the refusal does not explain itself. A curve counts as live if it holds a reserve, so 244,487 launches less the 240,350 that do gives the 4,137 that have graduated or been drained.

Classifying by fingerprint

Reading the quote asset of every curve directly is another call per curve, and unnecessary: the constants answer it. Each curve opens with a virtual reserve fixed by its denomination against the same fixed supply, so the constant product is identical within a denomination and differs between them. For ether it is 1.68 × 1,000,000,000 = 1,680,000,000, which held to five significant figures for all 125,256 of them.

Stated precisely: this is a classifier, not a proof. A fingerprint partitions a population cheaply and can in principle collide, which is why the run does not stop here.

Confirming the shortlist

The classification was checked by direct call on a shortlist: the deepest curves, where a misclassification would move a headline figure, and the cases nearest the boundary. Each answered as the fingerprint said. It is where the quote asset of the deepest curve on the chain, AMC Entertainment · Robinhood Token, was confirmed rather than inferred, and why it is the only one this site names.

Limitation

What was deliberately not done

No quote-asset read was performed across the 115,094 stranded curves. That is a separate run, scheduled for 2026-09-14, and until it lands this site publishes no breakdown by ticker — not estimated, not partial. See The stranded population for what that absence permits the desk to claim.

Reproducing it

Everything needed to repeat the run against the identical state:

chain id   4663
rpc        https://rpc.mainnet.chain.robinhood.com
explorer   https://explorer.mainnet.chain.robinhood.com
factory    0x7eD598BcEf8bd9Edd8C97A195C6d13f40801EC7e
block      55223440
eth/usd    2459.19    # published, not fetched at run time

Enumerate the launch event below that height with the splitting rule above, batch the reserve reads at that block, partition on the constant product, and these counts should come back identically. If they do not, the figures here are wrong and this desk would rather be told. Reading state at a fixed height needs an endpoint that retains it: log enumeration can outlive the pruned state, and a run against the current head gives different numbers, correct for that height and not comparable to these.

Known weakness: the head can move under a pinned block

Pinning removes the inconsistency between reads; it does not make the block permanent. The pin was taken near the head, and a block near the head can be reorganised out after it was read — in which case these figures describe a state the chain no longer agrees it passed through. Nothing in the run proves the block is canonical today.

Limitation

Reorg exposure has not been re-checked

The mitigation is cheap and has not been repeated: compare the block hash at height 55,223,440 against the explorer at https://explorer.mainnet.chain.robinhood.com and confirm the height is still canonical. Until that is done and dated, the survey carries the risk of having read a block that was later discarded.

Known weakness: one factory is assumed to be all of them

The enumeration reads a single factory address. Nothing in the run searched Robinhood Chain for other contracts emitting the same launch event, whether a second deployment or a fork. If one exists, the launch, live, ether-quoted and stranded counts are all undercounts, and the stranded share could move in either direction.

Limitation

No search was made for a second factory

This is an assumption, not a finding, and it is stated as one wherever the counts appear. The test is to scan for the launch event topic with no address filter and see whether any address other than the one above emits it — which the splitting rule makes feasible, and which has not been run.

What would make these numbers better

Three things, in order of value: the quote-asset census, which turns an aggregate into a distribution; a second run at a later height, which turns a snapshot into a drift; and a run by somebody who is not Nobid, which is the only one that establishes the first two were honest.