shareyouropinion

Encontrei um relatório de transparência anterior na noite passada que eu não tinha lido antes, e isso mudou a forma como eu entendo o que a Newton realmente é. A Newton não foi originalmente concebida como um mecanismo de conformidade de forma alguma.

A divulgação de outubro de 2025 descreve o projeto original como um rollup de keystore construído para gerenciamento de chaves, com foco especificamente em automação verificável e autorização delegada para agentes de IA.

A ideia central era permitir que agentes executassem ações on-chain por meio de permissões criptograficamente verificadas, atreladas à infraestrutura de gerenciamento de chaves.

A virada aconteceu quando a equipe percebeu que as mesmas primitivas subjacentes — automação verificável e autorização delegada — poderiam se estender muito além do gerenciamento de chaves de agentes, chegando a um framework geral para aplicação de políticas em stablecoins, RWA e no mercado de ativos mais amplo.

O rollup de keystore se tornou a base para algo muito mais amplo: um mecanismo de políticas que governa quais ações podem ocorrer, em quais condições e com quais atestações.
Isso é um ponto de partida significativamente diferente do que o whitepaper que eu li originalmente sugeria.

Eu realmente acho que essa história importa para entender as escolhas de arquitetura da Newton — o modelo de atestação BLS, o desenho do quorum de operadores, a ênfase no comércio de agentes como caso de uso; estas não são decisões de projeto voltadas primeiro para conformidade. São decisões de projeto de gerenciamento de chaves e de autorização de agentes que depois foram generalizadas para casos de uso de conformidade.

O que eu ainda não determinei é quanto da arquitetura atual ainda carrega premissas do projeto original de rollup de keystore que talvez não sejam ideais para um mecanismo de políticas com foco em conformidade — se a virada foi uma reformulação limpa ou uma extensão da base técnica original.
#ShareYourOpinion
$EVAA $LAB
Como você acha que a arquitetura da Newton evoluiu?
@NewtonProtocol $NEWT #Newt

Realidade operacional tradicional de KYC/AML vs lacuna de responsabilidade no modelo de credenciais da Newton

Conversei sobre o modelo de identidade da Newton com um amigo que trabalha como officer de compliance na semana passada — alguém que administra programas de KYC em uma instituição regulada — e a lacuna entre o que a Newton descreve e o que as equipes de compliance fazem operacionalmente foi maior do que eu esperava.

KYC/AML tradicional: ao onboar-ding, o cliente coleta documentos, confere na base de dados de sanções, atribui pontuação, armazena o registro. A transação é sinalizada post hoc; depois, puxa o arquivo, revisa o histórico e escreve o relatório; arquiva o SAR.

Trilha manual pesada de documentos em papel que os auditores aceitam. O banco é responsável. Ele fez a verificação. Ele é dono do resultado.

No modelo da Newton, a credencial emitida por um terceiro — provedor de KYC — fica em poder do usuário, é avaliada por operadores em um enclave TEE de acordo com a política em segundos. O recibo de compliance é a trilha de auditoria.

Velocidade e automação são reais. Primeira pergunta que meu amigo do compliance fez: quem é responsável quando a Newton diz que a credencial é válida, mas os dados do emissor estão errados? No modelo da Newton, o emissor emitiu; operadores avaliaram; o contrato inteligente aplicou. A cadeia de responsabilidade é mais longa e menos clara.

Eu realmente acho que a distribuição de responsabilidade é a questão de design mais importante, de forma prática, para adoção institucional — não a capacidade técnica, mas quem assume a responsabilidade quando uma transação atestada pela Newton acaba sendo não conforme.

O que eu ainda não esclareci é se os recibos de Compliance da Newton atendem às exigências regulatórias de responsabilidade ou se apenas documentam que uma verificação foi feita. E se essas coisas são a mesma coisa.
$LAB $HMSTR #shareyouropinion
@NewtonProtocol $NEWT #Newt

programas de pontos e recompensas em DeFi criam oportunidades de conformidade. casos-limite: a identidade de Newton e os domínios de conformidade não foram claramente projetados para endereçar.

um programa de pontos distribui créditos ou tokens para carteiras com base na atividade do protocolo.
em ambos os casos,
a questão de conformidade é se a carteira destinatária é elegível para receber o valor que está sendo distribuído.
a conformidade com sanções se aplica às distribuições de recompensas da mesma forma que se aplica a qualquer outra transferência de valor.

