Binance Square
Mr_Badshah77
9.8k Publicações

Mr_Badshah77

Square verificado+
The Real Badshah || No Duplicates
561 A seguir
32.3K+ Seguidores
17.0K+ Gostaram
Publicações
·
--
#dusk $DUSK @Dusk_Foundation .......Eu esperava que um bug em uma ponte viesse de algo complicado. A que prendeu minha atenção começou com algo muito mais comum: copiar e colar um endereço.... Um endereço BSC pode parecer perfeitamente limpo para um humano, enquanto a string real contém um espaço no fim, uma quebra de linha ou uma tabulação. Pense nisso como copiar um endereço de uma casa com uma linha extra invisível anexada. Você consegue ler o endereço corretamente, mas o software recebe algo ligeiramente diferente..... Foi isso que importou no fluxo de ponte BEP20 da Dusk.. O memo não é apenas uma anotação. Ele informa à ponte qual endereço BSC deve receber o DUSK. Antes da correção, esse valor podia ser tratado de forma diferente entre validação, tela de revisão e execução, criando espaço para essas etapas discordarem. A correção foi surpreendentemente simples..... A Web Wallet da Dusk agora normaliza o memo uma vez, removendo espaços, e então usa o mesmo valor limpo em validação, revisão e execução. Aprofundou ainda mais.. .. A Dusk também adicionou um teste com um endereço EVM cercado por espaços, uma quebra de linha e uma tabulação. O teste verifica que a tela de revisão mostra o endereço limpo e que a execução recebe exatamente o mesmo valor normalizado. Esse último detalhe chamou minha atenção.... A documentação da Dusk alerta que um memo de ponte ausente ou inválido pode impedir o roteamento automático e potencialmente tornar uma transferência irrecuperável. A correção adiciona mais uma camada de segurança, mas os usuários ainda precisam verificar o destino por conta própria. Copiar e colar parece coisas comuns demais para ser perigoso. É exatamente por isso que bugs em torno disso importam.... Uma boa infraestrutura não é só sobre fazer o protocolo funcionar. É sobre eliminar pequenas lacunas entre o que o usuário vê, o que o software valida e o que acaba sendo executado. Esses detalhes invisíveis muitas vezes é onde a confiança é construída.. $PROM $AAVE
#dusk $DUSK @Dusk .......Eu esperava que um bug em uma ponte viesse de algo complicado. A que prendeu minha atenção começou com algo muito mais comum: copiar e colar um endereço....

Um endereço BSC pode parecer perfeitamente limpo para um humano, enquanto a string real contém um espaço no fim, uma quebra de linha ou uma tabulação.

Pense nisso como copiar um endereço de uma casa com uma linha extra invisível anexada. Você consegue ler o endereço corretamente, mas o software recebe algo ligeiramente diferente.....

Foi isso que importou no fluxo de ponte BEP20 da Dusk..

O memo não é apenas uma anotação. Ele informa à ponte qual endereço BSC deve receber o DUSK. Antes da correção, esse valor podia ser tratado de forma diferente entre validação, tela de revisão e execução, criando espaço para essas etapas discordarem.

A correção foi surpreendentemente simples.....

A Web Wallet da Dusk agora normaliza o memo uma vez, removendo espaços, e então usa o mesmo valor limpo em validação, revisão e execução.

Aprofundou ainda mais.. ..

A Dusk também adicionou um teste com um endereço EVM cercado por espaços, uma quebra de linha e uma tabulação. O teste verifica que a tela de revisão mostra o endereço limpo e que a execução recebe exatamente o mesmo valor normalizado.

Esse último detalhe chamou minha atenção....

A documentação da Dusk alerta que um memo de ponte ausente ou inválido pode impedir o roteamento automático e potencialmente tornar uma transferência irrecuperável. A correção adiciona mais uma camada de segurança, mas os usuários ainda precisam verificar o destino por conta própria.

Copiar e colar parece coisas comuns demais para ser perigoso.

É exatamente por isso que bugs em torno disso importam....

Uma boa infraestrutura não é só sobre fazer o protocolo funcionar. É sobre eliminar pequenas lacunas entre o que o usuário vê, o que o software valida e o que acaba sendo executado.

