MiCA Decodificado: Seu white paper de criptomoedas não pode ser apenas um Gitbook ou um PDF

“MiCA Decoded” é uma série semanal de 12 artigos para o Bitcoin.com News, de autoria conjunta dos cofundadores e diretores executivos da LegalBison: Aaron Glauberman, Viktor Juskin e Sabir Alijev. A LegalBison assessora empresas de criptomoedas e FinTech em licenciamento MiCA, solicitações de CASP e VASP e estruturação regulatória na Europa e além.

No âmbito da MiCA, um white paper é um instrumento de divulgação legal obrigatório. Sua analogia mais próxima nas finanças tradicionais é um prospecto de valores mobiliários, não um documento de marketing. A regulamentação prescreve quem deve prepará-lo, em que formato, contendo quais identificadores, sujeito a qual validação automatizada e com responsabilidade atribuída a uma pessoa específica nomeada.

Errar em qualquer um desses elementos significa que o documento não existe aos olhos dos reguladores europeus, independentemente de quão bem escrito ele esteja.

Esta sexta edição do MiCA Decoded desdobra o que isso realmente significa, passo a passo.

O mito: um white paper MiCA é apenas um GitBook ou um PDF

Um white paper MiCA tem o peso de um documento regulatório formal.

O Regulamento de Execução (UE) 2024/2984 da Comissão, que rege os formulários, formatos e modelos para white papers de criptoativos, exige que o documento seja elaborado em um formato digital estruturado, projetado de forma que a ESMA e as autoridades nacionais competentes em todos os Estados-Membros da UE possam realizar análises automatizadas idênticas em cada envio, independentemente de quem o apresentou ou onde.

O objetivo jurídico dessa escolha de design é mais importante do que as especificações técnicas. A MiCA é um regulamento do mercado único, e a comparabilidade entre os registros é uma ferramenta fundamental de fiscalização.

Um white paper que não possa ser lido pela mesma máquina que todos os outros white papers apresentados na Europa não está em conformidade, independentemente do seu conteúdo. A ESMA publicou a taxonomia exigida (a estrutura que define o que um white paper em conformidade deve conter) em 5 de agosto de 2025. As regras entram em vigor a partir de 23 de dezembro de 2025.

As obrigações de divulgação variam dependendo do tipo de criptoativo envolvido. A MiCA estabelece três categorias distintas, cada uma com seu próprio modelo de white paper e requisitos de campos:

A categoria determina não apenas o conteúdo do white paper, mas todo o caminho legal para o seu registro. Um projeto não pode escolher qual categoria se aplica com base em preferência. As características do ativo determinam isso, e as obrigações de preparação decorrem daí.

Quem arca com a obrigação legal — e a responsabilidade

Para a grande maioria dos tokens no mercado (classificados como criptoativos “Outros”, ou OTHR), a obrigação não recai automaticamente sobre a entidade que criou o token. Para esses ativos, a MiCA atribui a obrigação ao ofertante ou à pessoa que busca admissão à negociação, que são funções definidas que podem ou não coincidir com o emissor original.

Essa distinção tem consequências reais. Um projeto enquadrado na categoria OTHR, lançado a partir das Ilhas Virgens Britânicas, das Ilhas Cayman ou de qualquer outra jurisdição offshore, pode ser o ofertante nos termos da MiCA e assumir diretamente a obrigação do white paper, sem qualquer exigência de transferir sua sede jurídica para a Europa.

(Observação: essa flexibilidade estrutural aplica-se estritamente aos tokens OTHR. Para tokens referenciados a ativos e tokens de dinheiro eletrônico, a obrigação legal e a responsabilidade civil estrita pelo white paper recaem inteiramente sobre o emissor autorizado da UE e não podem ser delegadas).

Conforme examinamos na segunda parte desta série, os registros da ESMA confirmam que essa já é uma prática padrão: a maioria dos registros de tokens independentes provém de entidades sediadas fora da UE.

Um CASP que opera uma plataforma de negociação também pode assumir a obrigação do white paper, seja por iniciativa própria ou por meio de acordo escrito com a equipe do projeto. Isso não é uma brecha legal nem uma conveniência administrativa.

