Eman098

ENA acabou de ter um movimento monstruoso, subindo 25% para 0.1854, rebatendo forte a partir da mínima de 0.1349 de alguns dias atrás. Isso é uma reversão em “V” clássica após uma tendência de queda prolongada.

O volume, porém, conta a história de verdade: aquela enorme barra verde bem na hora em que o preço rompeu confirma que não foi um falso rompimento — houve compra real. O RSI(6) em 87 está gritando sobrecompra no curto prazo; o RSI(14) em 74 também reforça isso, então uma correção ou consolidação aqui não seria nada surpreendente. O MACD acabou de cruzar para o lado bullish e o histograma está virando verde, o que dá suporte ao movimento, mas ainda é recente, não maduro.

Sinceramente, isso parece uma forte ruptura por impulso que está a caminho de uma pausa. Perseguir agora em 0.1854 é arriscado; esperar por uma retração em direção a 0.165 0.170 para entrar parece mais inteligente do que comprar o topo desta vela.
$ENA

#dusk $DUSK @Dusk
O que chamou minha atenção ao analisar a documentação do Dusk: existem apenas dois contratos. No genesis, o contrato de stake e o contrato de transferência. Todo o resto — incluindo o DuskVM e o DuskEVM — fica por cima deles.

Isso é uma quantidade estranha de concentração para uma cadeia criada para liquidar ativos regulados. Então quis verificar o que exatamente esses dois fazem e se eles podem ser alterados depois.

O contrato de stake acompanha os provisioners: quanto cada um tem em stake, quando as recompensas amadurecem e quando ocorre slashing. O contrato de transferência lida tanto com saldos públicos (Moonlight) quanto com saldos protegidos (Phoenix) e é o único lugar em que o movimento de fundos entre contratos realmente acontece. Cada ambiente de execução o utiliza para liquidação e disponibilidade de dados, conforme a documentação atual.

Por que isso importa: se você está construindo sobre o DuskEVM ou emitindo ativos via Dusk Trade, você não está apenas confiando na lógica do seu próprio contrato. Você está confiando que esses dois contratos do genesis se comportam corretamente indefinidamente, já que eles são a base de liquidação por baixo de tudo o que existe.

Aqui está o que eu não consegui esclarecer. A documentação descreve que esses contratos foram refatorados ao longo do tempo: o contrato de staking foi reconstruído para corrigir um problema de armazenamento e, depois, atualizações de engenharia alteraram sua estrutura de eventos. Então eles claramente não estão congelados no sentido imutável do genesis.

O que não está claro para mim é o caminho de atualização: é discricionário (a equipe do protocolo envia uma atualização de rede) ou existe uma etapa formal de governança on-chain em que os provisioners votam antes que a lógica do contrato do genesis seja alterada? As docs que encontrei descrevem o que os contratos fazem, não como as modificações neles recebem autorização.

Para uma cadeia que se posiciona para liquidação institucional, essa distinção entre atualização autorizada pela equipe vs. atualização ratificada pelos provisioners parece algo que deveria ser documentado explicitamente em algum lugar.

Alguém viu onde @Dusk especifica o processo real de autorização para mudanças nos contratos do genesis?

$DUSK #dusk

#dusk $DUSK @Dusk
O que me chamou a atenção não foi a mensagem de conformidade da Dusk, e sim o que uma empresa de auditoria independente encontrou dentro do Dusk plonk: o sistema de provas que protege o modelo de transação com valores ocultos (shielded) do @Dusk na DuskDS.

O mecanismo: a Phoenix usa provas PLONK para que um gasto possa ser verificado sem revelar saldos. O verificador deve checar um lote de compromissos (commitments) de polinômios contra uma chave verificada (trusted verifier key) antes de aceitar qualquer prova como válida.

A parte que eu quis confirmar: de acordo com um relatório de uma firma de segurança, quatro dessas avaliações de seletor nunca foram de fato verificadas em relação aos seus commitments. O verificador as consumiu sem validá-las. Em teoria, essa lacuna poderia permitir que uma prova forjada passasse como legítima.

Por que isso importa: isso fica diretamente abaixo do pool shielded de onde os fluxos regulados de ativos deveriam herdar privacidade. Uma prova forjada em um sistema de notas opaco é difícil de detectar depois — esse é justamente o objetivo do shield.

O detalhe que a maioria das pessoas deixaria passar: a correção foi implementada no meio de fevereiro de 2026, antes da divulgação pública em abril, então foi corrigido sem ser explorado, com base no que foi publicado. O que não está claro para mim é se isso foi identificado na revisão interna da Dusk ou por uma parte externa primeiro, e como esse cronograma foi comunicado aos parceiros que dependem dessa camada.

"Audited" (auditado) significa muito se a correção antecede a divulgação em dois meses?

$DUSK #dusk

