Aadi33

Confissão de Mercado #37

Na verdade, eu não sei por que eu vendo do jeito que eu vendo. Eu só faço, e depois invento um motivo.

Comecei a observar minhas próprias operações como se fossem as de um estranho. A mesma configuração, o mesmo medo, o mesmo ponto de saída, todas as vezes. Não é análise. Memória muscular vestida de decisão.

Então eu comecei a fazer uma pergunta antes de cada trade: estou fazendo isso por causa do gráfico, ou por causa da última que me machucou.

Na maior parte das vezes é a segunda.

Acontece que o mercado não está testando suas previsões. Ele está testando se você já se encontrou.

$BTC $BNB $ZEC #crypto #BinanceSquare

Os ETFs de Bitcoin acabaram de interromper uma sequência de saídas por 8 semanas, com US$ 197 milhões em entradas líquidas frescas.

As instituições estão, silenciosamente, dando um passo para trás.

Uma semana em alta não confirma uma nova tendência, mas é o primeiro sinal relevante de que a pressão de venda pode estar diminuindo. Se as entradas nos ETFs continuarem nas próximas semanas, o sentimento do mercado pode mudar muito mais rápido do que a maioria espera.

O dinheiro inteligente não toca na campainha no fundo.

Ele se acumula enquanto a multidão ainda está debatendo.

#bitcoin #BTC #etf #crypto #BinanceSquare
$BTC

As pessoas muitas vezes presumem que ativos do mundo real tokenizados carregam o mesmo modelo de risco que os ativos que eles representam; um título do tesouro tokenizado se comporta como um título do tesouro, apenas mais rápido para movimentar.

Tenho analisado como @NewtonProtocol mede o risco real em RWAs e não é realmente sobre o ativo subjacente. A documentação da Newton aponta para comprometimento de chave de administrador, manipulação de NAV ou de oráculo e cunhagem não autorizada como o verdadeiro modelo de ameaça — riscos que existem devido ao modo como o token é emitido e gerenciado on-chain, e não por algo inerente ao próprio título do tesouro.

O que a Newton aplica são invariantes de tempo de execução especificamente para isso: restrições que valem independentemente de quem detenha a chave de administrador. Guardrails de cunhagem e resgate garantem que apenas investidores elegíveis participem. Checagens de integridade do NAV fazem referências cruzadas entre preços do oráculo e faixas de tolerância. Estas não são permissões que possam ser dispensadas por quem tiver acesso elevado; elas são verificadas no nível da transação toda vez.

Aqui está o que realmente me deixa com isso em mente. Na maioria dos ativos tokenizados, se alguém obtém a chave de administrador, basicamente é o jogo inteiro: ele pode cunhar sem autorização, drenar um tesouro, contornar quaisquer controles que supostamente estavam em vigor. A chave era o controle. Invariantes de tempo de execução quebram essa ligação de propósito, então ter a chave não significa automaticamente obter a restrição junto.

Eu teria curiosidade para saber se essas invariantes foram de fato testadas contra um cenário real de comprometimento de chave de administrador, ou se essa garantia ainda é em grande parte teórica nesta fase.

$NEWT #Newt
#BinanceTurns9



Invariantes de tempo de execução realmente impediriam uma chave de administrador comprometida?

As pessoas assumem que, se um gateway recusar processar sua solicitação, você fica preso.

Pelo que li, a Newton tem um mecanismo de inclusão de força que permite que aplicativos enviem tarefas diretamente para a rede do operador, em vez de depender do gateway. Se isso estiver correto, significa que o gateway não é um gargalo permanente, o que é uma propriedade importante para resistência à censura.

O que eu entendo menos é o lado prático.

Usar esse caminho, presumivelmente, significa lidar com o trabalho que o gateway normalmente abstrai, como roteamento e coordenação com a rede do operador. Isso levanta a questão de saber se a inclusão de força é algo que o aplicativo comum conseguiria usar realisticamente durante uma interrupção ou um evento de censura, ou se ela é principalmente prática para equipes com infraestrutura substancial.

Alguém aqui já testou a inclusão de força de ponta a ponta de verdade? Eu gostaria de saber como funciona na prática, em comparação com como é descrito no papel.

@NewtonProtocol $NEWT #Newt
$ZEC $BTC

A maioria das pessoas costuma assumir que a equipe de compliance para a infraestrutura de instituições é de alguma “loja” especializada em RegTech, trabalhando profundamente com regulamentações, mas ainda nova para a escala do cripto voltado ao consumidor. Em geral, essa é uma suposição segura para esse tipo de produto.

