林木森Woody

#币安夏令营 冲呀

Esta semana, ao rever a tokenomics de @Dusk , eu só me lembrava de “limite de 1 bilhão e redução pela metade a cada quatro anos”; seguindo a distribuição das recompensas, percebi que o produtor de blocos não leva toda a emissão de cada bloco. No ciclo inicial atual, conforme o plano, são emitidos cerca de 19.8574 DUSK por bloco, além das taxas de transação do bloco; o gerador do bloco recebe 70% como base, podendo somar até mais 10% conforme os credits no certificado, o fundo de desenvolvimento recebe 10%, o comitê de validação e o comitê de aprovação recebem 5% cada, e a parte não distribuída é queimada.

Esse desenho não tenta resolver apenas um APR isolado, e sim garantir que as três ações de consenso — proposta, validação e aprovação — gerem receita. O problema também muda com isso: se as taxas de transação on-chain forem muito baixas, o orçamento de segurança passa a depender principalmente da emissão contínua; se a qualidade da participação dos nós não for suficiente, as recompensas extras não são totalmente pagas e o novo suprimento real fica abaixo da curva nominal. Por isso, ao olhar $DUSK , não dá para simplesmente multiplicar “19.8574 por bloco” pelo número de blocos e tratar isso como uma produção fixa que todos conseguiriam receber.

O modelo de longo prazo divulgado oficialmente é: 500 milhões iniciais e, ao longo de cerca de 36 anos, a emissão de mais 500 milhões, com oferta máxima de 1 bilhão; a taxa de emissão por bloco é reduzida pela metade a cada quatro anos. O teto é claro, mas “ter um teto” não significa que não haja diluição no curto prazo; nos primeiros quatro anos, a emissão já é naturalmente a fase mais concentrada. Por outro lado, essa emissão inicial também está de fato comprando segurança para nós e comitês, e não deveria ser apagada com o rótulo de inflação apenas.

Quando olho para a oferta de #dusk , observo três coisas ao mesmo tempo: o que é realmente cunhado, a proporção de staking ativo e a participação das taxas de transação nas recompensas. Só quando taxas e uso real começarem a assumir gradualmente o orçamento de segurança da emissão é que o halving deixará de ser simplesmente um corte na renda dos nós. O que vocês acham mais importante: o limite máximo de oferta estar fixado, ou a rede conseguir continuar pagando o custo de segurança depois que a emissão cair?

Eu separei o comunicado de parceria entre @Dusk , NPEX e Chainlink e descobri que o que realmente vai ser colocado em prática não é apenas uma frase do tipo “RWA cross-chain”, e sim três tipos completamente diferentes de canais de dados e de ativos. O CCIP cuida das mensagens entre cadeias e do movimento de ativos; o CCT fornece para tokens como $DUSK um caminho controlado de burn/mint; o DataLink envia para a blockchain os dados oficiais da exchange da NPEX, e o Data Streams então processa atualizações de preço com menor latência.

Por que essa camada de dados é mais complicada do que “transformar uma obrigação em token”? Ativos regulados não podem apenas provar que uma certa quantidade existe dentro de um contrato. O mercado secundário precisa saber de onde vem o preço, se o emissor ainda tem controle, a quem pertencem as limitações de taxa e as permissões de upgrade em operações cross-chain, e como pausar dados anômalos. No comunicado, enfatiza-se que Dusk e NPEX mantêm a propriedade dos contratos de tokens e podem configurar rate limit e upgrade path. Isso é capacidade de controle para instituições — e também algo que usuários comuns precisam monitorar, em termos de permissões de governança.

Por um lado, vemos o lado positivo: a NPEX fornece um cenário real de emissão e negociação; a Chainlink completa a interoperabilidade e a porta de entrada para cotações oficiais; e o Dusk só tem chance de conectar emissão, negociação, liquidação e divulgação em uma única cadeia. Por outro, também fica claro: parceria, adoção de padrões e ativos realmente ativos são três coisas diferentes. Sem quantidades de emissão auditáveis, negociações, detentores e registros de resgate, qualquer “grande escala de on-chain pelas instituições” ainda é apenas fase de construção.

Então, a seguir, vou acompanhar #dusk . Não vou apenas contar logo de parceiros; vou aguardar três tipos de evidência: contratos reais de ativos, dados de mercado contínuos e fluxos de liquidação verificáveis. Vocês acham que o mais difícil no RWA é fazer os ativos atravessarem cadeias, ou garantir que o preço on-chain, os direitos legais e o resgate fora da cadeia permaneçam sempre alinhados?

Nesses dias, redesenhei os Core Components de @Dusk do zero, só então consegui separar corretamente os três nomes: DuskVM, DuskEVM e DuskDS. No começo, eu também achei que era apenas “uma cadeia compatível com dois tipos de máquinas virtuais”. Mas, na prática, o trabalho é mais como três camadas: o DuskDS cuida do consenso, da finalidade e da disponibilidade de dados; o DuskVM faz com que contratos Rust/WASM rodem diretamente na L1; e o DuskEVM é um ambiente de execução equivalente ao EVM baseado no OP Stack, deixando a finalização e a publicação de dados a cargo do DuskDS.

Isso significa que desenvolvedores não precisam escolher de forma cega entre uma e outra. Se você já tem contratos Solidity prontos, depende de carteiras e de toolchains do ecossistema EVM, seguir pelo DuskEVM tende a ser mais barato; mas se a ideia é mexer diretamente com ativos da L1, usar o modelo de privacidade do Phoenix, recursos de zero knowledge ou um controle ainda mais baixo nível do protocolo, então o DuskVM é a entrada nativa. As duas rotas compartilham a base de finalização, mas isso não quer dizer que funções e premissas de segurança sejam exatamente as mesmas.

Eu sou particularmente cauteloso com a afirmação de que “EVM compatível = a comunidade/ecossistema vem automaticamente”. Compatibilidade só reduz a barreira de implantação; não substitui conexão de carteira, RPCs estáveis, indexadores, liquidez e usuários reais. Por outro lado, só enfatizar capacidades nativas em Rust/ZK também não basta: as ferramentas ainda são duras demais, e desenvolvedores não vão reescrever todo o produto por uma questão de pureza técnica.

