Zyphron Toto

Estive nos documentos do Newton Protocol e no contrato do $NEWT no Etherscan (0xD0eC…85D) a maior parte da tarde, mexendo nas autorizações @NewtonProtocol authorization receipts. $NEWT e alguma coisa sobre o design de privacidade continuou martelando na minha cabeça depois.
A Newton se vende como a camada que torna as finanças onchain verificáveis por padrão — uma checagem de política antes de cada ação de vault, um recibo assinado que um curador pode entregar a um regulador. Mas, ao rastrear como esse recibo é realmente escrito, e o que vai para o onchain, vê-se que é apenas um compromisso por hash mais um bit de aprovação/reprovação. A pontuação de risco impulsionada por IA, os limiares proprietários do curador, qualquer PII — tudo isso fica dentro de um TEE ou de um circuito SP1 zkVM. Nunca toca o estado público.
O que… tecnicamente, tudo bem. Instituições não querem que a lógica de conformidade fique exposta. Mas isso, silenciosamente, estreita o que significa “verificável”. Você consegue confirmar que uma decisão passou por alguma regra. Você não consegue ver a regra, nem se ela foi aplicada da mesma forma em todos os vaults que a usam. Cruzando isso com o repositório newton-policy-packs, continuei caindo no mesmo buraco — prova de resultado, não prova de computação.
O Snack já foi, mas eu ainda estou mastigando essa. Se todo o rastro de auditoria só prova que uma checagem aconteceu… quem está de fato checando o verificador?
#Newt

Tenho comparado plataformas centralizadas de IA com o que o Newton Protocol ($NEWT ) realmente está entregando, e uma coisa continuou me incomodando.
Infra de IA centralizada — pense em camadas de moderação com acesso via API — funciona do mesmo jeito para todo mundo por padrão. Você não ativa as proteções; elas apenas... estão lá, invisíveis, e você confia na palavra da plataforma. O argumento inteiro do Newton com @NewtonProtocol é o oposto: aplicação verificável, uma atestação que você consegue realmente checar no Newton Explorer em vez de confiar na alegação de uma empresa.
Então fui ver o que está ao vivo desde o beta do mainnet (1º de julho) — a primeira integração real do VaultKit é com o Euler, na Base e no Ethereum, usando feeds de preço da RedStone e dados de risco do Vaults.fyi como entradas de políticas. Legal. Exceto... isso só roda se o curador conectar. Nada obriga um vault a ligar isso. A linguagem de “verificável por design” é real, mas está ao lado de uma chave de ativação opt-in que a maioria dos curadores ainda não virou.
Peguei um café no meio da pesquisa e continuei girando isso na cabeça — descentralizado não significa automaticamente default-on. Às vezes, só muda quem segura a chave.
Isso me faz pensar em quantos vaults no Euler, agora, realmente têm um policy pack anexado versus simplesmente... conectados ao SDK e ociosos.
#Newt

O Protocolo Newton me fez pensar nas indústrias do mundo real hoje — especificamente em empréstimos — e algo nos docs do VaultKit me fez pausar no meio do scroll. @NewtonProtocol construiu toda essa história de "execução de IA verificável" em torno das feeds de preço da RedStone agora dentro do motor de políticas (a integração ficou no ar junto com o mainnet beta, em 23 de junho, na Base e no Ethereum). Cada saque ou empréstimo contra um vault é verificado contra o preço ao vivo da RedStone antes de ser liquidado, e $NEWT emite uma atestação assinada, seja qual for o resultado.
Parece exatamente o que empréstimos, seguros, custódia de RWA — todas as indústrias que ficam dizendo que precisam de trilhos "verificáveis" — têm pedido. Abri o repositório newton-policy-packs no GitHub para ver como está implementado de verdade… e espere — a checagem da RedStone só dispara se o curador do vault escrever explicitamente isso no seu policy pack. Não é obrigatório. Um curador pode criar um vault Morpho no VaultKit e nunca tocar na política do oracle.
Continuei relendo essa parte porque não batia com como eu tinha vendido isso pra mim uma hora antes. Eu tinha assumido que "execução verificável" significava que cada ação do vault seria checada com algo real por padrão. Não é. Significa que a ferramenta existe, e quem estiver operando o vault decide quanto disso ativar.
Então quais indústrias adotam primeiro a versão mais rígida — as que estão sob pressão regulatória, ou as que têm depositantes que sabem pedir?
#Newt