Esses detalhes invisíveis muitas vezes é onde a confiança é construída..
$PROM $AAVE
Parcialmente verdadeiro
#dusk $DUSK @Dusk_Foundation ......Eu esperava que o modelo de transação do Dusk fosse um detalhe de implementação menor. O problema mais profundo era mais difícil de perceber: uma única intenção de usuário ainda pode exigir várias transações independentes.... Pense em uma transação de blockchain como uma instrução selada. Se sua ação precisa de cinco instruções, assiná-las juntas não significa automaticamente que a rede as trate como uma única ação. Uma pode ser executada enquanto outra falha. Esse é o problema que o Dusk está examinando na issue #4058..... Hoje, uma transação Moonlight ou Phoenix carrega uma única operação opcional TransactionData. Então um fluxo como aprovar → trocar → apostar precisa ser dividido em várias transações, cada uma com sua própria assinatura, nonce e risco de inclusão. Vai mais fundo.... O Dusk está considerando uma transação em lote em nível de protocolo que poderia executar várias chamadas de contrato de forma atômica sob a identidade do usuário. Isso também permitiria que cada operação carregasse seu próprio valor ou depósito, enquanto potencialmente abrange o Phoenix sem mudar seu circuito de transferência ou configuração confiável... Mas existe outra rota. Um contrato agregador poderia executar várias chamadas sem mudar o protocolo. A troca é a autorização: contratos que usam caller() poderiam ver o agregador em vez do usuário original, enquanto public_sender() pode preservar a conta original do Moonlight. Essa distinção chamou minha atenção.... A parte difícil de agrupar não é colocar várias chamadas em um único contêiner. É definir o que significam identidade, gás, valor e falha quando essas chamadas viram uma única transição de estado. E a #4058 ainda está aberta, com a implementação real e a especificação do protocolo explicitamente deixadas para trabalho futuro..... Para uma cadeia voltada a fluxos financeiros, a execução atômica em múltiplas etapas deve se tornar um primitivo de protocolo, ou deve permanecer como algo que contratos compõem? $ADA $TUT
#dusk $DUSK @Dusk ......Eu esperava que o modelo de transação do Dusk fosse um detalhe de implementação menor. O problema mais profundo era mais difícil de perceber: uma única intenção de usuário ainda pode exigir várias transações independentes....
Pense em uma transação de blockchain como uma instrução selada. Se sua ação precisa de cinco instruções, assiná-las juntas não significa automaticamente que a rede as trate como uma única ação. Uma pode ser executada enquanto outra falha.
Esse é o problema que o Dusk está examinando na issue #4058.....
Hoje, uma transação Moonlight ou Phoenix carrega uma única operação opcional TransactionData. Então um fluxo como aprovar → trocar → apostar precisa ser dividido em várias transações, cada uma com sua própria assinatura, nonce e risco de inclusão.
Vai mais fundo....
O Dusk está considerando uma transação em lote em nível de protocolo que poderia executar várias chamadas de contrato de forma atômica sob a identidade do usuário. Isso também permitiria que cada operação carregasse seu próprio valor ou depósito, enquanto potencialmente abrange o Phoenix sem mudar seu circuito de transferência ou configuração confiável...
Mas existe outra rota.
Um contrato agregador poderia executar várias chamadas sem mudar o protocolo. A troca é a autorização: contratos que usam caller() poderiam ver o agregador em vez do usuário original, enquanto public_sender() pode preservar a conta original do Moonlight.
Essa distinção chamou minha atenção....
A parte difícil de agrupar não é colocar várias chamadas em um único contêiner. É definir o que significam identidade, gás, valor e falha quando essas chamadas viram uma única transição de estado.
E a #4058 ainda está aberta, com a implementação real e a especificação do protocolo explicitamente deixadas para trabalho futuro.....
Para uma cadeia voltada a fluxos financeiros, a execução atômica em múltiplas etapas deve se tornar um primitivo de protocolo, ou deve permanecer como algo que contratos compõem?
$ADA $TUT
#dusk $DUSK @Dusk_Foundation .....Eu não estava procurando uma atualização do Dusk sobre Macs. Eu estava mexendo no Piecrust, e uma pequena mudança de CI fez eu parar. @dusk moveu a validação do macOS ARM para fora do fluxo principal e para um caminho separado com validação condicional.... No começo, isso parece apenas uma rotina chata de engenharia. Aí eu lembrei do que, de fato, é o Piecrust. É a máquina virtual WASM por trás dos smart contracts do Dusk. Então a pergunta interessante vira: como testar uma camada de execução crítica sem fazer com que cada detalhe específico de plataforma desacelere todo o pipeline de desenvolvimento? Pense nisso como inspecionar uma aeronave... As verificações padrão acontecem toda vez. Uma configuração especial ganha seu próprio procedimento de teste quando o hardware exige... É basicamente isso que essa mudança faz. O pipeline regular continua focado na validação central, enquanto o teste de macOS ARM pode rodar separadamente em gatilhos específicos, em vez de virar um caminho obrigatório para tudo.. E essa distinção importa ainda mais à medida que o protocolo evolui. O trabalho do Rusk na versão 1.7.x já vem mexendo no comportamento da VM em torno do hardfork Boreas, incluindo mudanças envolvendo eventos revertidos e o comportamento de replay histórico. O Piecrust claramente ainda faz parte de uma stack de execução que está mudando ativamente. O que eu acho interessante não é “Dusk suporta outra máquina”. É o trade-off de engenharia... Você pode fazer com que cada teste rode em todo lugar, o tempo todo. Ou você pode manter o caminho crítico enxuto e isolar a validação específica de plataforma onde ela realmente adiciona sinal.. Nenhuma das abordagens é automaticamente melhor.. Mas, para uma VM de smart contract, eu prefiro ver os testes organizados em torno de onde existe risco de execução, e não em torno de um checklist gigante. Essa é a parte invisível da infraestrutura que as pessoas raramente notam. A qualidade de uma blockchain não é decidida apenas pelo que chega ao mainnet. Ela também é determinada por quão cuidadosamente o software por baixo dela está sendo desafiado antes de chegar lá. Então o que você otimizaria primeiro? Mais testes a cada mudança, ou mais testes direcionados para os caminhos de execução mais prováveis de falhar? $ACE $TRUMP
#dusk $DUSK @Dusk .....Eu não estava procurando uma atualização do Dusk sobre Macs.
Eu estava mexendo no Piecrust, e uma pequena mudança de CI fez eu parar.
@dusk moveu a validação do macOS ARM para fora do fluxo principal e para um caminho separado com validação condicional....
No começo, isso parece apenas uma rotina chata de engenharia.
Aí eu lembrei do que, de fato, é o Piecrust.
É a máquina virtual WASM por trás dos smart contracts do Dusk. Então a pergunta interessante vira: como testar uma camada de execução crítica sem fazer com que cada detalhe específico de plataforma desacelere todo o pipeline de desenvolvimento?
Pense nisso como inspecionar uma aeronave...
As verificações padrão acontecem toda vez.
Uma configuração especial ganha seu próprio procedimento de teste quando o hardware exige...
É basicamente isso que essa mudança faz.
O pipeline regular continua focado na validação central, enquanto o teste de macOS ARM pode rodar separadamente em gatilhos específicos, em vez de virar um caminho obrigatório para tudo..
E essa distinção importa ainda mais à medida que o protocolo evolui.
O trabalho do Rusk na versão 1.7.x já vem mexendo no comportamento da VM em torno do hardfork Boreas, incluindo mudanças envolvendo eventos revertidos e o comportamento de replay histórico. O Piecrust claramente ainda faz parte de uma stack de execução que está mudando ativamente.
O que eu acho interessante não é “Dusk suporta outra máquina”.
É o trade-off de engenharia...
Você pode fazer com que cada teste rode em todo lugar, o tempo todo.
Ou você pode manter o caminho crítico enxuto e isolar a validação específica de plataforma onde ela realmente adiciona sinal..
Nenhuma das abordagens é automaticamente melhor..
Mas, para uma VM de smart contract, eu prefiro ver os testes organizados em torno de onde existe risco de execução, e não em torno de um checklist gigante.
Essa é a parte invisível da infraestrutura que as pessoas raramente notam.
A qualidade de uma blockchain não é decidida apenas pelo que chega ao mainnet.
Ela também é determinada por quão cuidadosamente o software por baixo dela está sendo desafiado antes de chegar lá.
Então o que você otimizaria primeiro?
Mais testes a cada mudança, ou mais testes direcionados para os caminhos de execução mais prováveis de falhar?
$ACE $TRUMP
#termmax @termmax ...Eu estava analisando as correções mais recentes da V2 do TermMax, e uma coisa continuava me incomodando. Eu costumava achar que a maioria dos bugs em DeFi se resume a matemática ruim. Desta vez, a matemática estava, em sua maior parte, ok. O problema maior foi usar a representação errada da realidade. Vamos falar de apr(). A lógica antiga olhava o saldo bruto de XT da ordem. Parece razoável, certo? Mas a V2 não usa o saldo bruto de XT como estado de precificação. Ela usa virtualXtReserve. Essa diferença importa... Imagine uma loja em que a etiqueta de preço é controlada pelo livro interno da própria loja, mas você começa a calcular preços a partir de qualquer quantia de dinheiro que alguém aleatoriamente largou no balcão. O dinheiro mudou. O modelo de preços não mudou. É basicamente isso que uma transferência direta de XT poderia fazer com o cálculo antigo de APR. Um saldo pode se mover sem a curva se mover, e ainda assim apr() pode tratar esse saldo como o novo estado de precificação. A correção faz o modelo contábil coincidir com o modelo econômico. E eu acho que essa é a lição mais interessante. Em contratos inteligentes financeiros, a pergunta perigosa nem sempre é: “A fórmula está correta?” Às vezes é:... “Estamos alimentando a fórmula com o estado certo?” O mesmo tema aparece na correção da liquidação. Um oráculo de dívida com 18 decimais poderia fazer uma conversão de decimais colapsar a comparação de garantias, transformando posições que deveriam permitir uma liquidação de 50% em liquidação total. De novo, não era um problema de fórmula tão complicado. Era um problema de unidades. É por isso que estou começando a prestar mais atenção nessas mudanças aparentemente “boring” (entediante). Uma correção contábil de uma linha pode importar mais do que um recurso novo e chamativo, porque ela decide se o protocolo está interpretando o mercado corretamente. No TermMax, eu observaria uma coisa de perto daqui pra frente: não apenas quanta liquidez o sistema tem, mas se precificação, avaliação de garantias e lógica de liquidação estão lendo a mesma realidade econômica..... É aí que “o código funciona” começa a virar “a infraestrutura financeira funciona”. Você preferiria auditar as fórmulas primeiro, o estado contábil primeiro, ou as premissas do oráculo/unidade primeiro?....
#termmax @TermMax ...Eu estava analisando as correções mais recentes da V2 do TermMax, e uma coisa continuava me incomodando.
Eu costumava achar que a maioria dos bugs em DeFi se resume a matemática ruim.
Desta vez, a matemática estava, em sua maior parte, ok.
O problema maior foi usar a representação errada da realidade.
Vamos falar de apr().
A lógica antiga olhava o saldo bruto de XT da ordem.
Parece razoável, certo?
Mas a V2 não usa o saldo bruto de XT como estado de precificação. Ela usa virtualXtReserve.
Essa diferença importa...
Imagine uma loja em que a etiqueta de preço é controlada pelo livro interno da própria loja, mas você começa a calcular preços a partir de qualquer quantia de dinheiro que alguém aleatoriamente largou no balcão.
O dinheiro mudou.
O modelo de preços não mudou.
É basicamente isso que uma transferência direta de XT poderia fazer com o cálculo antigo de APR.
Um saldo pode se mover sem a curva se mover, e ainda assim apr() pode tratar esse saldo como o novo estado de precificação.
A correção faz o modelo contábil coincidir com o modelo econômico.
E eu acho que essa é a lição mais interessante.
Em contratos inteligentes financeiros, a pergunta perigosa nem sempre é:
“A fórmula está correta?”
Às vezes é:...
“Estamos alimentando a fórmula com o estado certo?”
O mesmo tema aparece na correção da liquidação.
Um oráculo de dívida com 18 decimais poderia fazer uma conversão de decimais colapsar a comparação de garantias, transformando posições que deveriam permitir uma liquidação de 50% em liquidação total.
De novo, não era um problema de fórmula tão complicado.
Era um problema de unidades.
É por isso que estou começando a prestar mais atenção nessas mudanças aparentemente “boring” (entediante).
Uma correção contábil de uma linha pode importar mais do que um recurso novo e chamativo, porque ela decide se o protocolo está interpretando o mercado corretamente.
No TermMax, eu observaria uma coisa de perto daqui pra frente:
não apenas quanta liquidez o sistema tem, mas se precificação, avaliação de garantias e lógica de liquidação estão lendo a mesma realidade econômica.....
É aí que “o código funciona” começa a virar “a infraestrutura financeira funciona”.
Você preferiria auditar as fórmulas primeiro, o estado contábil primeiro, ou as premissas do oráculo/unidade primeiro?....
#dusk $DUSK @Dusk_Foundation ......Eu estava olhando o código ZK mais antigo do Dusk e depois encontrei uma mudança mais recente que deixou tudo mais interessante: o sistema de provas não está apenas ficando mais forte, ele está ficando mais enxuto..... O lançamento dusk-plonk 0.22.1 de junho apertou o próprio verificador. As entradas públicas agora são tratadas de forma mais esparsa, a alocação de heap foi reduzida e parte da sobrecarga de multiplicação escalar foi cortada da verificação da prova. Também endureceu a desserialização da prova, rejeitando dados de tamanho malformados em vez de causar um panic. Pense nisso como um checkpoint de segurança..... Você não melhora o checkpoint fazendo cada pessoa desempacotar cada bolsa. Você inspeciona exatamente o que importa, evita trabalho desnecessário e rejeita entradas obviamente quebradas antes que elas entrem mais fundo no sistema. É mais ou menos isso que chamou minha atenção aqui..... A pilha PLONK do Dusk é seu sistema de provas ZK sobre BLS12-381, e o PLONK V3 ficou ativo com a atualização de rede Aegis. Então essas melhorias no verificador não estão “pairando” como um experimento isolado de criptografia. Elas fazem parte da pilha que o Dusk está ativamente mantendo por baixo da sua arquitetura de privacidade. Espere, deixe eu voltar um pouco..... As pessoas geralmente falam de ZK como se a parte difícil fosse simplesmente “você consegue prová-lo?” Em uma rede real, existe outra pergunta:... Quanto trabalho o sistema precisa fazer toda vez que ele verifica que uma prova é válida? É aí que essa atualização importa para mim. Menores alocações e menos sobrecarga de multiplicação escalar não mudam o grande destaque do recurso. Elas melhoram a engrenagem por baixo.... A compensação é que otimizações nessa camada podem tornar o código criptográfico mais difícil de entender; então ganhos de desempenho só importam quando a correção e o endurecimento de entrada permanecem intactos. Eu ainda estou mais interessado na direção do que em qualquer número isolado de benchmark: @dusk está tratando a verificação ZK como infraestrutura que precisa de engenharia contínua, não como uma checklist adicionada uma vez.... Quando a privacidade vira parte da pilha financeira, a eficiência da verificação de provas não deveria importar quase tanto quanto o próprio primitivo de privacidade?
#dusk $DUSK @Dusk ......Eu estava olhando o código ZK mais antigo do Dusk e depois encontrei uma mudança mais recente que deixou tudo mais interessante: o sistema de provas não está apenas ficando mais forte, ele está ficando mais enxuto.....
O lançamento dusk-plonk 0.22.1 de junho apertou o próprio verificador. As entradas públicas agora são tratadas de forma mais esparsa, a alocação de heap foi reduzida e parte da sobrecarga de multiplicação escalar foi cortada da verificação da prova. Também endureceu a desserialização da prova, rejeitando dados de tamanho malformados em vez de causar um panic.
Pense nisso como um checkpoint de segurança.....
Você não melhora o checkpoint fazendo cada pessoa desempacotar cada bolsa. Você inspeciona exatamente o que importa, evita trabalho desnecessário e rejeita entradas obviamente quebradas antes que elas entrem mais fundo no sistema.
É mais ou menos isso que chamou minha atenção aqui.....
A pilha PLONK do Dusk é seu sistema de provas ZK sobre BLS12-381, e o PLONK V3 ficou ativo com a atualização de rede Aegis. Então essas melhorias no verificador não estão “pairando” como um experimento isolado de criptografia. Elas fazem parte da pilha que o Dusk está ativamente mantendo por baixo da sua arquitetura de privacidade.
Espere, deixe eu voltar um pouco.....
As pessoas geralmente falam de ZK como se a parte difícil fosse simplesmente “você consegue prová-lo?”
Em uma rede real, existe outra pergunta:...
Quanto trabalho o sistema precisa fazer toda vez que ele verifica que uma prova é válida?
É aí que essa atualização importa para mim. Menores alocações e menos sobrecarga de multiplicação escalar não mudam o grande destaque do recurso. Elas melhoram a engrenagem por baixo....
A compensação é que otimizações nessa camada podem tornar o código criptográfico mais difícil de entender; então ganhos de desempenho só importam quando a correção e o endurecimento de entrada permanecem intactos.
Eu ainda estou mais interessado na direção do que em qualquer número isolado de benchmark: @dusk está tratando a verificação ZK como infraestrutura que precisa de engenharia contínua, não como uma checklist adicionada uma vez....
Quando a privacidade vira parte da pilha financeira, a eficiência da verificação de provas não deveria importar quase tanto quanto o próprio primitivo de privacidade?
#termmax @termmax .........O que acontece aos credores quando a liquidação não consegue recuperar totalmente um empréstimo do TermMax? Tenho pensado nisso ao observar @termmax . Na maioria dos sistemas de concessão de crédito, a liquidação é o ponto em que a garantia é vendida para cobrir a dívida. Mas o que acontece quando a janela de liquidação termina e o empréstimo ainda não foi totalmente recuperado? É aí que o mecanismo de Entrega Física do TermMax se torna interessante. Se a liquidação recuperar apenas parte da dívida em aberto, o processo pode mudar automaticamente para a entrega física. Em vez de deixar os detentores de FT com uma reivindicação não resolvida, o pool de resgate pode conter tanto os tokens de dívida subjacente quanto os tokens de colateral. Os detentores de FT então recebem uma parcela proporcional desse pool com base na sua participação em FT em relação ao total de FT em aberto. Então a compensação fica bem clara: Liquidação completa = dívida recuperada por meio de vendas do colateral. Liquidação incompleta = ativos restantes entregues de forma proporcional aos detentores de FT. Isso não elimina o risco de perda. Mas muda o que acontece quando o processo normal de liquidação não é suficiente para fechar a posição. Você preferiria: 1. Entrega física automática dos ativos restantes 2. Um modelo apenas de liquidação 3. Depende do tipo de colateral?
#termmax @TermMax .........O que acontece aos credores quando a liquidação não consegue recuperar totalmente um empréstimo do TermMax?
Tenho pensado nisso ao observar @TermMax .
Na maioria dos sistemas de concessão de crédito, a liquidação é o ponto em que a garantia é vendida para cobrir a dívida.
Mas o que acontece quando a janela de liquidação termina e o empréstimo ainda não foi totalmente recuperado?
É aí que o mecanismo de Entrega Física do TermMax se torna interessante.
Se a liquidação recuperar apenas parte da dívida em aberto, o processo pode mudar automaticamente para a entrega física.
Em vez de deixar os detentores de FT com uma reivindicação não resolvida, o pool de resgate pode conter tanto os tokens de dívida subjacente quanto os tokens de colateral.
Os detentores de FT então recebem uma parcela proporcional desse pool com base na sua participação em FT em relação ao total de FT em aberto.
Então a compensação fica bem clara:
Liquidação completa = dívida recuperada por meio de vendas do colateral.
Liquidação incompleta = ativos restantes entregues de forma proporcional aos detentores de FT.
Isso não elimina o risco de perda.
Mas muda o que acontece quando o processo normal de liquidação não é suficiente para fechar a posição.
Você preferiria:
1. Entrega física automática dos ativos restantes
2. Um modelo apenas de liquidação
3. Depende do tipo de colateral?
#dusk $DUSK @Dusk_Foundation ....... Eu normalmente não percebo pequenos commits na carteira. Este me fez parar: @Dusk_Foundation alterou três linhas do comportamento da ponte porque alguns caracteres invisíveis podem importar quando um memo é o destino. A ponte BEP20 usa o memo para dizer ao Dusk qual endereço BSC deve receber o DUSK. Então, neste caso, o memo não é apenas uma nota. Ele faz parte da instrução de roteamento. Pense nisso como um rótulo de pacote. Se o endereço disser: 0xABC... uma pessoa vê o mesmo destino. O software nem sempre trata os espaços extras e as quebras de linha do mesmo jeito. É isso que este commit corrige. Para transferências na ponte BEP20, a Web Wallet agora cria um memo normalizado removendo espaços em branco e, em seguida, usa esse mesmo valor limpo para validação, para a tela de revisão e para a transação real. A parte interessante é o teste. O Dusk adicionou um caso em que o endereço EVM está cercado por espaços, uma nova linha e uma tabulação. A carteira ainda precisa mostrar o endereço limpo na revisão e enviar exatamente esse endereço normalizado para a execução. Uma mudança pequena, mas a consequência importa porque os documentos do Dusk avisam que um memo de ponte ausente ou inválido pode impedir o roteamento automático e pode tornar uma transferência irrecuperável. Os usuários ainda precisam verificar o endereço de destino por conta própria. Eu gosto desse tipo de engenharia porque não é chamativa. É o caso de borda “chato” que fica entre “o código funciona” e “um usuário pode confiar com segurança no fluxo”. Quantos riscos sérios de carteira estão escondidos em detalhes que parecem tão pequenos? $ACE $BOME
#dusk $DUSK @Dusk ....... Eu normalmente não percebo pequenos commits na carteira. Este me fez parar: @Dusk alterou três linhas do comportamento da ponte porque alguns caracteres invisíveis podem importar quando um memo é o destino.
A ponte BEP20 usa o memo para dizer ao Dusk qual endereço BSC deve receber o DUSK. Então, neste caso, o memo não é apenas uma nota. Ele faz parte da instrução de roteamento.
Pense nisso como um rótulo de pacote.
Se o endereço disser:
0xABC...
uma pessoa vê o mesmo destino.
O software nem sempre trata os espaços extras e as quebras de linha do mesmo jeito.
É isso que este commit corrige. Para transferências na ponte BEP20, a Web Wallet agora cria um memo normalizado removendo espaços em branco e, em seguida, usa esse mesmo valor limpo para validação, para a tela de revisão e para a transação real.
A parte interessante é o teste.
O Dusk adicionou um caso em que o endereço EVM está cercado por espaços, uma nova linha e uma tabulação. A carteira ainda precisa mostrar o endereço limpo na revisão e enviar exatamente esse endereço normalizado para a execução.
Uma mudança pequena, mas a consequência importa porque os documentos do Dusk avisam que um memo de ponte ausente ou inválido pode impedir o roteamento automático e pode tornar uma transferência irrecuperável. Os usuários ainda precisam verificar o endereço de destino por conta própria.
Eu gosto desse tipo de engenharia porque não é chamativa.
É o caso de borda “chato” que fica entre “o código funciona” e “um usuário pode confiar com segurança no fluxo”.
Quantos riscos sérios de carteira estão escondidos em detalhes que parecem tão pequenos?
$ACE $BOME
Parcialmente verdadeiro
#termmax @termmax Você se sentiria confortável com um token em que 80% da oferta ainda é mantida pelo emissor? Tenho pensado nisso enquanto lia o whitepaper da @termmax MiCA. A TMX tem uma oferta máxima fixa de 1 bilhão de tokens. Mas o whitepaper afirma que 80% são mantidos pelo emissor, cobrindo alocações para equipe, assessores e ecossistema dentro da estrutura de aquisição estabelecida. Esse número chamou minha atenção imediatamente. Porque a concentração de propriedade não é automaticamente boa ou ruim. O que importa é como esses tokens são adquiridos, quando eles se tornam disponíveis e quanta influência de governança eles podem eventualmente representar. Pense nisso como dar a maioria dos ingressos para um pequeno grupo, mas trancando esses ingressos ao longo do tempo. Eles podem ter uma participação societária significativa. Mas nem sempre conseguem usar tudo de uma vez. A TermMax também reconhece o outro lado dessa equação: conforme a governança se torna cada vez mais on-chain, a propriedade concentrada de tokens pode permitir que um grupo menor de detentores adquira um poder de voto significativo. Esse é o trade-off interessante para mim. Aquisição longa = potencialmente um alinhamento de longo prazo mais forte. Alta concentração = potencialmente maior risco de governança. Então a pergunta importante não é apenas: “80% retido é demais?” É se o processo de aquisição e de descentralização pode, gradualmente, transformar essa concentração em um alinhamento genuinamente duradouro. Se você estivesse avaliando a TMX, em que você focaria primeiro? 1. Cronograma de aquisição 2. Distribuição futura da governança 3. Crescimento da oferta em circulação 4. Os três juntos $BTW $HEMI $BR
#termmax @TermMax Você se sentiria confortável com um token em que 80% da oferta ainda é mantida pelo emissor?
Tenho pensado nisso enquanto lia o whitepaper da @TermMax MiCA.
A TMX tem uma oferta máxima fixa de 1 bilhão de tokens.
Mas o whitepaper afirma que 80% são mantidos pelo emissor, cobrindo alocações para equipe, assessores e ecossistema dentro da estrutura de aquisição estabelecida.
Esse número chamou minha atenção imediatamente.
Porque a concentração de propriedade não é automaticamente boa ou ruim.
O que importa é como esses tokens são adquiridos, quando eles se tornam disponíveis e quanta influência de governança eles podem eventualmente representar.
Pense nisso como dar a maioria dos ingressos para um pequeno grupo, mas trancando esses ingressos ao longo do tempo.
Eles podem ter uma participação societária significativa.
Mas nem sempre conseguem usar tudo de uma vez.
A TermMax também reconhece o outro lado dessa equação: conforme a governança se torna cada vez mais on-chain, a propriedade concentrada de tokens pode permitir que um grupo menor de detentores adquira um poder de voto significativo.
Esse é o trade-off interessante para mim.
Aquisição longa = potencialmente um alinhamento de longo prazo mais forte.
Alta concentração = potencialmente maior risco de governança.
Então a pergunta importante não é apenas:
“80% retido é demais?”
É se o processo de aquisição e de descentralização pode, gradualmente, transformar essa concentração em um alinhamento genuinamente duradouro.
Se você estivesse avaliando a TMX, em que você focaria primeiro?
1. Cronograma de aquisição
2. Distribuição futura da governança
3. Crescimento da oferta em circulação
4. Os três juntos