Por isso, ao olhar para o avanço técnico do $DUSK , eu separaria as métricas: o DuskEVM tem aplicações Solidity de terceiros? O DuskVM tem contratos não-oficiais? E os caminhos para a finalização no DuskDS são estáveis? Se a “cava” do #dusk realmente se sustentar, a explicação faz mais sentido como: “consegue entrar quem já conhece as ferramentas; e, quando precisar de privacidade, ainda dá para seguir por baixo”, e não três novos nomes empilhados. Vocês vão primeiro escolher compatibilidade ou capacidades nativas?

Eu costumava ver @Dusk falando ao mesmo tempo de Moonlight e Phoenix e achava que era apenas “transferência comum” versus “transferência de privacidade”, cada uma com um conjunto de funções, repetindo o trabalho. Ao ler juntos a documentação do modelo de transações e as instruções de integração da exchange, percebi que os dois modelos não são para exibir tecnologia: é um reconhecimento ativo, na mesma camada de liquidação, de que alguns fluxos de fundos precisam ser públicos, enquanto outros não devem expor valores e relações a todos.

Moonlight é um modelo de contas públicas. Saldo, remetente, destinatário e valor ficam visíveis; isso torna cenários como recargas via exchange, tesouraria (fundo do tesouro) e situações que exigem reconciliação pública mais fáceis. Phoenix, por sua vez, coloca os fundos em um note criptografado e usa provas de conhecimento zero para confirmar que não há gasto duplo e que o saldo é suficiente, sem revelar ao público o valor específico e a note correspondente. Quando for necessária auditoria, é possível fazer divulgação seletiva por meio de uma viewing key.

O maior mal-entendido aqui é a ideia de que, “como há privacidade, então o navegador não consegue ver nada”. O navegador oficial ainda consegue ver metadados públicos como blocos, tipo de transação, taxas e gas—e o que exatamente fica visível depende do modelo de transação e do contrato. Do outro lado, uma exchange também não pode tratar Phoenix como se fosse Moonlight e simplesmente fazer um “scan” direto: a documentação oficial de integração recomenda explicitamente que recargas sejam feitas usando Moonlight; para saldo de privacidade, é necessário primeiro transferir para uma conta pública. A lógica de custódia e de varredura é completamente diferente.

Então o desafio do $DUSK não é provar que a privacidade funciona, e sim garantir que o usuário, ao alternar entre o modo público e o de privacidade, não siga o caminho errado. Se o #dusk realmente vai entrar em fluxos de fundos regulados, a privacidade padrão, a divulgação sob demanda e a custódia previsível precisam coexistir. Vocês estão mais preocupados com a transparência total vazar posições (exposições) ou com o fato de que os dois modelos tornam o produto excessivamente complexo?

Esta semana, revisei do documento de staking de @Dusk , indo de ativação até a saída, e só então percebi que estas duas frases—“mínimo de 1000 DUSK, sem período de espera de acordo”—são as que mais induzem a erro. Fazer staking diretamente não é apenas “carimbar” as moedas e esperar uma taxa fixa; é preciso executar um provisioner contínuo e online, com sincronização normal. O rendimento depende de você ser selecionado para participar do consenso e da proporção efetiva de stake elegível, não de um retorno fixo prometido pelo protocolo.

A linha do tempo também tem detalhes. Um novo stake só passa a valer no “limite do próximo epoch e para além”, a partir daí. A estimativa oficial, com base no tempo-alvo de produção de blocos, costuma ser de cerca de 6—12 horas, mas o mais preciso é o que o seu wallet mostra como “active from block”. A saída em si não tem período de lock do protocolo, mas ela também não vai automaticamente sacar junto os prêmios acumulados; “withdraw reward” é outra operação.

Ainda mais contraintuitivo é o adição de stake (top-up): depois que a posição original já está ativa, a parte que você adiciona entra com 90% imediatamente em active, e os 10% restantes ficam como locked stake. O valor bloqueado continua sendo seu, mas não participa do consenso. Para recuperar essa cauda, pode ser necessário des-stakar totalmente a parcela restante. Esse desenho não é necessariamente ruim, mas faz com que quem olha apenas o APR do painel calcule a eficiência do capital errado.

Pools de terceiros podem reduzir o nível de exigência operacional, mas a custódia, os contratos, a equipe operacional e as regras de saída viram outro conjunto de riscos. Por isso, ao ver o staking de $DUSK , eu não acho que a pessoa só vai perguntar “quanto rende”; ela também vai perguntar quem controla o nó, como os prêmios são distribuídos e como funciona a parte locked. O usuário #dusk provavelmente se encaixa melhor em operar o nó por conta própria, ou prefere assumir o risco de mais uma camada de pool para ter uma operação mais simples?

Coloquei juntos o whitepaper da TMX de @TermMax e os documentos de incentivos e percebi uma pergunta que vale mais ser feita primeiro do que “quanto há em um airdrop”: o tempo em que o cronograma foi escrito pode ser tratado diretamente como um TGE que já aconteceu?

A resposta, ao menos com base nos documentos públicos atuais, ainda não permite traçar um sinal de igualdade.

Na versão do whitepaper de março de 2026, a TMX é definida como um token de governança e utilidade, com oferta total fixa de 1 bilhão. A circulação inicial é estimada em cerca de 20%. A tabela de alocação mostra 29% para o ecossistema, 28% para investidores, 15% para a equipe, 15% para a comunidade, e o restante para liquidez, fundação e consultores. O cronograma coloca TGE, liquidez em exchanges, distribuição e pools de staking no 2º trimestre de 2026.

Mas, nos parâmetros da mesma versão do whitepaper, a data do TGE ainda aparece como “A ser anunciado”. O documento de pré-escavação diz apenas que o que os usuários acumulam corresponde a uma quantia temporariamente não transferível; após o TGE, a reivindicação será feita em regime de 1:1. A equipe oficial já listou endereços de tokens na Ethereum e na BNB Chain, o que indica que o contrato está preparado e publicado, mas isso não comprova, por si só, que a geração, a reivindicação e a circulação total já tenham sido concluídas.

