Alex Nick

Eu continuo vendo Newton ser promovido ao lado de um hype genérico de IA, em vez de seus competidores reais. Isso é preguiçoso. A comparação verdadeira é com a Gelato Network e a Keep3r Network, dois players estabelecidos que lidam com a execução básica de tarefas sob demanda. Nenhuma delas verifica se a ação de um agente realmente correspondeu ao que o usuário autorizou; elas apenas executam o gatilho e confiam no script que o escreveu. A proposta inteira da Newton é preencher exatamente essa lacuna com prova criptográfica, em vez de confiar cegamente em um bot de custódia.
Revogação é quando isso fica genuinamente amigável ao usuário, e está subestimada. Um usuário que concede a um agente acesso via zkPermissions pode revogar essa permissão a qualquer momento e, como a regra fica no Keystore em vez de uma transferência de chave privada, revogá-la não exige rotacionar carteiras nem migrar fundos para lugar nenhum. Você simplesmente mata o objeto de permissão e o agente perde sua autorização instantaneamente — sem confusão, sem uma janela de exposição pendurada. Compare isso com um bot do Telegram que mantém suas chaves reais, onde revogar basicamente significa torcer para que o operador do bot ouça.

Newton's First Real Agent Is Just A Recurring Buy Bot And Honestly That's The Smart Move
Everyone expected Newton to launch with some flashy multi agent trading suite. They didn't. The first agent live on the Protocol is a Recurring Buy Agent, letting users automate scheduled crypto purchases directly onchain instead of relying on a centralized exchange's internal cron job. It's boring by design, and boring is exactly what you want when you're asking regular users to trust a brand new permission system with their wallet.
The onboarding side matters more than people give it credit for. Magic Labs built the embedded wallet layer underneath Newton, so a new user doesn't need a browser extension or a seed phrase ritual just to grant an agent scoped access. You sign in, pick an agent from the Model Registry, define your limits through zkPermissions, and the wallet handles the rest quietly in the background. That's a real attempt at making onchain automation feel closer to a normal app than a DeFi terminal.
Four roles keep this running. Developers build and publish agent models, operators execute the actual tasks, users submit the automation intents, and validators secure everything through delegated proof of stake. Early on, transaction fees were subsidized to lower the barrier for first time users testing the system, which tells me the team knew gas friction would kill adoption faster than any security concern. Subsidies don't last forever though, and NEWT becomes the required gas token for every permission update once that training wheel comes off.
Here's my honest read. A recurring buy bot isn't exciting, but it's the correct first product because it fails safely if something breaks. The real test comes when developers start publishing more aggressive strategy agents into that same registry, competing for the same user trust. I don't think the friendly onboarding survives contact with a bad actor listing a malicious model dressed up as a simple dollar cost averaging tool. Watch the registry curation closely, that's where this either holds together or doesn't.
@NewtonProtocol #Newt $NEWT

E eu não estou convencido de que a cadeia aguente o peso
Passei o fim de semana vasculhando o beta do mainnet da Newton em vez de dormir. A alegação central é simples. Antes que qualquer transação de um agente de IA seja incluída em um bloco, ela precisa passar por uma aplicação de políticas pré-transação executada dentro de TEE’s e respaldada por ZKPs. Isso não é um ajuste de interface. É uma restrição rígida que fica entre a intenção do agente e a mudança de estado executada, o que significa que a operação ou satisfaz o objeto de permissões ou nem sequer toca o mempool.

The Market And Nobody Explained What Happens When It Goes Down
Most DeFi infrastructure fails gracefully. If a price aggregator goes offline, your swap still routes, maybe at worse execution, but it routes. If a governance forum goes down, you can still trade. If a data dashboard stops loading, your positions keep running. Newton doesn't work like that. When you use a Newton-governed vault or authorize a Newton-managed agent, Newton's policy enforcement network sits directly between your capital and execution, meaning if the TEE operator network loses quorum, degrades below its minimum threshold, or experiences a service disruption, your authorized agents can't get policy proofs and can't execute trades. Your positions don't fail gracefully into a degraded mode. They freeze. And they freeze during the same kind of stressed network conditions, high transaction volumes, elevated gas prices, rapid market movement, that are most likely to cause operator availability problems in the first place.
Here's what that freezing actually looks like from your side of the screen. You authorized a Newton agent to manage your position with a stop-loss at a specific threshold. The market moves hard, your stop-loss threshold triggers, the agent submits the exit intent to Newton's policy enforcement network, and the network is congested or operating below quorum because every other Newton-governed agent is also trying to get policy proofs for their own urgent transactions at exactly the same moment. Your agent's policy proof request sits in queue while your position bleeds through the stop-loss threshold you set specifically to prevent that outcome. Eventually the proof comes through or it doesn't, the market has moved, and the execution that Newton's policy enforcement authorized is now settling at a price that makes the entire exercise of setting a stop-loss feel like a formality. You handed custody of your risk management to an automated agent and then discovered that agent's execution path has a queuing system that doesn't prioritize urgency.
My honest take from a pure user perspective. The technology Newton built is genuinely ambitious and I understand why the architecture works the way it does. But every layer of enforcement that sits between a user's intent and market execution is a layer where latency, outage, or congestion can turn a protection mechanism into the very thing it was designed to prevent. Before using any Newton-governed product with real capital, ask one question that Newton should answer publicly and prominently: what is the defined system behavior when the policy enforcement network can't fulfill a proof request within a specific time window, does the transaction fail closed meaning your agent can't act at all, or does some fallback exist that lets critical position management operations execute without a fresh proof during network stress events. If the answer is fail closed, your Newton agent's reliability during the market conditions that matter most is exactly as good as Newton's operator network uptime at that specific moment. And mainnet beta uptime under real market stress is something none of us have data on yet.
@NewtonProtocol #Newt $NEWT

Quebrou dezenas de sistemas de produção em 2025
O mecanismo de distribuição é a superfície de ataque. Integrações do oracle de Newton e os policy packs são distribuídos como pacotes de código aberto pela organização GitHub newt-foundation, especificamente por meio dos repositórios newton-policy-packs e newton-sdk, que os operadores baixam e executam dentro de seus ambientes de avaliação TEE durante a aplicação de políticas. Somente em 2025, pesquisadores de segurança identificaram mais de 454.600 novos pacotes maliciosos no npm, PyPI, Maven Central, NuGet e Hugging Face, com o padrão dominante sendo que atacantes tratam registros públicos como plataformas de distribuição e automatizam a publicação em escala. O Newton’s SDK faz parte dessa mesma infraestrutura de distribuição. Uma credencial comprometida do GitHub newt-foundation, uma solicitação pull maliciosa explorando uma configuração incorreta do fluxo de trabalho do Actions, ou uma dependência envenenada no próprio grafo de pacotes do newton-sdk poderia publicar uma versão do SDK com backdoor que os operadores instalam sem perceber que a lógica de avaliação de políticas executada dentro do TEE foi modificada silenciosamente. E o TEE é especificamente onde a arquitetura de privacidade da Newton encaminha os dados mais sensíveis que ela lida: atributos de identidade, pontuações de risco de carteira, resultados de KYC e parâmetros de restrição financeira que a Newton garante explicitamente que nunca tocam um ledger público.