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 · A lead is recordedA discovered listing or reader submission enters the index. Its claims, website and wallet links are leads, not proof of ownership.
2 · Public observations are savedThe scanner records website responses, selected page details, available chain information and market data with dates and limits.
3 · Narrow product tests may runOnly named public functions with a supported read-only test can qualify for a focused score. A separate full-project review uses its own 12-area evidence gate.
4 · Results keep their scopeA scan request, AI research note, website observation and verified product pass are different states. Missing or unsupported tests stay unknown—not safe, unsafe or failed.
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.
- Scan queue: a saved request can enter a priority website-scan queue. A request being accepted is not the same as a worker starting, a scan finishing or a product function passing. Completed automatic scans may be reused for up to six hours for matching project inputs; that is a reuse limit, not a refresh schedule or completion promise.
- Reader-supplied addresses: a submitted website/address pair is an unverified lead. Its format, balance, transaction count or matching site name does not establish who controls it, whether it is an official project address or whether addresses share an operator.
- Request an engine check: an eligible Robinhood Chain request is prioritized for a read-only website scan. If it completes, its limited observations may appear in Projects. Submitted wallet and contract checks are separate and are not assigned as official project identity. The request explanation is kept in the restricted request record. Unsupported website paths remain unverified; no completion time is promised.
- Background AI research: research can be not scheduled, awaiting queue confirmation, queued, running, blocked or complete. “Queued” means a durable job is recorded; “running” means a worker has started. The production scheduler is enabled by default only when its required services are ready, starts at most one job per minute, and is disabled by default in preview environments. These are scheduler settings, not a completion guarantee. AI commentary and bounded research observations do not qualify a score without a trusted engine observation bound to the exact site and saved as durable evidence.
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 verified: arbitrary website features, full workflows, wallet signatures, approvals, payments, transactions or other write actions, user-data recipients, full contract security, a real trading exit, or who controls an address. Only a small set of named public read-only functions is supported. Other paths remain unverified.
Coverage words are not verdicts. “Checked” means the stated observation ran; “Limited” means only part of the question was checked; “Not verified” means no conclusion was established; “Not provided” means an input is missing; “Not found” means the queried source returned no match; “Unavailable” means the check could not be completed. An unavailable check is unknown—not a LARP, failure or accusation. Open a project for its scope, source and observation time.
4. Focused Product audit and separate full-project review
The focused Product audit has four areas: website (10 points), named core function (50), backend responses (30) and claim clarity (10). The score requires a current engine-verified pass for the named function and its input-linked backend responses, bound to the same project and exact site with dated public evidence. Those two passing areas are mandatory. The website and claim-clarity areas add their points only when separately verified, so a valid 90/100 can have three of four areas passed. The claim/disclosure area currently has no supported passing producer, so current producers cannot earn its 10 points and the focused Product score tops out at 90/100; this ceiling does not apply to the separate full-project review. A verified failure earns no points for that area; an unknown, stale, blocked or missing result is not treated as a failure.
The public product probes are deliberately narrow: read-only asset search on pair.trade and a read-only token-pair price quote on paceonrh.xyz. They test named functions on those supported sites—not arbitrary websites or every advertised feature. Other site paths stay unverified. No wallet signature, approval, payment, transaction or other write action is automatically verified. An HTTP 200 response, coverage percentage, AI summary or token listing is not a product pass.
The separate full-project review uses its own 12 audit areas and requires a current 12/12 result (100/100). It is not required for the focused Product score. The basic engine assessment lists seven categories: website, product, backend, privacy, wallet, contract and market. Its completed/total technical counter counts only four designated categories: website, wallet, contract and market. That technical counter is not the separate 19-check evidence-coverage count or the Product score's four weighted areas.
Technical detail: how a product score is qualified
For supported functions, the engine checks two distinct harmless inputs and a controlled negative response, then confirms that those input-linked results came from the supported function's backend route. The observation must be current (within 24 hours) and tied to the exact listed site. Full-project review results use a separate 30-day window.
A manual scoring write is disabled; the API returns 410 Gone. AI commentary or research can provide context but cannot award points. A score needs trusted engine observations and a durable record bound to the project and site.
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: all 12 areas must pass with current evidence for a 100/100 full-project result. 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): the named core function (50 points) and its linked backend responses (30 points) must pass before a score is available. The website and claim-clarity areas are worth 10 points each and add points only when verified. The claim/disclosure area currently has no supported passing producer, so the focused Product score from current producers tops out at 90/100; 90/100 is possible with the two required passes plus a verified 10-point website area (three of four areas). That Product-score ceiling does not apply to the separate full-project review. This focused result must be current within 24 hours and bound to the exact project and listed site.
Evidence coverage: the ring and Projects row show the percentage of the current 19 evidence checks that are verified, rounded down—not a Product-audit score. The basic engine assessment lists seven categories, but its completed/total technical counter counts only four designated technical categories: website, wallet, contract and market. This counter is distinct from both the 19-check coverage count and the four weighted Product-audit areas. Unknown, stale, failed and unavailable checks do not count as verified coverage; 100% coverage is not a quality grade or review pass.
- Based · Tested utility: applies only to the named function on its tested website/backend route. It is not a whole-project or investment rating.
- Based / Trusted: requires a separate current, qualified 12/12 full-project review (100/100); the result is current for up to 30 days. It is not an investment recommendation or safety guarantee.
- Wallet pattern: dated direct transfers or repeated transaction sequences can be recorded as a lead. A pattern does not establish who controlled an address or prove fraud.
- 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: product-function observations and focused scores use a 24-hour window. A full-project review uses a 30-day window. An unavailable source remains unknown and cannot become a pass or a LARP finding.
Interpretation: a Product score reports only the documented, narrowly tested public function at its observation time; even 100/100 is not a security certificate, guarantee of safety or investment advice. The separate full-project review has its own 12 areas and score.
6. Product labels and the proof behind them
Current product conclusions require validated engine evidence, not AI commentary, market data or an admin-entered score. The API does not accept a human-written project review score (it returns 410 Gone). “Scammer” and “Serial Farmer” are not supported automatic results; older labels, when shown, are historical records, not current accusations.
- Unknown
- The available evidence does not establish whether a product function works. Missing, blocked or unsupported checks are not a negative finding.
- Working Product
- An older label, not an active automatic result. A named-function pass or focused Product score is narrower and does not certify every product feature or all 12 full-review areas.
- LARP / Dummy
- A scoped finding needs a reproduced failure of a claimed live feature plus separate evidence of its mechanism. An unavailable check, preview label or wallet pattern alone is not a LARP result.
- Dead Product
- An older label. A failed website check alone does not show that a product has closed.
- Discontinued
- An earlier recorded closure label. Check its date and source; it is not a current automatic result.
- Early Product
- An earlier-stage label, not proof that a live workflow was verified.
- Scammer
- An unsupported automatic label. An inaccessible site, buy-only counts or a name resemblance do not prove fraud. Treat any older record as a dated claim to inspect, not a current verdict.
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: a historical pattern record describes repeated fee-claim, token-buy and burn/transfer events in available explorer history. Review the dated transactions and limits. It is a wallet-pattern description, not proof of a person's identity, control or intent.
- Farmer Cluster C2: a historical record describes direct ETH transfers from listed wallet addresses to another address. Bridge and shared-service funding is not an identity link. An existing record remains dated evidence to inspect, not proof of a person's role.
- Serial Farmer: an older case label, not a supported automatic result. Launch counts, fee claims, copied scripts and shared service IDs by themselves do not identify one 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 prompts (main action, changing output, deployment, page leftovers, token timing, fee behavior, claims and branding) are questions for follow-up. They do not feed the 100-point Product-audit score or establish a verdict. An unresolved wallet-pattern record is considered separately in a full-review decision.
8. How to read one project
- Check primary sources for any claimed link between a website, token contract and wallet. Submitted leads and market names do not establish an official role.
- 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.
- Read the engine assessment, its sources and observation dates. The 19-check coverage value is progress, not a score. “Based · Tested utility” is a narrow function test; “Based / Trusted” requires a separate current 12/12 full-project review.
- ChainLint does not assess whether an asset is suitable for anyone or whether it 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 saved 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 wallet addresses, 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: published results come from dated engine observations and their validation rules. AI research may help locate public context, but cannot award points or labels. A displayed project name is a readable title; it does not replace or change the saved project record identifier. Times shown in the product use UTC.
Time labels: “Observed” or “checked” is when evidence was gathered. “Evaluated” is when a saved summary was derived. “API synced” or “snapshot loaded” is when the page fetched data. These times describe different events and must not be read as interchangeable.