Essa diferença é crucial. A implantação do contrato é um evento técnico; o TGE é um evento de distribuição; a abertura de depósitos/saques e as negociações nas exchanges são eventos de mercado. As três coisas podem acontecer em sequência ou com um intervalo grande. Transformar “o endereço existe”, “o cronograma venceu” e “a página tem números” em uma única frase do tipo “já foi lançado” distorce a informação.

Avaliando o progresso da TMX, eu só observo quatro sinais: horário claro do TGE; página oficial de reivindicação e suas regras; circulação em um explorador de blocos que esteja de acordo com as informações da alocação; e os anúncios próprios da exchange sobre listing e depósitos/saques. Se faltar qualquer um desses itens, a descrição deve seguir o estágio real, sem tentar completar as etapas futuras em nome do projeto.

O risco não está só nas datas. O whitepaper afirma que a equipe terá um cliff de 12 meses antes de liberar linearmente; investidores também têm um cliff de 12 meses e, depois, 24 meses de aquisição. O que realmente afeta o mercado não é o número de 1 bilhão em si, mas sim quanto é liberado em cada janela, quais endereços assumem a entrega e se isso consegue coincidir com as tabelas públicas.

Por isso, eu não vou presumir que a TMX de #TermMax “deveria ter sido concluída” apenas porque o trimestre do cronograma já passou. Cronograma é plano; distribuição on-chain e anúncios oficiais é que refletem o status. Apostar menos em suposições sobre o progresso em um único dia — e checar com mais uma rodada de estimativas — é mais útil do que calcular uma avaliação imaginada.

Eu comparei as instruções do novo wallet @Dusk com as do Dusk Connect e só então entendi que o que eles estão “complementando” não é “criar mais uma skin de carteira”, e sim a camada de conexão que o dApp vinha sentindo falta. O Web Wallet antigo conseguia transferir, fazer staking e afins por conta própria, mas o aplicativo não conseguia descobrir a carteira por meio de uma interface unificada, solicitar contas, assinar e enviar transações; assim, os desenvolvedores acabavam tendo de adaptar tudo em torno de uma carteira específica.

O que o Dusk Connect faz é algo bem parecido com padronizar essa “cola”: a descoberta de wallets segue a ideia do EIP-6963, o RPC trata contas, assinatura, transações e requisições de rede por namespaces, e ainda prepara testes de conformidade para quem implementa carteiras. As novas carteiras oficiais passam a seguir essa interface de provider desde o início, cobrindo extensões do navegador, desktop e mobile; transferências públicas e privadas, shield/unshield, staking, resgatar recompensas, DRC-20 e DRC-721 ficam todos na mesma trilha de interação.

O ponto mais fácil de ser desviado pelo texto de divulgação é igualar “repositório aberto” diretamente a “produto maduro”. A posição oficial, por enquanto, continua sendo developer preview. A chave fica armazenada localmente; a ponta de extensão usa PBKDF2 e AES-GCM; a ponta nativa usa Stronghold e Argon2. Esses são os alicerces de segurança corretos, mas o que realmente determina a experiência são coisas como recuperação após desconexão, avisos de permissão, feedback de transações falhadas e consistência do estado entre múltiplos dispositivos.

Esse é também o motivo de eu ter olhado recentemente para o #dusk não apenas focando nos termos de protocolo: sem uma camada de conexão estável de carteira, até os contratos de privacidade mais bonitos continuam sendo apenas uma demonstração para desenvolvedores. O $DUSK precisa do próximo passo não de mais um screenshot de interface, mas de um dApp de terceiros realmente conseguindo integração sem dor. Quando vocês avaliam se uma nova carteira é utilizável, olham primeiro para a lista de funcionalidades ou primeiro para como ela se comporta em cenários de falha?

Depois de ler as notas de lançamento do V2 para o @TermMax , fui primeiro rever o V1. O problema dos acordos de taxa fixa talvez não seja a falta de cotações, e sim o dinheiro estar dividido em diferentes pedidos, páginas de mercado e páginas de chain: ver uma taxa não significa que o valor completo consiga ser fechado por ela.

No V1, as ordens range do curador e as ordens limit dos usuários ficam separadas. Se você quiser tomar um montante um pouco maior, precisa comparar pedidos um a um e ainda aguentar as mudanças de preço causadas por cada faixa de profundidade. A taxa pode ser chamada de “fixa”, mas o custo de entrada talvez não fique claro à primeira vista.

O V2 mexe exatamente nessa camada. A ordem unificada passa a ler tanto as ordens range da área do curador quanto as ordens limit pessoais, combinando tudo em um único caminho de execução; o usuário vê uma cotação, assina uma vez, e o sistema completa a combinação dentro da liquidez do mesmo mercado. As ordens limit também ficam abertas em cada mercado: o credor fixa a menor taxa de juros aceitável, e o tomador fixa a maior taxa que está disposto a pagar, sem precisar “comer” o preço vigente à força em profundidades finas.

Não é que eles deixaram a taxa ainda mais fixa; eles apenas desdobraram o atrito no livro de ofertas. É como um balcão que escreve um certo preço: o que realmente importa é se a quantidade que você quer consegue ser comprada a um preço próximo. O V2 monta o pedido e então entrega um caminho executável.

Mas existe um limite que não dá para apagar por conveniência. O que a equipe oficial diz é que os mercados cross-chain e os cofres são exibidos, filtrados e comparados na mesma interface; não dizem que os fundos de cadeias diferentes são fisicamente unidos em um único pool. A profundidade na Ethereum não vai, só porque a página Base também é visível, automaticamente atravessar e fazer a execução por você. A liquidez on-chain, o Gas, o tempo de espera das ordens limit e a quantidade de fato executável continuam sendo calculados separadamente.

Outro ponto de observação é o desempenho com ordens grandes. O caminho fica mais direto, mas isso não significa que qualquer escala consiga obter a taxa da tela inicial. Vale prestar atenção nas diferenças de cotação entre valores distintos, no tempo de espera das ordens limit e em quantas fontes uma combinação de transações agrega; isso explica a qualidade de execução melhor do que apenas “quantas cadeias suporta”.

Então, o valor do V2 do #TermMax não é só deixar a interface mais simples: é separar “taxa definida” de “execução definida”. A primeira é definida pelo FT e pelo vencimento; a segunda ainda precisa ser provada pela profundidade. A interface pode traçar o caminho, mas se há carros suficientes nele, ainda depende da execução real.
$BOME $BTC

