Paul Nguyen

O roadmap de Newton lista um conjunto específico de gates que precisam ser superados antes que validadores e agentes permissionless possam entrar na rede: revisões de segurança, auditorias formais e clareza regulatória sobre agentes de automação tocarem fundos do protocolo ou governança. Leia isso tanto como um resguardo responsável quanto como uma desculpa conveniente para manter a centralização por mais tempo — e, honestamente, ambas as leituras têm algum grau de verdade.

O caso do resguardo é direto. O argumento central da Newton se apoia em confiança: operadores avaliando a política corretamente, agentes se comportando conforme especificado, atestações significando aquilo que afirmam significar. Abrir o onboarding de validadores e agentes para qualquer pessoa antes de essas coisas serem de fato auditadas seria imprudente, dado que fundos reais de usuários já estão passando pela mainnet beta. Um gate aqui não é burocracia por si só; é a mesma lógica que impede que uma equipe não licenciada se aproxime de pacientes no primeiro dia.

O caso de uma descentralização mais lenta também tem consequências. Cada gate adicional também é um motivo para a Fundação continuar sendo a operadora principal por mais tempo, coletando a confiança e as taxas associadas a operar a rede antes de abri-la à competição de validadores de terceiros. Auditorias levam tempo, e o tempo favorece quem já está no comando. Isso não é necessariamente má-fé; talvez seja apenas o incentivo natural de qualquer equipe que controla uma infraestrutura que as pessoas estão usando ativamente com dinheiro real.

Eu não acho que dá para definir, de fora, qual leitura domina. Depende de quanto tempo esses gates levam quando as auditorias são encomendadas, e se o onboarding é aberto assim que elas passam ou se os “postes” mudam silenciosamente. A Newton ainda não deu uma data firme.

A Newton exige auditorias e clareza regulatória antes do onboarding de validadores e agentes permissionless: um gate que protege hoje os fundos reais dos usuários com o custo explícito de uma descentralização mais lenta, e só o tempo mostrará qual lado dessa troca efetivamente prevalece.

@NewtonProtocol $NEWT #Newt $BLUR

Um bom senhorio não verifica apenas uma vez o score de crédito e depois esquece. Ele verifica referências, verifica há quanto tempo você manteve contratos de locação anteriores e, se algo mudar mais adiante, ele nota. A integração do Newton's Neynar trata a confiança onchain de forma muito parecida com como um senhorio trata um inquilino — não como uma checagem de antecedentes que roda uma vez e fica arquivada para sempre.

O Neynar Data Oracle traz o score do usuário de uma conta no Farcaster, a contagem de seguidores, endereços de carteira externos verificados e insígnias da conta para uma política do Newton, checada antes que uma transação ou tarefa seja permitida. Uma votação de governança pode exigir uma pontuação mínima de qualidade. Uma queda de recompensa pode exigir pelo menos uma carteira verificada mais uma contagem real de seguidores, e não apenas um endereço que apareceu ontem sem nada por trás.

A comparação com um senhorio checando referências se sustenta melhor do que parece. Ter apenas a contagem de seguidores é como um nome numa inscrição de aluguel: fácil de falsificar com paciência suficiente. Uma carteira externa verificada é mais próxima de uma referência real, um vínculo com algo que é concreto e mais difícil de montar do nada. As insígnias da conta funcionam como um histórico de locação, evidência de comportamento ao longo do tempo, em vez de uma afirmação feita no momento.

Nada disso torna uma conta à prova de bala, da mesma forma que nenhuma checagem de um senhorio impede que todo inquilino ruim passe eventualmente. Mas isso afasta o sistema inteiro de aceitar a palavra de alguém e vai em direção a “mostre algo que levou tempo real e presença real para ser construído”.

Esse é o valor silencioso aqui. Confiança que custa algo para falsificar vale mais do que confiança que só precisava de uma alegação. E a forma como a Newton constrói essa lógica em uma política reutilizável, em vez de deixar cada app reinventar sua própria versão da mesma checagem, é o ponto principal que a maioria das pessoas passa direto.
@NewtonProtocol $NEWT #Newt
$TLM $SYN

