Docs

What this reads,
and what it will not say

How to read a report and what stands behind each figure. For the per-check detail and the scoring mechanics, see the methodology.

What Pons Scanner is

One paragraph, so there is no confusion about what you are looking at.

On-chain intelligence for every token on Robinhood Chain. Paste an address and it reads the contract itself — the code, the permissions, the pools, the holders, the deployment — and reports what it found, with a link to the source of every figure. It works for any token regardless of how it launched: through pons, through Virtuals, or deployed directly. It surfaces evidence and never issues verdicts. It will not tell you a token is safe, because that is not a thing on-chain data can establish.

How to read a report

Two numbers sit at the top of every report. They answer different questions and are never combined.

Risk points

Every finding carries a band of points, and the score is the sum of what was allocated inside those bands. It counts up from zero as signals are found, and it comes with a band label — from no signals through to heavy signals — that states the direction in words.

It is deliberately not out of 100. A denominator turns the figure into a grade, and a grade with a low number on it reads as a bad mark, which is the exact opposite of what few findings means. There is no maximum to be a fraction of: points accumulate from what was found.

Coverage

The share of attempted checks that came back with real data. Pure arithmetic, no model involved. It answers a different question from the score: how much of this token could we actually read?

Low coverage means we could not read much. That is not the same statement as low risk, and the report never lets one stand in for the other.

The governing rule

Anything unreadable lowers coverage and never adds risk points. A contract whose source is unpublished scores no worse for it — it simply reports less, and says so. Counting missing information as danger would punish a token twice for the same gap and make the score meaningless.

Unknown is not the same as absent

These look similar in a report and mean opposite things. Unknown means we could not find out. Absent means we found out, and the answer is that the mechanism is not there.

Confirmed absence

On the reference token, the Owner field reads: no owner: neither owner() nor getOwner() exists on this contract, so no address holds an owner role.

Both functions were called and neither exists. That is an answer about the contract, so it counts as a resolved check and does not lower coverage.

Unknown

On an unverified token, the buy-tax field reads: Unknown — contract exposes none of the 35 tax getters this scanner probes for, and its source is not verified, so no rate could be read.

Without the source, the bytecode could still be deducting a fee through a path we cannot see. So the rate is not established, coverage drops, and no points are added.

A confirmed absence is only ever concluded from a call that actually executed. A read that failed at the RPC proves nothing and is reported as Unknown — inferring absence from a failed call would state as fact something that was never checked.

What gets checked

Eight checks run on every scan. Each states what it reads and where it read it.

Contract: Verification status, compiler, and whether the address is a proxy pointing somewhere else.; Chain for bytecode and EIP-1967 storage slots; the explorer for verification metadata.
Ownership and permissions: Who holds the owner role, and whether anything can mint, blacklist, pause, or change fees and limits.; Chain for owner and role state; the verified source for what the privileged functions actually do.
Transfer mechanics: Buy, sell and transfer taxes, plus maximum transaction and wallet caps. 35 getter names are probed.; Chain, read directly from the contract, with the verified source consulted for fee logic.
Holders: Concentration across independent wallets, with pools, burn addresses and the token itself excluded.; The explorer supplies which addresses to look at; every balance is then re-read from the contract.
Liquidity: Pools and their depth, across 3 quote tokens and 4 fee tiers on V3, plus every V4 pool for the token.; Chain. The V3 factory is asked directly; V4 pools come from the singleton’s own Initialize logs.
LP status: Who holds each liquidity position — a burn address, a locker, or a wallet that can withdraw it.; Chain, through the V3 position manager, weighted by each pool’s share of depth.
Deployer: The creation transaction, the account behind it, its age and activity, and whether a factory deployed it.; The explorer for the address record and history; the chain for the creation transaction itself.
pons launch registry: Graduation progress, launch caps, the protection window, fee routing and creator-supplied links.; Chain, from both pons factories and the token’s own storage.

What the chain looks like

Our own measurements, taken by reading each factory's launch history from the chain rather than repeating a figure from anywhere else.

1 in577: legacy-factory launches graduated; 3 of 1,730 — every launch that factory ever made. The whole population, not a sample.
1 in1,500: active-factory launches graduated; 4 of the 6,000 most recent, from 57,608 launches in total. Kept separate from the legacy figure because the two factories run different mechanics and averaging them would hide that graduation is rarer here.
about24seconds: of launch protection; Median across 400 tokens, at 2 L1 blocks. Stated loosely because it is derived from measured L1 block time, which varies. After the window closes the caps stay readable on the contract while binding nothing.
214: V4 pools on one token; On the reference token, where a V3-only scanner sees none of them. A floor rather than a total: a dropped log window can only under-count, so this is the largest of three passes.

Measured at L2 block 23,999,321 on 31 July 2026.

Data sources and their limits

Two sources, used for different things, and one of them is not trusted for values.

The chain is the source of truth

Balances, supply, owner and role state, taxes and caps, pool state, positions, launch records and the creation transaction are all read directly from contracts over RPC. Where a figure can be read on-chain, that is where it comes from.

The explorer is used for discovery, not for values

Blockscout supplies things the chain cannot cheaply answer: verification metadata and source, the holder list, the creator record and account history. It is not trusted for quantities.

That is not caution for its own sake. On a live token the explorer credited two addresses with roughly 9.7 million and 9.5 million tokens that in fact held zero, and its listed total exceeded the token’s own supply — which produced concentration figures above 100%. Indexed balances go stale, and a holder report built on them is wrong in a way nobody can see.

So the explorer is asked only which addresses to look at, and every balance is then re-read from the contract, which cannot be stale. The same rule applies everywhere the two disagree: the chain wins.

What this cannot tell you

Stated in full, because a limit you find out about later is worse than one you were told.

V4 hook behaviour is not established.A V4 pool can attach a hook contract that runs on every swap and can change what a trade does, including blocking it. The report says a hook is present and links to it. It does not read the hook’s code, so what it does is unknown.
Deployer history is time-capped. That module runs against the explorer, one request after another, under a hard budget. An account with more history than the walk covers reports its age as Unknown rather than guessing, and a slow explorer means the section arrives late or not at all.
V4 pool discovery is a floor. Pools are found by walking Initialize logs in up to 40 block windows. A window the RPC will not serve is counted as unread, so the count can be lower than the truth. It is never higher.
Only Uniswap is read. V3 pools against the probed quote tokens, and V4 pools in the singleton. Liquidity on any other venue is outside what these checks can see.
Socials are creator-supplied. The links in a pons launch record are whatever the deployer typed at launch. They are stored on-chain, which makes them tamper-evident, not true. Nobody verifies that the account exists or belongs to anyone.
Verified source does not mean safe. Verification means the code is readable. It says nothing about whether the code is correct, or benign.
Nothing here predicts what a token will do next. Every figure describes the chain at the block it was read. Ownership can change, liquidity can be pulled, a proxy can be repointed. A report is a photograph, not a forecast.

Embed a report

A live badge showing current risk points and coverage. It re-reads from the chain and links back to the full report.

Worth having because it is a claim the project it describes cannot quietly revise. Paste it into a README or a site and it shows what the chain says today, not what someone typed once.

[![Pons Scanner](/api/badge/0x39dBED3a2bd333467115dE45665cC57F813C4571)](/token/0x39dBED3a2bd333467115dE45665cC57F813C4571)

Markdown — paste into a README

<a href="/token/0x39dBED3a2bd333467115dE45665cC57F813C4571"><img src="/api/badge/0x39dBED3a2bd333467115dE45665cC57F813C4571" alt="Pons Scanner report" /></a>

HTML — paste into a site