Nos últimos dois dias, analisei com foco na segurança do AEGIS usando o caso @Dusk . No começo, só consegui memorizar “39 correções, 7 críticas”, mas ao terminar a leitura dos detalhes percebi que os números, na verdade, não são o ponto principal. No fim, esses 7 problemas graves se convergiram em 4 categorias de causa raiz: problemas de alias na sandbox de VM, desserialização insegura do lado do host, taxas e reembolsos do Phoenix que não ficaram completamente vinculados, e também um caminho de falsificação de assinatura BLS.

Por que olhar para as causas raiz, e não apenas para o número de vulnerabilidades? Porque, se a mesma fronteira de confiança não for bem desenhada, o problema pode reaparecer repetidamente em módulos diferentes. Por exemplo: se a entrada ainda não foi validada antes de desserializar, isso parece superficialmente um erro de processamento; na prática, pode esbarrar em segurança de memória do host. Já o conjunto de problemas do Phoenix não é apenas “um cálculo de taxa um pouco errado”: o que falha é que provas, assinaturas e execução de reembolso não seguem o mesmo conjunto de semânticas — no pior cenário, isso pode comprometer a integridade da cadeia de suprimentos e a segurança dos fundos.

A versão oficial diz que, no momento, não foram encontrados indícios de que essas críticas tenham sido exploradas antes de receber correções. Eu posso tratar isso como conclusão da investigação e não vou transformar em “nunca aconteceu”. Para $DUSK , o sinal positivo do AEGIS é que o time publicou internamente a descoberta, chegando às causas raiz e à lógica de correção; o sinal negativo também é bem claro: após o lançamento na mainnet, houve de fato lacunas de alto risco no core stack que puderam afetar execução, autenticação de consenso e a disponibilidade da cadeia.

Então eu não vou carimbar segurança para #dusk usando apenas “fez muitas auditorias”. Observação mais útil é: na próxima rodada, vão continuar divulgando; os testes de regressão para fronteiras do mesmo tipo vão existir; e a auditoria externa consegue abranger o código depois do AEGIS. Vocês se importam mais com o fato de o projeto nunca ter vazado problemas grandes, ou com o fato de, depois de algum vazamento, conseguirem explicar claramente a causa raiz, o impacto e a cadeia de correção?
$USELESS $BOME

Revisei novamente a documentação de taxa fixa de @TermMax e, do meu ponto de vista, o que primeiro me travou não foi como a taxa é calculada, mas uma questão mais básica: o custo do capital em empréstimos on-chain muda todos os dias; com que direito ele consegue fixar a taxa de uma dívida antecipadamente até o vencimento?

Se a resposta for apenas “o protocolo promete não mudar”, então essa taxa fixa não tem muito o que explorar. Continuando para a relação entre FT, XT e GT, a lógica finalmente se completa.

FT é um comprovante que pode ser resgatado pelo valor de face na data de vencimento. O credor compra FT com desconto e, no vencimento, resgata pelo valor de face; a diferença é o rendimento travado antecipadamente. XT é a parte complementar; a relação dada no documento é que, em qualquer momento, 1 FT + 1 XT correspondem a 1 unidade do ativo de dívida. O mutuário transforma o valor que precisará pagar no futuro em FT e depois vende a parte dos juros ao book de ordens, obtendo liquidez hoje, enquanto o custo também fica determinado no momento da execução.

GT parece mais a estrutura externa da posição. Ele é um ERC-721 que registra o colateral e a dívida, em vez de recriar uma “moeda de rendimento” que possa circular livremente. Quanto colateral uma posição alavancada precisa, quanto FT deve, quando vence — tudo isso fica embutido no mesmo endereço on-chain.

De forma mais intuitiva: um pool comum de taxa variável continua reprecificando a dívida depois do empréstimo; o TermMax primeiro transforma “quanto será pago no vencimento” em um crédito negociável e então deixa o mercado decidir quanto quer pagar hoje para aceitá-lo. O que é fixo não é o preço do ativo, nem o fato de o colateral estar eternamente seguro; o que é fixo é o tempo e o custo dessa dívida depois que a negociação acontece.

Aqui também existe um limite que é muito fácil de ser ofuscado pelo marketing. Taxa fixa não significa ausência de liquidação. A documentação oficial do Market ainda define MLTV e LLTV; se o preço do colateral cair ou o ativo da dívida se valorizar, fazendo o LTV atingir o LLTV, a posição ainda entra em liquidação. O que ele elimina é a incerteza de um salto repentino na taxa de juros; não elimina a volatilidade do colateral, o oráculo nem o risco de pagamento no vencimento.

Então, quando eu olho para #TermMax agora, a primeira pergunta não é se o APY está alto, mas qual é a data de vencimento do FT, qual a profundidade de negociação e quão longe o GT está da linha de liquidação. Se eu entender “taxa fixa” como algo que não pode dar errado, estarei indo na direção errada; o que ela fixa é apenas a parte do preço da dívida que é mais difícil de prever.
$CLO $ETH

Eu revisei de novo, em 2026, o relatório de recuperação daquela ponte cross-chain cujo caso ocorreu este ano (@Dusk ). O mais valioso de assistir não são apenas as duas palavras “foi roubado”, mas sim em que camada a falha realmente aconteceu. Em 16 de janeiro, o problema afetou a carteira de assinatura usada pelo serviço da ponte: depois que o atacante obteve as permissões de empréstimo, ele transferiu os ativos do lado da Dusk e, em seguida, enviou parte deles para a BSC. A equipe oficial foi explícita: não foi falha de consenso e nem o L1 foi “rompido” por completo.

Mas isso não significa que a camada de base esteja tudo bem e que os usuários devam ignorar o risco da ponte. A arquitetura antiga concentrava a recepção do evento, a assinatura e a liberação de fundos em um único caminho: é rápido, mas, se o lado da assinatura for comprometido, as permissões ficam demais centralizadas. O redesenho posterior separou essas três coisas: o evento primeiro é gravado como uma tarefa; o worker processa conforme a máquina de estados; as transações originais já assinadas são salvas, e, em caso de falha, a mesma operação é reenviada; a hot wallet fica apenas com o saldo necessário no curto prazo — se cair abaixo de um limiar, pausa; e a cold wallet é complementada manualmente.

