Contratos inteligentes na tokenização: automação e riscos

Na tokenização, os contratos inteligentes são o código que executa as regras do token: quem pode recebê-lo, em que condições ele pode ser transferido, quando e como os pagamentos e os resgates são feitos. Eles reduzem etapas manuais e tornam as regras verificáveis, mas não substituem o contrato jurídico e introduzem riscos próprios: falhas de código, poderes administrativos concentrados e dependência de dados externos. O que o código faz precisa coincidir com o que a documentação jurídica promete.

O que é um contrato inteligente

Um contrato inteligente (smart contract) é um programa registrado e executado em uma rede de registro distribuído que, verificadas as condições programadas, executa automaticamente operações, como transferências de tokens. A própria Resolução CVM nº 249/2026 adota uma definição nesse sentido: programa de computador registrado e executado em DLT que, verificadas as condições nele parametrizadas, executa automaticamente, no todo ou em parte, operações, transferências ou outras funções relativas aos tokens e aos direitos e deveres dos agentes (art. 4º, XII).

Para o conceito geral e os modos de falha fora da tokenização, veja contratos inteligentes: o que são e onde falham. Dois esclarecimentos evitam confusão:

• Não é um contrato no sentido jurídico. É software. O direito do titular do token vem de documentos e da lei aplicável, não do código.
• Automático não significa correto. O código executa o que foi escrito, inclusive o erro.

O que o código pode automatizar

Uma observação importante: a parte mais difícil da tokenização costuma estar nas interfaces entre o código e o mundo real. O contrato “sabe” apenas o que a rede registra ou o que um oráculo informa. Se o pagamento do devedor não chega ao emissor, nenhum código o cria.

Padrões de token com permissão

Tokens comuns, como os do padrão ERC-20, podem ser transferidos livremente para qualquer endereço. Para valores mobiliários e outros ativos regulados, isso costuma ser inadequado, e por isso surgiram padrões de token com permissão (permissioned). Dois são frequentemente citados.

ERC-3643 (T-REX)

Segundo a especificação publicada no repositório de EIPs, o ERC-3643 consta com status “Final”, foi criado em julho de 2021 e depende dos padrões ERC-20 e ERC-173 (propriedade de contratos). Seu desenho organiza a verificação de investidores e das regras em componentes:

• Identidade on-chain (ONCHAINID): cada investidor tem um contrato de identidade que guarda atestações (claims) assinadas por emissores confiáveis.
• Registro de identidades (Identity Registry): uma lista dinâmica que vincula carteira, identidade e país; a função de verificação checa se as atestações exigidas estão presentes e assinadas por emissores autorizados.
• Conformidade (Compliance): contrato com as regras da oferta, consultado a cada transferência (por exemplo, limites por país ou por investidor).
• Poderes de agentes: a especificação prevê transferência forçada (forced transfer), congelamento total ou parcial de saldos, pausa de todas as transferências e recuperação de tokens de uma carteira perdida para outra vinculada à mesma identidade.

O padrão é compatível com ERC-20, mas transfer e transferFrom passam a depender dessas verificações. A página da especificação informa que o código foi auditado pela Kaspersky e pela Hacken, sem problemas relevantes identificados; isso diz respeito ao padrão de referência, e não a uma emissão específica que o utilize.

ERC-1400

O ERC-1400 agrupa quatro padrões: ERC-1410 (saldos divididos em partições), ERC-1594 (restrições de transferência), ERC-1643 (documentos) e ERC-1644 (operações de controlador). Na discussão original no repositório de EIPs, o padrão aparece com status “Draft”, sem implementação de referência na página, e o tópico foi encerrado em 2022 por “housekeeping”, com registro de críticas à complexidade das partições. Quem encontrar um ativo “ERC-1400” deve verificar qual implementação específica foi usada, já que o padrão deixa parte da lógica a cargo de cada projeto.

O ponto comum: poder de controle

Nos dois casos, o token existe para ser controlável. Isso é desejável quando a lei exige bloqueio de contas, ordens judiciais ou recuperação de acesso, mas significa que alguém detém poder para pausar, congelar ou mover tokens. A pergunta da análise é quem é esse alguém, com que controles (multiassinatura, prazos de espera, trilha de auditoria) e sob qual fundamento no documento da oferta.

Auditoria: o que cobre e o que não cobre

