trust

How verification works.

icantmarket verifies ownership of the listed asset — not quality, not endorsement. The trust level on each product page tells you which substrate confirmed control. The audit log on every product page is public + append-only.

Trust levels

  • L0

    Claimed

    The owner submitted the product but hasn't completed verification yet. Don't treat this any differently from an unverified link.

  • L1

    Ownership verified

    One of the three substrates (GitHub admin / DNS TXT / package provenance) confirmed control. This is the baseline for posting asks.

  • L2

    Activity verified

    Verification holds AND the product shows real activity (commits, downloads, releases) — not abandoned, not a stub.

  • L3

    Contribution trusted

    The maker has built up history on the platform — multiple substantive reviews credited, helpful verdicts, no spam flags.

  • L4

    Featured

    Curated. Editorial decision by the icantmarket team based on sustained contribution + product impact. Rare.

Re-verification runs periodically (every 30–90 days). If the substrate stops confirming ownership — repo permissions changed, DNS record removed, package unpublished — the product is auto- revoked and shows a banner. See /policy for the revocation flow.

The three substrates

GitHub admin

github_repo

Owner has admin or maintain permission on the linked repo. Verified via the GitHub /collaborators/{user}/permission endpoint at OAuth time.

DNS TXT

dns_txt

A TXT record at _icantmarket.<your-domain> matches a server-generated nonce. Re-checked on the public /verify endpoint.

Package provenance

package_provenance

The package's registry metadata (PyPI or npm) lists a source URL pointing at a GitHub repo the user has admin on. Triangulation.

A maker can pick whichever substrate fits — for an OSS library the GitHub or package routes are natural; for a domain-only product (a landing page, a documentation site) DNS TXT is the path.

Why three substrates, not one

Single-factor verification is exploitable. A GitHub-only check misses domain owners; a domain-only check misses package maintainers; either alone misses the cross-check that catches fake package repos posing as the real maintainers. The three substrates together let us triangulate.

Famous-name claims (claiming react, numpy, stripe, etc.) always go through manual review even if the technical check passes — the famous-name gate is a 50+ slug list.

Public re-check anyone can run

Every product has a /verify/<slug> page that lets anyone — signed in or not — trigger a real-time re-check against the substrate. Useful for journalists, security folks, and the original maker confirming the badge still reflects reality.

Result appended to the public audit log either way. No silent moderation.

/policy · /faq · /about