Antes eu também era propenso a tomar a frase “ponte não é protocolo” como uma justificativa para isentar culpa. Agora, eu prefiro olhar ao contrário: enquanto o usuário tratar a ponte como uma porta de liquidez, a ponte já entrou na verdadeira fronteira de segurança de $DUSK . Segurança do consenso on-chain e segurança das entradas e saídas de ativos são dois boletins que precisam ser aprovados ao mesmo tempo.

A direção do resgate desta vez está correta, e o risco não desapareceu: precisa continuar acompanhando se o isolamento de chaves é executado de forma contínua, se o limiar é razoável e se a parada e a reposição de fundos são auditáveis. #dusk A comunidade deveria perguntar não apenas “a cadeia foi hackeada?”, mas sim “qual chave ainda tem poder além do necessário?”. Quando vocês olham para pontes cross-chain, vocês verificam primeiro a auditoria de código ou primeiro como as permissões operacionais são segmentadas?
$TREE $ETH

Hoje eu tracei o fluxo de fundos do documento @TermMax , puxando as partes FT, XT e GT — e quando cheguei na terceira seta, deu vontade de rir: um empréstimo com prazo fixo, como é que foi desmembrado em três tokens? O design é realmente engenhoso, mas para um usuário comum, qual deles afinal deve acompanhar?

Primeiro eu organizei a lógica. FT funciona como uma dívida sem cupom: no vencimento, é possível resgatar de volta o ativo da dívida pelo valor nominal. XT complementa a parcela do desconto do FT; na definição do protocolo, sempre é 1 FT mais 1 XT para corresponder a 1 unidade do ativo da dívida. Já o GT é um ERC-721: ele carrega o colateral e as posições da dívida. O tomador bloqueia o colateral, cunha o FT, então troca o FT — dividindo-o em parte do principal e parte dos juros — por XT, e por fim recompõe o ativo que quer tomar emprestado. No papel, o ciclo fechado fica bem bonito; admito que isso é mais verificável do que “taxa de juros escrita na página”.

Mas quanto mais eu olho, mais fico com dúvidas. O preço do FT varia com o tempo restante e com a curva do mercado. O valor do XT no vencimento vai a zero. E o GT ainda assume o risco de liquidação. Esses três tokens registram, cada um, prazos, juros e dívidas colateralizadas. O TermMax torna a divisão de uma única operação de empréstimo muito transparente, mas também quebra em mais partes o estado que o usuário precisa entender. Um clique para negociar na página não significa que, fora da cadeia, a mente também entenda com um clique, certo?

O ponto mais importante: o tomador pode liquidar diretamente usando o ativo da dívida, ou então comprar FT com desconto para sair. Parece flexível, mas isso significa que o custo de sair antes do vencimento não depende só da taxa de juros travada inicialmente — também depende da profundidade do mercado do FT e de qual preço a curva estava oferecendo naquele momento. Juros fixos resolvem a certeza contratual; o preço de saída ainda precisa ser negociado com o mercado.

Eu comparei também o lado do vencimento. Em condições normais, o FT é resgatado pelo valor nominal. Porém, se o tomador atrasa, e se a liquidação não é tratada com limpeza dentro da janela, o pool de resgate pode acabar misturando colateral. Em outras palavras: FT parece uma “cobrança tipo título”, mas a proteção de crédito não é promessa de pagamento por alguma instituição; é uma cadeia de “passa adiante” feita por taxa de colateral, oráculos, liquidadores e liquidez do mercado. Não deixar de ver uma peça — e a conclusão pode se desviar.

Então, depois de eu estudar o #TermMax , o que eu mais quero ver não é um novo pôster de “APY fixo”, e sim que cada posição explique, em linguagem humana, como FT, XT e GT mudam e qual é o pior caminho para sair. Mecanismos complexos podem ficar escondidos atrás de um clique; mas se o risco também ficar escondido junto, essa simplificação está servindo o usuário… ou só servindo a execução/fechamento da negociação?
$PRL $CLO

Falar de algo que não é tão “sexy”, mas que realmente determina se uma rede consegue rodar por muito tempo: a emissão e a participação em staking do $DUSK . Depois de ler a documentação mais recente do @Dusk , percebi que muita gente discute só o “maior supply de 1 bilhão”, mas ignora que esses 1 bilhão não entram no mercado de uma vez.

O modelo da Dusk é: 500 milhões de supply inicial; depois, ao longo de 36 anos, libera outros 500 milhões como recompensas da rede. As emissões seguem um ritmo geométrico decrescente, com a redução pela metade a cada quatro anos. A utilidade do token, hoje, é bem direta: pagar Gas, participar do staking e proteger o consenso. Para se tornar Provisioner, é necessário no mínimo 1000 DUSK em staking, além de manter o nó online e sincronizado continuamente. A configuração-base oficial não é exagerada; porém, as recompensas são geradas pela participação no consenso e pela probabilidade de um staking efetivo — não é simplesmente depositar e receber rendimentos fixos.

O mérito dessa arquitetura é amarrar o uso da rede às verbas de segurança. As recompensas do bloco vêm de emissão adicional e taxas de transação. No início, a rede usa subsídios de emissão para compensar os nós; mais tarde, passa a depender cada vez mais de taxas reais. Se o uso na cadeia crescer, o orçamento de segurança pode ir, gradualmente, de “emitir moedas novas” para “usuários pagando pelo serviço”, e aí sim o ciclo fecha.

Mas há riscos bem claros. Emissões ao longo de 36 anos significam que a diluição de longo prazo não pode ser vista apenas como slogan de total. O mínimo de 1000 moedas, somado às exigências de operação, pode excluir parte dos detentores menores do staking direto. Além disso, como as recompensas têm caráter probabilístico, é fácil interpretá-las erroneamente como uma APY estável. O ponto mais crítico: se as receitas de transações on-chain e das aplicações não decolarem, as taxas não conseguem assumir o papel; no fim, a segurança da rede ainda dependerá principalmente dos subsídios de emissão.