A auditoria de código é a revisão do contrato por especialistas independentes. A documentação do ethereum.org afirma que auditorias de contratos inteligentes não encontram todos os erros e devem servir sobretudo como uma rodada adicional de revisão, não como solução definitiva. A mesma fonte indica que testes unitários isolados têm eficácia limitada e recomenda combiná-los com análise estática e dinâmica e, quando possível, com verificação formal.

Ao ler um relatório de auditoria, observe:

• se a versão auditada é exatamente a implantada (um código alterado depois deixa de estar coberto);
• o escopo (só o token ou também contratos de pagamento, de identidade e de governança);
• o que foi classificado como grave e se foi corrigido;
• se há programa de recompensa por falhas (bug bounty), que a mesma documentação descreve como incentivo financeiro a quem encontra vulnerabilidades.

Para um panorama de falhas documentadas, veja o artigo sobre risco de contratos inteligentes, auditorias e falhas conhecidas.

Upgradeability: corrigir o código também é um risco

Contratos na Ethereum são imutáveis por padrão. Para permitir correções, projetos usam padrões de proxy: o usuário interage com um endereço fixo (o proxy), que encaminha as chamadas para um contrato de lógica que pode ser trocado. O OpenZeppelin descreve que o estado fica no proxy e a lógica na implementação para a qual ele aponta.

Isso resolve um problema e cria outro:

• Vantagem: erros podem ser corrigidos e regras podem evoluir, o que é relevante para ativos de longa duração.
• Risco de confiança: o ethereum.org observa que a possibilidade de atualização contradiz a imutabilidade do código e exige que os usuários confiem que os desenvolvedores não alterarão os contratos arbitrariamente.
• Risco técnico: a documentação do OpenZeppelin alerta para colisões de armazenamento entre versões e para a necessidade de funções de inicialização protegidas contra reuso.
• Governança do upgrade: o padrão não impõe quem decide. Segundo o OpenZeppelin, o controle pode ser uma carteira multiassinatura, um endereço simples ou uma DAO; o ethereum.org cita multiassinatura e timelock (atraso obrigatório antes de a mudança valer) como mitigações, ao custo de retardar correções urgentes.

Em ativos tokenizados, a pergunta prática é se o documento jurídico informa que o contrato pode ser alterado, por quem e com qual aviso aos titulares.

Risco operacional além do código

• Chaves administrativas: a perda ou o roubo da chave que controla um contrato pode ter efeito equivalente a uma falha de código.
• Dados externos: preços, eventos e confirmações de pagamento dependem de oráculos; dado errado leva a execução errada.
• Descompasso entre registros: o saldo on-chain pode divergir do registro oficial do ativo ou do livro do emissor.

Limites e o que não é verdade

• “Está no contrato inteligente, logo está garantido”: o código não garante o pagamento do devedor nem a existência do ativo.
• “Auditado, logo seguro”: a auditoria reduz risco; não o elimina.
• “Imutável, logo sem risco de alteração”: contratos com proxy podem ser alterados por quem detém a chave de upgrade.
• “Descentralizado”: tokens com permissão são, por desenho, controlados por agentes definidos.

Contexto regulatório

No Brasil, o enquadramento depende dos direitos conferidos pelo token e da forma de oferta, e não da tecnologia. O Parecer de Orientação CVM nº 40/2022 afirma que a forma digital ou baseada em registro distribuído é irrelevante para o enquadramento como valor mobiliário. A Resolução CVM nº 249/2026 instituiu o Programa Piloto DLT CVM, de caráter experimental, entre cujos princípios consta que contratos inteligentes e integrações com oráculos passem por verificações de segurança, com mecanismos de tratamento de incidentes (art. 3º, V). O programa, porém, não autoriza atividades reguladas nem implica manifestação da CVM sobre a adequação dos contratos inteligentes testados (art. 1º, § 3º).

O que observar

• Se o documento jurídico descreve o que o contrato pode fazer, inclusive pausar, congelar e transferir à força.
• Qual padrão e qual implementação são usados, e se o endereço do contrato é público e verificado.
• Relatório de auditoria independente: escopo, versão e correções.
• Se o contrato é atualizável, quem controla o upgrade e se há multiassinatura e prazo de espera.
• Como os dados externos entram e o que ocorre se falharem.
• Plano de resposta a incidentes e de comunicação aos titulares.

Esses pontos fazem parte da due diligence em tokenização, e a consultoria para empresas pode apoiar a organização dessa análise. Conteúdo informativo; não constitui recomendação de investimento nem aconselhamento jurídico ou tributário.