A crítica comum a Newton é mais ou menos esta: empilhar Chainalysis, Hexagate, EigenLayer, Succinct, Rhinestone, Octane, RedStone, Credora e Vaults.fyi em um único protocolo apenas cria mais área de superfície para algo quebrar. Mais fornecedores, mais pontos únicos de falha.

Eu não acho que essa crítica se sustente quando você olha como a Newton integra cada um deles. Por causa do modelo de único gancho de verificação de política, cada uma dessas integrações fica em um ponto específico e estreito do pipeline, não entrelaçada diretamente na lógica do contrato central. Chainalysis e Hexagate alimentam o domínio de segurança. RedStone e Credora alimentam o domínio de risco. EigenLayer garante a rede de operadores. Cada um faz uma tarefa, e nenhum deles exige mexer nos outros para serem substituídos.

Isso é estruturalmente diferente de um sistema monolítico em que cada dependência fica emaranhada com todas as outras; tirar um único fornecedor significaria reescrever metade da base de código. A arquitetura da Newton faz com que um provedor de oracle com falha ou um feed de detecção de ameaças comprometido seja um problema contido dentro de um único domínio, e não algo que se propaga simultaneamente por identidade, conformidade e risco.
Não é uma defesa perfeita: um domínio que depende inteiramente de um único fornecedor ainda fica exposto se esse fornecedor falhar de forma grave o bastante. Mas "mais integrações = mais risco de centralização" assume que essas integrações são sustentação umas das outras. No design da Newton, na maior parte, não são.

Acredito que o risco mais interessante não é arquitetural; é operacional. Trocar RedStone por outro provedor de feed de preços é tecnicamente direto graças ao modelo de gancho, mas ainda significa que um curador precisa notar o problema, decidir por uma substituição e migrar uma política em execução sem downtime. A arquitetura remove o risco de dependência emaranhada. Ela não remove o risco de coordenação humana de realmente agir em um sinal de alerta a tempo.
@NewtonProtocol $NEWT #Newt $LAB $GAIA

As políticas do agente de IA da Newton impõem limites de gastos, listas de beneficiários aprovados e defesa contra injeção de prompt antes de uma transação ser concluída — e isso é apresentado como segurança do agente. Eu acho que é segurança real, mas também acho que existe uma linha tênue entre “conter um agente comprometido” e “encerrar a luta contra um agente comprometido”, e essas não são a mesma alegação, mesmo quando o discurso às vezes as mistura.

Aqui está a versão forte do argumento. Um agente que é manipulado para agir fora do seu trabalho pretendido ainda esbarra em uma barreira na camada de transação se a ação cair fora da sua lista aprovada de beneficiários ou exceder o escopo da sua missão, mesmo quando o valor em dólares parece perfeitamente razoável. Isso é, de fato, mais sofisticado do que um simples limite de gastos: é verificar se o agente deveria estar fazendo isso, e não apenas se ele consegue pagar.

Aqui está a versão fraca, e eu acho que ela importa mais do que as pessoas dão crédito. Tudo o que a Newton impõe acontece na camada de transação, que é o último ponto de verificação antes de o dinheiro se mover. Um ataque de injeção de prompt que manipula o raciocínio de um agente acontece antes disso, a montante, dentro do próprio processo de decisão do modelo, antes mesmo de qualquer transação ser rascunhada. A Newton pode bloquear a transação ruim. Ela não pode desfazer o fato de que o agente foi manipulado com sucesso em primeiro lugar, e um agente que continua sendo enganado continuará gerando tentativas de transação maliciosas — cada uma delas agora precisando ser detectada individualmente.

Então a Newton resolve a segurança do agente ou apenas contém os danos de um problema que ela não consegue realmente corrigir? Eu acho que a resposta honesta é contenção, e contenção é de fato valiosa; a maioria dos ataques sequer chega a esse nível de defesa hoje. Mas a luta mais difícil, impedir que um agente seja manipulado em primeiro lugar, ainda acontece totalmente antes de qualquer coisa que a Newton toque.
@NewtonProtocol $NEWT #Newt $HMSTR