Por isso, observo que o #dusk não vai olhar apenas se a taxa de staking é alta; vai colocar três indicadores juntos: se os Provisioners ativos são descentralizados, a proporção das recompensas que vem de taxas reais de transação, e se, após a atualização, os nós conseguem ficar online de forma estável. Somente olhar o volume travado pode até parecer bonito; travar muito, mas ninguém usar, só “esconde” liquidez e não prova demanda.

O que você acha: no começo de uma nova rede, deve priorizar aumentar a participação no staking ou primeiro fazer as taxas reais de transação acontecerem? Deixe sua ordem. $ETH $RED

Eu revisei novamente, do começo ao fim, o mecanismo de taxa fixa do @TermMax , e quanto mais leio, mais sinto que as duas palavras “fixo” podem relaxar a vigilância das pessoas. A taxa de fato consegue travar durante a negociação, mas o meu resultado final também ficou “fixo” de verdade?

Primeiro, o empréstimo. O TermMax define, para cada mercado, previamente os ativos da dívida, os bens em garantia e a data de vencimento. O tomador trava o colateral no GT e depois cunha o FT que representa a dívida com vencimento. O custo não fica oscilando com a utilização — eu admito isso — pelo menos não preciso ficar encarando taxa de empréstimo flutuante de madrugada. Mas, assim que o LTV encostar no LLTV, a posição ainda entra no processo de liquidação. O que está fixo é o preço do capital, não o preço do colateral, e muito menos a segurança do principal. Promover essas três coisas como se fossem a mesma coisa me parece fácil de induzir ao erro.

Agora, a data de vencimento. A documentação é bem clara: o não pagamento ao final do prazo aciona a liquidação, com uma janela de liquidação de duas horas aberta. Se a dívida não tiver sido resolvida totalmente, passa para a physical delivery, e o pool de resgate que o detentor de FT recebe pode incluir tanto os ativos subjacentes quanto os bens em garantia. Eu achava que comprar FT é esperar até o vencimento para receber exatamente a mesma dívida subjacente, mas em cenários extremos, posso acabar com uma cesta de colaterais que eu mesmo vou precisar administrar. Isso ainda é “renda fixa” no sentido que a maioria das pessoas entende?

A parte dos oráculos também não dá para contornar. O próprio TermMax lista como pontos de risco as fontes de preço da Chainlink e da RedStone. Se houver anomalia na alimentação de preços, isso pode causar liquidação incorreta ou insuficiência de garantia. A taxa fixa não consegue blindar para mim contra falha dessas fontes; esse risco só saiu da curva de juros e foi parar na avaliação e no fluxo de liquidação.

E o custo da liquidação não se resolve com uma frase tipo “overcollateral”. Regras públicas dizem que, ao liquidar dívidas, há uma penalidade de 10% calculada sobre o valor da dívida liquidada: metade para o liquidante e metade para o tesouro de reservas do protocolo. Quando a dívida excede 10.000 dólares, por transação normalmente o máximo é processar 50%. Isso pode evitar que uma posição grande seja cortada toda de uma vez. Mas se o mercado realmente continuar despencando, o processamento em partes é suficiente? Ou dá tempo? Depende da execução on-chain e da liquidez.

Então, quando vejo #TermMax , não basta perguntar se o APY da página está travado ou não. A pergunta certa é: qual é o colateral? Onde fica o LLTV? Quem é responsável pelo pagamento no vencimento? Depois da entrega física, o que eu vou receber? A taxa de juros foi fixada, mas o risco não ficou preso no mesmo lugar, ficou? Não foi isso?
$GPS $ETH

Relembrei e revi o guia de migração da rede principal do @Dusk e há um detalhe fácil de ignorar: clicar em <Approve> na carteira não significa que o $DUSK já tenha sido migrado para a rede principal da Dusk. O que realmente dispara a migração é a <Execute transaction> seguinte. Entre as duas etapas, qualquer interrupção pode fazer o usuário achar que os ativos “ficaram travados”.

O procedimento oficial é bloquear o ERC-20 na Ethereum ou o BEP-20 na BNB Chain do DUSK em um contrato de migração e, então, creditar os respectivos tokens nativos na conta da rede principal da Dusk designada. Para isso, o usuário precisa preparar uma carteira EVM auto-hospedada, uma conta na Dusk e pagar as taxas da cadeia de origem em ETH ou BNB; após confirmar a execução da transação, geralmente ainda é necessário aguardar o processamento. Contas de corretoras normalmente não conseguem concluir essa operação diretamente via WalletConnect; é preciso primeiro conectar/indicar uma carteira que a pessoa controle.

O mecanismo em si não é difícil, mas os “buracos” estão todos nos limites de operação. Primeiro, a autorização apenas concede um limite ao contrato; ela não transfere moedas automaticamente. Segundo, o token na cadeia de origem tem 18 casas decimais, enquanto o DUSK na rede principal tem 9; o valor da migração é arredondado para baixo até a menor unidade LUX. A fração menor que 1 LUX fica na carteira original. Terceiro, ao ver que o saldo não chegou, o correto é verificar se a transação <Execute> foi bem-sucedida, em vez de repetir a autorização.

Esse desenho de travamento unidirecional seguido de liberação é mais claro do que fazer o usuário encontrar uma “piscina”/pool cross-chain, mas ainda assim coloca duas redes, duas carteiras e duas confirmações no mesmo fluxo. Para usuários antigos, basta um olhar a mais; para iniciantes, porém, pode levar a entender “autorização concluída” como “migração concluída”. Se o mecanismo de segurança não for explicado claramente pela interface, no fim ainda vira erro humano.

Então, ao migrar meus ativos, o que eu observo na migração da rede principal #dusk não é apenas se o contrato tem auditoria, mas também se a carteira exibe simultaneamente o passo atual, o hash da cadeia de origem, o status de processamento previsto e o endereço de recebimento. A documentação oficial fornece um caminho de verificação bem definido—isso já é um ponto positivo. O próximo passo deve ser incorporar esses avisos em cada botão-chave, em vez de esperar o usuário falhar e então mandar consultar o Central de Ajuda.