$BTW $HEMI $BR
#dusk $DUSK @Dusk_Foundation ........I expected Boreas to make Dusk faster and cleaner. A mudança mais profunda foi mais difícil de notar: ela alterou as regras do que a rede considera uma transação válida. Pense em uma blockchain como um manual de regras de um árbitro. Uma atualização de software não é importante porque o árbitro corre mais rápido. Ela é importante quando as próprias regras mudam, e cada nó precisa interpretar o jogo da mesma forma..... Foi isso que Boreas fez. Com o Rusk 1.7, o Dusk introduziu versionamento explícito entre transações recebidas, sua forma canônica e o que finalmente é confirmado no livro-razão. A contabilidade de gás também passou a ser ciente de fork, com custos de recursos para operações como hash e verificação criptográfica vinculados às regras do protocolo ativo....... Foi mais fundo. Boreas mudou a ordem de transição de estado, tornou eventos de contrato revertidos explícitos para consumidores de arquivo e criou uma fronteira de protocolo clara para o comportamento de transações mais antigas. Mais importante: transações Phoenix foram desativadas na rede principal do Dusk no reinício de 10 de junho no bloco 4,414,095, enquanto a testnet as manteve durante um período de testes antes de desativá-las no bloco 4,000,000 em 7 de agosto. Os dados históricos do Phoenix permanecem reproduzíveis..... Esse último detalhe foi o que chamou minha atenção. Uma rede madura não é apenas sobre adicionar novos recursos. Às vezes, a atualização importante é decidir o que o protocolo deve parar de fazer, ainda preservando histórico suficiente para que a cadeia continue sendo reproduzível....... E com o Rusk v1.7.1 agora como a versão mais recente listada, o trabalho de engenharia do Dusk parece menos uma única atualização e mais um aperto contínuo das regras por baixo da pilha financeira. Para mercados regulados, o comportamento de protocolo previsível não é tão importante quanto adicionar novas funcionalidades? $ACE $BTW
#dusk $DUSK @Dusk ........I expected Boreas to make Dusk faster and cleaner. A mudança mais profunda foi mais difícil de notar: ela alterou as regras do que a rede considera uma transação válida.
Pense em uma blockchain como um manual de regras de um árbitro. Uma atualização de software não é importante porque o árbitro corre mais rápido. Ela é importante quando as próprias regras mudam, e cada nó precisa interpretar o jogo da mesma forma.....
Foi isso que Boreas fez.
Com o Rusk 1.7, o Dusk introduziu versionamento explícito entre transações recebidas, sua forma canônica e o que finalmente é confirmado no livro-razão. A contabilidade de gás também passou a ser ciente de fork, com custos de recursos para operações como hash e verificação criptográfica vinculados às regras do protocolo ativo.......
Foi mais fundo.
Boreas mudou a ordem de transição de estado, tornou eventos de contrato revertidos explícitos para consumidores de arquivo e criou uma fronteira de protocolo clara para o comportamento de transações mais antigas. Mais importante: transações Phoenix foram desativadas na rede principal do Dusk no reinício de 10 de junho no bloco 4,414,095, enquanto a testnet as manteve durante um período de testes antes de desativá-las no bloco 4,000,000 em 7 de agosto. Os dados históricos do Phoenix permanecem reproduzíveis.....
Esse último detalhe foi o que chamou minha atenção.
Uma rede madura não é apenas sobre adicionar novos recursos. Às vezes, a atualização importante é decidir o que o protocolo deve parar de fazer, ainda preservando histórico suficiente para que a cadeia continue sendo reproduzível.......
E com o Rusk v1.7.1 agora como a versão mais recente listada, o trabalho de engenharia do Dusk parece menos uma única atualização e mais um aperto contínuo das regras por baixo da pilha financeira.
Para mercados regulados, o comportamento de protocolo previsível não é tão importante quanto adicionar novas funcionalidades?

