Cómo curamos.

Rubric de gradoA · B · C · D · F

Etiquetas KYCuna por entrada

• NON-KYC — para servicios de alto riesgo que necesitan conocer a su cliente sin recoger IDs. El rastro de auditoría KYC se sustituye por un marco de evaluación construido sobre proof-of-work verificable — historial público, atestaciones de terceros por parte de la comunidad, entregas tangibles, o un anclaje público sólido. Diseñado para ser difícil de burlar y fácil para usuarios genuinos. Postura significativamente más exigente que NO-KYC abajo: el filtro es activo, no ausente — posiblemente una forma más justa de conocer al cliente que recoger documentos.
• NO-KYC — no se recoge identidad en ninguna fase.
• ANON — creación anónima de cuenta, pero KYC opcional para ciertas funciones.
• LIGHT KYC — email obligatorio, sin documento oficial.
• KYC — documento oficial, prueba de domicilio o selfie obligatorios.

Tags de featuresmulti-select, no exclusivos

Etiquetas que se combinan libremente. Chips de filtrado en categorías.

• open_source · non_custodial · self_hosted · cli_supported
• tor_mirror · i2p_mirror · xmr_native · lightning_native
• atomic_swap · audited · port_forwarding · ram_only_servers
• transparent_fees · hidden_fees

Transparencia de tarifas

Calificamos por transparencia, no por nivel absoluto.

• transparent_fees — la cotización antes del depósito equivale a lo recibido.
• hidden_fees — la cotización visible subestima lo retenido.

Recurso de terceros

Cuando un operador de routing-swap se porta mal, recurso legal directo suele ser imposible. Algunos operadores depositan garantía con un directorio peer.

• La señal de confianza externa única más fuerte que un swap routing puede llevar.
• Verifica el monto en el sitio del peer antes de depender — los pools pueden reducirse.

Adendum apuestascasinos + mercados de predicción

Casinos y mercados de predicción acarrean riesgos que el resto del directorio no: los juegos de ventaja de la casa pueden manipularse, y las resoluciones de mercados de predicción pueden disputarse. Aplicamos verificaciones adicionales además del rubric estándar.

Para RNG / juegos con ventaja de la casa (/wagering/casinos)

• Esquema provably-fair — el operador debe publicar la construcción del RNG (típicamente sha256(server_seed + client_seed + nonce) o equivalente) y permitir rotar el client seed. Cuando aplica on-chain, el reviewer verifica una apuesta end-to-end.
• Ventaja de la casa publicada — debe declararse por tipo de juego. No calificamos por si la ventaja es alta o baja, sólo por si está documentada.
• Ciclo de retiro — el curador fondea, juega, retira. Latencia de retiro + confirmación on-chain registradas. Cualquier disparo de KYC en esta etapa cambia la etiqueta KYC del listado inmediatamente.
• Declaración de custodia — los juegos con ventaja de la casa son necesariamente custodial durante una sesión. Exigimos al operador declarar dónde se depositan los fondos y qué pasa si se cae a mitad de apuesta.

Para mercados de predicción (/wagering/prediction-markets)

• Integridad del orderbook — al menos 24h de histórico público de órdenes/operaciones disponible vía API.
• Oráculo de resolución — ¿cómo se determina el outcome? Oráculo de precio cripto (Hyperliquid, Pyth, Chainlink), árbitro humano, comité multi-sig? Single point of failure señalado en caveats.
• Ruta de disputa — ¿qué recurso si un mercado resuelve mal? Escrito, público, sin KYC.
• Sanidad de volumen — wash-trading es fácil en libros delgados. Anotamos volumen total + traders únicos de stats públicas y señalamos si el ratio se ve artificial.
• Custodia / liquidación — cuándo y cómo se acreditan las ganancias. Mismos estándares que la subcategoría de casinos.

⚠ El gambling está restringido en algunas jurisdicciones. Listar no implica respaldo; verifica tu ley local antes de participar.

Cadencia de verificación

• Cada entrada lleva last_verified. Reprobamos al menos una vez al año. Estado: /freshness.
• Si el last_verified tiene más de 18 meses, bajamos una letra hasta re-verificar.
• Cada entrada también lleva operating_since — el año desde el que el operador actual atiende usuarios. Operadores con 5+ años (ciclo crypto completo) obtienen un trust bump implícito; lanzamientos menores a 2 años se listan con caveats. Ranking completo: /tenure.
• Los patrocinios no extienden el reloj de verificación.

La respuesta del operador como entrada del grado

Cómo un operador gestiona un mal día es un multiplicador del grado, no un tie-breaker. Los servicios adyacentes a la custodia (exchanges, mixers, casinos, mercados de predicción) descansan sobre una vía de confianza implícita que sobrevive a cualquier incidente puntual; los lectores extienden o retiran el beneficio de la duda futuro según la *forma* de la última respuesta, no la última cifra de uptime. Dos ejes de conducta del operador pesan materialmente cuando el curador fija y mueve grados.