Um registo de títulos que só verifica a qualificação de um comprador depois de o imóvel já ter mudado de mãos não está realmente a proteger ninguém; está apenas a documentar um problema depois de ser tarde demais para o impedir. A maior parte da conformidade real de ativos no mundo da cripto tem funcionado silenciosamente como essa segunda versão: a elegibilidade é verificada uma vez algures a montante, e depois a transferência efetiva acontece sem um verdadeiro “portão” no momento em que realmente importa.

A Newton inverte essa ordem para os RWAs. A elegibilidade do investidor, a jurisdição, as restrições de transferência e a triagem de sanções são aplicadas no momento da emissão e em todas as transferências subsequentes, e não verificadas uma vez e depois confiadas para sempre. Um ativo tokenizado a passar por um contrato com portão da Newton é verificado em relação às regras de elegibilidade atuais no momento em que alguém tenta movê-lo, da mesma forma que um registo de títulos idealmente verificaria a qualificação de um comprador antes de a venda ser concluída, e não depois de a papelada já ter sido arquivada e as chaves já terem mudado de mãos.

Essa comparação também se sustenta no lado do “trade off”. Um registo que verifica antes do encerramento é mais lento; ele adiciona fricção exatamente no momento em que alguém quer que a transação apenas prossiga. Ninguém gosta de um encerramento que fica preso por uma verificação de conformidade. Mas a alternativa — descobrir depois que, na verdade, o comprador nunca deveria ter sido elegível — significa desfazer uma transação que já aconteceu, o que é um problema muito mais confuso e mais caro do que a fricção que teria sido necessária para detetar antecipadamente.

A Newton está a fazer a mesma aposta que um registo bem gerido faz: identificar uma transferência inelegível antes de ela ser liquidada vale a fricção, porque desfazer uma operação depois é o verdadeiro modo de falha caro que os emissores institucionais de RWA tentam evitar em primeiro lugar. E essa aposta só vale a pena se os dados de elegibilidade por trás da verificação se mantiverem suficientemente atuais para serem confiáveis exatamente no momento em que cada transferência acontece.
@NewtonProtocol $NEWT #Newt $RE

Um cliff de aquisição (vesting) de 48 meses e uma dieta “crash” têm a mesma lógica básica: a disciplina só conta se você realmente cumpre — uma vez que ninguém está te obrigando a isso.

A NEWT foi lançada com apenas 21,5% do seu total de 1 bilhão de tokens em circulação, enquanto as alocações para o ecossistema e infraestrutura ficaram travadas por desbloqueios lineares de 48 meses. Isso é um compromisso real no papel; a maioria dos lançamentos de “tokens de utilidade” promete disciplina de longo prazo e, depois, encontra uma votação de governança para afrouxar isso pela primeira vez quando a ação do preço fica desconfortável.

A parte nebulosa é que ninguém consegue definir ainda. Uma agenda de desbloqueio linear escrita em um documento de lançamento só é tão durável quanto os incentivos de quem a controla mais tarde. O roadmap da Newton descreve um caminho do controle da fundação rumo à governança comunitária, e os detentores de NEWT eventualmente terão voz em parâmetros que os termos atuais não contemplam. É essa a tensão honesta: o mesmo mecanismo de governança projetado para descentralizar o controle é também o mecanismo que, um dia, poderia votar para suavizar um cronograma de oferta que hoje parece disciplinado.

Não acho que isso torne o cronograma de desbloqueio atual sem sentido — um compromisso de 48 meses ainda é uma pista mais longa do que a maioria dos tokens tenta. Mas tratá-lo como algo permanentemente travado ignora que tokens de governança, por definição, podem eventualmente governar as próprias regras que os definem.

O design do token da NEWT mostra uma disciplina real de curto prazo, e saber se essa disciplina sobrevive ao contato com o poder real de governança anos à frente é algo que os termos do lançamento não conseguem responder por si só. Eu prefiro acompanhar a primeira votação de governança que toque diretamente nos parâmetros de desbloqueio do que confiar em qualquer documento de lançamento, porque é nessa votação que a “dieta” ou se mantém firme — ou é renegociada silenciosamente pelas pessoas que agora têm a “garra” da própria situação na mão.
@NewtonProtocol $NEWT #Newt $RE