Ao migrar seus ativos, qual etapa você teme mais: a autorização, escolher a rede errada ou o status de recebimento não ser transparente? Conte quais “armadilhas” você já encontrou ao operar.
$ACE $BTC

Depois de ler a documentação de desenvolvimento completa do @Dusk , percebi que o mais valioso agora não é nenhum slogan de TPS, e sim o fato de terem dividido o ponto de entrada de desenvolvimento em dois ambientes: DuskVM e DuskEVM. À primeira vista parece repetir a roda; por trás disso, porém, está a tentativa de resolver o problema de que “capacidades nativas de privacidade” e “ecossistema de desenvolvimento pronto” não conseguem ser atendidos em um único passo.

O DuskVM permite que contratos Rust/WASM sejam executados diretamente na L1, ficando mais próximo da Phoenix ao ocultar transações, capacidades de zero conhecimento e o modelo de ativos nativos; já o DuskEVM é baseado no OP Stack: os desenvolvedores podem continuar usando Solidity, Hardhat, Foundry e ferramentas de carteira já conhecidas, e o resultado da execução é então liquidado e garantida a disponibilidade dos dados via DuskDS. Em poucas palavras: o primeiro é como um laboratório dedicado — profundo em capacidades, mas com alta barreira de aprendizado; o segundo é como uma interface padrão — integração rápida, mas exige lidar com a coordenação entre camadas.

Essa rota é, de fato, pragmática. Muitas tecnologias de cadeias de privacidade ficam pesadas e, no fim, emperram porque ninguém sabe como desenvolvê-las; por outro lado, as ferramentas padrão de cadeias EVM estão completas, mas é difícil tratar de forma nativa ativos regulados que exigem confidencialidade e divulgação seletiva. A Dusk mantém os dois tipos de desenvolvedores, evitando pelo menos o velho problema de “tecnologia correta, ecossistema vazio”.

Mas os benefícios de dois ambientes não são “grátis”. Onde o contrato fica, como os ativos atravessam camadas e qual camada responde por falhas — tudo isso aumenta a complexidade de engenharia. Especialmente no DuskEVM, que depende da DuskDS para liquidação e disponibilidade de dados: o usuário vê uma interface EVM familiar, mas por baixo não é uma simples sidechain comum do Ethereum. Se a documentação, o navegador e as mensagens de estado entre camadas não acompanharem, a compatibilidade pode, na verdade, criar um novo custo de entendimento.

Eu não vou tirar conclusões sobre o crescimento dos desenvolvedores de #dusk apenas com base em “suporta Solidity”. O que vale observar agora é: a quantidade real de contratos na mainnet, se os caminhos de ativos entre camadas são suaves e quando capacidades de privacidade como a Hedger se transformarão em componentes reutilizáveis. $DUSK , como ativos de segurança e de Gas dentro dos dois ambientes, também precisa provar seu valor pela quantidade real de chamadas — não por um loop automático movido por diagramas de arquitetura.

O que você acha: esse modelo de execução dupla é uma divisão inteligente do trabalho, ou é ampliar a dificuldade de manutenção? Fique à vontade para deixar sua opinião.
$BTW $ETH

Revi o relatório da ponte cross-chain de março deste ano, @Dusk . O que vale lembrar não é que “o consenso da mainnet não deu problema”, e sim outra constatação ainda mais dolorosa: as permissões de uma carteira de assinatura podiam, antes, ser grandes o suficiente para arrastar toda a ponte junto para o fundo.

Em 16 de janeiro, o atacante obteve as permissões da carteira de assinatura Dusk do serviço da ponte. Primeiro desviou fundos do lado Dusk e, em seguida, enviou parte deles para a BSC. Na sequência divulgada oficialmente, foram roubadas 9.000, 89.700, 2.743.310 e 8.068.000 unidades de $DUSK ; além disso, houve duas transações que conseguiram atravessar a ponte. A última tentativa, com 8.910.000 unidades, falhou após o desligamento.

Isso não é que o consenso do DuskDS foi “furado”, nem que a criptografia da Phoenix falhou na hora. O problema está no caminho de operação da ponte: assinatura, tratamento de eventos e conexão de rede ficaram amontoados na mesma linha. É como se o cofre do banco não tivesse sido arrombado, mas o motorista do carro-forte tivesse, ao mesmo tempo, a chave da porta do cofre, a planilha de rotas e o carimbo de liberação; se as credenciais do motorista forem perdidas, por mais grosso que seja o cofre, não dá para impedir o carro de seguir a direção errada.

A reforma depois do retrospecto, sim, veio no alvo: a assinatura e o tratamento de eventos foram separados; os eventos primeiro viram tarefas e depois são executados por um worker independente. O estado das transações foi decomposto em seen, submitted, completed, failed e stuck. A hot wallet fica apenas com o saldo mínimo operacional; abaixo de um limiar, ela pausa automaticamente, e o restante é completado manualmente pela cold wallet. Em outras palavras: transformaram “uma estrada que vai até o fim” em várias cancelas.

Mas eu não vou fingir que agora, depois da correção, a história pode ficar para trás. O mais chato da ponte é que segurança do protocolo e segurança operacional costumam ser empacotadas junto na compreensão dos usuários. Você está com o mesmo DUSK, vê a mesma marca, mas pode estar lidando com um modelo de confiança totalmente diferente. Dentro da cadeia, a segurança depende do consenso; no passo cross-chain, na época, dependia do caminho de assinatura. Assim que os ativos atravessam a fronteira, a suposição de segurança já mudou de carro.

Minha avaliação: uma linha do tempo pública e as causas-raiz são muito mais fortes do que uma frase vaga do tipo “já foi restaurado”; porém, o retrospecto transparente é apenas o ponto de partida para recálculo de pontuação, não é um selo de “dispensa de inspeção”. Depois de #dusk , os itens realmente úteis para observar são: quanto a hot wallet fica exposta, se o mecanismo de pausa funciona de forma contínua, se o isolamento de assinaturas é mantido e se o tratamento de anomalias roda por muito tempo como foi desenhado.

Então não pergunte mais “Dusk é seguro?”. A pergunta correta é: em qual camada seus ativos estão agora, quem assina, e qual cancela que falhar mexe com o dinheiro? A ponte ficou mais complexa—mas será que a confiança realmente foi fragmentada? Continuem desmontando no campo de comentários.
$BTC