se o domínio de conformidade da Newton pode impor uma verificação de sanções em transações de distribuição de recompensas
especificamente na transferência de saída de recompensas de um protocolo para uma carteira não é claramente descrito na documentação.

a direcionalidade importa.
a maioria dos casos de uso da Newton envolve verificar uma carteira antes que ela envie uma transação para um protocolo.
um airdrop de recompensas funciona na direção oposta.
se o modelo de aplicação se aplica a transferências de saída iniciadas pelo protocolo é uma questão estrutural sobre como a verificação de política é acionada.

não há resposta disso na documentação atual. o caso-limite é suficientemente real para importar para qualquer protocolo DeFi que execute programas de recompensas ativas.
@NewtonProtocol $NEWT $LAB $HMSTR #ShareYourOpinion
#Newt #NEWT
As recompensas precisam de verificações?

Leia o documento de governança novamente ontem à noite, porque eu posso compreender o que se entende por governança assumida: significa algo que já está em funcionamento. Isso significa algo que foi projetado.

O ciclo de vida da proposta que Newton descreve tem cinco etapas. Ideia: discussão informal, sem processo formal. RFC: Request for Comments, um documento estruturado que propõe uma mudança. NIP: Newton Improvement Proposal, a versão formalizada de um RFC, pronta para consideração.

Discussão da Comunidade: um período aberto para feedback antes de uma votação. Votação do Token House: realizada off-chain via Snapshot, na qual detentores de NEWT votam no NIP.

Esse é o pipeline completo, como foi desenhado.

O que eu não fiz na primeira leitura é perceber que esse pipeline existe no documento, mas o Token House em si — o órgão que de fato vota — ainda não existe como uma estrutura em funcionamento. No momento, no que o documento chama de Fase 0, o Foundation Board toma decisões. O ciclo de vida da proposta é o estado-alvo, e não o atual.

Esse detalhe muda a forma como eu leio cada afirmação de governança nos materiais de Newton.

Eu realmente gosto de como o documento deixa essa distinção explícita: a linguagem da Fase 0, não vaga — marketing “governado pela comunidade”. É raro ver um nome de projeto no próprio estágio centralizado atual dele, de forma tão direta.

O que eu ainda não entendi é o que exatamente dispara uma transição da Fase 0 para a Fase 1: se é um cronograma fixo, uma métrica de descentralização ou totalmente a critério do Foundation Board.
$TAC $LAB #ShareYourOpinion
@NewtonProtocol $NEWT #Newt

comece pequeno. agentes de IA que geram negociações em DeFi nunca depois fazem trading algorítmico nas finanças tradicionais, e a infraestrutura de conformidade ao redor deles é significativamente menos desenvolvida.

faça zoom out a camada de política de newton aborda a questão de conformidade no nível da transação: esta transação específica atende às regras definidas? essa é uma camada do que a conformidade para trading algorítmico tradicional exige.
#NEWT
as camadas acima são diferentes. a conformidade para trading algorítmico tradicional requer documentação de modelos, trilhas de auditoria que conectem negociações executadas a decisões específicas do modelo, e capacidade de killswitch para intervenção humana quando o modelo se comporta de forma inesperada.
#newt

nenhuma dessas coisas é endereçada por enforcement prévia de liquidação em transações individuais.

faça zoom out ainda mais: se o trading por agentes de IA em DeFi escalar, reguladores aplicarão requisitos semelhantes aos que regem o trading algorítmico nos mercados tradicionais. a infraestrutura de newton é um componente necessário dessa pilha de conformidade. tratá-la como suficiente por si só seria uma lacuna significativa para qualquer entidade regulada que use agentes de IA em DeFi.

#ShareYourOpinion $LAB $HMSTR

@NewtonProtocol $NEWT #Newt

$BTC Long Entry Setup Price Limit Order 💫

#shareyouropinion #WarshSaysInflationIsFedTopFocus

A whitepaper dos Cofres de Bitcoin Sem Confiança (TBV) faz algo que vale destacar na Seção 5: ela lista a Participação Aberta como um benefício declarado e especifica liquidadores cadastrados como o mecanismo real na mesma seção.@BabylonLabs_io

