Glossary · xmr.club

Grades

Grade A: Best evidence tier. Signup tested end-to-end by xmr.club curator — deposit + withdrawal + edge cases. No-KYC posture verified at retail volume. Last_verified within 12 months.
Grade A-: B-shape positive signal at A grade — solid posture and likely A, but one element of the A bar (typically operating tenure or a fresh test-trade) is not yet on file.
Grade B: Solid pick. Verified working but with a meaningful caveat (UX rough, smaller market, intermediate trust step, partial coverage). Listed because the trade-off is sometimes worth it.
Grade B-: B-shape signal but tenure has not yet validated the publishable claims under stress. Used for high-loss-asymmetric categories (exchanges, casinos, custodial mixers) where the operator surface looks B-grade but the service has been operating < 12 months. Drops to C if tenure does not accumulate; promotes to B once it does.
Grade C: Acceptable with reservations. Posture intact but evidence is older, lighter, or the provider sits on a known weakness (custody risk, history of customer-fund freezes resolved, etc.).
Grade C-: C-shape but with notable concerns — listed for completeness or comparison, but readers should consider stronger alternatives where available.
Grade D: Listed for completeness or as a warning. Either KYC posture is questionable at scale, the provider has known unresolved issues, or the listing exists to anchor a comparison.

KYC posture

no kyc no_kyc: Provider does not require government-ID verification at any point — signup, deposit, withdrawal, or limit-raise. Verified end-to-end against the public methodology.
anonymous signup anonymous_signup: No account creation required, or the account is email-only / no personal information. Often paired with no_kyc but not always.
light kyc light_kyc: Some user information is requested at signup (email, phone, name) but no government ID. Acceptable for some threat models; downgrades placement in xmr.club grading.
heavy kyc heavy_kyc: Full KYC: government ID, sometimes selfie + proof of address. Listed only when there is editorial reason — a warning entry or a category-defining example.

Feature tags

xmr native xmr_native: Provider settles natively to Monero, not via a bridge or wrapped token. Critical for swap engines and merchant rails. Confirmed at the technical / on-chain level by xmr.club curators.
tor mirror tor_mirror: Provider publishes a working .onion mirror (cross-checked daily against the Onion-Location header in /onion-audit). Tor-first means the service is usable inside Tor without leaving the network.
no js supported no_js_supported: Functional UI without JavaScript enabled. Tested with Tor Browser at Safest level. Critical for hardened threat models.
open source open_source: Source code published under an OSI-approved license. For wallets/tools, paired with reproducible-build documentation where available.
cash accepted cash_accepted: Cash is an accepted payment / payout method, in-person or by mail. Common for P2P trading, prepaid cards, and select OTC desks.
lightning native lightning_native: Native Bitcoin Lightning Network support — receive / send / settle. Often paired with XMR via atomic-swap or sideshift bridges.
audited audited: Provider has published a third-party security audit (smart-contract, custody, operational). Audit recency factors into xmr.club grade.
non custodial non_custodial: Provider never holds user funds — escrow, multisig, or atomic-swap-based settlement.
self hosted self_hosted: Can be installed and operated on infrastructure the user controls. Eliminates trust in the listed operator at the cost of operational complexity.
i2p mirror i2p_mirror: Provider publishes a working .b32.i2p mirror — the I2P-native counterpart to .onion. Common in the Monero remote-node ecosystem.
atomic swap atomic_swap: Trustless cross-chain exchange via hash-time-locked contracts. No custodian holds either side mid-trade; the swap either completes atomically or refunds.
pgp supported pgp_supported: Provider lists a PGP key and accepts PGP-signed support requests / disclosures.
transparent fees transparent_fees: The quote shown before deposit equals what the user receives (minus destination-network protocol fees that are surfaced separately). No hidden spread, no post-deposit slippage adjustment, no "partner gave us worse execution" gap between quote and fill. Spread above mid-market is fine if named and shown up front. We grade on transparency, not on absolute fee level.
hidden fees hidden_fees: The user-visible quote understates what the provider actually keeps. Typical patterns: spread baked silently into the rate, withdrawal-fee markup beyond the upstream network cost, partner slippage absorbed by the operator and not refunded. Fails the "transparent_fees" test. Auto-caps grade at C; pairs with a curation_reports audit entry documenting the discrepancy.
no account no_account: No user account required. No registration step, no email, no phone, no Web2 PII at all.
no logs no_logs: Operator does not retain identifying logs against the swap — no IP retention, no user-agent fingerprinting, no behavioural analytics. Per published policy.
no pii no_pii: Operator does not collect or retain personally-identifying information (name, address, government ID, biometrics) at any stage of the flow.
custodial custodial: Provider holds user funds at some point during the flow (escrow, partner-routed CEX leg, intermediate balance). Use is contractually time-bounded but funds are temporarily under operator control.
closed source closed_source: Provider runs proprietary closed-source code; users cannot independently audit the backend logic.
web3 signin web3_signin: Account / session is bound to a Web3 wallet signature (MetaMask, Phantom etc.). Pseudonymous: avoids Web2 PII but exposes a persistent public address as identifier.
country blocks country_blocks: Provider enforces hardcoded country blocks (typically a sanctions list — BY/CU/IR/RU/SY etc.). Anti-aligns with the strict "no-KYC regardless of jurisdiction" posture.
cli supported cli_supported: Provider ships or supports a command-line / API client for headless use, beyond just a web UI.
aggregator aggregator: Aggregator: routes user orders through multiple upstream providers and surfaces the best quote — not a primary execution venue itself.