André Dias Moreira Prol explica: Soroban vs Solidity, qual é mais segura

Quando revisei o código de um contrato inteligente que havia sofrido um exploit de reentrância em 2022, percebi algo que carrego até hoje: a segurança de um smart contract raramente é falha do desenvolvedor — muitas vezes é falha da própria linguagem em protegê-lo. Essa constatação me levou a estudar profundamente as diferenças entre Soroban, o ambiente de contratos da rede Stellar, e Solidity, a linguagem que domina o ecossistema Ethereum. E os resultados são reveladores para quem constrói aplicações críticas. A raiz do problema: modelos de segurança opostos Solidity nasceu poderosa, mas permissiva. Ela permite que o desenvolvedor faça praticamente qualquer coisa — inclusive erros catastróficos. Segundo dados da Chainalysis, exploits em contratos EVM causaram mais de US$ 3,7 bilhões em perdas apenas em 2022, sendo que vulnerabilidades clássicas como reentrância, integer overflow e problemas de controle de acesso respondem por boa parte desse montante. Soroban, por outro lado, foi construída sobre Rust, uma linguagem cuja filosofia é "segurança por padrão". O modelo de ownership e borrow checker do Rust elimina, em tempo de compilação, categorias inteiras de bugs de memória. Isso significa que muitos erros que em Solidity só apareceriam em produção — quando já é tarde — simplesmente não compilam em Soroban. Na minha experiência liderando projetos de tokenização, essa diferença é decisiva. Quando eu, André Dias Moreira Prol, avalio uma stack para um cliente do setor financeiro brasileiro, a capacidade de "falhar cedo" no ciclo de desenvolvimento vale mais do que qualquer flexibilidade sintática. Reentrância, overflow e o custo do descuido O caso mais didático é a reentrância. Em Solidity, é preciso disciplina rigorosa — usar o padrão checks-effects-interactions ou modificadores como nonReentrant do OpenZeppelin. Esquecer isso é um convite ao desastre, como demonstrou o histórico ataque ao The DAO. Soroban trata o estado de forma isolada e determinística, com um modelo de execução que reduz drasticamente a superfície de ataque para chamadas maliciosas cruzadas. Além disso, Rust trata overflow aritmético como erro por padrão (em modo debug e com verificações explícitas), enquanto versões antigas de Solidity exigiam bibliotecas como SafeMath — algo só resolvido nativamente a partir da versão 0.8. Vale um contraponto honesto: Solidity tem um ecossistema maduro. Ferramentas de auditoria como Slither, MythX e Certora, além de milhares de auditores capacitados, formam uma rede de segurança que Soroban, mais jovem, ainda está construindo. No Brasil, encontrar um desenvolvedor Solidity experiente é bem mais fácil hoje do que um especialista em Soroban — realidade que impacta diretamente prazos e custos de projeto. O que o mercado brasileiro deve considerar O Drex, o real digital do Banco Central, e a crescente onda de tokenização de recebíveis e crédito no país aumentam a urgência dessa decisão. Instituições que buscam liquidação rápida, taxas baixas e conformidade encontram na Stellar — e portanto em Soroban — argumentos técnicos fortes: finalização de transações em segundos e custos irrisórios comparados à gas fee volátil do Ethereum. Do ponto de vista de segurança, minha recomendação é pragmática. Para projetos que exigem robustez máxima na proteção contra bugs de baixo nível e que podem investir em capacitação da equipe, Soroban oferece vantagens estruturais claras. Para projetos que dependem de composabilidade com o vasto ecossistema DeFi existente e de auditorias rápidas com talento disponível, Solidity ainda é imbatível em maturidade. Como sempre digo em minhas consultorias, e reforço aqui como André Dias Moreira Prol: segurança não é escolher a linguagem "mais forte", e sim alinhar as garantias da tecnologia ao perfil de risco e à maturidade da equipe. Uma equipe despreparada torna insegura qualquer linguagem. Conclusão Soroban leva vantagem estrutural em segurança por herdar as garantias do Rust, enquanto Solidity compensa com maturidade de ferramentas e talento — a escolha certa depende do seu contexto, não de dogmas. Avalie seu projeto com critério técnico e, se precisar de uma análise aprofundada, entre em contato para desenharmos juntos a arquitetura mais segura para o seu caso.