O item de benefício é explícito sobre quem a participação aberta abrange: liquidadores, tomadores e desenvolvedores — todos supostamente precisam se integrar ao protocolo com um onboarding mínimo. O fluxo de liquidação, alguns parágrafos antes, também é igualmente explícito: as liquidações são executadas por liquidadores cadastrados, um conjunto definido e permissionado, e não por qualquer pessoa que queira fechar uma posição subcolateralizada.$BABY

Não estou dizendo que a exigência de cadastrar liquidadores seja irrazoável. Liquidação significa manter e mover capital real rapidamente, e avaliar participantes para esse papel é uma prática padrão em protocolos de empréstimo, onchain ou off.

Também não estou dizendo que as duas afirmações se encaixam confortavelmente juntas. O benefício nomeia liquidadores como participantes abertos — o mecanismo os restringe. As duas coisas não podem ser totalmente verdadeiras ao mesmo tempo: a participação aberta carrega mais peso nesse item do que a whitelist sustenta. #baby

Pode haver uma resolução se a própria whitelist for fácil de entrar — o conjunto de coassinaturas k-de-n, por exemplo, permitiria que qualquer pessoa entrasse. Nesse caso, onboarding mínimo e whitelisted poderiam ser a mesma coisa vista por ângulos diferentes. Mas a whitepaper nunca diz como um liquidador de fato passa a ser cadastrado.

Então alguém pode se tornar um liquidador ou a participação aberta termina na whitelist? A Seção 5 nomeia o benefício e a barreira na mesma página e nunca conecta os dois.

$UAI $BANK
#ShareYourOpinion
#ShareYourVote

Voltei e realmente percorri o fluxo do testnet neste fim de semana, em vez de apenas ler sobre isso por terceiros. Eu poderia achar que assistir ao vídeo de guia presumidamente seria suficiente para entender a mecânica. Não foi.

O testnet público de empréstimos lastreados em Bitcoin nativo via Aave v4, alimentado pelo Trustless Bitcoin Vaults (TBV), permite que você deposite test BTC em um cofre, acompanhe sua verificação on-chain e faça empréstimos contra ele do mesmo jeito que o whitepaper descreve: a cunhagem de collBTC e o lending. Resgatar tokens de teste no faucet primeiro e depois acompanhar o depósito pelo explorador transformou a descrição abstrata de “o cofre é verificado, o collBTC é cunhado” nos documentos em uma sequência de passos real, em vez de um diagrama.

O que ficou claro para mim só depois de fazer isso foi que a etapa de verificação do light client não é instantânea da forma como uma transferência normal de token parece. Há uma espera real entre o depósito e o collBTC aparecer como utilizável.

Eu realmente acho que fazer isso por conta própria muda como você lê as seções posteriores dos whitepapers. Os fluxos de liquidação e settlement deixam de ser diagramas abstratos depois que você já assistiu um único depósito seguir as mesmas etapas.

O que eu ainda não tinha entendido é se o timing dos testnets corresponde ao que o mainnet realmente vai parecer, ou se a infraestrutura do testnet roda mais rápido ou mais lento do que uma implantação ao vivo.

Existe um formulário de feedback vinculado ao lado do app do testnet: vale a pena usar se você passar pelo fluxo e notar algo que não corresponda aos documentos.
$EUL $ON #shareyouropinion
@BabylonLabs_io $BABY #baby

Dinâmica do poder de governança: quem controla os limites de quórum, a divisão de taxas e a admissão de operadores

A parte que ninguém pergunta sobre a governança de Newton é quem realmente controla os parâmetros que mais importam.

Três trilhas de governança: padrões de política, admissão de operadores, atualizações de protocolo. O que falta na discussão é o que essas trilhas realmente governam.

Limites de quórum: configuráveis por tarefa, definidos pela governança, determinam a segurança econômica de toda atestação na rede.

Divisão de taxas: configurável, definida pela governança, determina a economia dos operadores.

Admissão de operadores: governada pela estrutura de governança do protocolo, determina quem recebe taxas.
Agora observe quem detém NEWT.

Operadores colocam NEWT em stake. Operadores ganham taxas. Operadores são obrigados a manter NEWT para participar. Se os operadores tiverem participações desproporcionais de NEWT em relação a outros detentores de tokens, eles terão influência desproporcional nas votações de governança que definem o próprio quórum e a própria divisão de taxas.

