Find information about any token

Start with the contract address #

Paste the full token contract address into the scanner. PeelSignal checks Robinhood Chain mainnet, chain ID 4663. The token does not need to appear in the oracle coverage table or have a reviewed project profile.

Use the chain and full address together. A ticker can belong to several contracts, and the same address can exist on several networks. Native ETH has no ERC-20 contract address; this flow inspects token contracts, including wrapped assets at their own addresses.

Read what the contract returns #

The scanner verifies the chain and records a block number, hash and time. It reads deployed bytecode and attempts name(), symbol(), decimals() and totalSupply() at that block. A failed call leaves that field missing while successful independent reads remain visible.

Names and symbols are self-reported text. Total supply is the raw contract value, with decimals used only when available; it does not establish circulating supply or ownership distribution. A contract can implement these calls without satisfying every ERC-20 requirement.

An address with no deployed code is recorded as such. An RPC failure leaves deployment unknown. Those outcomes are different, and neither is filled by an explorer listing.

Read owner, proxy and interface surfaces #

At the same pinned block, the scanner calls owner() and reads the EIP-1967 implementation, admin and beacon storage slots. It also asks supportsInterface() whether the contract reports ERC-721 or ERC-1155, so a non-fungible contract is not mistaken for a broken ERC-20 token.

A null field means the method reverted, the read failed or the slot is zero; control.unavailable names the failed reads so an empty slot stays distinct. A zero owner() address is recorded as renounced. A set implementation slot means the address is a proxy whose code can change; the admin or beacon address says which contract can change it. None of these reads identify who holds the keys, list every privileged function, or establish that the code is safe.

Control reads need deployed code at a consistent block. When that is missing, the control check is unavailable rather than filled from an explorer record.

Read indexed explorer facts #

The Blockscout address API looks up the exact address for indexed token details and contract information. Available fields can include token type, metadata, supply, holder count, reported source verification, creator and creation transaction, and proxy or implementation hints. Each source keeps its retrieval time and response outcome.

Explorer records can lag the chain. Reported source verification describes the explorer’s published code record; it does not audit the code, prove that an administrator is trustworthy or establish project ownership. Proxy hints describe indexed contract relationships, not a complete review of upgrade permissions.

A missing indexed record and an unavailable API have separate outcomes. If the explorer is blocked or rate limited, the receipt still keeps usable RPC and market observations. No historical explorer record substitutes for the failed request.

Read the largest indexed holders #

The explorer holder index is queried by exact address alongside the address record. The receipt keeps up to 10 largest indexed holders with their raw balances, their share of the indexed total supply and the combined share of the recorded holders.

Shares use indexed supply from the holder response when present, otherwise from the separately recorded explorer address response. totalSupplySourceId identifies the denominator’s source; neither response is pinned to the onchain block. Liquidity pools, bridges, vesting contracts and custodians appear as single holders, so a concentrated list is a distribution observation, not a judgment about the project.

An empty list, a missing index record and a failed request are separate outcomes. The public explorer instance sits behind a browser challenge, so without a configured explorer credential the holder and address checks are recorded as unavailable while contract and market evidence continues.

Read matching market pairs #

The DEX Screener adapter queries by address and accepts pairs only on the configured Robinhood Chain identifier with that exact token address as a base or quote asset. Names and symbols cannot select a pair. A token without a reviewed profile uses this same lookup.

Available pair evidence can include the DEX, pool address, base and quote assets, provider-reported USD price, liquidity, 24-hour volume and trade counts. The provider’s USD price and price change describe the base asset, so PeelSignal leaves them missing when your requested token is the quote asset. Pair-wide liquidity and volume can still appear.

A receipt records up to 12 matching pools ordered by reported liquidity and shows when the result was truncated. Conflicting or mismatched records are discarded with an explanation; usable matching pairs can remain visible alongside that conflict.

Read the retrieval time with the numbers. It records when PeelSignal received the response, not the last trade or price update. A pair’s creation time is separate. A quote and listed liquidity cannot establish the execution price available for a specific trade.

No accepted pairs means this provider returned no matching indexed pairs for the observation. It does not establish that the token has no markets. A failed request is unavailable evidence, not an empty market result.

Treat discovered links as unreviewed #

Matching base-token market records may publish website or social links. PeelSignal retains up to 12 HTTPS links, labels them as discovered and unreviewed, and keeps their source. It does not fetch the linked pages or use them to establish project identity.

A listing can contain incorrect or impersonating links. Check the address and publisher before relying on one. A discovered link, reported source verification or listed pool cannot award Canonical, Fresh or a reviewed project identity match.

Read identity checks alongside discovery #

Contract facts and indexed markets can be available while the token remains unclassified. Classification requires the separate issuer or reviewed project identity evidence. Unclassified does not erase the information collected about the address.

The four panels keep their existing meanings. Canonical concerns the reviewed issuer Stock Token method. Price integrity uses reviewed oracle requirements, so a market quote cannot award Fresh. Exposure needs its own reviewed evidence, and personal eligibility remains Not confirmed.

Optional project profiles support a stricter published-identity comparison. They are not an allowlist for token discovery. Coverage explains which oracle and exposure checks have reviewed mappings.

Keep the observation and recheck #

Open the receipt to preserve the exact fields, source outcomes and timestamps collected. Recheck creates a new observation. Explorer and market responses are not synchronized to the recorded RPC block.

New receipts use schema v4. Earlier v1, v2 and v3 receipts remain unchanged and do not gain control, holder, summary or not-assessed fields. The shared oracle coverage sweep skips explorer and market lookups to keep its feed refresh bounded; those checks are marked not attempted. Run an individual token check for discovery evidence.

PeelSignal checks an address on demand. It does not promise a complete catalogue of Robinhood Chain coins, continuous token monitoring or full market coverage. See Source outages when a provider cannot return evidence.

Every receipt also carries a fixed not-assessed list: transfer taxes and honeypot behaviour, code audits, key holders, third-party liquidity locks, off-chain backing, price history and legal status are never checked. A missing section is not a clean result. See Understand missing evidence.