$ACE $BTW
#dusk $DUSK @Dusk_Foundation ......Eu geralmente olho o código de protocolo para as coisas grandes. Desta vez, uma pequena mudança na documentação chamou minha atenção. A Dusk mudou como a documentação dela valida e publica o sitemap. No começo, parece manutenção: “npm run build” virou um fluxo de verificação que constrói o site, roda testes e então confere o resultado. Mas a mudança mais interessante é o que acontece com o sitemap.xml. Em vez de manter um sitemap estático separado, o build agora pega o sitemap-index.xml gerado pelo Astro e cria o sitemap.xml convencional como um alias. Isso soa chato. Na verdade, resolve um problema útil de infraestrutura. Pense como mudar o sistema de endereços de um prédio. O prédio já gera o mapa interno correto, mas visitantes externos ainda esperam encontrar a entrada em um endereço familiar. Em vez de manter dois mapas que podem divergir, o build cria o endereço familiar a partir da fonte gerada. Os testes reforçam essa ideia. #Dusk agora verifica se o sitemap gerado é válido e se o sitemap.xml convencional o espelha exatamente. Então uma mudança na documentação pode falhar na verificação se essa relação se romper. O que eu gosto aqui é a mentalidade de engenharia. O commit não está adicionando algum recurso de protocolo chamativo. Ele está reduzindo a chance de que a infraestrutura de documentação fique, silenciosamente, inconsistente à medida que o site evolui. E isso importa mais do que parece. Para um projeto técnico, a documentação faz parte da interface que desenvolvedores, operadores e ferramentas automatizadas dependem. Um link quebrado, um sitemap desatualizado ou um build incompleto não compromete o consenso, mas ainda pode criar atrito em tudo que é construído em cima do protocolo. Commit pequeno. Um problema bem pouco glamouroso. Mas muitas vezes são esses detalhes que mostram o quão a sério uma equipe trata a infraestrutura em torno do produto principal. É essa a parte que achei interessante nessa mudança da Dusk. $ACE $RED #ChinaJulyOutputRetailInvestmentAllMiss #CMESeptemberHikeOddsFallTo30.6% #CryptoStartupsRaise$11.2BInH1 #EthereumFoundationLaunchesGlamsterdamTestnet
#dusk $DUSK @Dusk ......Eu geralmente olho o código de protocolo para as coisas grandes. Desta vez, uma pequena mudança na documentação chamou minha atenção.
A Dusk mudou como a documentação dela valida e publica o sitemap.
No começo, parece manutenção:
“npm run build” virou um fluxo de verificação que constrói o site, roda testes e então confere o resultado.
Mas a mudança mais interessante é o que acontece com o sitemap.xml.
Em vez de manter um sitemap estático separado, o build agora pega o sitemap-index.xml gerado pelo Astro e cria o sitemap.xml convencional como um alias.
Isso soa chato.
Na verdade, resolve um problema útil de infraestrutura.
Pense como mudar o sistema de endereços de um prédio. O prédio já gera o mapa interno correto, mas visitantes externos ainda esperam encontrar a entrada em um endereço familiar. Em vez de manter dois mapas que podem divergir, o build cria o endereço familiar a partir da fonte gerada.
Os testes reforçam essa ideia.
#Dusk agora verifica se o sitemap gerado é válido e se o sitemap.xml convencional o espelha exatamente. Então uma mudança na documentação pode falhar na verificação se essa relação se romper.
O que eu gosto aqui é a mentalidade de engenharia.
O commit não está adicionando algum recurso de protocolo chamativo. Ele está reduzindo a chance de que a infraestrutura de documentação fique, silenciosamente, inconsistente à medida que o site evolui.
E isso importa mais do que parece.
Para um projeto técnico, a documentação faz parte da interface que desenvolvedores, operadores e ferramentas automatizadas dependem.
Um link quebrado, um sitemap desatualizado ou um build incompleto não compromete o consenso, mas ainda pode criar atrito em tudo que é construído em cima do protocolo.
Commit pequeno. Um problema bem pouco glamouroso.
Mas muitas vezes são esses detalhes que mostram o quão a sério uma equipe trata a infraestrutura em torno do produto principal.
É essa a parte que achei interessante nessa mudança da Dusk.
$ACE $RED #ChinaJulyOutputRetailInvestmentAllMiss #CMESeptemberHikeOddsFallTo30.6% #CryptoStartupsRaise$11.2BInH1 #EthereumFoundationLaunchesGlamsterdamTestnet
#termmax @termmax Acho que o mais importante a entender sobre o TermMax não é o que ele promete simplificar, mas o que ainda é responsabilidade do usuário. Seus Termos descrevem um design não custodial em que os usuários mantêm o controle dos ativos depositados, enquanto a segurança da chave privada e as decisões de transação permanecem com o usuário. Essa distinção importa porque a DeFi pode tornar a interface mais simples, enquanto o risco subjacente continua complexo. Pense nisso como uma transmissão automática. Você pode precisar de menos etapas manuais, mas o motor por baixo ainda precisa funcionar corretamente. O TermMax reconhece explicitamente riscos, incluindo volatilidade do mercado, vulnerabilidades de contratos inteligentes, incerteza regulatória, possível perda de fundos e falhas de design ou desenvolvimento. O mesmo se aplica à execução. Seus termos afirmam que contratos inteligentes são imutáveis e irreversíveis, ficando os usuários responsáveis por questões como transações incorretamente construídas ou endereços de carteira digitados de forma errada. Isso cria um desafio de design interessante para um protocolo construído em torno de empréstimos, concessões de crédito e alavancagem. O objetivo pode ser reduzir o número de etapas que os usuários fazem, mas reduzir etapas não diminui automaticamente o risco econômico ou técnico. É aí que eu acho o TermMax interessante. O teste real não é se a DeFi pode se tornar mais fácil de usar. É se essa simplicidade pode coexistir com usuários ainda entendendo exatamente a que eles estão expostos. Você preferiria uma experiência de DeFi mais simples, ou uma que torne cada risco subjacente impossível de ignorar? #TermMax $ALLO $RED #ChinaJulyOutputRetailInvestmentAllMiss #EthereumFoundationLaunchesGlamsterdamTestnet #CMESeptemberHikeOddsFallTo30.6%
#termmax @TermMax Acho que o mais importante a entender sobre o TermMax não é o que ele promete simplificar, mas o que ainda é responsabilidade do usuário.
Seus Termos descrevem um design não custodial em que os usuários mantêm o controle dos ativos depositados, enquanto a segurança da chave privada e as decisões de transação permanecem com o usuário.
Essa distinção importa porque a DeFi pode tornar a interface mais simples, enquanto o risco subjacente continua complexo.
Pense nisso como uma transmissão automática. Você pode precisar de menos etapas manuais, mas o motor por baixo ainda precisa funcionar corretamente.
O TermMax reconhece explicitamente riscos, incluindo volatilidade do mercado, vulnerabilidades de contratos inteligentes, incerteza regulatória, possível perda de fundos e falhas de design ou desenvolvimento.
O mesmo se aplica à execução.
Seus termos afirmam que contratos inteligentes são imutáveis e irreversíveis, ficando os usuários responsáveis por questões como transações incorretamente construídas ou endereços de carteira digitados de forma errada.
Isso cria um desafio de design interessante para um protocolo construído em torno de empréstimos, concessões de crédito e alavancagem.
O objetivo pode ser reduzir o número de etapas que os usuários fazem, mas reduzir etapas não diminui automaticamente o risco econômico ou técnico.
É aí que eu acho o TermMax interessante.
O teste real não é se a DeFi pode se tornar mais fácil de usar.
É se essa simplicidade pode coexistir com usuários ainda entendendo exatamente a que eles estão expostos.
Você preferiria uma experiência de DeFi mais simples, ou uma que torne cada risco subjacente impossível de ignorar?
#TermMax $ALLO $RED #ChinaJulyOutputRetailInvestmentAllMiss #EthereumFoundationLaunchesGlamsterdamTestnet #CMESeptemberHikeOddsFallTo30.6%
#dusk $DUSK @Dusk_Foundation Eu sempre assumi que colocar uma bolsa de valores on-chain simplesmente significava reconstruir a própria bolsa. Mas ao analisar a reforma real da UE, vê-se algo diferente — trata-se de quem está autorizado a operar a infraestrutura central do mercado. Pense em uma bolsa tradicional como dois setores separados. Um faz o pareamento entre ordens de compra e venda. O outro confirma a titularidade depois que a negociação é liquidada. Eles são mantidos separados de propósito — uní-los aumenta riscos regulatórios e operacionais reais. O Regime Piloto de DLT da UE mudou isso com uma nova categoria chamada DLT-TSS, que permite que um operador licenciado execute tanto a negociação quanto a liquidação em um único sistema DLT, sob condições definidas. É isso que torna a 21X digna de acompanhamento. Em dezembro de 2024, a 21X recebeu aprovação alemã para operar como um Sistema de Negociação e Liquidação por DLT. @Dusk_Foundation já tem uma base por lá. A Dusk entrou como participante de negociação na 21X, começando com operações de tesouraria para seu stablecoin — usando fundos do mercado monetário tokenizados e regulamentados para lastrear as reservas de EURQ. O que se destaca para mim não é apenas mais um ativo sendo tokenizado. É a mudança do papel do blockchain. A pergunta não é mais “o DLT consegue manter ativos financeiros?” — é “o DLT consegue, de fato, se tornar parte do modo como o próprio mercado opera?” Esse é um patamar bem mais difícil de cumprir. Para mim, é isso que torna a 21X digna de acompanhamento: é um teste em tempo real de como se parece um mercado financeiro quando a infraestrutura já nasce nativa em DLT desde o primeiro dia, e não é “acoplada” depois. Se funcionar, o blockchain deixa de ser apenas a canalização por baixo dos mercados — e passa a ser o mercado? $ACE $ADA #duskusdt
#dusk $DUSK @Dusk Eu sempre assumi que colocar uma bolsa de valores on-chain simplesmente significava reconstruir a própria bolsa. Mas ao analisar a reforma real da UE, vê-se algo diferente — trata-se de quem está autorizado a operar a infraestrutura central do mercado.
Pense em uma bolsa tradicional como dois setores separados. Um faz o pareamento entre ordens de compra e venda. O outro confirma a titularidade depois que a negociação é liquidada. Eles são mantidos separados de propósito — uní-los aumenta riscos regulatórios e operacionais reais.
O Regime Piloto de DLT da UE mudou isso com uma nova categoria chamada DLT-TSS, que permite que um operador licenciado execute tanto a negociação quanto a liquidação em um único sistema DLT, sob condições definidas.
É isso que torna a 21X digna de acompanhamento. Em dezembro de 2024, a 21X recebeu aprovação alemã para operar como um Sistema de Negociação e Liquidação por DLT.
@Dusk já tem uma base por lá. A Dusk entrou como participante de negociação na 21X, começando com operações de tesouraria para seu stablecoin — usando fundos do mercado monetário tokenizados e regulamentados para lastrear as reservas de EURQ.
O que se destaca para mim não é apenas mais um ativo sendo tokenizado.
É a mudança do papel do blockchain.
A pergunta não é mais “o DLT consegue manter ativos financeiros?” — é “o DLT consegue, de fato, se tornar parte do modo como o próprio mercado opera?”
Esse é um patamar bem mais difícil de cumprir.
Para mim, é isso que torna a 21X digna de acompanhamento: é um teste em tempo real de como se parece um mercado financeiro quando a infraestrutura já nasce nativa em DLT desde o primeiro dia, e não é “acoplada” depois.
Se funcionar, o blockchain deixa de ser apenas a canalização por baixo dos mercados — e passa a ser o mercado?
$ACE $ADA
#duskusdt
#dusk $DUSK @Dusk_Foundation Todo mundo presume que a função de uma blockchain de privacidade é esconder tudo. A aposta real da Dusk é o oposto: esconder tudo, muitas vezes, é a resposta errada. Pense no que um sistema financeiro de verdade precisa. Um depósito em uma exchange e uma transferência confidencial de propriedade não são o mesmo problema. Um precisa ser rastreável o suficiente para que seja reconciliado com um saldo do cliente. O outro precisa permanecer privado o bastante para que ninguém fora da transação consiga nem sequer ver que ela aconteceu. Forçar ambos dentro de um único modelo de privacidade significa que você quebra a reconciliação ou quebra a confidencialidade — não existe uma versão de “uma única configuração” que sirva corretamente para os dois. A Dusk não escolhe um lado. Ela disponibiliza dois modelos de transação na mesma base DuskDS e deixa o fluxo de trabalho decidir qual deles precisa. Moonlight é o modelo de conta transparente — saldos e transferências permanecem visíveis, o que é exatamente o que uma exchange quer quando precisa combinar depósitos recebidos com o cliente certo, sem adivinhações. Phoenix vai na direção oposta: transações protegidas, provas de conhecimento zero, detalhes da transação ocultos por padrão, com divulgação disponível apenas para quem for realmente autorizado a vê-los. Aqui está a parte que é fácil de esquecer: isto não é só “criamos duas funcionalidades”. Escolher Phoenix traz um peso operacional real — uma configuração de custódia diferente, um modelo de varredura diferente — e é exatamente por isso que a própria orientação de integração da Dusk para exchanges aponta para o Moonlight como opção para depósitos. Privacidade não é grátis, e fingir o contrário é como projetos acabam com um modelo que parece privado no papel e se torna inviável em produção. Então a tese real não é “tornar as finanças privadas”. É mais específica e útil: permitir que o fluxo de trabalho escolha sua própria visibilidade, em vez de forçar cada transação na rede a viver sob a mesma regra. $ACE $HEMI
#dusk $DUSK @Dusk Todo mundo presume que a função de uma blockchain de privacidade é esconder tudo. A aposta real da Dusk é o oposto: esconder tudo, muitas vezes, é a resposta errada.