Quando um CASP faz o registro, ele assume a responsabilidade legal pela exatidão e integridade da divulgação. Se o white paper contiver informações enganosas ou não cumprir os padrões regulatórios, a responsabilidade recai sobre quem o apresentou.

A pessoa que aprova o white paper não pode delegar essa responsabilidade a um fornecedor de software, a um integrador técnico ou a um escritório de advocacia. A revisão jurídica do conteúdo e a validade técnica são duas obrigações de conformidade distintas, e ambas recaem sobre o ofertante. Esse é o ponto que a maioria dos projetos subestima.

Dois códigos que devem existir antes do início do registro

Dois identificadores obrigatórios são pré-requisitos para qualquer white paper em conformidade. Ambos são extraídos de normas internacionais anteriores à MiCA. A regulamentação não os criou, mas os tornou obrigatórios.

O primeiro é o Identificador de Entidade Jurídica (LEI), um código ISO 17442 atribuído a entidades jurídicas e mantido no banco de dados Global LEI administrado pela GLEIF. A obrigatoriedade de seu uso abrange várias normas regulatórias: enquanto o Artigo 14 da RTS de manutenção de registros (Regulamento Delegado da Comissão UE 2025/1140) impõe requisitos de LEI aos CASPs para seus clientes, o Artigo 3 da RTS de classificação de white papers (Regulamento Delegado da Comissão UE 2025/421) determina estritamente que todos os elaboradores de white papers devem identificar sua própria entidade jurídica com um código LEI válido. Para qualquer entidade que ainda não possua um, o processo de solicitação do LEI deve ser concluído antes do início da elaboração do white paper.

O segundo é o Identificador de Token Digital (DTI), um código ISO 24165 que identifica o próprio criptoativo, mantido no registro DTIF. O Artigo 15 da RTS de manutenção de registros e o Artigo 3 da RTS de classificação de white papers (Regulamento Delegado da Comissão UE 2025/421) exigem seu uso. O ponto crucial para qualquer projeto que lance um novo token: se o DTI ainda não existir no registro, alguém deve solicitar sua criação antes que o white paper possa ser enviado. Quando um CASP estiver registrando um ativo sem emissor centralizado e sem white paper existente, a plataforma é responsável por recuperar ou solicitar o DTI diretamente do DTIF.

Fonte: o Registro DTIF para criptoativos

Um white paper que não contenha um LEI e um DTI válidos falha na validação automatizada antes mesmo que qualquer revisor humano o veja. Projetos que chegam à fase de envio sem ambos os códigos em mãos enfrentam um reinício completo.

O Portão Automatizado e o que isso significa legalmente

Nenhum funcionário de uma autoridade nacional competente analisa um white paper que falhe nas verificações automatizadas. A taxonomia da ESMA define 257 verificações de existência (verificando se os campos obrigatórios estão presentes) e 223 verificações de valor (verificando se o conteúdo dos campos é válido). Um registro que falhe em uma verificação classificada com gravidade “Erro” é tecnicamente inválido. O documento não prossegue.

A implicação jurídica dessa arquitetura é direta: a validade técnica e a precisão do conteúdo são igualmente de responsabilidade do ofertante. Uma divulgação legal perfeitamente redigida, mas com a estrutura errada, é rejeitada. Um arquivo estruturalmente válido com conteúdo enganoso também é rejeitado; ele simplesmente é rejeitado em uma etapa diferente e com consequências diferentes.

Projetos que oferecem tokens em vários Estados-Membros da UE enfrentam uma camada adicional. Cada versão linguística do white paper requer seu próprio arquivo estruturado separadamente. Todas as versões linguísticas devem ser internamente consistentes e não apenas traduzidas, mas organizadas de forma idêntica no nível dos campos. Uma tradução que não reflita a estrutura do original é tecnicamente não conforme, independentemente de sua precisão linguística.

