Every launch is new. The people behind them are not.

Paste a Pons v2 token. Meet its deployer.

This runs in your browser, against the public RPC, with no key and no backend. It reads the factory's own TokenLaunched log directly — the same path the tool falls back to when its indexer goes quiet.

A launch gets judged alone. Its deployer never does.

Every tool in this space answers the same question: what is this token, right now. Curve, tax, liquidity, holder spread. All of it about one launch, in isolation, as if it arrived from nowhere.

But two facts already sit in Pons v2's own contracts and nobody keeps them. The factory records who deployed each token. The fee escrow records who actually gets paid on it. Neither needs guessing at wallet ownership across the wider chain, and both compound: the tenth launch by an address you have already seen is a fact, not an inference.

The busiest deployer in the sample turned out not to be a person.

Before writing any indexing code, the premise had to be checked: do deployers on Pons v2 repeat at all? A sample of 300 consecutive real launches answered it — 275 unique deployers, 12 repeats. The biggest had eight launches and looked exactly like a token farm.

It is Multicall3: a generic batching contract deployed at the same address on nearly every EVM chain. Launches routed through it record the batcher as msg.sender, so eight unrelated people collapse into one apparent deployer.

$ python3 analysis/verify_infra.py 0xca11bde05977b3631167028862be2a173976ca11

  3808 bytes of deployed code — a genuine contract

  known selectors present:
    0x4d2301cc  getEthBalance(address)        — Multicall3
    0xa8b0574e  getBasefee()                  — Multicall3
    0x252dba42  aggregate((address,bytes)[])  — Multicall
    0x82ad56cb  aggregate3((...)[])           — Multicall3

  Two or more Multicall selectors: this is a batching contract.
  Launches crediting it as deployer are unrelated callers sharing a router.

The next four repeaters were a different story: distinct EIP-7702 delegated accounts, real people using account abstraction. Those stayed.

One address in. Everything that deployer has shipped, out.

A lookup that fails is not a lookup that found nothing.

This is the distinction most tools quietly collapse, and it is the difference between "this address is clean" and "ask me again later." thread keeps them apart on purpose.

The indexer this runs on was observed timing out on genuine zero-match queries rather than returning an empty list. A timeout and an absence look identical from the outside, so a timeout alone can never produce a negative here. The chain has to be asked directly, and it has to answer.

Evidence, never a verdict.

• No score, no rank, no risk level. A single number invites trust it has not earned. Every output is a list of dated, sourced facts.
• Never "these wallets are the same person." A shared funding source is disclosed as a fact with a timestamp, not as proof of common control.
• Missing data stays missing. If something could not be checked, it says so. It is never rounded down to "clean".
• Every claim carries its receipt. A transaction hash or block number accompanies each fact, or it does not ship.
• No key, no signer, no buy button. It reads. It cannot trade, even if you want it to.

The full seven rules live in RULES.md, in the repository, in plain text. Rule 4 is the one most likely to be tempting to bend for a punchier post. It does not get bent.

The contracts this reads, and nothing else.

The live numbers at the top of this page are read from that RPC by your own browser, right now. No key, no backend, nothing cached — the same endpoint the tool uses.

Node 18, no build step, no dependencies.

$ git clone https://github.com/dunik77/thread && cd thread
$ npm test                       # 55 checks, offline, no key needed

# deployer history needs a free Bitquery token
$ cp .env.example .env           # then paste your token in
$ npm run serve                  # → http://localhost:4663

The ERC-20 reader needs no key at all and opens straight from disk. The token is only required for deployer history, and it lives in the server process — never in a page, because a key in a static page is a key anyone can read out of view-source.