Pense no que um sistema financeiro de verdade precisa. Um depósito em uma exchange e uma transferência confidencial de propriedade não são o mesmo problema. Um precisa ser rastreável o suficiente para que seja reconciliado com um saldo do cliente. O outro precisa permanecer privado o bastante para que ninguém fora da transação consiga nem sequer ver que ela aconteceu. Forçar ambos dentro de um único modelo de privacidade significa que você quebra a reconciliação ou quebra a confidencialidade — não existe uma versão de “uma única configuração” que sirva corretamente para os dois.

A Dusk não escolhe um lado. Ela disponibiliza dois modelos de transação na mesma base DuskDS e deixa o fluxo de trabalho decidir qual deles precisa.

Moonlight é o modelo de conta transparente — saldos e transferências permanecem visíveis, o que é exatamente o que uma exchange quer quando precisa combinar depósitos recebidos com o cliente certo, sem adivinhações.

Phoenix vai na direção oposta: transações protegidas, provas de conhecimento zero, detalhes da transação ocultos por padrão, com divulgação disponível apenas para quem for realmente autorizado a vê-los.

Aqui está a parte que é fácil de esquecer: isto não é só “criamos duas funcionalidades”. Escolher Phoenix traz um peso operacional real — uma configuração de custódia diferente, um modelo de varredura diferente — e é exatamente por isso que a própria orientação de integração da Dusk para exchanges aponta para o Moonlight como opção para depósitos. Privacidade não é grátis, e fingir o contrário é como projetos acabam com um modelo que parece privado no papel e se torna inviável em produção.

Então a tese real não é “tornar as finanças privadas”. É mais específica e útil: permitir que o fluxo de trabalho escolha sua própria visibilidade, em vez de forçar cada transação na rede a viver sob a mesma regra.

