Methodology

Ownership not being renounced is never scored on its own. It is only surfaced as contextual information when the contract also has one of the strong owner powers above (mint, blacklist, pause, or fee-change), to clarify that those powers are currently exercisable rather than purely theoretical.

Coverage is tracked independently of the Risk Score. It counts how many of ~14 checkpoints across contract verification, holder data, liquidity data, liquidity lock status, and deployer history returned real, usable data instead of "Unknown." A token can have a low Risk Score and low coverage at the same time — that combination means "little was found wrong, but also little could be verified," which is very different from a token with high coverage and a low score.

• Blockscout (robinhoodchain.blockscout.com) — contract verification status, ABI, source code, compiler metadata, proxy detection, token metadata, holder balances, and creator/deployer information. All requests happen server-side against Blockscout's public v2 REST API.
• DexScreener — price, liquidity, market cap/FDV, 24h volume and buy/sell counts, pair creation date, and DEX identity, queried by the Robinhood Chain slug configured in DEXSCREENER_CHAIN_ID.
• Robinhood Chain RPC — direct, read-only calls used only as a cross-check: confirming bytecode exists, reading owner() when present, reading the EIP-1967 proxy implementation storage slot when Blockscout doesn't already report it, and fetching deployed bytecode for bytecode-reuse comparison.

RHCHECK fetches the deployed (runtime) bytecode of up to 5 other contracts recently created by the same deployer and compares it byte-for-byte against this contract's bytecode. An exact match means the same underlying logic was redeployed under a different name, symbol, or marketing — a pattern commonly seen in mass-produced token launches. This is exact string comparison, not a similarity heuristic, so it never reports a match that isn't genuinely identical. It is bounded to the 5 most recent sibling contracts for scan performance, so a deployer with many more contracts than that may have additional undetected reuse.

RHCHECK never infers a capability from a function name alone. A detection requires (1) a matching function actually present in the verified ABI, with the correct mutability (e.g. a real state-changing mint(), not just the word "mint" appearing in a comment or an internal OpenZeppelin _mint call that is never exposed externally), and (2) the verified source code is inspected for an access-control modifier (like onlyOwner or onlyRole(MINTER_ROLE)) on that exact function. If a modifier can't be found, the finding is still shown, but its confidence is lowered and the report says so explicitly rather than asserting who can call it. If the contract's source is not verified at all, none of these checks run — permissions are reported as Unknown, never as absent.

• This is not a honeypot simulator — RHCHECK does not simulate buy/sell transactions.
• Holder concentration only excludes addresses RHCHECK can confidently identify (the token contract, burn/zero addresses, and pools confirmed via DexScreener, or contracts explicitly labeled by the explorer). Unlabeled contract holders are not assumed to be infrastructure and are counted as independent holders.
• Deployer history is limited to what is derivable from public transaction history in this MVP. Tokens launched through a factory/launcher contract show the end-user account that triggered the launch, but full multi-hop attribution across unrelated wallets is out of scope.
• Analysis only covers the top holders returned by Blockscout's paginated holder endpoint, not the full holder list for tokens with very large holder counts.
• Only one chain — Robinhood Chain mainnet (chain ID 4663) — is supported.
• This score reflects a fixed rule set. It is not a machine-learning prediction and does not update retroactively for new attack patterns without a code change.