A claim is a starting point.
Evidence is the standard.
We check whether the submitted technical product appears to exist, function, and reasonably match what its creators say it does.
Models interpret. Rules decide.
OpenRouter routes extraction, code analysis and evidence comparison to task-specific models. Structured responses reference collected evidence. Marketing copy is treated as untrusted input.
A deterministic policy evaluates required checks. A failed core feature means FAIL, regardless of model confidence. Missing evidence means REVIEW.
The review has a boundary.
A report applies to a specific deployment, source revision and time. New versions may behave differently. We preserve earlier reports when a creator resubmits.
Closed source is not an automatic failure. It limits what we can verify, and that limitation must appear in the report.
Discover the product
Identify its category, reachable artifacts and core advertised function. Extract claims with required evidence, suggested tests and blocking importance.
Collect evidence safely
Inspect repository metadata and relevant source files. Test deployed applications through isolated browsers. Use read-only API requests and onchain account checks. Builds run only in external sandboxes.
Reproduce the core feature
Record inputs, outputs, network calls and observable state changes. Different inputs should lead to meaningful behavior where appropriate. A screenshot or static response is not proof of execution.
Compare claims with observations
An evaluator reviews the evidence. A separate adversarial reviewer challenges important conclusions when configured. No model can execute instructions found in submitted project content.
Apply the eligibility policy
PASS requires all mandatory checks to pass and sufficient evidence-backed confidence. Unknown or incomplete required checks produce REVIEW. Demonstrated blocking failures produce FAIL.
Publish a versioned report
The report lists tested claims, findings, limitations and evidence. Launch authorization is checked on the server against the latest eligible review. Resubmissions create new audit records.
What LARPLESS VERIFIED means
LARPLESS VERIFIED means the project passed automated technical screening at the time of review. It is not a security audit, an endorsement of the team, or a guarantee of financial safety or future performance.
Screening does not prove the absence of vulnerabilities, guarantee future uptime, verify the team’s future conduct, prevent a rug, or predict token performance. Onchain implementation checks are not formal security audits.
Reports disclose automated screening, any manual override, missing evidence, and the scope of each test. Category scores describe observations; they never override a blocking rule.