Não estou dizendo que isso é incomum. A maior parte da governança em proof of stake tem alguma versão desse problema: validadores em outras redes votam em parâmetros que afetam a economia do validador.
#newt
Não estou dizendo que isso é um defeito também. Operadores com participação no jogo via holdings de NEWT podem alinhar seus interesses com a saúde de longo prazo das redes, em vez de extração de curto prazo.
#NEWT
O que eu ainda não calculei é se Newton projetou algum mecanismo específico para impedir que os operadores votem coletivamente para reduzir os limites de quórum — reduzindo sua própria carga operacional — de formas que silenciosamente degradem a segurança da rede.
#shareyouropinion $HMSTR $LAB
@NewtonProtocol $NEWT #Newt

Há um conjunto de dados no whitepaper que a maioria das pessoas ignora: uma pesquisa com 166 redes blockchain. Dezesseis já têm congelamento de ativos embutido.

Dezenove mais poderiam habilitá-lo com mudanças mínimas.

Trinta e cinco redes em que o acesso sem permissão é condicional.

Newton usa isso para enquadrar um problema central: controles no nível de interface são insuficientes, mas também é insuficiente a suposição de que os “trilhos” (rails) da blockchain são neutros.

Uma rede com capacidade de congelamento pode impor conformidade de maneiras opacas e controladas por quem detém a autoridade de congelar, sem responsabilidade criptográfica.

A resposta de Newton aplica enforcement na camada de política, não na camada de protocolo. A lógica de autorização é auditável em Rego. O conjunto de operadores é descentralizado. Recibos de conformidade onchain. Isso não impede que uma rede congele ativos, mas torna decisões de conformidade separáveis do protocolo e auditáveis, mesmo quando a cadeia não é neutra.

Não é uma solução completa. Uma camada diferente de responsabilização sobre o problema.
#NEWT
Na verdade, eu acho que os dados sobre congelamento reformulam o que Newton está resolvendo — menos adicionar conformidade a “rails” sem permissão e mais tornar a conformidade transparente quando os próprios rails talvez não sejam.
#newt
A questão é se a camada de política de Newton fornece responsabilização significativa quando a cadeia subjacente mantém autoridade unilateral de congelamento, ou se um recibo de conformidade se torna irrelevante quando os ativos ainda podem ser congelados.
#ShareYourOpinion
@NewtonProtocol $NEWT #Newt
$LAB $HMSTR

A seção de roteamento de taxas de Babylons tem uma única linha que vale a pena ler duas vezes
Acordo automatizado em cadeia (on-chain) em que taxas denominadas em BTC são leiloadas para BABY, e os licitantes vencedores que gastam BABY recebem o BABY de forma programática queimado.

Sem discricionariedade do tesouro. Sem comitê decidindo quanto queimar ou quando. Apenas um leilão mecânico ligado diretamente ao uso do Protocolo.

Essa é uma escolha de design específica, não uma alegação genérica de Tokenomics deflacionária. À medida que a atividade de Trustless Bitcoin Vaults (TBV) cresce, mais cofres são criados, mais empréstimos lastreados em BTC, mais resgates — as taxas geradas em BTC são roteadas através desse Leilão e o BABY é removido da oferta como uma função direta do uso real, e não de um cronograma fixo de emissão.

Não estou dizendo que isso garante algo sobre o valor do token. As queimadas vinculadas ao uso ainda dependem de o uso de fato acontecer em escala relevante, e o whitepaper deixa explícito que as estruturas de taxas e as regras de staking permanecem sob design ativo e sujeitas à aprovação de governança.

Não estou dizendo que seja um detalhe menor também. Vincular a mecânica de queima do token a um uso do protocolo demonstrado, e não a uma promessa de marketing ou a um cronograma fixo, é um sinal mais honesto para acompanhar do que a maioria das alegações de tokenomics neste segmento.

O que eu ainda não trabalhei é se esse mecanismo de leilão já foi ativado em alguma implantação ao vivo ou se ele permanece entre as propostas ainda em discussão sob design, junto com o restante do arcabouço de roteamento de taxas.

@BabylonLabs_io $BABY #baby
#ShareYourOpinion
$BANK
$DEXE