MiCA Decoded é uma série semanal de 12 artigos para Bitcoin.com Notícias, em coautoria com os cofundadores e diretores administrativos da LegalBison: Aaron Glauberman, Viktor Juskin e Sabir Alijev. LegalBison aconselha criptografia e empresas FinTech em licenciamento MiCA, aplicações CASP e VASP e estruturação regulatória em toda a Europa e além.
No MiCA, um white paper é um instrumento de divulgação legal obrigatório. A sua analogia mais próxima nas finanças tradicionais é um prospecto de valores mobiliários, não um documento de marketing. O regulamento prescreve quem deve preparar um, em que formato, contendo quais identificadores, sujeito a qual validação automatizada e com responsabilidade atribuída a uma pessoa específica.
Errar em qualquer um destes elementos significa que o documento não existe aos olhos dos reguladores europeus, independentemente de quão bem escrito seja.
Esta sexta parte do MiCA Decoded revela o que isso realmente significa, peça por peça.
O mito: um white paper da MiCA é apenas um GitBook ou um PDF
Um white paper da MiCA carrega o peso de um registro regulatório formal.
O Regulamento de Execução (UE) 2024/2984 da Comissão, que rege formulários, formatos e modelos para livros brancos sobre criptoativos, exige que o documento seja preparado num formato digital estruturado concebido para que a ESMA e as autoridades nacionais competentes em todos os estados membros da UE possam executar análises automatizadas idênticas em cada apresentação, independentemente de quem a apresentou ou onde.
A finalidade legal dessa escolha de design é mais importante do que as especificidades técnicas. O MiCA é uma regulamentação do mercado único e a comparabilidade entre os registros é uma ferramenta essencial de aplicação.
Um documento branco que não possa ser lido pela mesma máquina que qualquer outro documento apresentado na Europa não é compatível, independentemente do seu conteúdo. A ESMA publicou a taxonomia exigida (o quadro estruturado que define o que um livro branco conforme deve conter) em 5 de agosto de 2025. As regras são aplicáveis a partir de 23 de dezembro de 2025.
As obrigações de divulgação variam dependendo do tipo de criptoativo envolvido. MiCA desenha três categorias distintas, cada uma com seu próprio modelo de white paper e requisitos de campo:
| Tipo de ativo | Quem prepara o Livro Branco | Característica Chave |
| OUTRO (Outros criptoativos, por exemplo, tokens utilitários) | Ofertante, pessoa que busca admissão para negociação ou CASP que opera uma plataforma de negociação | Categoria mais ampla; cobre a maioria dos tokens atualmente no mercado |
| ARTE (Tokens referenciados a ativos) | Emitente autorizado ou instituição de crédito | Faz referência a uma cesta de ativos; autorização necessária antes da emissão |
| EMT (Tokens de dinheiro eletrônico) | Instituição de crédito ou instituição de moeda eletrónica | indexação à moeda única; requer EMI ou autorização bancária |
A categoria determina não apenas o conteúdo do white paper, mas todo o caminho legal para apresentá-lo. Um projeto não pode escolher qual categoria se aplica com base na preferência. As características do ativo o determinam e daí decorrem as obrigações de preparação.
Quem assume a obrigação legal – e a responsabilidade
Para a grande maioria dos tokens existentes no mercado (categorizados como “Outros” criptoativos, ou OTHR), a obrigação não recai automaticamente sobre a entidade que criou o token. Para estes ativos, o MiCA impõe a obrigação ao oferente ou ao requerente da admissão à negociação, funções definidas que podem ou não coincidir com o emitente original.
Esta distinção tem consequências reais. Um projeto que se enquadre 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 oferente no âmbito do MiCA e cumprir diretamente a obrigação do livro branco, sem qualquer necessidade de transferir a sua sede legal para a Europa.
(Nota: Esta 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 livro branco cabem inteiramente ao emissor autorizado da UE e não podem ser delegadas).
Tal como examinamos na segunda parte desta série, os registos da ESMA confirmam que esta já é uma prática padrão: a maioria dos registos independentes de tokens 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 documento branco, por sua própria iniciativa ou por acordo escrito com a equipe do projeto. Isso não é uma lacuna ou uma conveniência administrativa.
Quando um CASP arquiva, ele assume 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 pertence a quem o enviou.
A pessoa que assina o white paper não pode delegar essa exposição a um fornecedor de software, um integrador técnico ou um escritório de advocacia. A revisão legal do conteúdo e a validade técnica são duas obrigações de conformidade distintas e ambas cabem ao ofertante. Este é o ponto que a maioria dos projetos subestima.
Dois códigos que devem existir antes do início do arquivamento
Dois identificadores obrigatórios são pré-requisitos para qualquer white paper compatível. Ambos são extraídos de padrões internacionais anteriores ao MiCA. O regulamento não os criou, tornou-os obrigatórios.
O primeiro é o Identificador de Entidade Jurídica (LEI)um código ISO 17442 atribuído a pessoas jurídicas e mantido no banco de dados Global LEI administrado pela GLEIF. O mandato para seu uso abrange vários padrões regulatórios: enquanto o Artigo 14 do RTS (Regulamento Delegado da Comissão UE 2025/1140) de manutenção de registros impõe requisitos de LEI em CASPs para seus clientes, o Artigo 3 do RTS de classificação do livro branco (Regulamento Delegado da Comissão UE 2025/421) determina estritamente que todos os preparadores de white paper devem identificar sua própria entidade legal 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 preparaçã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.º das RTS de manutenção de registos e o artigo 3.º do livro branco RTS de classificação (Regulamento Delegado UE 2025/421 da Comissão) exigem a sua utilização. O ponto operatório para qualquer projeto de lançamento de um novo token: se o DTI ainda não existir no cadastro, alguém deverá solicitar sua criação antes que o white paper possa ser submetido. Quando um CASP apresenta um pedido de um ativo sem emitente centralizado e sem documento branco existente, a plataforma é responsável por recuperar ou solicitar o DTI diretamente ao DTIF.
Fonte: Registro DTIF para criptoativos
Um white paper que não contém um LEI e DTI válido falha na validação automatizada antes que qualquer revisor humano o veja. Projetos que chegam à fase de submissão sem os dois códigos em mãos serão totalmente reiniciados.
O portão automatizado e o que isso significa legalmente
Nenhum ser humano de uma autoridade nacional competente analisa um white paper que não passa 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 do campo é válido). Um arquivamento que não seja aprovado em uma verificação com gravidade de “Erro” é tecnicamente inválido. O documento não avança.
A implicação legal dessa arquitetura é direta: a validade técnica e a precisão do conteúdo são igualmente de responsabilidade do ofertante. Uma divulgação jurídica perfeitamente redigida na estrutura errada falha. Um arquivo estruturalmente válido com conteúdo enganoso também falha; simplesmente falha num estágio diferente e com consequências diferentes.
Os 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 a nível de campo. Uma tradução que não reflita a estrutura do original é tecnicamente não conforme, independentemente da sua exatidão linguística.
As divulgações de sustentabilidade acrescentam uma restrição adicional. A taxonomia exige unidades de medida específicas para consumo de energia e emissões de CO2: kWh e tCO2, respectivamente. Estes são requisitos de divulgação legal e não relatórios ambientais opcionais. O preenchimento com unidades diferentes ou a omissão dos campos gera falha na validação.
O padrão em todos esses requisitos é o mesmo: o white paper é um documento legal com padrões aplicados por máquinas. Os 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
O entendimento popular de um white paper criptográfico como um discurso narrativo (algo escrito para persuadir em vez de divulgar) descreve um tipo de documento que o MiCA substituiu por algo categoricamente diferente.
O white paper MiCA é um instrumento legal com conteúdo prescrito, identificadores obrigatórios, um formato estruturado projetado para comparabilidade transfronteiriça automatizada e responsabilidade pessoal nomeada vinculada a quem o assina. A porta de entrada para o mercado europeu de criptografia passa por ela. Projetos que entendem o depósito pelo que ele é legalmente, e não pelo que o termo historicamente sugeria, são aqueles que não são rejeitados na verificação automatizada.
Principais vantagens:
- O white paper não é um documento de marketing. MiCA redefiniu o termo. O equivalente mais próximo nas finanças tradicionais é um prospecto de valores mobiliários, e deve ser tratado com o mesmo peso legal.
- Três categorias de ativos, três caminhos diferentes. OTHR, ART e EMT possuem requisitos distintos de white paper e diferentes pré-requisitos de autorização. As características do ativo determinam qual categoria se aplica, o projeto não escolhe.
- A responsabilidade segue o arquivador, mas as regras dependem do ativo. Para a grande maioria dos tokens (OTHRs), a obrigação legal pertence ao oferente 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 obrigações regulatórias significativas, mas não assume totalmente a responsabilidade. Nos termos do Artigo 14(3) do MiCA, a pessoa original que solicita a admissão à negociação permanece legalmente responsável se fornecer informações incompletas, injustas, pouco claras ou enganosas ao CASP. Você pode terceirizar a papelada, mas não pode terceirizar totalmente a responsabilidade.
- Para tokens referenciados a ativos (ARTs) e tokens de dinheiro eletrônico (EMTs)a responsabilidade civil objetiva pelo white paper não cabe apenas ao emissor autorizado como pessoa jurídica; estende-se explicitamente aos membros do seu órgão de administração, de direção ou de fiscalização. Qualquer tentativa contratual de limitar ou excluir esta responsabilidade é legalmente nula.
- LEI e DTI são pré-requisitos. Ambos os identificadores devem estar em vigor antes do início da preparação do white paper. Se não existir um DTI para o activo, este deverá ser solicitado ao registo DTIF antes de qualquer outra coisa avançar.
- A validação automatizada é o primeiro guardião. 257 verificações de existência e 223 verificações de valor são executadas antes que qualquer humano revise o arquivo. Um documento que falha em uma afirmação de nível de erro não chega ao regulador.
- Os arquivamentos multilíngues acarretam uma obrigação técnica oculta. Cada versão linguística requer o seu próprio ficheiro estruturado separadamente, organizado de forma idêntica ao original. Uma tradução que não corresponda à estrutura de origem no nível do campo não é compatível.
- A precisão do conteúdo e a validade técnica são duas obrigações distintas. A revisão jurídica cobre o primeiro. A estruturação técnica abrange o segundo. Ambos ficam com o ofertante e nenhum substitui o outro.
Este artigo é baseado em um estudar conduzido por LegalBison em abril de 2026. O conteúdo é apenas para fins informativos e não constitui aconselhamento jurídico.
Fontenews.bitcoink
Leia Também:
Hester Peirce: Repensando a vigilância e a privacidade financeira em criptografia
Promessas de mineração de Bitcoin sob ataque enquanto a SEC alega que fundos de investidores de US$ 48,5 milhões foram usados indevidamente
CVM atualiza regimento interno e amplia estrutura com criação de novas superintendências