$ACE $HEMI
Verificado
#dusk $DUSK @Dusk_Foundation ......... Pergunte a dez pessoas o que uma obrigação tokenizada realmente lhes dá. Nove vão dizer “a obrigação”. Estão errados — e grande parte do setor de RWA foi construída silenciosamente sobre esse erro. Tokenização, por definição, significa emitir um token que representa um ativo. Não o ativo. Uma reivindicação sobre ele. A obrigação real ainda fica fora da cadeia, em um registro que você nunca verá, sob um custodiante que você nunca vai conhecer — e o único trabalho do seu token é continuar concordando com essa papelada, para sempre, sem nunca se tornar ela. Isso não é ponto miúdo. É todo o modelo de risco....... Cada transferência, cada cupom, cada ação corporativa precisa ser espelhada entre dois sistemas — um na cadeia e outro não. A conciliação não é ruído de fundo aqui; é a parede que sustenta o peso. Deixe escapar — uma atualização atrasada, uma entrada de registro contestada — e o que você tem em mãos, silenciosamente, deixa de coincidir com o que deveria representar. Você normalmente descobre no pior momento: o resgate...... Emissão nativa não corrige essa lacuna; ela remove justamente aquilo que estava em risco de criar uma divergência. Quando um ativo é criado, transferido, atendido e liquidado diretamente na cadeia — sem um “wrapper” sintético servindo como uma versão guardada em outro lugar — não sobra uma segunda cópia da verdade para discordar. O ledger deixa de acompanhar o ativo. Ele passa a ser sua única casa..... É isso que o @dusk foi construído para fazer. O DuskDS lida com uma liquidação determinística, nativa da cadeia. O DuskEVM permite que os criadores desenhem controle de acesso e divulgação seletiva no núcleo de um ativo, não acoplados depois. Os destaques sobre RWA adoram citar bilhões “tokenizados”. Poucos perguntam quantos desses bilhões ainda dependem de um pedaço de papel em algum lugar concordando em continuar sincronizado. $ACE $ALICE
#dusk $DUSK @Dusk ......... Pergunte a dez pessoas o que uma obrigação tokenizada realmente lhes dá. Nove vão dizer “a obrigação”. Estão errados — e grande parte do setor de RWA foi construída silenciosamente sobre esse erro.

Tokenização, por definição, significa emitir um token que representa um ativo. Não o ativo. Uma reivindicação sobre ele. A obrigação real ainda fica fora da cadeia, em um registro que você nunca verá, sob um custodiante que você nunca vai conhecer — e o único trabalho do seu token é continuar concordando com essa papelada, para sempre, sem nunca se tornar ela.

Isso não é ponto miúdo. É todo o modelo de risco.......

Cada transferência, cada cupom, cada ação corporativa precisa ser espelhada entre dois sistemas — um na cadeia e outro não.

A conciliação não é ruído de fundo aqui; é a parede que sustenta o peso.

Deixe escapar — uma atualização atrasada, uma entrada de registro contestada — e o que você tem em mãos, silenciosamente, deixa de coincidir com o que deveria representar. Você normalmente descobre no pior momento: o resgate......

Emissão nativa não corrige essa lacuna; ela remove justamente aquilo que estava em risco de criar uma divergência. Quando um ativo é criado, transferido, atendido e liquidado diretamente na cadeia — sem um “wrapper” sintético servindo como uma versão guardada em outro lugar — não sobra uma segunda cópia da verdade para discordar. O ledger deixa de acompanhar o ativo.

Ele passa a ser sua única casa.....

É isso que o @dusk foi construído para fazer. O DuskDS lida com uma liquidação determinística, nativa da cadeia. O DuskEVM permite que os criadores desenhem controle de acesso e divulgação seletiva no núcleo de um ativo, não acoplados depois.

Os destaques sobre RWA adoram citar bilhões “tokenizados”. Poucos perguntam quantos desses bilhões ainda dependem de um pedaço de papel em algum lugar concordando em continuar sincronizado.

$ACE $ALICE
Verificado
#dusk $DUSK ......Uma bolsa de valores regulada de 200M€+ está migrando para a blockchain — e DOIS produtos da Chainlink estão resolvendo dois problemas que a maioria das pessoas completamente ignorou. É isso que a manchete deixa de fora... Quando @Dusk_Foundation e NPEX anunciaram sua integração com a Chainlink, a maioria das pessoas viu apenas uma história: “Parceria Chainlink”. Mas colocar uma bolsa regulada on-chain não é apenas um problema. São dois..... Problema um: os dados de mercado oficiais realmente existem na blockchain? É aí que entra o DataLink. O DataLink atua como o oráculo on-chain dos dados oficiais da bolsa da NPEX, permitindo que informações financeiras verificadas cheguem a contratos inteligentes. Essa distinção importa. A Dusk e a NPEX não estão simplesmente consumindo um feed genérico de preços de terceiros. Os próprios dados de mercado da bolsa ficam disponíveis como informação on-chain verificada. Problema dois: esses dados são rápidos o suficiente para serem usados na negociação? Estar on-chain não torna os dados automaticamente em tempo real. Modelos tradicionais de oráculo podem depender de intervalos de atualização ou de limites pré-definidos. Para mercados financeiros ativos, isso pode virar uma limitação séria. O Data Streams aborda isso de forma diferente, com um modelo baseado em pull, projetado para dados de baixa latência e alta frequência, que podem ser solicitados quando necessário e verificados criptograficamente. Então a arquitetura fica surpreendentemente simples: Primeiro, publique a “verdade” do mercado on-chain. Depois, garanta que essa verdade seja rápida o bastante para agir. Erre a primeira, e o mercado não tem dados confiáveis. Erre a segunda, e pode haver dados reais que chegam tarde demais para serem úteis. Por isso, acho que a parte interessante da história Dusk × NPEX × Chainlink não é a chamada de parceria. É a infraestrutura por baixo disso. Porque trazer um mercado regulado para a blockchain significa resolver os detalhes “chatos” que, na prática, fazem o mercado funcionar. {future}(DUSKUSDT) $AKE {future}(AKEUSDT) $SYN
#dusk $DUSK ......Uma bolsa de valores regulada de 200M€+ está migrando para a blockchain — e DOIS produtos da Chainlink estão resolvendo dois problemas que a maioria das pessoas completamente ignorou.

É isso que a manchete deixa de fora...

Quando @Dusk e NPEX anunciaram sua integração com a Chainlink, a maioria das pessoas viu apenas uma história: “Parceria Chainlink”.

Mas colocar uma bolsa regulada on-chain não é apenas um problema.

São dois.....

Problema um: os dados de mercado oficiais realmente existem na blockchain?

É aí que entra o DataLink.

O DataLink atua como o oráculo on-chain dos dados oficiais da bolsa da NPEX, permitindo que informações financeiras verificadas cheguem a contratos inteligentes.

Essa distinção importa.

A Dusk e a NPEX não estão simplesmente consumindo um feed genérico de preços de terceiros. Os próprios dados de mercado da bolsa ficam disponíveis como informação on-chain verificada.

Problema dois: esses dados são rápidos o suficiente para serem usados na negociação?

Estar on-chain não torna os dados automaticamente em tempo real.

Modelos tradicionais de oráculo podem depender de intervalos de atualização ou de limites pré-definidos. Para mercados financeiros ativos, isso pode virar uma limitação séria.

O Data Streams aborda isso de forma diferente, com um modelo baseado em pull, projetado para dados de baixa latência e alta frequência, que podem ser solicitados quando necessário e verificados criptograficamente.

Então a arquitetura fica surpreendentemente simples:

Primeiro, publique a “verdade” do mercado on-chain.

Depois, garanta que essa verdade seja rápida o bastante para agir.

Erre a primeira, e o mercado não tem dados confiáveis.

Erre a segunda, e pode haver dados reais que chegam tarde demais para serem úteis.

Por isso, acho que a parte interessante da história Dusk × NPEX × Chainlink não é a chamada de parceria.

É a infraestrutura por baixo disso.

Porque trazer um mercado regulado para a blockchain significa resolver os detalhes “chatos” que, na prática, fazem o mercado funcionar.

$AKE
$SYN
#dusk $DUSK Na maioria das blockchains, a pergunta é: “Como adicionamos privacidade?” A Dusk fez uma pergunta mais difícil: “E se títulos regulados e aplicações EVM precisarem de tipos completamente diferentes de privacidade?” Essa pergunta explica por que @dusk construiu dois motores de privacidade em vez de apenas um. O Zedger foi projetado para o ambiente nativo de ativos financeiros da Dusk. O seu modelo híbrido UTXO/conta e o Sparse Merkle-Segment Trie permitem registrar mudanças privadas de saldo enquanto expõe apenas o que a rede precisa para verificar. Isso o torna relevante para Confidential Security Contracts, em que distribuições de dividendos, resgates compatíveis e liquidação precisam funcionar sem expor cada detalhe sensível. Mas o DuskEVM muda as regras. Aplicações Solidity padrão operam em um ambiente baseado em contas; portanto, a Dusk precisava de um sistema de privacidade desenhado para esse mundo. O Hedger usa criptografia homomórfica e provas de zero conhecimento para levar saldos e fluxos confidenciais para aplicações EVM, mantendo as ferramentas familiares do ecossistema Ethereum. A parte interessante não é apenas que a Dusk tem duas tecnologias de privacidade. É que a arquitetura aceita algo que muitas redes tentam evitar admitir: privacidade é específica para cada tipo de carga de trabalho. Um título regulado tem requisitos diferentes dos de uma aplicação Solidity. A elegibilidade do investidor, o ciclo de vida da segurança e a liquidação compatível não são o mesmo problema de uma execução EVM confidencial. Assim, o Zedger e o Hedger compartilham o mesmo destino, mas seguem por rotas técnicas diferentes. O compromisso também é óbvio: dois sistemas especializados podem oferecer um encaixe melhor, mas também introduzem mais complexidade arquitetural. Para finanças on-chain reguladas, a especialização é a abordagem mais inteligente, ou a privacidade eventualmente deve se tornar uma camada universal única? @Dusk_Foundation $AVAAI $BANK
#dusk $DUSK Na maioria das blockchains, a pergunta é: “Como adicionamos privacidade?”

