MiCA Decodificado es una serie semanal de 12 artículos para Bitcoin.com News, coescrita por los Directores Cofundadores y Gerentes de LegalBison: Aaron Glauberman, Viktor Juskin y Sabir Alijev. LegalBison asesora a empresas de cripto y FinTech sobre licencias MiCA, solicitudes de CASP y VASP, y estructuración regulatoria en Europa y más allá.
Bajo MiCA, un white paper es un instrumento de divulgación legal obligatorio. Su analogía más cercana en las finanzas tradicionales es un prospecto de valores, no un documento de marketing. La regulación prescribe quién debe preparar uno, en qué formato, conteniendo qué identificadores, sujeto a qué validación automatizada, y con responsabilidad adjunta a una persona específicamente nombrada.
Equivocarse en cualquiera de esos elementos significa que el documento no existe a los ojos de los reguladores europeos, sin importar qué tan bien escrito esté.
Esta sexta entrega de MiCA Decodificado desglosa lo que eso realmente significa, pieza por pieza.
El Mito: Un White Paper de MiCA es Solo un GitBook o un PDF
Un white paper de MiCA lleva el peso de una presentación regulatoria formal.
El Reglamento de Ejecución de la Comisión (UE) 2024/2984, que rige los formularios, formatos y plantillas para white papers de criptoactivos, requiere que el documento sea preparado en un formato digital estructurado diseñado para que ESMA y las autoridades competentes nacionales de todos los estados miembros de la UE puedan ejecutar análisis automatizados idénticos en cada presentación, independientemente de quién lo presentó o dónde.
El propósito legal de esa elección de diseño importa más que los detalles técnicos. MiCA es una regulación de mercado único, y la comparabilidad entre presentaciones es una herramienta central de aplicación.
Un white paper que no puede ser leído por la misma máquina que cualquier otro white paper presentado en Europa no es conforme, sin importar lo que diga su contenido. ESMA publicó la taxonomía requerida (el marco estructurado que define lo que un white paper conforme debe contener) el 5-8-2025. Las reglas aplican a partir del 23-12-2025.
Las obligaciones de divulgación varían según el tipo de criptoactivo involucrado. MiCA establece tres categorías distintas, cada una con su propia plantilla de white paper y requisitos de campo:
| Tipo de Activo | Quién Prepara el White Paper | Característica Clave |
| OTHER (Otros criptoactivos, ej., tokens de utilidad) | Oferente, persona que busca admisión al trading, o CASP que opera una plataforma de trading | Categoría más amplia; cubre la mayoría de tokens actualmente en el mercado |
| ART (Tokens Referenciados a Activos) | Emisor autorizado o institución de crédito | Referencia una cesta de activos; autorización requerida antes de la emisión |
| EMT (Tokens de Dinero Electrónico) | Institución de crédito o institución de dinero electrónico | Paridad de moneda única; requiere autorización EMI o bancaria |
La categoría determina no solo el contenido del white paper, sino todo el camino legal para presentar uno. Un proyecto no puede elegir qué categoría aplica según preferencia. Las características del activo lo determinan, y las obligaciones de preparación se derivan de allí.
Quién Lleva la Obligación Legal – y la Responsabilidad
Para la gran mayoría de tokens en el mercado (categorizados como "Otros" criptoactivos, u OTHR), la obligación no recae automáticamente en la entidad que creó el token. Para estos activos, MiCA coloca la obligación en el oferente o la persona que busca admisión al trading, que son roles definidos que pueden o no coincidir con el emisor original.
Esta distinción tiene consecuencias reales. Un proyecto que cae en la categoría OTHR, lanzado desde las Islas Vírgenes Británicas, las Caimán, o cualquier otra jurisdicción offshore, puede ser el oferente bajo MiCA y llevar la obligación del white paper directamente, sin ningún requisito de reubicar su sede legal en Europa.
(Nota: Esta flexibilidad estructural aplica estrictamente a tokens OTHR. Para Tokens Referenciados a Activos y Tokens de Dinero Electrónico, la obligación legal y la responsabilidad civil estricta por el white paper recaen enteramente en el emisor autorizado de la UE y no pueden ser delegadas).
Como examinamos en la segunda entrega de esta serie, los registros de ESMA confirman que esto ya es práctica estándar: la mayoría de presentaciones independientes de tokens provienen de entidades con sede fuera de la UE.
Un CASP que opera una plataforma de trading también puede asumir la obligación del white paper, ya sea por iniciativa propia o por acuerdo escrito con el equipo del proyecto. Eso no es una laguna ni una conveniencia administrativa.
Cuando un CASP presenta, asume responsabilidad legal por la exactitud e integridad de la divulgación. Si el white paper contiene información engañosa o no cumple con los estándares regulatorios, la responsabilidad pertenece a quien lo presentó.
La persona que firma el white paper no puede delegar esa exposición a un proveedor de software, un integrador técnico o un bufete de abogados. La revisión legal del contenido y la validez técnica son dos obligaciones de cumplimiento separadas, y ambas recaen en el oferente. Este es el punto que la mayoría de proyectos subestima.
Dos Códigos Que Deben Existir Antes de Comenzar la Presentación
Dos identificadores obligatorios son prerrequisitos para cualquier white paper conforme. Ambos se derivan de estándares internacionales que preceden a MiCA. La regulación no los creó, los hizo obligatorios.
El primero es el Identificador de Entidad Legal (LEI), un código ISO 17442 asignado a entidades legales y mantenido en la base de datos Global LEI administrada por GLEIF. El mandato para su uso abarca múltiples estándares regulatorios: mientras que el Artículo 14 del RTS de mantenimiento de registros (Reglamento Delegado de la Comisión UE 2025/1140) aplica requisitos LEI en CASPs para sus clientes, el Artículo 3 del RTS de clasificación de white papers (Reglamento Delegado de la Comisión UE 2025/421) estrictamente exige que todos los preparadores de white papers deben identificar su propia entidad legal con un código LEI válido. Para cualquier entidad que no posea uno ya, el proceso de solicitud LEI debe completarse antes de que comience la preparación del white paper.
El segundo es el Identificador de Token Digital (DTI), un código ISO 24165 que identifica el criptoactivo en sí, mantenido en el registro DTIF. El Artículo 15 del RTS de mantenimiento de registros y el Artículo 3 del RTS de clasificación de white papers (Reglamento Delegado de la Comisión UE 2025/421) requieren su uso. El punto operativo para cualquier proyecto que lance un nuevo token: si el DTI aún no existe en el registro, alguien debe solicitar su creación antes de que el white paper pueda ser presentado. Cuando un CASP presenta para un activo sin emisor centralizado y sin white paper existente, la plataforma es responsable de recuperar o solicitar el DTI directamente del DTIF.
Fuente: el Registro DTIF para criptoactivos
Un white paper que no contiene un LEI y DTI válidos falla la validación automatizada antes de que cualquier revisor humano lo vea. Los proyectos que alcanzan la etapa de presentación sin ambos códigos en mano enfrentan un reinicio completo.
La Puerta Automatizada y Lo Que Significa Legalmente
Ningún humano en una autoridad competente nacional revisa un white paper que falla sus verificaciones automatizadas. La taxonomía de ESMA define 257 verificaciones de existencia (verificando que los campos requeridos estén presentes) y 223 verificaciones de valor (verificando que el contenido del campo sea válido). Una presentación que falla una verificación calificada con severidad de "Error" es técnicamente inválida. El documento no procede.
La implicación legal de esa arquitectura es directa: la validez técnica y la exactitud del contenido son igualmente responsabilidad del oferente. Una divulgación legal perfectamente redactada en la estructura incorrecta falla. Un archivo estructuralmente válido con contenido engañoso también falla; simplemente falla en una etapa diferente y con consecuencias diferentes.
Los proyectos que ofrecen tokens en múltiples estados miembros de la UE enfrentan una capa adicional. Cada versión de idioma del white paper requiere su propio archivo estructurado por separado. Todas las versiones de idioma deben ser internamente consistentes y no solo traducidas, sino organizadas idénticamente a nivel de campo. Una traducción que no refleja la estructura del original es técnicamente no conforme, independientemente de su precisión lingüística.
Las divulgaciones de sostenibilidad añaden una restricción adicional. La taxonomía exige unidades de medida específicas para consumo de energía y emisiones de CO2: kWh y tCO2, respectivamente. Estos son requisitos de divulgación legal, no informes ambientales opcionales. Presentar con unidades diferentes u omitir los campos desencadena una falla de validación.
El patrón en todos estos requisitos es el mismo: el white paper es una presentación legal con estándares aplicados por máquina. Los proyectos que lo abordan como un ejercicio de redacción de documentos, en lugar de un proceso de cumplimiento con prerrequisitos estructurados y control automatizado, encontrarán esa aplicación antes de llegar a un regulador humano.
Lo Que Esto Significa en la Práctica
La comprensión popular de un white paper de cripto como un argumento narrativo (algo escrito para persuadir en lugar de divulgar) describe un tipo de documento que MiCA ha reemplazado con algo categóricamente diferente.
El white paper de MiCA es un instrumento legal con contenido prescrito, identificadores obligatorios, un formato estructurado diseñado para comparabilidad transfronteriza automatizada, y responsabilidad personal nombrada adjunta a quien lo firme. La puerta de entrada al mercado cripto europeo pasa por él. Los proyectos que entienden la presentación por lo que legalmente es, en lugar de lo que el término históricamente sugirió, son los que no son rechazados en la verificación automatizada.
Conclusiones Clave:
- El white paper no es un documento de marketing. MiCA redefinió el término. El equivalente más cercano en las finanzas tradicionales es un prospecto de valores, y debe tratarse con el mismo peso legal.
- Tres categorías de activos, tres caminos diferentes. OTHR, ART y EMT cada uno lleva requisitos de white paper distintos y diferentes prerrequisitos de autorización. Las características del activo determinan qué categoría aplica, el proyecto no elige.
- La responsabilidad sigue al presentador, pero las reglas dependen del activo. Para la gran mayoría de tokens (OTHRs), la obligación legal pertenece al oferente o la persona que busca admisión al trading, no necesariamente al creador original del token. Cuando un CASP (como un operador de plataforma de trading) acuerda preparar y publicar un white paper en nombre de un proyecto OTHR, asume deberes regulatorios significativos, pero no asume la responsabilidad completamente. Bajo el Artículo 14(3) de MiCA, la persona original que busca admisión al trading permanece legalmente responsable si proporciona información incompleta, injusta, poco clara o engañosa al CASP. Puedes externalizar el papeleo, pero no puedes externalizar completamente la responsabilidad.
- Para Tokens Referenciados a Activos (ARTs) y Tokens de Dinero Electrónico (EMTs), la responsabilidad civil estricta por el white paper no recae únicamente en el emisor autorizado como entidad corporativa; se extiende explícitamente a los miembros de su órgano administrativo, de gestión o de supervisión. Cualquier intento contractual de limitar o excluir esta responsabilidad es legalmente nulo.
- LEI y DTI son prerrequisitos. Ambos identificadores deben estar en su lugar antes de que comience la preparación del white paper. Si un DTI no existe para el activo, debe solicitarse del registro DTIF antes de que cualquier otra cosa avance.
- La validación automatizada es el primer guardián. 257 verificaciones de existencia y 223 verificaciones de valor se ejecutan antes de que cualquier humano revise el archivo. Un documento que falla una aserción de nivel de Error no llega a un regulador.
- Las presentaciones multilingües llevan una obligación técnica oculta. Cada versión de idioma requiere su propio archivo estructurado por separado, organizado idénticamente al original. Una traducción que no coincide con la estructura de origen a nivel de campo no es conforme.
- La exactitud del contenido y la validez técnica son dos obligaciones separadas. La revisión legal cubre la primera. La estructuración técnica cubre la segunda. Ambas recaen en el oferente, y ninguna sustituye a la otra.
Este artículo se basa en un estudio realizado por LegalBison en abril de 2026. El contenido es solo para fines informativos y no constituye asesoramiento legal.
Fuente: https://news.bitcoin.com/mica-decoded-your-crypto-white-paper-cant-just-be-a-gitbook-or-pdf/
