EVM deployer records

The Solana deployer record answers one question no other provider does: what the wallet behind a launch did before. This page is the same question asked on Ethereum, and the honest differences between the two answers. The short version, stated first because it is the part most likely to be dropped when this is restated: the Solana answer is a scored screen and this one is not. Nothing on this page predicts anything.

​

What a record contains

For one address on one chain:

​

How it is measured

There is no EVM census. The record is walked live, per request:

1. Direct creations. The address’s transaction list, keeping rows that created a contract and did not revert.
2. One level of factory. Most tokens are not deployed by a person. They are deployed by a factory that a person deployed, through CREATE2, and appear nowhere in that person’s own transaction list. Each non-token contract from step 1 is walked for the contracts it created.
3. Is it a token? A contract counts as a launch only if it answers both totalSupply() and decimals(). Both, because an ERC-721 answers the first through the Enumerable extension and is not a token launch.
4. Who made it? Every candidate is confirmed against the chain’s own contract-creation record, which names the originating wallet even for a factory deployment. A contract the chain attributes to someone else is skipped and never counted for or against the address.
5. What happened to it? The same venue, floor and classification the Solana walk uses: listed at or above $1,000 of liquidity is live, listed below it is illiquid, and a request that did not answer is unchecked and never a death.

​

Why the second hop is not optional

Measured on a real Ethereum deployer on 2026-09-22: eight direct contract creations, of which seven were not tokens. The tokens that address actually launched were deployed by a factory it had created. The one-hop walk found a single token, it was dead, and the record read every launch died. The two-hop walk found three, one of them live, and the record read mixed. On a page someone reads before risking money those are not two shades of one answer. One of them is a false accusation against a named wallet.

​

What “no pair” means here, and what it does not

This is the largest difference from the Solana record and the one most likely to be got wrong. On Solana the census records a launch at birth. So when the venue later lists no pair for that mint, the token demonstrably launched and is now unreachable. That is a death and is counted as one. This walk has no birth record. It finds contracts that exist now. A contract with no pair is therefore ambiguous between two unrelated facts:

• it launched, traded, and is now gone — a death
• it was deployed and never traded at all — not a launch

Of the two unlisted ERC-20s on the deployer above, one had nine transfers in its lifetime and the other had zero. Neither ever launched. Counting them as deaths — which is what porting the Solana rule verbatim would have done — would have manufactured a death record out of contracts nobody ever traded. So never_listed is its own outcome, it is not counted in died, and the death rate is taken over listed launches only. Each launch carries its observed transfer count so a reader can see which of the two facts they are looking at. The consequence is that on this chain died means illiquid. An EVM pair contract is immutable and stays indexed, so a token that really did trade and then died keeps its pair and reads illiquid. The signal survives the change; the fabrication does not.

​

Why calibrated is always false

The Solana screen is worth something because a rule was scored against a held-out later window, and again prospectively against calls written down before their outcomes existed. None of that has been done on EVM. There is no EVM holdout, no EVM prospective arm and therefore no EVM screen. The states here are deliberately named so they cannot be swapped for the Solana ones, there is no flagged field in the payload, and no sentence quotes a survival rate. A record that says every listed launch by this address is illiquid is a statement about three contracts. It is not a statement about what the next one will do, and it must not be restated as one.

​

What is not covered

Stated plainly, because a limit that only appears in a field is a limit nobody reads.

• Ethereum only. Etherscan’s v2 endpoint refuses six of the ten chains the engine knows about on a free API key, including Base, where most new launches now happen. Polygon, Arbitrum and Linea return transactions but the attribution lookup has not been confirmed on them, so they are not offered. A request for an unsupported chain answers not_supported with the specific refusal, never an empty record.
• No birth observation. Every launch is measured at whatever age it happens to be now, recorded per launch as observed_age_days. Ages of over a year are normal. No horizon is claimed.
• One level of factory. A factory that deploys a factory that deploys a token is not reached. coverage.factory_depth says so on every record.
• A wallet that launches through someone else’s factory — a public launchpad — is not attributed those launches by this walk, and will read as no_record.
• Long histories truncate. A single query returns at most 10,000 rows with no cursor. When that cap is hit, coverage.truncated is true and the counts are a floor rather than a total, which the record’s own sentence says.
• no_record is not a clean record. It means nothing was found by this walk, which is a statement about the walk.

​

Reading the coverage block

Four different kinds of nothing are kept apart, because collapsing them is how a gap in our reading becomes a finding about a wallet: undetermined exists because the first live run of this walk did not have it. A rate-limited call was caught and recorded as “not a token”, and a wallet with three launches came back as having none — with nothing in the payload to say anything had been missed. A gap in our own reading has to be visible as a gap.