#dusk $DUSK @Dusk
O que chamou minha atenção sobre a NPEX não foi o valor de €300M em si; foi o fato de que a NPEX já possui uma licença de MTF, uma licença de corretora e uma licença de ECSP sob as regras holandesas/da UE, e a Dusk está construindo diretamente em cima dessa pilha regulatória existente — em vez de pedir aos reguladores um novo arcabouço específico para cripto. Então, a parte que eu queria verificar era: como uma negociação onchain consegue manter conformidade com as regras de elegibilidade dos investidores de uma MTF sem que um gatekeeper centralizado verifique cada transação?

O mecanismo, conforme descrevem os documentos atuais, passa pela divulgação seletiva da Citadel.
Um investidor comprova um status específico de credenciamento de residência, conclusão de KYC como uma prova de conhecimento zero vinculada à sua carteira, sem expor o documento subjacente nem dados pessoais. A contraparte ou a lógica do protocolo verifica a prova, não os dados em si.

Por que isso importa especificamente para um ambiente regulado: a NPEX não pode, legalmente, permitir que qualquer pessoa negocie certos instrumentos. Historicamente, isso significava que um corretor centralizado verificava IDs antes de cada ordem. Aqui, a elegibilidade vira uma credencial criptográfica reutilizável em vez de uma checagem manual repetida — e é isso que torna o acordo instantâneo plausível para ativos regulados, e não apenas uma afirmação de marketing.

O que eu não consegui confirmar na documentação atual é como funciona, na prática, a revogação de credenciais: se o status de Elegibilidade de alguém muda (uma mudança de residência, uma sinalização de sanções), com que rapidez isso é propagado para carteiras que possuem provas emitidas sob o status antigo, e isso exige que o investidor reprove ou o emissor pode invalidar as provas unilateralmente?

Essa lacuna — a atualidade (freshness) de uma prova de divulgação em relação às expectativas em tempo real de um regulador — parece ser o teste real de se isso escala além de um único piloto de exchange. Qualquer pessoa que tenha olhado a especificação da Citadel sabe como a revogação é tratada atualmente?

$DUSK #dusk @Dusk

#dusk $DUSK @Dusk
O que chamou minha atenção não foi o lado de zero knowledge de Dusk que recebe a maior parte da atenção; foi um detalhe menor sobre como um bloco de fato se torna final.

Eu queria entender como a Succinct Attestation, o protocolo de consenso de proof-of-stake baseado em comitês permissionless da DuskDS, confirma uma transação na prática, já que “instant settlement” é jogado ao ar com alguma leveza neste espaço.

Cada rodada passa por três etapas: um proponente propõe e transmite um bloco candidato, um comitê o valida e um segundo comitê ratifica essa validação e finaliza o bloco. Só depois que ambos os comitês concordam é que o bloco segue adiante.

O interessante é que @Dusk não trata a finalidade como um evento binário. Um bloco é Aceito quando passa por todas as três etapas. É Confirmado uma vez que blocos posteriores se baseiam nele. É Estável quando está suficientemente enterrado e, finalmente, Final — determinístico e garantido criptograficamente, o que significa que ele não pode ser revertido.

Para liquidação regulada, essa distinção em etapas importa mais do que a velocidade bruta. Um custodiante não precisa apenas de uma transação rápida: ele precisa de um ponto definido em que a irreversibilidade possa ser provada, não apenas assumida.

O que eu gostaria que fosse esclarecido é o comportamento sob carga sustentada. Dois comitês separados concordando adiciona uma etapa de coordenação que cadeias de um único proponente evitam. À medida que o conjunto de proponentes e a distribuição de participação crescem, a ratificação continua rápida ou a própria coordenação do comitê vira o gargalo?

A documentação descreve as fases e a divisão de recompensas 70% para o proponente e 5%/5% para os comitês de validação e ratificação. O que ela não esclarece é um teto de throughput sob congestionamento real da rede — apenas comportamento de testnet.

Alguém já viu dados de seleção de comitê ou de tempo de finalidade do Dusk sob carga real sustentada de transações, e não apenas números de rede ociosa?

$DUSK #Dusk

#dusk $DUSK @Dusk
Tenho passado vai e volta entre dois documentos da Dusk que descrevem privacidade de maneiras completamente diferentes, e a lacuna entre eles é a história em si.

Zedger, o protocolo original de ativos regulamentados da Dusk, roda nativamente na DuskDS e é baseado em UTXO — o mesmo modelo de contabilização que o Bitcoin usa. l
extendido para conformidade. Hedger, seu sucessor, roda na DuskEVM e toma outro caminho: ele combina criptografia homomórfica (ElGamal sobre curvas elípticas) com provas de conhecimento zero sobre um modelo híbrido UTXO/conta.