Fiquei sentado(a) com o repo @NewtonProtocol por tipo uma hora e uma coisa não saía da minha cabeça.
Voltei a abrir novamente esta noite — a lista real do que está no ar: vaults.fyi para sinais de risco, RedStone para divergência de preço, Chainalysis para sanções, Blockaid para detecção de transações maliciosas. Mais ou menos oito packs, cada um ligado a um provedor de dados real, e cada um é opcional.
O problema é o que me interrompeu no meio do scroll. A proposta é "Agentes de IA precisam de execução/força de aplicação, não de aprovação" — chega de entregar suas chaves a um bot e torcer. Justo. Mas nada obriga o operador de um agente a realmente anexar qualquer um desses packs antes de ele tocar um cofre (vault). O Curator escolhe o que compor, ou não escolhe. O Newton AVS só verifica o que lhe mandam verificar.
Então a parte de "confiança descentralizada" é real — operadores re-stakeds, atestações de TEE, recibos que qualquer um pode puxar no Explorer $NEWT . Isso não é marketing. O que é meio que adjacente a marketing é a insinuação de que isso acontece por padrão para toda ação de cada agente. Não acontece. Acontece onde alguém optou por isso.
Me faz pensar menos sobre cripto e mais sobre quem está de fato verificando quais agentes pularam as proteções — alguém já está acompanhando isso, ou estamos todos só confiando naqueles que mostram seus recibos?
#Newt

Acabei de passar uma hora nos docs e no repositório do VaultKit @NewtonProtocol , e uma frase ficou me incomodando: uma curadoria "compõe sua política a partir desses blocos de construção do jeito que você montaria qualquer coisa a partir de peças." Isso está no post de lançamento do VaultKit de 1º de julho — no mesmo dia em que a Magic Newton Foundation disponibilizou as policy packs em código aberto.
A questão que me fez parar no meio do scroll. Os packs são genuinamente sólidos — Chainalysis para sanções, SumSub para identidade, Blockaid para detecção de transações maliciosas, RedStone para divergência de oráculos. Cobertura de verdade. Mas todos eles são opt-in. Nada no contrato do vault obriga um curador a conectar os compliance packs em vez de apenas os de rendimento/risco. Um vault pode ser lançado como "Newton-secured" e ainda estar rodando com zero checagem de identidade ou sanções ligada, porque ninguém é obrigado a compor a stack completa.
Hmm… fiquei entre pensar se isso é um bug ou apenas como sistemas modulares precisam funcionar. A composabilidade meio que exige opcionalidade por design. Mas a linguagem de marketing ("executável", "verificável", "camada de política onchain") soa como um piso, quando na prática é mais como um cardápio.
Fico me perguntando quantos depositantes estão verificando quais packs um vault de fato conectou, em vez de apenas confiar no nome da Newton que aparece no rótulo.
$NEWT #Newt

