01Principles
Three rules govern everything below.
- Evidence over claims. A service saying it has no KYC is a claim. We record it as such until we confirm it independently. Confirmed and claimed are shown differently, never merged.
- Reconstructible scores. No opaque letter grades. Every axis score derives from stated criteria and public evidence, and the weights are published here. Given the same inputs, you'd reach the same number.
- Freshness is a feature. A correct listing that's six months stale is a liability. Every verified attribute carries its own timestamp — when we last confirmed it and how — and each has an expiry suited to how fast it changes: a KYC posture can flip with one terms edit, a legal entity rarely moves. When a critical attribute outlives its window, its green mark demotes to amber on the page and the grade takes a small, capped penalty until we re-verify. Staleness is our failure, not the service's — so it costs points rather than triggering a ceiling.
02Verification pipeline
A listing moves from submitted to verified through a fixed sequence. Automated checks run every 24 hours; manual review happens on submission and on any material change.
03Criteria collected
Each listing records the following. Fields we've confirmed are marked verified; the rest stay unverified until a future sweep.
Privacy & KYC
- KYC level —
none/email/rare/tiered/full - Account required, data collected, logging policy, JavaScript requirement
Custody & security
- Custodial or non-custodial, swap type (atomic / bridge / order-book / instant)
- Liquidity model — own book, third-party providers, or mixed — with the providers we've actually observed settling swaps, not the operator's partner list
- Frozen-funds / AML posture, open-source status
- Incident history — each entry recorded with its severity, kind (policy / event / allegation) and resolution
Operational
- Supported assets, trade pairs, min/max limits, fee range, settlement speed
- Blocked jurisdictions, available networks (clearnet / Tor / I2P)
Reliability signals
- Per-attribute verification timestamps and methods, live status, observed 30-day uptime, API availability
04Scoring model
Each service gets a set of axis scores from 0 to 100; the overall is their weighted average. The axes are per type: what makes a good exchange isn't what makes a good VPN. Every type shares three common axes (~40%) so any two services stay comparable, plus type-specific axes (~60%) that judge it on its own terms.
Common axes — every service (~40%)
| Axis | Weight | Computed from |
|---|---|---|
| Privacy / KYC | 20% | KYC level, account requirement, logging, data collected, JS optionality, Tor/I2P, type privacy signals |
| Reliability | 12% | 30-day uptime, live status, years operating, incident history |
| Reputation | 8% | Time in operation, exit-scam/hack record, open-source User reviews are not open yet. The plan is to accept them only when backed by proof of a real transaction — a hash or order ID we confirm before anything publishes — because an unverified review section is the same astroturfing noise this site exists to cut through. Rather than ship a review form whose "verified" badge we couldn't stand behind, it stays closed until that check is real. Every grade you see today comes from the objective criteria above; the Reputation axis currently scores on time in operation, incident record and open-source status alone.
07Live statusIndependent of grade, every service shows a real-time availability state from the last reachability probe.
live — endpoints responding, flow loads
degraded — reachable but slow or partial
down — unreachable or swaps paused
Down services stay listed — hiding them would erase the warning — but they drop to the bottom and carry a red flag. This is the check most directories skip, and the reason stale, dead services keep appearing on them. 08Limits & conflicts of interestHonesty about what we can't guarantee is part of the methodology.
|