Você implementa o contrato. Você chama a função que define o endereço do Policy. Tudo corre bem. No Etherscan, parece tudo bem conectado — o endereço está lá, a integração parece completa. Então você alimenta com uma atestação real da Newton para validação e… nada. Simplesmente falha. Não há revert com uma mensagem útil, nem erro óbvio. Apenas uma rejeição silenciosa.
Esse é o armadilha silenciosa que fica dentro do design da Newton.
A Newton separa duas coisas que parecem que deveriam ser uma etapa. Primeiro, você aponta seu contrato para o contrato Policy chamando _setPolicyAddress() (ou a setPolicyAddress() apenas do owner). Isso só armazena o endereço. Ele não faz nenhum trabalho de registro dentro do próprio contrato Policy. Nenhuma configuração é salva. Nenhum ID de política é criado.
O segundo passo é o que realmente importa: você precisa chamar setPolicy() (ou disparar _setPolicy()) para registrar as regras reais da política — os parâmetros, a lógica de expiração, tudo o que as atestações serão verificadas. Só então o sistema devolve um policyId de verdade.
Ignore essa segunda chamada e seu policyId fica em zero. Todo caminho de validação que compara o policyId da atestação com o que está configurado vai falhar, mesmo que o endereço pareça correto.
A documentação de integração do próprio Newton é clara sobre isso, mas é fácil perder porque o primeiro passo é feito sem reclamação. O contrato é implantado. O endereço fica visível na blockchain. Por fora parece pronto. Por dentro, as funções protegidas que dependem de verificações de atestação ficam inativas até você concluir o registro.
Isso não é algum caso extremo obscuro. Newton foi construído exatamente para o tipo de uso de alto risco que importa agora — automação on-chain, agentes de IA executando estratégias, gates de conformidade em fluxos de stablecoin, transferências de RWA, o que quer que seja. O protocolo está buscando uma área de superfície enorme: mais de US$ 313 bilhões em stablecoins, trilhões de volume de transferência mensal e centenas de bilhões em gastos anuais com conformidade. A Magic Labs (a equipe por trás de wallets embarcadas) construiu isso como uma camada descentralizada de políticas usando atestações e um EigenLayer AVS para que as regras possam ser aplicadas antes que as transações sejam finalizadas.
Num mundo em que agentes de IA começam a mover dinheiro de forma autônoma, a camada de políticas é o guarda-corpo. Mas o guarda-corpo só funciona se a etapa de registro realmente acontecer.
A escolha de design é compreensível. Newton quer uma fronteira de ativação explícita para ninguém acionar acidentalmente uma política malfeita ou incorreta. Apenas definir um endereço não deveria ser suficiente para começar a aplicar regras — isso poderia ser perigoso. A transação extra te obriga a ser deliberado.
O lado ruim é exatamente o que estamos vendo: um estado meio configurado que passa por todas as validações superficiais. Os desenvolvedores são treinados para procurar implantações falhas, endereços ausentes ou transações revertidas. Aqui a falha é invisível até o momento em que você mais precisa da proteção. Chamadas protegidas simplesmente não funcionam, e o motivo não fica óbvio até você examinar especificamente o policy ID.
Essa fricção importa economicamente. Cada “pegadinha” extra desacelera a adoção. Na corrida entre IA e cripto, protocolos que tornam a autorização segura de agentes algo natural vão vencer. Aqueles que criam momentos do tipo “parece estar tudo bem até não estar” correm o risco de perder desenvolvedores para alternativas mais simples (e menos seguras). Tempo gasto depurando falhas silenciosas não é tempo gasto entregando produtos.
Newton traçou uma linha clara entre “isto aponta para um contrato de Política” e “isto tem uma configuração ativa e registrada de política que as atestações realmente podem validar”. A linha existe por um motivo. Mas isso também abre espaço para implantações que parecem concluídas quando não estão.
Então aqui vai a pergunta real: forçar essa etapa de registro explícita torna Newton mais seguro no geral, ou apenas torna configurações incompletas mais difíceis de detectar até elas quebrarem no pior momento possível? Você já enfrentou esse problema exato (ou algo parecido) ao integrar clientes de política?