Não é o caso de @NewtonProtocol . O desenvolvedor principal é a Magic Labs, e eu não tinha conectado isso até olhar para quem está realmente por trás. Eles criaram carteiras embutidas — um tipo de infraestrutura que permite que um app faça onboarding de usuários sem nunca mostrar a eles uma frase-semente. Com suporte da PayPal Ventures, já em execução em escala real: mais de 57 milhões de carteiras, mais de 200.000 desenvolvedores e é a camada de carteira que está por trás da Polymarket.

Isso muda como eu leio o risco de execução de Newton. Uma grande parte da infraestrutura cripto voltada à conformidade é criada por times fortes do lado regulatório, mas relativamente novos em fazer entrega em escala relevante. A Magic Labs é o oposto: eles já resolveram distribuição e confiabilidade especificamente para infraestrutura de carteiras. O Newton não é a primeira tentativa de um time novo em lidar com volume real de transações; é um time estabelecido expandindo para um problema adjacente.

O que eu destacaria, porém, é que carteiras embutidas e autorização baseada em políticas são, de fato, problemas de engenharia bem diferentes. A infraestrutura de carteiras é, na maior parte, gerenciamento de chaves e disponibilidade. A camada de autorização da Newton envolve consenso descentralizado do operador, atestações criptográficas e resolução de disputas via provas de conhecimento zero. A experiência comprovada em um não se transfere automaticamente para o outro.

Não é uma fraqueza,.. apenas vale ser preciso. Eu ficaria curioso para saber quanto do design de operadores e consenso do Newton está sendo liderado por pessoas com histórico nessa área específica, versus o lado de carteiras do time expandindo para isso.

@NewtonProtocol $NEWT #Newt
#Polymarket #MagicLabs #zkProofs
$SXT $LAB

As pessoas muitas vezes assumem que uma transferência de stablecoin, ou é bloqueada ou não é, passa ou falha, com uma verificação simples.

A parte de conformidade com a Travel Rule da Newton tem esse elemento de atribuição, mas não é algo que funcione como uma lógica de “passa ou falha” como a triagem de sanções. A Travel Rule é sobre as informações do originador e do beneficiário seguirem a transferência acima de certos limites: quem enviou, para quem está sendo enviado, com essas informações associadas de forma segura à transferência.

É um tipo de verificação diferente de bloquear um agente mal-intencionado. A triagem de sanções é binária: o remetente está em uma lista ou não está. A Travel Rule é mais sobre garantir que as informações exigidas acompanhem a transferência entre entidades reguladas, e não apenas que sejam checadas uma vez e depois esquecidas.

O que é realmente interessante é que isso só é acionado para transferências qualificadas, acima de qualquer limite que faça disparar essa regra. Então, a maioria das transferências de stablecoin de varejo nem sequer toca nesse ponto; isso é construído para as transferências grandes o suficiente para que os reguladores realmente se importem com o rastro documental.

Ainda não está claro para mim como isso se sustenta entre cadeias (cross chain). Se a origem de uma transferência está em uma cadeia e ela está indo para uma cadeia de destino por meio do conjunto sincronizado de operadores da Newton, a informação do originador é transmitida de forma limpa ou algo se perde ao coordenar as informações de identidade através desse limite (boundary). A atribuição só significa alguma coisa se sobreviver a toda a viagem, não apenas ao primeiro salto.

Curioso para saber se alguém realmente testou uma transferência com Travel Rule que cruza múltiplas cadeias de uma vez, ou se isso tem sido mais testado dentro de uma única cadeia até agora.

@NewtonProtocol $NEWT #Newt
$PYR $HMSTR

#RetailStockBuyingLowestSince2020 #JapanUrgesGPIFToBoostDomesticAssets #SKHynixCompletesRecordUSListing

As pessoas muitas vezes presumem que um cofre “curated” significa que alguém está realmente monitorando o risco em tempo real, uma equipe acompanhando dashboards, pronta para reagir assim que algo pareça fora do lugar.

Mas, na maior parte das vezes, não é assim que funciona. “Curated” normalmente só significa que alguém escreveu as regras uma vez. A execução real acontece transação por transação, no momento em que algo tenta se mover, e não por meio de monitoramento contínuo em segundo plano.

Eu tenho observado como @NewtonProtocol lida isso para casos de uso de RWA e de cofre especificamente. A Newton oferece policy packs, conjuntos pré-composicionados de módulos Rego, que incluem checagens de integridade de NAV cruzando preços de oráculos com limites de tolerância configurados, além de guardrails de elegibilidade para mint e redeem. Esses módulos rodam no momento da própria transação. Ninguém precisa ficar assistindo a uma tela. A checagem simplesmente fica lá e dispara quando é tRiggered.