O que chamou minha atenção foi o que essa combinação realmente compra. Com computações de HE acontecendo diretamente em saldos criptografados, ninguém precisa descriptografar um valor para adicioná-lo ou subtraí-lo. As provas ZK então verificam que a computação foi feita corretamente sem revelar as entradas. Saldos e valores de transferência permanecem criptografados de ponta a ponta, enquanto a rede ainda consegue confirmar que nada foi forjado.

A parte que eu queria verificar: isso custa algo a você em comparação com o Zedger? De acordo com os próprios materiais de @Dusk , sim — o modelo baseado em conta da EVM não consegue oferecer a anonimidade completa que uma camada UTXO como a do Zedger proporciona. Hedger te dá saldos confidenciais e auditabilidade, não anonimidade inlinkável.

Então o tradeoff é nOt privacidade vs. conformidade — é privacidade vs. superfície para desenvolvedores. O Zedger mantém uma anonimidade mais forte, mas continua nativo de UTXO. O Hedger sacrifica parte disso por ferramentas EVM prontas para uso.

O que eu ainda gostaria de saber: em um instrumento regulado que toca tanto o Zedger na DuskDS quanto o Hedger na DuskEVM, qual garantia de privacidade realmente governa na liquidação?

$DUSK #dusk

#dusk $DUSK @Dusk
Phoenix mantém provas de gasto duplo em uma árvore de Merkle de notas, em vez de um razão contábil de contas nAinda assim, nenhuma balança visível é exibida e, mesmo assim, ninguém consegue gastar a mesma saída duas vezes. Eu queria ver como isso realmente se sustenta.

Phoenix trata cada unidade de @Dusk como um UTXO chamado de nota. Cada nota vive como um hash dentro de uma árvore de Merkle. Gastar uma nota não a apaga — é assim que essas árvores funcionam. Em vez disso, ao gastá-la, é gerado um nullifier: um valor derivado da chave secreta da nota que aparece publicamente assim que ela é usada. A rede nunca aprende qual nota gerou o nullifier, apenas que ela agora é inválida. Tentar reutilizar a mesma nota e o nullifier duplicado a denuncia instantaneamente.

Esse é o motivo pelo qual Phoenix consegue permanecer protegida e ainda assim ser executável. Finanças reguladas não toleram liquidação ambígua, e nullifiers dão finalização determinística sem expor remetente, destinatário ou valor. Uma chave de visualização permite que o proprietário prove seletivamente o que uma nota continha, então a auditabilidade não é completamente sacrificada — ela é apenas adiada para o detentor da chave.

O que eu não consegui esclarecer totalmente na documentação: como o crescimento do conjunto de nullifiers é gerenciado a longo prazo e qual é o custo computacional de prova conforme a árvore de notas escala sob um volume institucional sustentado, em vez de cenários de teste.

Sinceramente curioso: alguém já viu números de throughput para geração de provas do Phoenix sob carga real de liquidação, e não apenas benchmarks de testnet?

$DUSK #dusk

#dusk $DUSK @Dusk

Eu mantenho dois perfis de navegador diferentes para trabalho e coisas pessoais — a mesma pessoa, mas as contas nunca se tocam. Algo semelhante está acontecendo por baixo dos panos na camada de privacidade do DuskEVM, e é um design mais estranho do que eu esperava.

O que chamou minha atenção ao ler a especificação do Hedger: um usuário @Dusk que opera neste sistema não tem um único endereço — ele tem dois. Um endereço EVM normal para chamadas de contrato comuns e um endereço separado do Hedger que mantém um saldo criptografado. A parte interessante é por que isso não é só para enfeite.

O mecanismo passo a passo: seu saldo do Hedger é criptografado usando ElGamal sobre curvas elípticas (um esquema homomórfico), para que a rede possa somar e subtrair valores criptografados sem nunca descriptografá-los. Quando você envia uma transferência privada, você anexa uma prova de conhecimento zero mostrando que a matemática confere — entradas batem com saídas, sem saldos negativos — sem revelar os números reais. A conformidade é tratada por meio de allowlisting (lista de permissões) em vez de transparência total, então um auditor pode receber acesso sem que a cadeia inteira veja tudo.

Por que isso importa: é um comprometimento genuinamente diferente do que a maioria dos setups de DeFi privado faz, que normalmente apenas oculta a transação, mas deixa você trabalhando dentro de uma única identidade. Separar a identidade pública de execução da identidade de saldo confidencial significa que uma aplicação pode se conectar às ferramentas EVM normais para lógica e apenas direcionar o lado do dinheiro pelo caminho criptografado.

O que eu não consegui resolver completamente com a documentação: como os dois endereços devem ser vinculados ou desvinculados na camada de UX — o binding acontece uma vez na configuração da carteira, por sessão ou por contrato?

Parece ser exatamente o detalhe que decide se isso parece “sem costura” ou como administrar duas contas separadas para sempre.

Alguém que realmente testou o Hedger na Sepolia: como esse vínculo funciona na prática?

$DUSK #dusk