Finalmente fui cavar no repositório real de policy-pack (@NewtonProtocol ) em vez de só ler o post do blog.
Acontece que o que me fez parar no meio do scroll sobre $NEWT foi o seguinte: a “policy stack” de que todo mundo fala (Chainalysis Hexagate, RedStone, vaults.fyi, Credora, Webacy) não vem embutida no vault. É um menu. O curador abre um dashboard do Newton Protocol e escolhe quais verificações se aplicam, e o RedStone só foi conectado ao Newton Protocol como dependência de price-feed há poucos dias, conforme o próprio post de integração deles. Antes disso, qualquer regra de colateral que referisse “condições de mercado ao vivo” dentro do Newton Protocol não tinha nada verificável por trás. Não é um bug no Newton Protocol, só... vale a pena sentar com isso.
Fui e conferi também o repositório no GitHub (newt-foundation/newton-policy-packs) — é open source, claro, mas para o Newton Protocol, open source e enforced by default são duas frases bem diferentes. Um curador pode fazer fork do repositório do Newton Protocol, disponibilizar um vault e simplesmente não anexar o sanctions pack. Nada impede isso. A chain não vai saber a diferença entre “Newton Protocol enforced” e “Newton Protocol skipped” a menos que alguém realmente verifique os logs do operador.
Fico indo e voltando sobre se isso é uma questão de fase de rollout — em que o Newton Protocol aperta depois — ou apenas... o formato permanente disso. Curioso para saber quais vaults acabam rodando a stack completa do Newton Protocol versus o mínimo necessário para dizer “nós integramos isso.
#Newt

Estive a me aprofundar no rollout do mainnet beta @NewtonProtocol — o post do blog de 1 de julho confirmando a aplicação ao vivo no Base e no Ethereum, com integração Euler também ao vivo. $NEWT . Li duas vezes porque parecia haver algo estranho, de um bom jeito — isto já não é uma demo de testnet. Cofres reais, atestações reais, registradas no Newton Explorer para qualquer pessoa verificar.
Mas eis a questão que realmente ficou comigo. A atestação só prova que a política escrita foi seguida. Ela não diz nada sobre se a própria política era boa. Um curador pode escrever uma política Rego afiada, mínima — uma verificação mínima de jurisdição, nada mais — e o Newton ainda emitirá um recibo criptográfico limpo. Luz verde igual à de um curador que escreveu algo realmente impecável. A cadeia não consegue dizer se as regras eram rígidas. Só que, quaisquer que fossem as regras existentes, elas foram aplicadas.
Entrei num pequeno buraco de coelho tentando encontrar um registro de políticas que mostre níveis de rigor ou padrões mínimos entre cofres. Não encontrei. Talvez seja cedo — mainnet beta, dê tempo. Ou talvez isso nunca venha estruturalmente, porque manter a autoria da política totalmente nas mãos do curador é justamente o ponto.
Aplicação verificável de uma regra fraca e aplicação verificável de uma regra forte parecem idênticas no explorer. Isso converge à medida que mais provedores de dados institucionais se conectam, ou continua sendo uma falha permanente às cegas?
#Newt

NEWT acumulando $6,77M em volume nas últimas 24h hoje, +15,4% em um dia — eu estava rolando pelo Newton Explorer verificando as atestações recentes de políticas quando notei o pico e fiquei curioso sobre o que está realmente impulsionando isso… acontece que a maior parte desse volume é apenas rotação spot, e não novos fluxos de automação passando pela AVS.
Essa é a questão com @NewtonProtocol que ficou comigo depois de examinar os últimos dias de interações de contratos. O argumento de "execução verificável" parece que cada transação passa por checagem de política por padrão. A realidade — as atestações zkPermissions e TEE só disparam quando um builder conecta explicitamente o contrato dele para rotear pelas políticas Rego do Newton. Sem opt-in, nenhuma camada de verificação toca a tx. A oferta circulante está em torno de 288,46M $NEWT agora, e a maior parte das carteiras que rastreei só estava movimentando tokens antes do próximo desbloqueio, sem acionar nenhuma avaliação de política.
Então o enquadramento de "neutralidade crível" é real, mas apenas para o subconjunto de builders que de fato o integram. Todo mundo mais só está... usando a rede como de costume. Peguei meu snack pensando nisso — parece menos como uma rede de segurança padrão e mais como um recurso que você precisa buscar.
Isso me faz pensar em quanto desse volume atual chega a qualquer camada de verificação.
#Newt