Isso é uma melhoria real em relação a depender de um humano que detecta um problema depois do fato, o que geralmente é tarde demais. Mas isso também significa que a proteção do cofre é tão boa quanto quaisquer limites de tolerância e regras que foram configurados quando a policy foi originalmente escrita. Se o mercado se mover de uma maneira que ninguém antecipou quando esses limites foram definidos, a checagem ainda roda. Só pode não estar verificando contra o limiar correto mais.

Não estou dizendo que isso seja uma falha no design. É apenas o tipo de suposição que vale estar ciente 0f. A proteção não é vigilância contínua; é uma regra escrita com antecedência, aplicada de forma consistente, mas apenas tão atual quanto a última vez em que alguém a atualizou.

Eu gostaria de saber com que frequência essas faixas de tolerância realmente são revisadas depois que um cofre está no ar, ou se elas normalmente são definidas uma vez e deixadas como estão.
@NewtonProtocol $NEWT #Newt
$LAB $TAG #LABTokenDrops94% #USNaturalGasFallsOver6%

As pessoas presumem que, uma vez que um sistema escolhe sua criptografia, ela fica basicamente “travada”. Tirar depois e refazer é como reconstruir metade da coisa.

A camada de privacidade da Newton, porém, não foi feita desse jeito. Ela usa HPKE, que na prática são três partes intercambiáveis acopladas juntas: troca de chaves, derivação de chaves e a criptografia em si. Como elas são modulares em vez de “fundidas”, trocar a troca de chaves por uma versão pós-quântica aparentemente é só uma mudança de configuração, não uma reconstrução.

Parece conveniente até você perceber que o HPKE foi literalmente projetado para isso. A Newton não inventou essa flexibilidade; só construiu em cima de algo que já tinha. E o NIST já padronizou as substituições pós-quânticas em 2024, então as peças já existem, prontas para serem trocadas quando for necessário.

Minha primeira reação foi: quebrar a criptografia com computadores quânticos parece um problema para “um dia”, não algo urgente. Mas isso é uma armadilha: dados criptografados hoje podem simplesmente ficar guardados e ser descriptografados depois, assim que a capacidade existir. Então, uma migração barata mais tarde importa agora, mesmo ainda não parecendo urgente.

O que eu continuo mastigando, porém, é que isso só cobre o lado da criptografia. Os operadores assinam atestações com assinaturas agregadas BLS, e isso é um sistema criptográfico totalmente separado das chaves de criptografia. Nada do que vi fala sobre o que migrar o BLS em si exigiria. Ao contrário da troca de chaves modular do HPKE, assinaturas não foram desenhadas como uma substituição simples. Então eu esperaria que essa migração fosse substancialmente mais envolvida.

Então “nossa criptografia está pronta para o pós-quântico” e “nossa pilha inteira está pronta para o pós-quântico” não são a mesma afirmação. É só que soam como se fossem.

Fico curioso se alguém realmente já olhou para como seria um caminho pós-quântico para o lado das assinaturas aqui, ou se isso ainda é uma questão de design em aberto.

@NewtonProtocol $NEWT #Newt
$LAB $SKYAI
#quantum

As pessoas muitas vezes assumem que, uma vez que você esteja verificado, o serviço que trata da verificação realmente viu seus documentos, avaliou-os e simplesmente se lembra do resultado.

A verificação de identidade da Newton foi projetada de forma diferente. A verificação é executada dentro de um TEE, um Trusted Execution Environment (Ambiente de Execução Confiável), de modo que a infraestrutura normal do verificador nunca acesse diretamente os dados de identidade subjacentes. Ele recebe o resultado da verificação, em vez das entradas brutas em si.

Esse é um modelo de segurança diferente daquele de apenas criptografia. A criptografia protege os dados enquanto eles estão armazenados ou em trânsito, mas geralmente alguém precisa descriptografar para realizar a verificação. Um TEE busca manter essa computação isolada mesmo, com o sistema hospedeiro incapaz de inspecionar o que acontece dentro do enclave.

Isso também se encaixa no modelo de identidade mais amplo da Newton. Os verificadores validam provas de credenciais sem aprender as informações pessoais subjacentes. O objetivo não é apenas manter os dados fora da cadeia (off chain), mas também mantê-los ocultos do verificador.

A questão restante é a de confiança. TEEs reduzem o quanto você precisa confiar no Verificador, mas não eliminam a confiança totalmente. Em vez disso, parte dessa confiança muda para a implementação do TEE, o fornecedor do hardware, o firmware e o processo de atestação. TEEs já tiveram vulnerabilidades reais de hardware e de canal lateral no passado, então eles são um mecanismo de redução de risco (risk reduction), e não uma garantia.

