Duas Portas Diferentes
Eu só tinha visto antes o fluxo de trabalho baseado na CLI do Newton — gerar CIDs, fazer deploy, configurar, simular e enviar. Voltando pela documentação, há um segundo caminho, separado: um SDK em TypeScript, `@magicnewton/newton-protocol-sdk`, em conjunto com viem, voltado para desenvolvedores que preferem escrever código em vez de rodar comandos de CLI. Público diferente, mesmo protocolo subjacente.
O caminho do SDK se concentra em um método chamado `simulateTask()` — uma simulação/dry run, documentada explicitamente como não enviando nada onchain, sem exigir Sepolia ETH e nem uma carteira. Você fornece uma intenção (de, para, valor, calldata, ID da chain, assinatura da função) e um objeto `policyTaskData` descrevendo qual política verificar, e ele retorna um resultado local.
Essa é uma forma genuinamente de baixa fricção de experimentar a Newton — sem carteira financiada, sem implantação, nada em jogo. E é exatamente por isso que o exemplo específico que o quickstart te entrega vale a pena ser observado com cuidado.
A Política de Demo que Todo Mundo Recebe
O exemplo `simulateTask()` do quickstart não te pede para escrever uma política. Ele aponta para uma que já está em execução: uma política pré-implantada de triagem de sanções da OFAC na Sepolia, com um endereço específico de política, um ID específico de política e um endereço específico de oracle para a lista de sanções, tudo fornecido diretamente na documentação como valores copiáveis. A documentação diz isso de forma clara: "você pode usar isso para testes."
Então, o caminho mais rápido do zero até "eu só usei a Newton" não envolve escrever nenhuma lógica de política. Envolve chamar uma função que verifica um endereço de exemplo fixo em relação a uma política que outra pessoa escreveu, implantou e mantém.
Por que isso vale ser notado, não criticado
Quero ter cuidado com o tom aqui, porque não há nada de errado com uma demo de baixa fricção — toda ferramenta séria para desenvolvedores tem uma, e exigir que um desenvolvedor escreva e implante uma política real antes de poder avaliar se a ferramenta vale o tempo dele seria uma experiência de onboarding pior, não uma mais rigorosa.
Mas isso significa que há uma lacuna significativa entre duas alegações diferentes: "eu testei o quickstart da Newton e funcionou" e "eu testei minha lógica de política no motor de avaliação da Newton". A primeira, por design, permite que um grande número de desenvolvedores que seguem o mesmo caminho de cinco minutos consiga dizer, usando exatamente a mesma política pronta e exatamente o mesmo endereço de exemplo. A segunda exige escrever o seu próprio Rego, implantar seu próprio contrato de dados de política e simular com base nas suas próprias intenções — um esforço materialmente maior do que o quickstart não exige que você faça antes de declarar sucesso.
Onde o caminho da CLI diverge
É por isso que eu acho que os dois caminhos de integração — SDK com política de demo compartilhada versus CLI com sua própria política implantada — não são realmente passagens intercambiáveis para a mesma experiência. O caminho da CLI que eu examinei anteriormente te força a gerar seus próprios CIDs e implantar seu próprio contrato de política antes mesmo de chegar a um passo de simulação; não existe um atalho equivalente para uma política preexistente embutida nesse fluxo. O caminho do SDK otimiza justamente para o oposto: o mais rápido possível para "funcionou", ao custo de que aquele primeiro sucesso não exercita de fato nenhuma lógica que você tenha escrito.
Nenhum dos caminhos está errado para o que está otimizando. Mas alguém que avalia a Newton tentando o guia rápido do SDK e alguém que a avalia trabalhando no fluxo de implantação via CLI podem sair com níveis significativamente diferentes de verificação prática real, enquanto ambos ainda podem dizer com precisão que "tentaram".
A Parte que Vale Perguntar Diretamente
Eu não tenho visibilidade sobre quantas integrações em execução ainda roteiam por aquela política de demo compartilhada específica versus uma genuinamente customizada, nem se a Newton acompanha essa distinção internamente. É uma pergunta razoável de se fazer diretamente: das políticas que estão sendo ativamente avaliadas na rede, quantas são lógicas originais, criadas por desenvolvedores, e quantas ainda apontam para exemplos de referência da documentação. Esse número diria algo que a abordagem de "as X integrações enviadas" não diz — quanto do ecossistema realmente fez o trabalho mais difícil de escrever e implantar suas próprias regras, versus quanto está rodando em lógica de demo emprestada que apenas continua funcionando.
Onde eu chego
Um caminho sem atrito de cinco minutos para "eu usei a Newton" é um bom design de produto. Só vale ser preciso sobre o que esses cinco minutos realmente verificaram — que a infraestrutura do protocolo funciona, usando a política de outra pessoa — em vez de tratar isso como evidência de que sua própria lógica de conformidade, seja ela qual for no fim, foi testada de forma significativa.