O mais estável em compliance de stablecoin que eu já vi na cadeia para na porta da frente. Faça uma verificação de KYC uma vez ao fazer o onboard, obtenha um selo verde e, a partir daí, ninguém fica realmente vigiando como o dinheiro se move. É exatamente essa lacuna que os reguladores continuam apontando quando os emissores de stablecoins pedem regras mais claras — e é exatamente nessa lacuna que as políticas de stablecoin da Newton se recusam a parar.
A Newton aplica os dados da regra de viagem (travel rule) e limites de velocidade no momento da transferência, não apenas no onboarding. Cada transferência acima de um determinado limite carrega informações do originador e do beneficiário que a política consegue verificar, e os limites de velocidade capturam o tipo de movimento rápido e estruturado que uma verificação única de KYC nunca foi criada para perceber. Isso representa um esforço maior para um emissor do que um fluxo estático de onboarding: há mais dados para acompanhar, mais condições para avaliar, em cada transação — e não apenas na primeira.
Eu entendo por que a maioria dos times pula isso. Compliance apenas no onboarding é mais simples de implementar e mais fácil de explicar para uma equipe de produto em uma reunião de planejamento de sprint. Mas também é uma triagem que chega tarde demais para detectar qualquer coisa que aconteça depois que a conta já foi aprovada — exatamente a lacuna que os reguladores continuam sinalizando nos frameworks de stablecoins, ano após ano, sem muita mudança em resposta.
O Protocolo Newton trata a compliance de stablecoins como uma checagem contínua em nível de transação, e não como um gate de onboarding único. A aplicação da travel rule e os limites de velocidade se aplicam a toda transferência que uma política governa, não apenas à primeira que um usuário faz. Isso é mais lento para integrar e mais difícil de manter do que um simples checkbox de KYC, mas é a diferença entre uma compliance que consegue realmente capturar um problema conforme ele acontece e uma compliance que só consegue provar que alguém passou por uma verificação uma vez — muito tempo antes da transação que importava.
@NewtonProtocol $NEWT #Newt $RE

O que é prometido no roadmap da Newton é amplo: cofres hoje, ativos do mundo real, stablecoins e agentes de IA amanhã, tudo ancorado em algo chamado Internet of Policies marketplace. O que, de fato, foi realizado até agora é mais restrito, e essa diferença vale a pena encarar em vez de simplesmente passar por cima.

O contexto aqui importa. Vários protocolos anunciam um roadmap expansivo no primeiro dia: RWAs, stablecoins, finanças agentic, os grandes sucessos de todos os decks de apresentação de 2025 e 2026 — e então passam o ano seguinte entregando quase nada disso. O padrão é tão comum que um roadmap ambicioso já virou um sinal de alerta leve por si só: uma indicação de que o time está vendendo uma visão em vez de construir um caso de uso de forma bem feita primeiro.

A sequência real da Newton se lê diferente quando olhamos com atenção. Os cofres foram entregues primeiro, em beta no mainnet, com um SDK funcional, parceiros de dados em operação e um caso de uso institucional de verdade já rodando através da Polymarket. RWAs e stablecoins ainda não foram lançados, e nem o Internet of Policies marketplace — onde curadores presumivelmente listariam e reutilizariam políticas do mesmo jeito que desenvolvedores reutilizam pacotes de código aberto hoje.

O efeito de colocar essa sequência no lugar errado seria sério. Um engine de políticas que não consegue aplicar com confiabilidade uma verificação simples de colateral em um cofre não deveria ser confiável para fazer triagem de sanções em uma stablecoin movimentando bilhões, muito menos para definir guardrails para um agente autônomo de IA tomando decisões sem um humano no loop. Começar estreito não é falta de ambição; é o único caminho crível para ganhar o direito de expandir.

O Newton Protocol está tratando os cofres como campo de prova para todo o resto do roadmap — não como produto final — o que significa que as afirmações de RWA, stablecoin e agente de IA continuam sendo promessas até que a camada de cofres tenha, de fato, aguentado sob volume real. Esse é o estado honesto da lacuna agora: não é uma crítica, apenas onde o cronograma realmente está.
@NewtonProtocol $NEWT #Newt

