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 future complete pass requires the engine to reproduce the core feature, inspect success and failure, review all 12 audit areas and record dated public proof. These tests are not all available yet.
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. Twelve audit areas required for an engine-issued review
The engine would need to record the claimed live core feature and its public source, then reproduce it with at least two different harmless synthetic inputs. For a pass, each area needs a concrete observation, UTC check time and its own public evidence link. These tests are not all implemented yet. “Passed” is not inferred from basic scan coverage.
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-audit evidence standard: a future engine-produced pass would need every check completed within 30 days, two distinct harmless inputs, actual successful and failed backend responses, and separate public evidence for each area. Evidence must not contain credentials, personal information or private traffic captures. The present engine does not perform all these tests; no admin can award missing points.
5. Audit score, qualification and expiry
Audit coverage (0–100%): every product shows the proportion of required evidence checks currently verified by the engine, rounded down to a whole percentage. The ring and Projects row use this coverage percentage. Unknown, stale, failed and unavailable checks stay in the denominator but do not count as verified. Coverage updates with the engine report; 0% is no verified coverage, not a failing quality grade. A full-review score is separate and still requires all 12 audit areas.
Formula and current state: a full score would add these weights only for areas the engine genuinely passed with a dated observation and valid public proof (maximum 100). The present scanner performs limited technical probes; they contribute no audit points. Their separate check count is coverage, not a quality grade. Price, popularity and page wording never add points.
- Not scored: the engine has not completed all required product, backend, contract, trading, privacy and other checks. Missing evidence is unknown, not a failed product or a 0/100 score.
- 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.
- Future qualification: a full pass would require all 12 current evidence-backed audit areas (100/100), distinct synthetic attempts, backend responses and proof links, and no unresolved cluster. A perfect number alone is insufficient.
- 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: even a future 100/100 would mean the documented tests qualified at check time, not 100% safety, a security certificate or investment suitability. No current project has an engine-issued full score.
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.