• Transparencia — Fechas concretas, cifras concretas, afirmaciones con fuente enlazable. Cifras de reembolso (p. ej. «90 XMR reembolsados el 2026-06-24»), post-mortems técnicos con commits de fix, referencias a auditorías de terceros, socios de mitigación nombrados. La tranquilización vaga («lo estamos manejando») no cuenta. Las respuestas de alta transparencia elevan el techo de grado alcanzable sobre la misma arquitectura.
• Respuesta rápida — Tiempo hasta el primer reconocimiento público, tiempo hasta el patch, y cadencia de actualizaciones intermedias. Detener el servicio para proteger a los usuarios mientras se prepara la corrección es señal positiva, no negativa; la postura de «security comes first» se valora al alza. El silencio prolongado durante un incidente que afecta a usuarios, o un único post desdeñoso antes de «volver a mis vacaciones», cierra estructuralmente el arco de recuperación del grado.

La consecuencia práctica: un servicio puede mantener un grado de «con fallos pero honesto» indefinidamente si el patrón de respuesta es el correcto, y un servicio con arquitectura intacta puede caer por debajo de su grado estructural si el patrón es incorrecto. Elevar el grado tras un incidente exige (a) que la causa operativa se haya resuelto Y (b) que la respuesta haya seguido el patrón de transparencia + reacción rápida. Ninguno basta por sí solo.

Reportes de usuarios como entrada del grado

Los reportes de usuarios sobre scam, denegación de retiro o mala conducta del operador son una señal legítima — algunas de las primeras señales de exit scam llegan de usuarios horas antes que cualquier evidencia estructural. Pero un pipeline no moderado de «reporte anónimo → downgrade automático» también es una superficie de ataque: un competidor puede tirar un envío gratis y costarle un tier al operador. Este directorio califica por evidencia, no por acusaciones. Cuatro tiers gobiernan cómo un reporte mueve el grado.

• Tier 1 — anónimo, sin evidencia — Queja solo con texto, sin hash de tx, ID de orden, captura, canal de contacto o hilo tercero citables. Se registra como nota de timeline en el listing, visible vía /audit/<slug>. Grado sin cambio. El reporte es público — la afirmación cruda queda en el archivo, mueva el grado o no.
• Tier 2 — dos reportes independientes O uno con evidencia — Mismo patrón reportado por dos reporteros no vinculados, o un reporte con artefacto citable (hash de tx on-chain, ID de orden que el operador pueda mirar, captura con timestamp de UI, hilo público con handle real). Abre incidente severity medium, el grado baja un tier pendiente de resolución. El grado vuelve si el operador entrega refutación a nivel de order ID o la traza on-chain resuelve benigna.
• Tier 3 — corroboración de terceros — Hilo coincidente en kycnot.me / monerica / monero.observer / Reddit o X con el mismo patrón; O el reportero saca una dirección de wallet pública y el análisis on-chain calza con el flujo descripto. El grado baja a D, incidente escala a severity critical. La recuperación de grado exige post-mortem público Y restitución independiente o evidencia de reembolso verificable.
• Tier 4 — pérdida de fondos verificada + negación del operador — Fondos drenados a una dirección controlada por el operador, comprobable on-chain, más el operador niega públicamente en lugar de reconocer. Grado F, retirar del índice de categoría + búsqueda + sitemap, mantener registro público en shamelist por 24 meses según política de retirada. Éste es el bucket de exit scam.

La consecuencia para el lector: un listing en Grado A puede llevar una nota Tier 1 en su página /audit sin que el grado se mueva. Los lectores que quieren la señal cruda la ven; el grado no se convierte en tragamonedas para cualquiera con $0 y un minuto libre. La compensación es honesta: no seremos los más rápidos en reaccionar a acusaciones de lectores, y ocasionalmente vamos a ir más tarde que alguien haciendo screenshot de una queja anónima. Ése es el costo de un grado en el que se pueda confiar.

Política de retirada

• Evidencia de robo — fondos tomados a los usuarios sin justificación: retirada inmediata.
• KYC masivo de un día para otro — el operador pasa de sin KYC a exigir KYC sin proteger a los usuarios actuales.
• Adquisición por una entidad hostil — vendido o fusionado con una matriz centrada en compliance.
• Enlaces muertos / sin mantenimiento — retirado del listado, conservado en el log de auditoría.

Correcciones y disputas

¿Ves un error? Vía /submit o DM @xmrclub_bot.

Declaración de conflicto de interés

• El equipo del curador opera otros productos. Llevan chip CURATOR-BUILT.
• Los enlaces de afiliado nos generan comisión vía /go/<slug>.
• El patrocinio sube una entrada y añade chip SPONSORED — cortafuegos editorial.

Ejemplo trabajadocómo se decide una A

1. Descubrimiento — Operador o comunidad envía via /submit.
2. Prueba de alta — Cuenta real desde Tor session limpia.
3. Prueba de depósito — Pequeño depósito XMR/BTC.
4. Prueba de retiro — Retiro a address nuevo. KYC en retirar = bajada inmediata.
5. Revisión de postura — Política + ToS leídas. Historial cruzado contra /audit.
6. Fijación de grado — Curador registra grado + chips + last_verified.
7. Re-test anual — Mismo flujo. Si algún paso falla, el grado baja y se registra.