Diga “rede de computação de IA descentralizada” para a maioria das pessoas e uma imagem específica é formada automaticamente. Sua solicitação ricocheteia de forma imprevisível por algum enorme enxame peer-to-peer; não há um único ponto decidindo qualquer coisa, pura aleatoriedade, pura distribuição, ninguém em particular tratando da sua consulta específica.

A documentação própria da arquitetura da OpenGradient descreve algo notavelmente mais deliberado do que essa imagem mental. Uma solicitação é roteada diretamente para um único nó de inferência, já selecionado. A própria blockchain, explicitamente, não está no caminho crítico dessa decisão inicial de roteamento. Um nó, escolhido por meio de um processo definido, é o que realiza a computação real da sua solicitação.

A descentralização nessa rede aparece depois, na forma como a saída desse nó é verificada e liquidada, e não em como sua solicitação encontrou um servidor para começar. Nós completos verificam provas e mantêm o livro-razão assim que um resultado retorna. A etapa de roteamento que leva sua pergunta a um trabalhador em primeiro lugar está mais para um balanceador de carga normal, fazendo uma única decisão limpa, do que para uma distribuição caótica e imprevisível por um enxame aberto.

Essa distinção importa mais do que parece. Uma única decisão de roteamento por solicitação, mesmo uma bem projetada, tem um perfil de confiabilidade e censura diferente do de redundância real com múltiplos caminhos, em que vários nós poderiam, de forma plausível, responder à mesma pergunta.

A OpenGradient descentraliza onde mais importa para a sua tese real: verificação e prova, a parte que permite que você confie em um resultado sem precisar confiar no nó específico que o produziu. A parte que a maioria dos recém-chegados imagina como descentralizada — o próprio roteamento — na verdade é uma camada que parece mais centralizada das duas quando você lê a documentação com atenção, em vez de seguir a imagem mental que a palavra “descentralizada” normalmente evoca.

@OpenGradient $OPG #opg $ARB

Rolei pelo arquivo inteiro do blog da OpenGradient em uma única sessão, em parte por curiosidade e em parte por teimosia, e a ordem em que as postagens apareceram acabou sendo a parte mais interessante de todo o exercício.
Logo ao lado de um texto técnico denso sobre pesquisa de taxas de AMM dinâmicas, há um anúncio para um AI Agent Meme Contest. Um pouco mais abaixo, um anúncio de Galxe Early Bird Campaign. Role um pouco mais e você volta ao território das pesquisas: modelos de previsão de volatilidade, previsões de retorno da SUI — coisas que parecem pertencer a um artigo acadêmico, não a um feed.
Eu voltei e contei só para ter uma noção da proporção, e, entre as últimas duas dezenas de posts no arquivo, mais ou menos 1 em cada 4 era algum tipo de iniciativa de comunidade ou marketing, em vez de uma atualização de pesquisa ou um anúncio de produto. Não foi uma avalanche avassaladora de memes, mas foi o suficiente para notar quando você começa a contar de propósito.
Entrei esperando o blog de um laboratório de pesquisa e encontrei algo mais parecido com o calendário de conteúdo de um projeto cripto “normal”: papers, quests e concursos empilhados no mesmo scroll, sem nenhuma separação entre eles.
Sinceramente, eu não acho que isso seja um mau aspecto, sem exagero. Um concurso de memes coloca o projeto na mira de pessoas que nunca clicariam em um paper sobre taxa de AMM, e os papers de pesquisa dão ao projeto substância de verdade quando essas pessoas aparecem. A maioria dos projetos de IA cripto mais bem-sucedidos agora roda exatamente essa mistura: a era de escolher estritamente entre laboratório sério e projeto divertido de comunidade acabou faz um tempo.
A OpenGradient também administra o conteúdo como qualquer outro projeto cripto tentando construir uma base agora, misturando resultados genuínos de pesquisa com concursos de memes e campanhas de quests no mesmo feed, sem tratar um como mais legítimo do que o outro.
@OpenGradient $OPG #opg $VELVET $PUNDIX