Eu encontrei a página de economia de tokens do @Dusk ; o que realmente me fez parar não foi o limite de 1 bilhão de moedas, e sim uma regra discreta: a estaca mínima é de 1.000 tokens $DUSK , mas o máximo não é limitado.

Vamos colocar as contas em ordem. O fornecimento inicial do Dusk é de 500 milhões; a ideia é liberar mais 500 milhões ao longo de 36 anos. Nos quatro primeiros anos, cada bloco ganha cerca de 19,8574 tokens adicionais; depois disso, aproximadamente a cada quatro anos, cai pela metade. Na recompensa do bloco, o minerador/quem forger pega 70% e ainda pode receber até mais 10% conforme os credits do certificado. O fundo de desenvolvimento fica com 10%, e os comitês de validação e aprovação com 5% cada. A parte que não for distribuída será destruída.

Essa divisão de fatias é como uma empresa repartindo bônus entre vendas, revisão de controle de risco e orçamento da sede. A vantagem é que cada papel recebe dinheiro, e a validação/aprovação não depende tanto de “romantismo”. Mais importante: a taxa também entra na recompensa do bloco; teoricamente, quanto mais uso na cadeia, mais o orçamento de segurança não depende só de emissão.

Mas “sem limite de estaca” é o osso duro. No consenso, o provisioner é sorteado aleatoriamente para propor, validar e aprovar blocos; os ganhos dependem da estaca efetiva e do nível de participação. Quanto mais grossos os recursos do grande nó, maior a expectativa econômica de ser sorteado. Os prêmios voltam para a estaca, e a “bola de neve” pode rolar cada vez mais forte. A regra não diz explicitamente que foi feita para os grandes tomarem conta—mas os juros compostos acabam fazendo o serviço sujo.

Claro, o Dusk também tem penalidades leves e pesadas: ficar offline pode levar a suspensão e a parte da estaca efetiva ser convertida em estaca bloqueada; votos inválidos ou condutas maliciosas comprováveis, como double-sign, podem queimar diretamente uma parte do capital. É como instalar um botão de autodestruição no cofre das grandes baleias: o botão limita ações maldosas, mas não resolve sozinho a concentração de peso.

Minha opinião é bem conturbada: a queda de emissão ao longo de 36 anos deixa claro o orçamento de segurança de longo prazo—isso é melhor do que ajustar inflação no “achismo”; porém, para quem vai o orçamento de segurança, vale mais observar do que a curva total de emissão. #dusk não deveria olhar para o “teto de 1 bilhão” apenas como um título grande; o que importa é a concentração da estaca ativa, a taxa de nós online e se os prêmios continuam retornando para a parte de cima.

Não traduza “teto de fornecimento” diretamente como escassez, e não traduza “rendimento de estaca” diretamente como segurança. Com peso de nó sem limite, é recompensa para investimento de longo prazo ou, aos poucos, transformar o comitê aleatório em um clube habitual de gente rica? Vamos esclarecer na praça. $VELVET $SNXXB

Eu li duas vezes a documentação do modelo de transações ligada ao @Dusk . O que mais chama atenção não são as duas palavras “privacidade”, e sim o fato de que, na mesma cadeia, ficam duas contas lado a lado: Moonlight em público, Phoenix em modo oculto.

Em linguagem simples: Moonlight funciona como um balcão de vidro — endereço e transferências podem ser vistos. Já o Phoenix coloca os fundos dentro de tíquetes criptografados e, com provas de conhecimento zero, informa à rede que o dinheiro é legítimo, sem dupla utilização (double-spend), mas sem expor completamente remetente, destinatário e valor. Um único perfil de conta ainda consegue controlar simultaneamente esses dois tipos de conta. Parece como se uma carteira tivesse tanto um cartão transparente quanto um cartão com compartimento secreto, e na hora do pagamento você escolhe qual deles entregar.

Essa ideia é, de fato, inteligente. Instituições financeiras não conseguem abrir todos os dados, e reguladores não aceitariam um sistema onde nada é visível. O Dusk coloca essa escolha dentro do modelo de transações: liquidações comuns ficam em conta aberta; posições sensíveis ficam em conta de privacidade. Quando houver auditoria, aí sim usa-se uma chave de visualização para fazer divulgações seletivas. Não é “privacidade vs. conformidade” lutando até a morte, é fazer com que ambas comam em mesas separadas.

O problema também está escondido nesse esquema “em duas trilhas”. A documentação de integração das corretoras recomenda recarregar usando o Moonlight, porque os tíquetes criptografados do Phoenix exigem outra lógica de custódia e de varredura. Ou seja: o protocolo dá uma saída para a privacidade, mas a entrada no mundo real pode, por questões de compatibilidade, acabar empurrando todo mundo de volta para o canal transparente. É como um hotel que cria uma porta discreta para convidados VIP, mas o sistema da recepção só reconhece documentos da porta principal; a porta existe, mas isso não significa que o hóspede realmente consiga passar por ela.

Então, o que é o $DUSK aqui? Tanto para transferências em um tipo quanto no outro, ele é usado para pagar; e a execução do contrato também depende dele. Não é só um “símbolo” colado na narrativa de privacidade: é o combustível compartilhado entre os dois livros-razão. Se esse combustível tem demanda, no fim depende de o wallet, a corretora e o aplicativo estarem dispostos a realmente “trazer” o Phoenix para fora — e não apenas deixar isso bonito no texto da documentação.

Minha avaliação atual: um modelo duplo fica mais perto da realidade do sistema financeiro do que um “tudo exposto de uma vez”, mas a complexidade foi movida da cadeia para quem faz a integração. O #dusk , no que realmente vale ficar de olho, não é se a função de privacidade existe — é quantas entradas estão dispostas a assumir o custo extra de varredura, custódia e divulgação.

Então não se deixe enganar só pelas quatro palavras “privacidade com opção”. Com o Moonlight e o Phoenix como um par de pistas, no fim os usuários vão escolher livremente o caminho? Ou a maioria dos acessos só vai abrir aquela pista transparente, que é a mais fácil? Continuem desvendando no campo de comentários.
$AKE $ACU