La diligencia debida de un proyecto cripto consiste en contrastar afirmaciones técnicas, económicas y jurídicas en fuentes primarias. La IA puede organizar preguntas, pero un white paper persuasivo no demuestra legitimidad, solvencia ni liquidez.
Contenido educativo, no asesoramiento financiero personalizado ni recomendación de comprar o vender activos. Comprueba las cifras en la documentación original y valora los riesgos por tu cuenta.
- Empieza por fuentes primarias
- Qué pedirle a la IA
- Comprueba la mecánica del token
Diligencia debida en cuatro capas: emisor, contrato, economía y regulación
Un white paper es la versión del proyecto sobre sí mismo; no es una verificación independiente. Organiza la revisión en cuatro capas y conserva para cada una una evidencia primaria distinta. En la capa del emisor, identifica la entidad legal, jurisdicción, responsables y canales oficiales. En la capa técnica, comprueba la dirección exacta del contrato, la red y si existe una auditoría que cubra esa versión. En la económica, documenta suministro, desbloqueos, asignaciones y liquidez. En la regulatoria, determina qué actividad se ofrece y dónde, sin inferir autorización a partir de una marca o una mención publicitaria.
| Capa | Prueba útil | Señal para detener la revisión |
|---|---|---|
| Entidad | Registro mercantil o regulador, nombre legal coincidente | Solo se ofrece un nombre comercial imposible de verificar |
| Contrato | Dirección publicada por canal oficial, código y permisos relevantes | La web y el explorador muestran contratos diferentes |
| Tokenomics | Suministro, calendario de desbloqueo, distribución y metodología | Las cifras no cuadran o cambian sin explicación |
| Regulación | Registro oficial aplicable a la entidad y actividad | Se afirma estar «regulado» sin identificar autorización |
En España, la CNMV explica el marco MiCA y la situación regulatoria de proveedores de servicios de criptoactivos. La comprobación debe realizarse en el registro oficial con la denominación exacta, no en una captura de pantalla enviada por el propio proyecto. Desde el 1 de julio de 2026, la página de la CNMV indica que solo pueden operar en España los proveedores autorizados por ella u otras autoridades europeas dentro del marco aplicable; revisa la página actual para no depender de una guía antigua.
Resultado recomendado: una ficha de evidencia con estados «confirmado en fuente primaria», «declarado por el proyecto», «no comprobado» y «contradictorio». Esta clasificación es más honesta que una puntuación única de «proyecto seguro».
Para un proyecto dirigido a usuarios de España o la UE, revisa las publicaciones regulatorias aplicables y las advertencias de la CNMV; que un proyecto tenga documentación propia no equivale a autorización. Fuentes de referencia: CNMV · MiCA y criptoactivos en España · CNMV · advertencias sobre entidades no autorizadas.
Empieza por fuentes primarias
Método de la guía: tratar la documentación del proyecto como una declaración hasta contrastar identidad, contrato, distribución y situación regulatoria.
Qué pedirle a la IA
Pide un resumen separado en: problema que dice resolver, utilidad del token, distribución, desbloqueos, gobernanza, ingresos o mecanismos de captura de valor, dependencias técnicas y riesgos. Cada afirmación importante debe enlazar a una fuente primaria.
Incluye un apartado “lo que no puede verificarse”. Si la IA dice que una auditoría elimina riesgos o que un equipo está verificado, busca el informe y el alcance concreto. La ausencia de una alerta no es prueba de legitimidad.
Comprueba la mecánica del token
Registra suministro circulante y máximo, calendario de desbloqueo, concentración de tenencias, liquidez y derechos concedidos al token. Comprueba si una cifra corresponde al suministro actual, al total o a una estimación diluida. Los sitios de datos pueden usar metodologías distintas.
No confundas una capitalización totalmente diluida elevada con una predicción de precio. Es un cálculo basado en precio y suministro asumido, no un valor realizable ni garantía de liquidez futura.
Cierra con un mapa de riesgos
Clasifica los riesgos en técnicos, económicos, de gobernanza, regulatorios, de custodia, de liquidez y de fraude. Incluye qué evidencia respalda cada riesgo y qué información falta. Una tabla así sirve para comparar proyectos sin fingir precisión cuantitativa.
Nunca compartas frases semilla, claves privadas ni archivos de wallet. Si se está considerando una exposición real, contrasta la situación con fuentes regulatorias vigentes y asume que puedes perder todo el capital expuesto.
Ejemplo aplicado: separar afirmaciones del proyecto y evidencia
Para una revisión inicial, crea una tabla con afirmación del proyecto, fuente, dato comprobable, evidencia independiente, incertidumbre y próximo paso. Si el equipo afirma que existe una auditoría de contrato, busca el informe original, verifica a qué versión del contrato se refiere y comprueba qué partes quedaron fuera del alcance. Una insignia o un enlace no equivalen a garantía.
Comprueba dirección del contrato en la red correcta, permisos de administrador, suministro y desbloqueos, liquidez, concentración de tokens, documentación sobre gobernanza y entidad responsable si la hay. Los exploradores de blockchain muestran transacciones, pero no siempre quién controla una dirección ni por qué hizo una operación. Evita mandar fondos o conectar una wallet para “verificar” un análisis.
Matriz mínima de diligencia debida
- Confirma nombre, red y dirección oficial del contrato por más de una fuente.
- Busca el white paper, documentación, auditoría y límites declarados.
- Comprueba suministro circulante, máximo, desbloqueos y distribución.
- Verifica si el proveedor de servicios aparece en registros regulatorios cuando corresponda.
- Registra las incógnitas y descarta afirmaciones sin fuente independiente.
Plantilla de prompt reutilizable
“Prepara una matriz de diligencia debida sobre este proyecto cripto usando únicamente las fuentes adjuntas. Clasifica cada afirmación como verificada, no verificada o contradicha; incluye URL, fecha y evidencia. No evalúes si el token subirá ni recomiendes comprar. Destaca riesgos de custodia, liquidez, contrato y concentración.”
Matriz de diligencia debida: cuatro capas que no deben confundirse
Una IA puede ordenar documentación de un proyecto cripto, pero la revisión debe separar cuatro dimensiones. Un contrato técnicamente correcto no demuestra que el equipo sea solvente; un white paper claro tampoco acredita que un proveedor esté autorizado para todos los servicios que anuncia.
| Capa | Fuente que comprobar | Pregunta concreta |
|---|---|---|
| Entidad y personas | Registro mercantil, web oficial, identidad jurídica y anuncios corporativos | ¿Quién asume obligaciones y quién controla las claves? |
| Tecnología | Dirección del contrato, explorador de la cadena, auditorías técnicas y repositorio | ¿El contrato observado coincide con el que publicita el proyecto? |
| Economía del token | White paper, calendario de desbloqueos, supply, contratos de vesting | ¿Qué puede cambiar la oferta y cuándo? |
| Regulación y servicios | Registro MiCA de ESMA, CNMV y advertencias nacionales | ¿Qué entidad y qué actividad concreta están autorizadas? |
En la UE, el registro provisional de ESMA incluye proveedores autorizados, white papers y entidades no conformes; la propia ESMA advierte que los white papers incluidos no equivalen a una aprobación de la autoridad. Por ello, aparecer en un fichero no es un sello de calidad del token ni una garantía de recuperación del capital.
Documenta señales, no acusaciones
Usa categorías como «confirmado por fuente pública», «no verificado», «inconsistente» o «requiere revisión legal». No declares que una persona comete fraude solo porque falte una información en una búsqueda. Guarda la URL, fecha y captura de la evidencia pertinente y revisa la información con la fuente oficial.
Preguntas frecuentes
¿Qué documentos pedirías a un proyecto antes de analizarlo?
White paper, documentación técnica, dirección de contratos, tokenomics, calendario de desbloqueos, entidad responsable, auditorías disponibles y comunicaciones regulatorias pertinentes.
¿Cómo se distingue una promesa de un hecho comprobado?
Etiqueta cada afirmación como declaración del equipo, dato on-chain verificable, documento de un tercero o hipótesis. La declaración del proyecto no es confirmación independiente.
¿La presencia en un exchange demuestra legitimidad?
No. La disponibilidad en una plataforma no elimina riesgo de fraude, vulnerabilidades, concentración, volatilidad o cambios regulatorios.
Fuentes y lecturas oficiales
Para el público español, combina la documentación del proyecto con los materiales de la CNMV, Investor.gov y las advertencias de ESMA; son fuentes de contexto, no certificaciones de un token.