Passe uma tarde explorando os repositórios públicos do OpenGradient em vez da página inicial, e aparece um padrão que a comunicação de marketing nunca menciona: a empresa não escreve tudo em uma única linguagem. O nó central da rede é Go. O SDK para desenvolvedores — a coisa que a maioria dos criadores realmente importa nos próprios projetos — é Python. O serviço de intermediação de pagamentos e o frontend do explorador de blocos são ambos TypeScript.

Isso não é acidente de engenheiros com preferências diferentes, ou pelo menos não parece assim quando você percebe para quem cada parte realmente é. Go é uma escolha razoável para infraestrutura que precisa rodar rápido e continuar simples sob carga — exatamente o que um nó de consenso tem que fazer o dia inteiro. Python é a linguagem padrão do pessoal de machine learning, as pessoas que o OpenGradient mais precisa que realmente peguem o SDK e comecem a chamar modelos. TypeScript é a linguagem dos desenvolvedores de web e app que vão mexer no frontend do explorador ou conectar a lógica de pagamentos ao próprio produto.

No conjunto, a escolha não é “qual é a melhor linguagem única para tudo”, e sim “qual linguagem a pessoa que precisa usar esta parte já conhece”. Um SDK mais pesado em Python reduz a barreira para um pesquisador de ML que nunca mexeu com Go na vida. Um explorador em TypeScript é mais fácil de estender para um desenvolvedor de frontend do que um em Go.

O custo é interno, não externo. Manter uma pilha poliglota significa que o time precisa ter familiaridade com pelo menos 3 ecossistemas de linguagens diferentes, em vez de consolidar a experiência em torno de uma única, e integrar um novo engenheiro significa perguntar qual parte da pilha ele realmente vai tocar antes de decidir qual habilidade importa. O OpenGradient aparentemente decidiu que o custo vale a pena se isso significar que cada peça encontre seu público naquilo que ele já domina, em vez de pedir para todo mundo aprender um padrão da empresa primeiro.
@OpenGradient $OPG #opg $VELVET $LAB

Ao ler a documentação da pilha de agentes da OpenGradient, a parte que chamou minha atenção não foi a camada de verificação — é a parte que todo mundo espera. Foi uma frase curta sobre carteiras. Em vez de construir sua própria infraestrutura de transações e assinaturas, a OpenGradient se integra a provedores externos de carteiras, para que um agente verificado possa mover fundos em praticamente todas as redes quando ele decide agir.

Pense em um tribunal que autentica um documento, carimba, confirma que é verdadeiro e o coloca em registro permanente, mas não o imprime nem o entrega. A reputação do tribunal depende totalmente de o carimbo ser confiável. Quem redigiu o papel e quem o leva ao destino são partes separadas, que operam fora do que o tribunal pode atestar.

Esse é, mais ou menos, o formato da pilha de agentes da OpenGradient. A etapa de raciocínio é verificada, registrada e atestada. A decisão a que um agente chega é registrada em um explorador que qualquer pessoa pode consultar. Mas, no momento em que o dinheiro realmente se move, a assinatura e a execução acontecem por meio de uma infraestrutura de carteiras que a OpenGradient não construiu e não controla totalmente. O acordo tem ganhos e perdas dos dois lados. Terceirizar a “canalização” das carteiras significa que um agente alcança muito mais redes, muito mais rápido, do que uma camada de transação construída do zero poderia alcançar. Porém também significa que a etapa mais importante do pipeline — a parte em que os fundos saem de uma carteira — fica uma camada fora do limite de verificação pelo qual o projeto é conhecido.

A OpenGradient escolheu amplitude em vez de controle vertical total aqui, apostando que uma decisão verificada entregue a uma infraestrutura de carteiras competente é mais útil do que uma pilha totalmente auto contida que se move mais devagar e alcança menos redes. É uma aposta defensável para um ecossistema de agentes em estágio inicial que tenta se conectar a todos os lugares de uma vez, mas isso implica confiar que o raciocínio é apenas metade da equação de confiança; a outra metade ainda depende de infraestrutura posicionada bem ao lado do que a OpenGradient consegue atestar.
@OpenGradient $OPG #opg $SYN