O que mais me intriga é o modelo de falha. Se uma vulnerabilidade séria de TEE fosse descoberta no hardware em que a Newton se baseia, o que aconteceria com as credenciais que foram verificadas anteriormente por esses enclaves? O impacto seria limitado a futuras atestações depois que a vulnerabilidade fosse conhecida, ou sessões de verificação anteriores também poderiam ser consideradas comprometidas? E, se isso acontecesse, existe um processo de recuperação documentado, como revogar enclaves confiáveis, rotacionar chaves de atestação ou exigir que as credenciais sejam revalidadas?
$NEWT @NewtonProtocol #Newt
$LAB $TLM #labcrashed

As pessoas assumem que, quando um protocolo diz “preservação de privacidade”, basicamente esse já é o estado final, como se a parte difícil estivesse pronta e daí fosse só implementação.

Mas esse não é o caso do plano de longo prazo da Newton. Há uma seção inteira no whitepaper sobre criptografia totalmente homomórfica, que é basicamente a versão ideal disso: executar a computação da política diretamente em dados criptografados, sem jamais descriptografá-los em nenhum momento. Sem etapa de descriptografia por limiar. Nenhum texto em claro é exposto durante a avaliação.

Só que, por enquanto, isso está apenas listado como uma direção de pesquisa. Não foi construído. A descoberta original de Craig Gentry sobre FHE foi em 2009, e mesmo hoje ela ainda é de ordens de magnitude mais lenta do que computar em dados em texto puro. Para o caso de uso da Newton, que envolve principalmente verificações booleanas e comparações por limiar, o whitepaper diz que isso fica na extremidade inferior dessa faixa, mas ainda assim é muito distante de algo prático para produção.

Então existe todo um roadmap entre onde o modelo de privacidade realmente está hoje e para onde o whitepaper diz que ele eventualmente vai. A versão atual depende de descriptografia por limiar, ou seja, os dados são descriptografados durante a avaliação da política em vez de permanecerem criptografados ponta a ponta. A camada de MPC depois disso busca evitar a reconstrução do texto em claro durante a avaliação. A FHE, depois disso, permitiria que a própria política fosse avaliada diretamente em dados criptografados, eliminando a necessidade de MPC interativa.

De certo modo, respeito o fato de eles serem transparentes quanto a ser uma pesquisa de vários anos, em vez de fingirem que está perto. Mas isso também significa que, quando as pessoas leem “preservação de privacidade”, vale perguntar qual modelo de privacidade elas estão recebendo hoje versus para qual o roadmap está mirando.

Me pergunto quantas pessoas que usam isso realmente sabem que existe diferença entre essas duas coisas, ou se simplesmente tudo vira lido como uma garantia única e genérica de privacidade.

@NewtonProtocol $NEWT #Newt
$LAB $TLM

As pessoas muitas vezes presumem que, uma vez que um contrato inteligente é implantado, suas regras são suficientes para manter usuários e ativos seguros. Para protocolos que gerenciam capital relevante, muitos dos salvaguardas importantes ainda existem fora da blockchain.

Tenho observado como @NewtonProtocol aborda isso. Em vez de depender de listas de verificação offchain ou de supervisão manual, ele permite que políticas sejam aplicadas onchain antes que uma transação chegue à liquidação. Essas políticas podem cobrir conformidade, identidade, segurança e risco, tornando-as parte do fluxo de execução, e não uma reflexão posterior.

Isso muda o equilíbrio de trade-offs. Em vez de confiar que cada aplicação implemente e mantenha seus próprios controles, os protocolos podem referenciar uma camada comum de autorização que avalia as transações em relação a políticas aCtive antes de prosseguirem. Em teoria, isso torna a aplicação mais consistente entre diferentes aplicações.

A parte interessante é a gestão de políticas ao longo do tempo. As condições de risco mudam, os requisitos de conformidade evoluem e as ameaças à segurança surgem sem aviso. O desafio não é apenas aplicar políticas onchain, mas atualizá-las sem criar incerteza sobre quais regras estavam ativas quando A transação foi autorizada.

Não estou dizendo que isso seja uma falha. É apenas o tipo de premissa de design que vale a pena observar. Uma camada de autorização só é tão útil quanto a confiabilidade e a transparência das políticas que ela aplica.

Tenho interesse em saber como Newton pretende equilibrar atualizações rápidas de políticas com a necessidade de decisões de autorização previsíveis e auditáveis.

@NewtonProtocol $NEWT #Newt
$TLM $VANRY
#SKHynixToIssue177.9MillionADSs