1. What ChainLint does
ChainLint is a research index for Robinhood Chain (chain ID 4663). It keeps token listings, projects and dated automated observations. Admins cannot assign audit scores or verdicts. Old human-entered reviews remain archived but do not determine public scores or verdicts. A listing or basic scan is not a complete audit, security certification or investment recommendation.
1 · LeadA discovered listing or reader submission enters the index. Its claims, website and wallet links are not accepted as ownership proof.
2 · Automatic evidenceReachability, page/code fingerprints, available chain snapshots and market data are checked and saved with timestamps and limits.
3 · Required engine testsA Product-audit score requires current evidence for the exact website, named product feature, successful and controlled-failure backend behavior, and clarity of the tested claim. A separate optional full-project/security review retains its historic 12-area gate.
4 · Published resultOnly actual, recent engine evidence can establish a result. Missing tests stay unverified rather than assumed safe or unsafe.
Boundary: ChainLint measures documented evidence, not the likelihood of profits, a fair token price, freedom from exploits, or whether anyone should buy.
2. Discovery and intake
- Radar: while the API server runs, it checks recent Robinhood Chain DexScreener profiles and boosts about every 15 minutes by default. Valid contracts are indexed by address, deduplicated, and retained across refreshes or source outages. “Saved feed entries” does not mean every chain launch was found; missed windows and unlisted tokens may remain missing.
- Feed category: a listing name resembling a known brand/person becomes an Impersonation lead (not a proven impersonation); a description with a product claim becomes Utility (not a working product); otherwise it is an Excluded meme for product-scan triage. These text rules can be wrong and may be revised when evidence changes.
- Project queue: saved leads, public scan requests, recorded projects, and reader-supplied sites can be checked. Workers discover and process new requests continuously while the API server is active. Completed assessments are saved and refreshed about every six hours; failed checks and engine updates can trigger an earlier check. A pending request is not an audit or a verdict.
- Reader-supplied addresses: a submitted site/wallet pair is stored as an unverified lead. An EVM-shaped address, balance, transaction count, or matching site name does not establish creator control, an official token contract, or a shared operator. Existing reviewed records are preserved.
- Request an engine check: a valid Robinhood Chain submission enters a priority scan queue. Its website results appear in Projects after the scan; submitted wallet and contract addresses are probed separately, not assigned to the project's official identity. The explanation remains private. A scan is not a complete audit or safety verdict, and the usual 1–10 minute target depends on source availability.
3. What the automatic scan actually checks
- Website: DNS, HTTP and TLS availability; title, description, share image, stack, visible text and page wording. A reachable homepage proves only reachability; a timeout, 403, 404 or 410 does not prove a business closed.
- Code fingerprints: up to four same-origin JavaScript bundles can reveal matching hashes, builder markers or service identifiers. Shared hosting, template text, old copyright, analytics, WalletConnect, Supabase or Firebase IDs are investigation leads, never operator identity or personal-data misuse proof.
- Chain history: where a usable indexed explorer history exists, the scanner looks for successful Pons factory launches, fee claims, direct fund flows and repeated claim → own-token buy → burn/transfer patterns. Missing credentials, unavailable or truncated history means unknown, not zero launches. Shared service or bridge funding is not an identity link.
- Token and wallet RPC snapshots: contract bytecode, raw supply, proxy implementation slot and optional owner/deployer responses; wallet balance, code and transaction count. Contract-returned values are not independently verified privileges, audited source, ownership or full transfer history.
- Market: available liquidity, volume, 24-hour price change and buy/sell counts from DexScreener. A market listing does not prove the website works, liquidity is safe, or selling is possible.
- Not automatically tested yet: the main product button, end-to-end workflow, successful and failed project API calls, user-data recipients, contract security, permissions in full, trading exit, or operator identity. The engine leaves these unverified rather than awarding points.
Coverage words are not verdicts. “Checked” means the stated automated observation ran; “Limited” means a partial snapshot; “Not verified” means the question was not established; “Not provided” means required input is missing; “Not found” means the queried source did not return a match; “Unavailable” means a check could not be completed. Open each project for its exact detail and timestamp.
4. Focused Product audit and separate full-project review
The routine Product audit checks four weighted areas: website and claim clarity (10 points), the named core function (50), and backend responses (30). Each requires a current engine-owned observation, an exact project/site binding, a UTC check time and public evidence; the backend also requires separate successful and controlled-failure evidence. Failed results may earn zero after the complete test is reproduced; Unknown, stale, blocked and missing results do not earn a score. “Passed” is not inferred from HTTP 200, scan coverage, an AI summary or a token listing.
The historic full-project review below is a separate optional scope and keeps its original 12 areas. It is not a prerequisite for the focused Product-audit score, and a Product-audit score is not a full security or investment review.
Identity · 8 ptsLink the official website, token and operator through primary sources; a submitted wallet alone is insufficient.
Website and claims · 5 ptsCheck the current site and advertised live features against what is actually available.
Product workflow · 15 ptsRepeat the core action with different synthetic inputs and verify meaningful, changing output.
Backend responses · 12 ptsObserve genuine successful and failed API/contract responses with separate evidence links.
Contract permissions · 10 ptsInspect source, proxy/upgrade controls, privileged functions and relevant contract behavior.
Trading exit · 10 ptsIndependently check the applicable sell/exit path, not only a listing or buy count.
Wallet history · 8 ptsReview available transaction history and cluster claims without treating bridges or service wallets as operators.
Data privacy · 10 ptsCompare stated data use with observed recipients using only synthetic inputs; never submit real personal data.
Supply and allocation · 8 ptsCheck supply, allocation and vesting claims against public records.
Liquidity and exit depth · 6 ptsInspect liquidity depth, relevant locks and an actual exit route where appropriate.
Holder concentration · 5 ptsReview concentration and disclose known service holdings rather than mislabeling them.
Fees and operator disclosure · 3 ptsCheck fee, conflict, control and operator claims against primary disclosures.
Full-project review evidence standard: a historic 12-area full pass still needs each required review area and its own current public proof, as well as the review's existing reproducibility and backend controls. Evidence must not contain credentials, personal information or private traffic captures. No admin can award missing points; this separate gate does not block a valid focused Product-audit score.
5. Product-audit score, qualification and expiry
Product-audit score (0–100): only a complete, current, engine-qualified review of the exact named product and website can show a number. The four weights are website 10, core function 50, backend responses 30 and claim clarity 10. A reproduced failed criterion contributes zero of its weight; Unknown or incomplete evidence suppresses the score instead of silently treating the check as a failure. Price, token activity, popularity, AI prose and page wording never add points.
Audit coverage: every product separately shows the proportion of required engine evidence checks currently verified, rounded down to a whole percentage. The ring and Projects row use this coverage value, never the Product-audit score. Unknown, stale, failed and unavailable checks do not count as verified coverage. 100% coverage is not a quality grade.
- Full-project review: the distinct legacy 12-area pass still requires all its own current evidence. It is not the focused Product-audit score or a security guarantee.
- Wallet pattern: a recent direct operator sweep or repeated fee-claim → buy → burn/transfer cycles may appear as an observed lead, not a fraud verdict or quality score.
- Product-score scope: a qualifying focused score establishes only what was tested about this product's website, claim, core function and backend behavior. It is not a contract security, privacy, token, trading, investment-suitability or full-project review.
- Stale or unavailable: old scans and unavailable explorer history cannot establish current activity. The engine shows the missing coverage rather than reusing past results as a pass.
Interpretation: a future 100/100 means only that the documented, scoped Product checks qualified at the recorded time; it is not a security certificate, guarantee of safety or investment advice. Any historic 12-area full score is shown only within its separate Full-project review scope.
6. Product labels and the proof behind them
Product labels require engine-produced evidence, not an admin decision or a prediction of returns. The scanner cannot promote a project to Working Product, Dead Product, LARP or Scammer from wording or market data. Old manually recorded labels remain archived in storage but are published as Unknown, not as current verdicts.
- Unknown
- Untested core actions: the engine has not reproduced a complete product result, including newly queued projects. This is not a negative verdict.
- Working Product
- Would require the engine to reproduce the core feature with distinct inputs and validate all 12 audit areas, including separate backend success/failure evidence. The current scanner cannot award this label.
- LARP / Dummy
- Would require the engine to reproduce a claimed live feature failure with two distinct synthetic inputs, inspect the backend and document a separate simulation/fabrication/inactive-workflow mechanism. The current scanner cannot award this label; a wallet pattern alone is insufficient.
- Dead Product
- Requires separate dated evidence of closure or core failure. A failed URL alone is insufficient; the current automatic scanner does not assign this label.
- Discontinued
- An earlier recorded discontinuation or closure case; check its dated primary sources. There is no current automatic promotion rule for this label.
- Early Product
- An earlier recorded early-stage finding, not a fully verified live workflow. It has no current automatic promotion rule or pass score.
- Scammer
- Requires independently substantiated adverse evidence. Buy-only counts, an inaccessible site or a brand-like name do not prove fraud; the current engine does not assign this label.
Keep categories separate: a feed tag such as Utility or Impersonation is claim-based discovery triage. It is not a product label, a wallet finding or a security assessment.
7. Wallet findings, prompts and thresholds
- Farmer Cluster C1: at least two observed fee-claim → own-token-buy → burn/transfer cycles; each matched buy follows a claim within 90 seconds and a burn/transfer follows within 600 seconds. The events must match on available explorer history. A repeated pattern is a wallet finding, not proof of fraud or a shared person.
- Farmer Cluster C2: an observed direct ETH sweep to a configured known operator address. Funding via bridges and service addresses is explicitly excluded as an identity link. An existing cluster case is not erased just because history is unavailable later; open the dated evidence.
- Serial Farmer: a historical case label for repeat operator behavior; the current scanner does not assign it from launch count alone. Multiple token launches, fee claims, copied scripts and shared service IDs by themselves do not prove a serial operator.
- Other prompts: a first launch buy sold/moved or burned within 30 minutes, a wallet emptied after fee claims, or ≥50 buys with zero reported sells in 24 hours is a lead for review, not a product/security verdict. Site phrases such as “not live,” “demo,” or “coming soon” flag questions; one strong not-live phrase or at least three weaker matches raises a review prompt, never an automatic LARP label.
Registry review prompts (main action, changing output, deployment, template leftovers, token timing, fee behavior, claims and branding) count answered questions needing follow-up. They do not feed the 100-point audit score or establish a verdict. A recorded cluster blocks a positive full-review pass until independently resolved.
8. How to read one project
- Confirm the project's website, token contract and wallet roles against official sources. Submitted leads and market icons do not prove attribution.
- Check Automated evidence coverage and scan date. Read “Unavailable,” “Limited,” and “Not verified” literally; do not turn missing data into a pass or accusation.
- Separate Latest automated check from earlier findings. Open the explorer/market links and note the source limits and timestamps.
- Check the engine assessment, which tests ran, their sources and dates. A check count is not a product pass; all 12 required audit areas must be evidenced for a full score.
- If you are making a financial decision, perform your own assessment of market risk and position sizing. ChainLint does not assess whether a token is worth buying.
9. Maintenance, corrections and standardization
Scanner observations can change on recheck; earlier human-entered reviews are kept only as archived records and do not set current public scores. Indexed results can be reused only for matching inputs and recent, completed engine checks; reuse keeps the original evidence date and is not a new test. New contrary evidence requires a fresh reproducible engine test, not a silent re-label from a homepage or token price. If a source is down, report the affected check as unavailable.
To suggest a project or correct a recorded fact, use Request Audit with the dated primary-source link and explain which claim is affected. Submissions are leads until reviewed. The Coverage page shows current index counts and source timing; the legal notice explains reliance limits.
Fee totals: an ETH amount is displayed only for creator-wallet records refreshed from complete indexed explorer history in the last 48 hours, with an as-of time and an address-history link. The visible sum covers only those wallets, not all chain fees. Old stored amounts without scan provenance are excluded. The app fetches updates every minute; the scanner is scheduled separately, so this is not a live block-by-block total.
Methodology authority: the engine's dated checks and validation rules determine what may be published. This page describes those rules; old seed labels are not promoted into engine reviews. Times shown in the product use UTC.