A Dusk fez uma pergunta mais difícil:

“E se títulos regulados e aplicações EVM precisarem de tipos completamente diferentes de privacidade?”

Essa pergunta explica por que @dusk construiu dois motores de privacidade em vez de apenas um.

O Zedger foi projetado para o ambiente nativo de ativos financeiros da Dusk. O seu modelo híbrido UTXO/conta e o Sparse Merkle-Segment Trie permitem registrar mudanças privadas de saldo enquanto expõe apenas o que a rede precisa para verificar. Isso o torna relevante para Confidential Security Contracts, em que distribuições de dividendos, resgates compatíveis e liquidação precisam funcionar sem expor cada detalhe sensível.

Mas o DuskEVM muda as regras.

Aplicações Solidity padrão operam em um ambiente baseado em contas; portanto, a Dusk precisava de um sistema de privacidade desenhado para esse mundo. O Hedger usa criptografia homomórfica e provas de zero conhecimento para levar saldos e fluxos confidenciais para aplicações EVM, mantendo as ferramentas familiares do ecossistema Ethereum.

A parte interessante não é apenas que a Dusk tem duas tecnologias de privacidade.

É que a arquitetura aceita algo que muitas redes tentam evitar admitir:

privacidade é específica para cada tipo de carga de trabalho.

Um título regulado tem requisitos diferentes dos de uma aplicação Solidity. A elegibilidade do investidor, o ciclo de vida da segurança e a liquidação compatível não são o mesmo problema de uma execução EVM confidencial.

Assim, o Zedger e o Hedger compartilham o mesmo destino, mas seguem por rotas técnicas diferentes.

O compromisso também é óbvio: dois sistemas especializados podem oferecer um encaixe melhor, mas também introduzem mais complexidade arquitetural.

Para finanças on-chain reguladas, a especialização é a abordagem mais inteligente, ou a privacidade eventualmente deve se tornar uma camada universal única?

@Dusk $AVAAI $BANK
Há uma sensação que eu conheço muito bem no mundo cripto. Você abre uma plataforma esperando ver mais atividade porque o mercado tem se mexido, mas então percebe que as suas próprias operações estão ficando menores e menos frequentes. Isso faz você se perguntar: o mercado está ficando realmente mais silencioso, ou eu é que estou sentindo isso? 👀 eToro’s números mais recentes me deram uma sensação parecida. O negócio de trading de cripto da plataforma gerou uma perda de US$ 7,2M no 2T de 2026, ante um lucro de US$ 37,7M no mesmo trimestre do ano passado. 😟 A receita de criptoativos também caiu para US$ 1,35B, abaixo dos US$ 1,91B de um ano antes. Mas o número que realmente chamou minha atenção foi a atividade. a eToro reportou apenas 1,4M de operações em cripto em julho, uma queda enorme de 73% em relação ao ano anterior. E a operação média em cripto caiu 50%, para US$ 182. Isso é uma mudança bem grande. O que torna isso interessante é que a própria eToro não necessariamente está passando por um trimestre geral ruim. Sua contribuição líquida total aumentou 9% para US$ 229M, as contas atingiram 4,28M e o EPS ajustado ficou em US$ 0,68, contra a estimativa de US$ 0,61 do analista. Então o problema parece ser bem mais específico: A atividade em cripto está esfriando, mesmo enquanto a plataforma mais ampla cresce. E é isso que explica por que o mercado reagiu tão negativamente. 📉😰 As ações da eToro caíram mais de 12% após os resultados, apesar de a empresa ter superado as expectativas de lucro. Ao mesmo tempo, a eToro ainda está construindo para o futuro das criptos, incluindo futuros perpétuos onchain e novo poder de compra em cripto. Então eu não leio isso como “cripto está morto”. Eu leio como um alerta de que as plataformas de cripto ainda precisam de atividade real de usuários — e não apenas alta nos preços das moedas — para gerar uma receita de negócios sustentável. Um mercado em alta pode fazer todo mundo parecer ocupado. O teste de verdade vem quando os traders começam a desacelerar. Você acha que isso é só um resfriamento temporário na atividade cripto, ou as plataformas estão começando a enfrentar uma mudança mais profunda na forma como as pessoas negociam? 🤔 $RAD $COOKIE $LUNA
Há uma sensação que eu conheço muito bem no mundo cripto.

Você abre uma plataforma esperando ver mais atividade porque o mercado tem se mexido, mas então percebe que as suas próprias operações estão ficando menores e menos frequentes.

Isso faz você se perguntar: o mercado está ficando realmente mais silencioso, ou eu é que estou sentindo isso? 👀

eToro’s números mais recentes me deram uma sensação parecida.

O negócio de trading de cripto da plataforma gerou uma perda de US$ 7,2M no 2T de 2026, ante um lucro de US$ 37,7M no mesmo trimestre do ano passado. 😟

A receita de criptoativos também caiu para US$ 1,35B, abaixo dos US$ 1,91B de um ano antes.

Mas o número que realmente chamou minha atenção foi a atividade.

a eToro reportou apenas 1,4M de operações em cripto em julho, uma queda enorme de 73% em relação ao ano anterior.

E a operação média em cripto caiu 50%, para US$ 182.

Isso é uma mudança bem grande.

O que torna isso interessante é que a própria eToro não necessariamente está passando por um trimestre geral ruim.

Sua contribuição líquida total aumentou 9% para US$ 229M, as contas atingiram 4,28M e o EPS ajustado ficou em US$ 0,68, contra a estimativa de US$ 0,61 do analista.

Então o problema parece ser bem mais específico:

A atividade em cripto está esfriando, mesmo enquanto a plataforma mais ampla cresce.
E é isso que explica por que o mercado reagiu tão negativamente. 📉😰

As ações da eToro caíram mais de 12% após os resultados, apesar de a empresa ter superado as expectativas de lucro.

Ao mesmo tempo, a eToro ainda está construindo para o futuro das criptos, incluindo futuros perpétuos onchain e novo poder de compra em cripto.

Então eu não leio isso como “cripto está morto”.

Eu leio como um alerta de que as plataformas de cripto ainda precisam de atividade real de usuários — e não apenas alta nos preços das moedas — para gerar uma receita de negócios sustentável.

Um mercado em alta pode fazer todo mundo parecer ocupado.

O teste de verdade vem quando os traders começam a desacelerar.

Você acha que isso é só um resfriamento temporário na atividade cripto, ou as plataformas estão começando a enfrentar uma mudança mais profunda na forma como as pessoas negociam? 🤔

$RAD $COOKIE $LUNA
Algumas vezes, abri um gráfico de Bitcoin depois de ver um título assustador e imediatamente comecei a procurar o nível sobre o qual todo mundo estava falando. Hoje foi US$ 20.000. Esse número assusta quando você o vê ligado ao Bitcoin — especialmente depois de acompanhar o BTC construindo tanto valor ao longo dos anos. 😰📉 Mas, depois de analisar melhor o argumento do analista, acho que a pergunta mais interessante não é “O Bitcoin vai cair para US$ 20K?”. É o que seria necessário para que esse cenário se tornasse realista? Alessio Rastani espera que o Bitcoin ainda possa disparar nos próximos 3–6 meses antes de entrar em um mercado de baixa muito maior em 2027. O ponto principal do aviso dele é US$ 57K. Se o BTC perder esse nível, ele acredita que a próxima grande área pode ficar por volta de US$ 47K–US$ 49K. A partir daí, a meta baixista de longo prazo dele fica em cerca de US$ 20K–US$ 25K até o fim de 2027. E, sinceramente, é aqui que eu fico desconfortável. 😟 Porque a previsão não se baseia em um único dia ruim ou em um único evento de liquidação. Ela vem de uma interpretação mais ampla de Ondas de Elliott, sugerindo que o Bitcoin pode ter concluído um grande avanço de cinco ondas ao atingir cerca de US$ 126K. Mas existe uma contradição interessante. O mesmo analista que prevê um possível Bitcoin de US$ 20K também acredita que o BTC pode eventualmente chegar a US$ 1 milhão. Só não imediatamente. A visão dele é que o Bitcoin talvez precise de outra correção profunda primeiro — potencialmente até abaixo de US$ 20K — antes de começar outra expansão de longo prazo. Isso me fez pensar em como é fácil confundir metas de preço com certeza. US$ 20K não é garantido. US$ 1M também não é garantido. O sinal real que eu observaria é muito mais simples: O Bitcoin mantém US$ 57K, ou perde isso? Se US$ 57K se mantiver, a tese baixista de US$ 20K fica muito mais difícil de defender no curto prazo. Se ele romper de forma decisiva, então eu paro de rir das metas assustadoras e começo a prestar atenção de verdade. 👀 Você ainda manteria Bitcoin durante uma possível queda de 50–70% se, de fato, acreditasse que US$ 1M pode acontecer anos depois? #BTCat20k #BTC #crash #bearishmomentum $BTC $SOL $DOGE
Algumas vezes, abri um gráfico de Bitcoin depois de ver um título assustador e imediatamente comecei a procurar o nível sobre o qual todo mundo estava falando.

Hoje foi US$ 20.000.

Esse número assusta quando você o vê ligado ao Bitcoin — especialmente depois de acompanhar o BTC construindo tanto valor ao longo dos anos. 😰📉

Mas, depois de analisar melhor o argumento do analista, acho que a pergunta mais interessante não é “O Bitcoin vai cair para US$ 20K?”.

É o que seria necessário para que esse cenário se tornasse realista?

Alessio Rastani espera que o Bitcoin ainda possa disparar nos próximos 3–6 meses antes de entrar em um mercado de baixa muito maior em 2027.

O ponto principal do aviso dele é US$ 57K.

Se o BTC perder esse nível, ele acredita que a próxima grande área pode ficar por volta de US$ 47K–US$ 49K. A partir daí, a meta baixista de longo prazo dele fica em cerca de US$ 20K–US$ 25K até o fim de 2027.

E, sinceramente, é aqui que eu fico desconfortável. 😟