As divulgações de sustentabilidade acrescentam uma restrição adicional. A taxonomia exige unidades de medida específicas para o consumo de energia e as emissões de CO2: kWh e tCO2, respectivamente. Trata-se de requisitos legais de divulgação, não de relatórios ambientais opcionais. O preenchimento com unidades diferentes ou a omissão dos campos aciona uma falha de validação.

O padrão em todos esses requisitos é o mesmo: o white paper é um documento legal com padrões aplicados automaticamente. Projetos que o abordam como um exercício de redação de documentos, em vez de um processo de conformidade com pré-requisitos estruturados e controle automatizado, encontrarão essa aplicação antes de chegarem a um regulador humano.

O que isso significa na prática

A compreensão popular de um white paper de criptomoedas como um argumento narrativo (algo escrito para persuadir, em vez de divulgar) descreve um tipo de documento que a MiCA substituiu por algo categoricamente diferente.

O white paper da MiCA é um instrumento jurídico com conteúdo prescrito, identificadores obrigatórios, um formato estruturado projetado para comparabilidade transfronteiriça automatizada e responsabilidade pessoal nominal atribuída a quem quer que o assine. A porta de entrada para o mercado europeu de criptomoedas passa por ele. Os projetos que entendem o documento pelo que ele é legalmente, em vez do que o termo sugeria historicamente, são aqueles que não são rejeitados na verificação automatizada.

Pontos-chave:

• O white paper não é um documento de marketing. A MiCA redefiniu o termo. O equivalente mais próximo nas finanças tradicionais é um prospecto de valores mobiliários, e ele deve ser tratado com o mesmo peso jurídico.
• Três categorias de ativos, três caminhos diferentes. OTHR, ART e EMT têm, cada um, requisitos distintos para o white paper e pré-requisitos de autorização diferentes. As características do ativo determinam qual categoria se aplica; o projeto não escolhe.
• A responsabilidade recai sobre o requerente, mas as regras dependem do ativo. Para a grande maioria dos tokens (OTHRs), a obrigação legal pertence ao ofertante ou à pessoa que busca admissão à negociação, não necessariamente ao criador original do token. Quando um CASP (como um operador de plataforma de negociação) concorda em preparar e publicar um white paper em nome de um projeto OTHR, ele assume deveres regulatórios significativos, mas não assume a responsabilidade totalmente. De acordo com o Artigo 14(3) da MiCA, a pessoa original que busca admissão à negociação permanece legalmente responsável se fornecer informações incompletas, injustas, pouco claras ou enganosas ao CASP. Você pode terceirizar a documentação, mas não pode terceirizar totalmente a responsabilidade.
• Para tokens referenciados a ativos (ARTs) e tokens de dinheiro eletrônico (EMTs), a responsabilidade civil estrita pelo white paper não recai exclusivamente sobre o emissor autorizado como pessoa jurídica; ela se estende explicitamente aos membros de seu órgão administrativo, de gestão ou de supervisão. Qualquer tentativa contratual de limitar ou excluir essa responsabilidade é legalmente nula.
• LEI e DTI são pré-requisitos. Ambos os identificadores devem estar em vigor antes do início da elaboração do white paper. Se não houver um DTI para o ativo, ele deve ser solicitado ao registro DTIF antes que qualquer outra etapa seja realizada.
• A validação automatizada é o primeiro filtro. São executadas 257 verificações de existência e 223 verificações de valor antes que qualquer pessoa revise o arquivo. Um documento que falhe em uma verificação de nível de erro não chega ao órgão regulador.
• Os registros multilíngues acarretam uma obrigação técnica oculta. Cada versão em idioma requer seu próprio arquivo estruturado separadamente, organizado de forma idêntica ao original. Uma tradução que não corresponda à estrutura de origem no nível dos campos é considerada não conforme.
• A precisão do conteúdo e a validade técnica são duas obrigações distintas. A revisão jurídica abrange a primeira. A estruturação técnica abrange a segunda. Ambas são de responsabilidade do proponente, e nenhuma substitui a outra.

Este artigo baseia-se em um estudo realizado pela LegalBison em abril de 2026. O conteúdo tem fins meramente informativos e não constitui aconselhamento jurídico.