Skip to content
Sign in

Verification criteria

Verification is a set of scoped records, not a universal badge. These criteria are public; every decision can be revoked or downgraded, and the history remains visible.

Four things that are never the same

  1. Listed — the project exists on the platform. Nothing was checked.
  2. Identity verified — evidence that the team controls its wallets, domain or repositories.
  3. Platform reviewed — an administrator reviewed a stated scope.
  4. Claims verified — a specific claim (a deployment, a source match, a deliverable) was checked.

Identity / ownership

Evidence that the team controls the project's wallets, official domain or repositories.

  • Wallet ownership: a signed, nonce-protected challenge from the wallet (shown as “Wallet proof”; reviewed separately if requested).
  • Domain control: a DNS TXT record or file at a well-known path on the official domain, naming the project ID.
  • Repository control: the requesting account is an admin of the GitHub organization or repository.

Platform review

A platform administrator manually reviewed the project's information and evidence within an explicit scope.

  • A named administrator reviews the project's declared information against the evidence provided.
  • The review scope is written down and published with the badge. Anything outside the scope is not covered.
  • Approval is never sold and never implied by registration, popularity or funding.

Technical evidence

A specific technical claim — a contract deployment, source match, release or audit — was checked.

  • Contract source match: deployed runtime bytecode matches verified source at a stated commit and compiler settings.
  • Deployment: the stated transaction created the stated address on the stated chain.
  • Release / audit evidence: the referenced artifact exists and corresponds to the reviewed version.

External acknowledgment

An attributable third party (grant provider, auditor) confirmed a specific claim.

  • Only accounts authorized by the funder or auditor can acknowledge a deliverable or claim.
  • Project members can never acknowledge their own deliverables.
  • Acknowledgments are attributed to the organization and reviewer, with a decision note.

Revocation, downgrades and appeals

Administrators revoke or downgrade a verification when its evidence no longer holds (for example, ownership changed). The project owner can submit a new request with fresh evidence; community members can report problems from any project page. Status changes are append-only.

Provenance of timeline entries

Team-reported
Published by a member of the project team. The platform has not checked the claim.
Imported
Copied from an external source (e.g. GitHub) with its source identifier preserved. Reflects what the source said, not the team's interpretation.
Automatically detected
Recorded by the platform itself when a state change happened (e.g. a member accepted an invite).
Platform-verified
A platform administrator checked the specific evidence listed in the verification scope.
Independently acknowledged
Confirmed by an attributable third party, such as an authorized grant reviewer.

Canonical serialization & hashing

  • Records are serialized with RFC 8785 (JSON Canonicalization Scheme): keys sorted by UTF-16 code units, no whitespace, ECMAScript number formatting.
  • The hash is SHA-256 over the UTF-8 bytes, hex-encoded. The database recomputes it on insert and rejects mismatches.
  • Schemas: vpn.manifest/1 for manifests and vpn.event/1 for events. Each manifest includes the previous version's hash, forming a chain.
  • The exact hashed bytes are stored and served, so old versions stay verifiable after schema changes.