P1. Para leitores que podem conhecer TEN apenas pelas manchetes recentes, como você explica a missão central do TEN Protocol e o problema que ele foi fundamentalmente projetado para resolver dentro do cenário de execução do Ethereum?
O Ethereum fez algo radical: tornou a computação globalmente verificável ao tornar tudo público. Essa troca desbloqueou finanças sem confiança – mas também, silenciosamente, quebrou uma enorme gama de aplicações reais.
Hoje, quando você usa a maioria dos L2s do Ethereum, você não está apenas executando uma transação. Você está transmitindo sua intenção, sua estratégia, seu timing e, muitas vezes, seu raciocínio econômico para todos os bots, concorrentes e adversários que assistem à rede. Essa visibilidade permite a verificação – mas também possibilita front-running, extração de estratégia, vigilância comportamental e mercados inteiros de ataques baseados em copiar intenções mais rápido do que humanos podem reagir.
O TEN existe para quebrar esse falso binário.
Nossa missão é simples de afirmar, mas difícil de executar: permitir que as pessoas usem aplicações do Ethereum sem revelar o que estão tentando fazer, enquanto ainda preservam a verificabilidade no padrão do Ethereum. Com a criptografia e o modelo de execução certos, é possível provar que a computação estava correta sem revelar os inputs, passos intermediários ou a lógica privada por trás disso.
Na prática, isso muda tudo. Operadores de nó não podem fazer front-running. Agentes de IA podem manter segredos com segurança. Jogos podem existir on-chain sem expor estados ocultos. Lances não são copiados. Aplicações não precisam vazar informações sensíveis apenas para serem prováveis.
O TEN trata de restaurar algo que os blockchains acidentalmente removeram: a capacidade de computar com confiança.
P2. O TEN posiciona “computar com confiança” como um elemento primordial ausente no stack de blockchain atual. Por que a confidencialidade seletiva é cada vez mais necessária para casos de uso reais em DeFi, IA, jogos e empresas?
Todo sistema de software bem-sucedido no mundo depende de controle de acesso. No Facebook, você não vê todas as postagens – apenas o que tem permissão para ver. No banco, seu saldo não é público. Em jogos, os oponentes não veem sua mão. Em empresas, a lógica interna e os dados são protegidos porque a exposição destrói valor.
Os blockchains inverteram esse modelo. Eles tornaram a transparência total o padrão – o que é ótimo para auditoria, mas catastrófico para muitas aplicações reais.
No DeFi, usuários vazam estratégias e se tornam presas previsíveis. Em jogos, informações ocultas, aleatoriedade e jogo justo são impossíveis de implementar corretamente. Em IA e empresas, expor dados, modelos ou lógica interna de decisão viola regulamentações ou elimina completamente a vantagem competitiva.
O que falta não é confiança – é confidencialidade programável com garantias criptográficas. Não privacidade acoplada via servidores centralizados ou promessas legais, mas controle de acesso imposto pelo próprio protocolo.
É isso que “computar com confiança” restaura: a capacidade de decidir quem pode ver o quê, mantendo o sistema verificável.
P3. Sua arquitetura depende de Trusted Execution Environments em vez de abordagens apenas ZK ou baseadas em MPC. Quais concessões foram feitas ao escolher esse design e como vocês mitigam as suposições de confiança associadas?
Desde o primeiro dia, nossa restrição era clara: os desenvolvedores devem poder implantar aplicações reais EVM sem reescrever o mundo.
Executar o EVM completo dentro de um Trusted Execution Environment permite que os desenvolvedores usem as mesmas linguagens, ferramentas e modelos mentais que já conhecem – enquanto ganham confidencialidade seletiva. Liquidez, liquidação e composabilidade permanecem ancoradas ao Ethereum.
As abordagens ZK e MPC são poderosas e estão evoluindo rápido, mas hoje geralmente impõem concessões sérias: complexidade de circuitos, gargalos de performance, programabilidade limitada ou sobrecarga operacional que dificulta o desenvolvimento e escalabilidade de apps de uso geral.
Usar TEEs introduz uma suposição de confiança enraizada em hardware – e somos explícitos quanto a isso. O TEN mitiga isso através de um design em camadas: hospedagem apenas em nuvem para reduzir vetores de ataque físico, atestação remota obrigatória, redundância, restrições de governança e engenharia de segurança rigorosa.
O resultado é um modelo híbrido. Público onde deve ser público – liquidação, auditabilidade, resultados. Confidencial onde precisa ser – inputs, fluxo de ordens e estado sensível. Não é pureza ideológica; é pragmatismo de engenharia.
P4. Como o TEN preserva a verificabilidade e composabilidade no padrão do Ethereum, enquanto permite que partes da execução, como inputs, fluxo de ordens ou estratégias, permaneçam confidenciais?
O TEN separa o que precisa ser comprovável do que precisa ser visível.
As regras do smart contract permanecem públicas. Qualquer um pode inspecioná-las. A execução ocorre dentro de um TEE atestado, e a rede pode verificar criptograficamente que o código correto foi executado em entradas válidas – mesmo se essas entradas estavam criptografadas.
Como um Layer 2, o TEN ainda publica rollups e transições de estado de volta ao Ethereum. Finalidade, liquidação e composabilidade permanecem exatamente onde os usuários esperam.
O que desaparece é a exposição desnecessária. Estratégias intermediárias, limites privados e lógica sensível não precisam vazar só para provar correção.
A confidencialidade torna-se uma capacidade de primeira classe, não um paliativo.
P5. Do ponto de vista da experiência do usuário, como a interação com uma aplicação alimentada pelo TEN difere de usar um L2 típico do Ethereum atualmente?
A maior diferença é psicológica – e é imediata.
Os usuários não se sentem mais vigiados. Não há ansiedade com o mempool, nem configurações defensivas de slippage, nem malabarismos de RPC privados apenas para evitar ser explorado. A intenção é privada por padrão.
Você submete um lance, uma estratégia ou uma jogada assumindo que não será copiada em tempo real – porque não será. Essa simples mudança faz o Web3 se aproximar mais de como softwares normais realmente se comportam.
A privacidade deixa de ser um recurso avançado para usuários experientes e passa a ser uma propriedade invisível da própria aplicação.
P6. Uma das principais narrativas do TEN é a redução do MEV e da exploração de mercado. Como mecanismos como lances selados, fluxo de ordens oculto ou roteamento privado funcionam na prática, e quais melhorias mensuráveis eles permitem?
O TEN muda o que é visível durante a execução.
Em um leilão de lances selados, os lances são criptografados e processados dentro de um TEE. Ninguém vê os lances individuais em tempo real. Dependendo do design, os lances podem nunca ser revelados – apenas o resultado final.
O fluxo de ordens oculto segue o mesmo princípio. Estratégias não são transmitidas ao mundo, então não há nada para copiar, simular ou sanduichar. O MEV não precisa ser “combatido” – ele simplesmente não tem do que se alimentar.
Crucialmente, isso não sacrifica a confiança. As regras são públicas, a execução é atestada e os resultados são verificáveis. Você pode provar justiça sem expor a intenção.
P7. O TEN destacou casos de uso como agentes de IA verificáveis e iGaming comprovadamente justo. Quais desses você vê como os primeiros impulsionadores da adoção real, e por que eles são mais adequados ao TEN do que às redes transparentes por padrão?
Jogos de aposta com dinheiro real são a aplicação de curto prazo mais clara.
Jogos exigem informação oculta, aleatoriedade rápida e baixa latência. Redes transparentes quebram essas premissas. No testnet do TEN, vimos dezenas de milhares de carteiras únicas e mais de um milhão de apostas – ordens de magnitude acima do engajamento típico de testnets.
House of TEN, o primeiro do mundo com pôquer onchain jogado por agentes de IA, foi um enorme sucesso durante o período beta.
Agentes de IA verificáveis são igualmente transformadores, mas com ciclo um pouco mais longo. Eles permitem gestão confidencial de tesouraria, tomada de decisão privada e sistemas de IA que podem provar conformidade com regras sem expor modelos ou dados proprietários.
Ambas as categorias se beneficiam diretamente da confidencialidade seletiva – e ambas são impossíveis de serem feitas corretamente em redes transparentes por padrão.
P8. O hardware confiável introduz uma classe diferente de risco operacional. Como o TEN foi projetado para garantir que falhas sejam detectáveis, contidas e recuperáveis, em vez de sistêmicas?
O hardware confiável muda o modo de falha – não o elimina.
O TEN assume que as coisas podem dar errado e é projetado para detectabilidade e contenção. A atestação remota garante que execuções incorretas sejam observáveis. Operadores redundantes evitam que falhas de nó único se tornem sistêmicas. Mecanismos de governança permitem que componentes comprometidos sejam isolados ou substituídos.
O objetivo não é confiança cega – é confiança limitada com garantias fortes.
P9. Mudando brevemente para operações de rede: como é o modelo atual de operador e como o roadmap caminha de uma fase inicial para maior descentralização e resiliência?
O TEN começa com um conjunto restrito de operadores para garantir segurança e performance, expandindo progressivamente a participação à medida que ferramentas, monitoramento e governança amadurecem.
Descentralização não é uma caixa a ser marcada – é uma sequência. Cada fase aumenta a resiliência sem comprometer as garantias de confidencialidade.
P10. Lançamentos de tokens são frequentemente confundidos com prontidão de produto. Como vocês separam internamente eventos de mercado do desenvolvimento do protocolo, e quais marcos são mais importantes para avaliar o progresso técnico do TEN nos próximos 6–12 meses?
De forma muito deliberada.
Eventos de token não definem prontidão. Implementação sim.
Internamente, o progresso é medido por lançamentos auditados, aplicações ao vivo, expansão de operadores, atividade de desenvolvedores e casos de uso reais que exigem confidencialidade.
Nos próximos 6–12 meses, o sucesso será medido pelas capacidades entregues – não pelas narrativas mantidas.
P11. Olhando para trás, quais lições operacionais a equipe tirou ao lançar um protocolo de infraestrutura complexo em um ambiente de mercado altamente reflexivo?
Que tecnologia sozinha não é suficiente.
Execução, comunicação e timing se potencializam – especialmente em mercados onde a percepção alimenta diretamente a realidade. Até sistemas fortes sofrem se as expectativas não estiverem alinhadas.
A lição é simples, mas impiedosa: a confiança é reconstruída pela entrega, não pela explicação. Infraestrutura funcionando supera mensagens perfeitas sempre.
P12. Olhando para o futuro, como seria o sucesso do TEN daqui a um ano em termos de capacidades entregues, adoção de desenvolvedores e aplicações reais rodando em produção?
Sucesso significa aplicações em produção que simplesmente não poderiam existir em redes transparentes.
iGaming ao vivo. Fluxos de trabalho DeFi protegidos. Agentes de IA verificáveis gerenciando valor real. Desenvolvedores usando confidencialidade como primitivo central de design, não como algo secundário.
Nesse ponto, o TEN não é “um projeto de privacidade”. É infraestrutura fundamental – a camada que faltava para o Ethereum finalmente suportar todo o espectro de aplicações reais.