Porque a previsão não se baseia em um único dia ruim ou em um único evento de liquidação. Ela vem de uma interpretação mais ampla de Ondas de Elliott, sugerindo que o Bitcoin pode ter concluído um grande avanço de cinco ondas ao atingir cerca de US$ 126K.

Mas existe uma contradição interessante.

O mesmo analista que prevê um possível Bitcoin de US$ 20K também acredita que o BTC pode eventualmente chegar a US$ 1 milhão.

Só não imediatamente.

A visão dele é que o Bitcoin talvez precise de outra correção profunda primeiro — potencialmente até abaixo de US$ 20K — antes de começar outra expansão de longo prazo.

Isso me fez pensar em como é fácil confundir metas de preço com certeza.

US$ 20K não é garantido.

US$ 1M também não é garantido.

O sinal real que eu observaria é muito mais simples:

O Bitcoin mantém US$ 57K, ou perde isso?

Se US$ 57K se mantiver, a tese baixista de US$ 20K fica muito mais difícil de defender no curto prazo.

Se ele romper de forma decisiva, então eu paro de rir das metas assustadoras e começo a prestar atenção de verdade. 👀

Você ainda manteria Bitcoin durante uma possível queda de 50–70% se, de fato, acreditasse que US$ 1M pode acontecer anos depois?

#BTCat20k #BTC #crash #bearishmomentum $BTC $SOL $DOGE
Há alguns dias, eu estava verificando quanta eletricidade uma determinada estrutura realmente estava consumindo, e uma coisa ficou evidente muito rapidamente. O hardware não era o maior problema. Manter tudo ligado era. Esse pequeno cálculo ficou na minha cabeça quando vi o que a Keel, antes Bitfarms, acabou de fazer. A Keel desligou todas as suas operações de mineração de Bitcoin nos EUA e agora está preparando esses locais para data centers de IA e de computação de alto desempenho. No começo, pareceu mais uma empresa apenas correndo atrás da “febre” de IA. Mas aí eu olhei para a parte econômica por trás. A concorrência real não é necessariamente Bitcoin vs. IA. É mineração de Bitcoin vs. IA pelo mesmo recurso escasso: energia. O CEO da Keel colocou isso de forma bem direta: “A energia é a restrição.” A empresa diz que seus sites estão agora se aproximando do licenciamento total, com potenciais locatários de IA/HPC já negociando capacidade. E isso não é só uma manchete estratégica. A Keel vendeu 1.085 BTC por cerca de US$ 75 milhões entre 1º de abril e 7 de agosto, deixando 1.861 BTC na sua reserva. Então, embora o Bitcoin esteja sendo negociado por volta de US$ 64 mil e os traders observem se US$ 68 mil–US$ 70 mil finalmente conseguem romper, parte do setor de mineração está fazendo um cálculo completamente diferente. Onde a próxima unidade de eletricidade gera o melhor retorno? É essa a parte que acho mais interessante do que o gráfico de curto prazo. O Bitcoin ainda pode ter forte demanda, e a IA ainda pode enfrentar seus próprios riscos. Mas quando as empresas começam a direcionar infraestrutura real de mineração para a IA porque a economia de energia parece mais atraente, isso é um sinal estrutural que vale acompanhar. Talvez a próxima grande história da mineração de Bitcoin não seja sobre quanto os mineradores de BTC conseguem produzir. Talvez seja sobre se eles ainda querem usar sua energia para produzi-lo. Você acha que a IA está se tornando uma concorrente genuína para o consumo de energia da mineração de Bitcoin? #AI #BTC #BTCMiningPeak $BTC $ETH
Há alguns dias, eu estava verificando quanta eletricidade uma determinada estrutura realmente estava consumindo, e uma coisa ficou evidente muito rapidamente.

O hardware não era o maior problema.

Manter tudo ligado era.

Esse pequeno cálculo ficou na minha cabeça quando vi o que a Keel, antes Bitfarms, acabou de fazer.

A Keel desligou todas as suas operações de mineração de Bitcoin nos EUA e agora está preparando esses locais para data centers de IA e de computação de alto desempenho.

No começo, pareceu mais uma empresa apenas correndo atrás da “febre” de IA.

Mas aí eu olhei para a parte econômica por trás.

A concorrência real não é necessariamente Bitcoin vs. IA.

É mineração de Bitcoin vs. IA pelo mesmo recurso escasso: energia.

O CEO da Keel colocou isso de forma bem direta: “A energia é a restrição.” A empresa diz que seus sites estão agora se aproximando do licenciamento total, com potenciais locatários de IA/HPC já negociando capacidade.

E isso não é só uma manchete estratégica.

A Keel vendeu 1.085 BTC por cerca de US$ 75 milhões entre 1º de abril e 7 de agosto, deixando 1.861 BTC na sua reserva.

Então, embora o Bitcoin esteja sendo negociado por volta de US$ 64 mil e os traders observem se US$ 68 mil–US$ 70 mil finalmente conseguem romper, parte do setor de mineração está fazendo um cálculo completamente diferente.

Onde a próxima unidade de eletricidade gera o melhor retorno?

É essa a parte que acho mais interessante do que o gráfico de curto prazo.

O Bitcoin ainda pode ter forte demanda, e a IA ainda pode enfrentar seus próprios riscos. Mas quando as empresas começam a direcionar infraestrutura real de mineração para a IA porque a economia de energia parece mais atraente, isso é um sinal estrutural que vale acompanhar.

Talvez a próxima grande história da mineração de Bitcoin não seja sobre quanto os mineradores de BTC conseguem produzir.

Talvez seja sobre se eles ainda querem usar sua energia para produzi-lo.

Você acha que a IA está se tornando uma concorrente genuína para o consumo de energia da mineração de Bitcoin?

#AI #BTC #BTCMiningPeak $BTC $ETH
Algumas vezes, cometi o erro de olhar para o Bitcoin apenas depois de um grande movimento. O preço sobe, todo mundo começa a falar sobre o próximo alvo, e fica muito fácil ignorar o que está acontecendo por baixo do gráfico. É por isso que o BTC perto de US$ 64K chamou minha atenção hoje. A primeira coisa que estou observando é a zona de US$ 68K–US$ 70K. Se o Bitcoin conseguir retomar essa área com força real, a recuperação atual começa a parecer mais convincente. Mas abaixo, US$ 61K ainda é importante. Perder esse nível pode trazer de volta para o foco US$ 57K, US$ 53K e possivelmente níveis ainda mais baixos. O que torna esse cenário mais interessante é o leverage. Cerca de US$ 113M em posições vendidas (short) em Bitcoin foram liquidadas nas últimas 24 horas, enquanto as liquidações totais de cripto ultrapassaram US$ 160M. Aprendi que esses números de liquidação podem fazer um movimento parecer mais forte do que realmente é. Compras forçadas podem empurrar o preço para cima rapidamente, mas isso não significa automaticamente que a demanda subjacente tenha mudado. Há outro sinal que eu também não ignoraria. Os ETPs de spot tiveram saídas líquidas em partes de maio e junho, enquanto as opções mostraram aumento na demanda por proteção contra queda. Então, mesmo com o BTC perto de US$ 64K, o mercado não está exatamente se comportando como se todos estivessem confortáveis com o lado positivo. Depois, existem questões de longo prazo: baixa sinalização de mineradores em torno do BIP-110 e a crescente conversa sobre ameaças quânticas à criptografia do Bitcoin. Para mim, isso torna o mercado atual menos sobre prever o próximo candle e mais sobre observar se o Bitcoin consegue construir uma força genuína sem depender demais do leverage. US$ 64K é interessante. Mas a reação em torno de US$ 70K pode nos dizer muito mais. No que você está observando com mais atenção agora: a ruptura acima de US$ 70K ou o suporte em US$ 61K? $BTC #BTC
Algumas vezes, cometi o erro de olhar para o Bitcoin apenas depois de um grande movimento.

O preço sobe, todo mundo começa a falar sobre o próximo alvo, e fica muito fácil ignorar o que está acontecendo por baixo do gráfico.
É por isso que o BTC perto de US$ 64K chamou minha atenção hoje.

A primeira coisa que estou observando é a zona de US$ 68K–US$ 70K. Se o Bitcoin conseguir retomar essa área com força real, a recuperação atual começa a parecer mais convincente. Mas abaixo, US$ 61K ainda é importante. Perder esse nível pode trazer de volta para o foco US$ 57K, US$ 53K e possivelmente níveis ainda mais baixos.

O que torna esse cenário mais interessante é o leverage.

Cerca de US$ 113M em posições vendidas (short) em Bitcoin foram liquidadas nas últimas 24 horas, enquanto as liquidações totais de cripto ultrapassaram US$ 160M. Aprendi que esses números de liquidação podem fazer um movimento parecer mais forte do que realmente é. Compras forçadas podem empurrar o preço para cima rapidamente, mas isso não significa automaticamente que a demanda subjacente tenha mudado.

Há outro sinal que eu também não ignoraria.

Os ETPs de spot tiveram saídas líquidas em partes de maio e junho, enquanto as opções mostraram aumento na demanda por proteção contra queda. Então, mesmo com o BTC perto de US$ 64K, o mercado não está exatamente se comportando como se todos estivessem confortáveis com o lado positivo.

Depois, existem questões de longo prazo: baixa sinalização de mineradores em torno do BIP-110 e a crescente conversa sobre ameaças quânticas à criptografia do Bitcoin.
Para mim, isso torna o mercado atual menos sobre prever o próximo candle e mais sobre observar se o Bitcoin consegue construir uma força genuína sem depender demais do leverage.

US$ 64K é interessante.

Mas a reação em torno de US$ 70K pode nos dizer muito mais.

No que você está observando com mais atenção agora: a ruptura acima de US$ 70K ou o suporte em US$ 61K?
$BTC #BTC
Inicia sessão para explorar mais conteúdos
Junta-te a utilizadores de criptomoedas de todo o mundo na Binance Square
⚡️ Obtém informações úteis e recentes sobre criptomoedas.
💬 Com a confiança da maior exchange de criptomoedas do mundo.
👍 Descobre perspetivas reais de criadores verificados.
E-mail/Número de telefone
Mapa do sítio
Preferências de cookies
Termos e Condições da Plataforma