Estive mexendo em @NewtonProtocol documentos hoje tentando conectar um aplicativo de agente ao fluxo de atestação deles, e uma linha no texto do dia 1º de julho me fez parar no meio da rolagem.
A mainnet beta foi ao ar em 23 de junho na Base e no Ethereum, e a proposta é "nenhum operador único decide o resultado" — uma supermaioria de operadores independentes verifica sua política, dá o aval e você recebe uma atestação compacta que pode ser verificada no Newton Explorer. Parece à prova de bala. Exceto que o próprio documento diz que o consenso multioperador entra em cena quando $NEWT sai da fase beta. Agora, durante exatamente a etapa em que a maioria dos desenvolvedores está fazendo integrações, você está confiando em um conjunto menor de operadores do que o enquadramento "trustless" sugere.
Relia esse parágrafo duas vezes achando que eu tinha interpretado errado. Eu não tinha.
As políticas são escritas em Rego (ok, é uma escolha amigável para compliance), e o sandbox WASM para conectores de dados personalizados é realmente inteligente — você não fica preso aos provedores prontos deles, como Chainalysis ou RedStone. Mas a suposição central de confiança, aquilo que faz toda a história de "verificável antes da liquidação" funcionar, está explicitamente escalonada para mais tarde.
Não estou dizendo que seja engenharia ruim. Só… se você está publicando um agente de IA nisso hoje, você está construindo no modelo de segurança que eles descrevem, ou no que está rodando de verdade?
#Newt

Passei a tarde mexendo com o lançamento do beta do @NewtonProtocol mainnet (25 de junho) e, honestamente, o que me fez pausar não foi a tecnologia — foi quem realmente consegue definir "verificado." $NEWT enviou Vaults com a RedStone e a Credora como parceiras de dados no lançamento. O argumento é claro: uma política verifica condições antes de uma tx se estabelecer e, então, gera um recibo assinado que qualquer um pode auditar.
Mas foi isso que ficou comigo. Esse recibo prova que a política executou corretamente — não que a política era a certa, nem que o feed de preços que ela leu estava preciso naquele exato momento. Um curador define o limite (por exemplo, liquidar se a classificação de risco da Credora cruzar X), e a Newton só aplica o que esse curador escreveu. Então, aqui, a verificação criptográfica confirma fidelidade de execução, não qualidade da decisão. São duas garantias bem diferentes, usando o mesmo rótulo de "verificável".
No Newt, continuei relendo o texto esperando encontrar alguma checagem sobre a escolha do curador ou revisão da política antes do lançamento… hmm, não encontrei nenhuma. Talvez seja algo de beta inicial, talvez não venha de jeito nenhum.
A confiança na ação de um agente de IA e a confiança nas regras que alguém passou para esse agente não são a mesma coisa. A Newton acerta perfeitamente a primeira. Quem está verificando a segunda?
#Newt

NEWT sentado em um volume de 24h de US$ 9,27M hoje, acima de 16,4% em um dia — small cap, mas o salto chamou minha atenção enquanto eu rolava pelos docs do Newton Protocol. @NewtonProtocol
Então eu fui parar no buraco de minhoca da arquitetura. A proposta da Newton é de quatro participantes operando em equilíbrio — desenvolvedores publicam modelos de agentes, operadores executam, usuários enviam intenções (intents) e validadores garantem tudo via dPoS. Um diagrama limpo. Parece um mercado funcionando.
Exceto… que a camada de validadores ainda não é realmente descentralizada. No momento, ela é operada pela fundação. A roadmap lista explicitamente "onboarding de validadores de terceiros" como um marco futuro, não como algo entregue. Então a parte do sistema que deveria garantir a integridade da automação — a que carrega o maior peso de confiança — ainda está centralizada, enquanto tudo o que vem depois (agentes, intents, fluxo de taxas) já está ativo e sendo comercializado como verificável hoje.
É uma forma meio familiar, ngh — entrega primeiro as peças que geram volume, descentraliza a camada de segurança depois. Não quer dizer que seja ruim; só torna o enquadramento de "verificável por padrão" um pouco adiantado em relação ao que o conjunto de validadores realmente é.
Fica me fazendo pensar o que "validadores de terceiros" significa aqui quando isso acontecer — novos entrantes, ou apenas os mesmos insiders vestindo um chapéu diferente?
#Newt $NEWT