小饼的撸毛日记

朋友跑 Dusk 验证者，问我他节点连续错过出块被罚了，这算不算恶意。我一开始觉得罚没就是罚没，Cosmos 那套双签直接关小黑屋，没什么好辩的。

后来翻 Dusk 的罚没机制，发现它分两种。Soft Slashing，软惩罚，专门管非恶意过失，比如节点该出块时掉线、没在窗口期内广播，不涉及作恶，就是运维出问题。惩罚是每次连续违规扣 N 乘 10% 的质押权益，N 是连续违规次数，同时把节点从共识里踢出去 N 个 epoch，epoch 是 Dusk 的共识周期，每轮结束验证者集合轮换一次。罚掉的 DUSK 不销毁，从活跃质押里划走，节点能自己取回。

Hard Slashing，硬惩罚，管恶意行为。生成无效区块扣 10% 质押并销毁，双重投票或双重出块扣 20% 并销毁。销毁是真的没了，不是锁一阵再还。

我没想通为什么要分两种。后来看文档里关于可追责性的部分才明白。节点只是网络波动错过出块，你就重罚，验证者会把节点放最贵的云上，运维成本高，去中心化反而变差。Soft Slashing 的作用是把不靠谱的节点从活跃集合里挤出去，给机会恢复，每次罚一点，不会让诚实运维的人破产

真正让我改变判断的是 N 的设定。连续违规越多，扣的越多，踢出去时间越长。第一次掉线扣 10% 移除 1 个 epoch，第二次 20% 移除 2 个 epoch，指数级压力，节点要么恢复稳定，要么自动离场。Hard Slashing 留给明确作恶，一次销毁，没有恢复窗口

拿 Polkadot 比。Polkadot 的 Slashing 也分级，但惩罚比例更细，从 0.1% 到 100% 都有，罚款分给举报者。Dusk 这套更简单，要么过失要么恶意，比例固定，销毁不奖励举报。好处是验证者能预测犯错代价，不会因复杂规则不敢跑节点

朋友听完说这次 Soft Slashing 认了，家里网络掉了半小时。我也明白 Dusk 为什么把机制分这么清。没有分级惩罚，诚实节点和作恶节点一视同仁#dusk $DUSK @Dusk

我那天翻Dusk的节点文档，Provisioner节点的官方最低要求写着2核CPU、4GB内存、50GB存储。看着不高对吧？普通云服务器就能跑。

但我顺手查了Archive节点，4核CPU、8GB内存、500GB存储。Prover节点更夸张，单Worker就要1核加1GB内存，最小配置4核8GB。

我纳闷了，同一个网络，节点之间的硬件怎么差这么多？

翻Dusk的共识设计才发现，SBA把参与者分两种。一种是Block Generator，通过Proof-of-Blind-Bid抽签选出，匿名出块。另一种是Provisioner，负责投票验证和敲定区块。每成功出一个块，1个Generator和192个Provisioner拿奖励。Provisioner的投票委员会每轮通过确定性抽签重新选。

Provisioner要验证区块合法性、检查ZK证明、广播BLS签名投票，每一轮都得跑。Generator被选中才干活，Provisioner得随时待命。Archive节点不光要跑共识，还得存整个链的历史。Prover节点专门生成ZK证明，那东西是单线程计算密集型。

我原来觉得PoS网络都差不多，质押够多DUSK就能跑节点。后来发现Dusk根本不是这么回事，每个节点的硬件要求天差地别，Generator匿名抽签、Provisioner委员会投票、Prover扛ZK计算、Archive存全量历史，每一层吃的硬件资源都不一样。

但更让我在意的是，Dusk现在206个活跃Provisioner，前20个控制了35%以上的质押。硬件要求分层之后，能跑Archive和Prover的本来就是少数人，这些人大概率也是筹码最多的人。不是代币分布的问题，硬件门槛本身就是第一道筛子。普通散户连门都摸不到，只能去Hyperstaking池子里把币交给别人。

现在我看Dusk的去中心化，先翻节点文档，再看三种节点的实际运行数量，最后看验证者质押分布。三个数据对不上，去中心化就是个修辞。#dusk $DUSK @Dusk

第一次研究Dusk的时候，我对“隐私金融”有点怀疑。过去很多项目讲隐私就是藏，但面对机构和受监管市场，问题没那么简单。金融系统需要的不是看不见，而是需要验证的时候能证明某些事成立。

后来重新翻Dusk Citadel资料，才发现自己之前理解偏了。Citadel把身份验证拆成两步。第一步用户发一笔链上交易，附带一个只有自己能控制的隐身地址。许可证颁发方一直在扫链，看到发给自己的请求后验证通过，把许可证铸造到那个地址，用户再扫链接收。第二步用户拿着许可证申请服务，发一笔链上交易附带零知识证明，证明自己持有有效许可证，同时计算一个会话cookie——这是一个能用链上数据验证的值，只有用户和服务方知道它的含义。cookie通过加密信道发给服务方，服务方去链上核对会话ID，对上了才放行。全程链上完成，但除了用户和服务方没人知道谁在申请什么。

这个零知识证明电路的约束数大概是3.5万，生成证明十几秒，链上验证只要0.007秒。对用户来说多等十几秒申请一次，后面每次验证都是毫秒级。好在许可证可以提前作废，不用等过期，所以那个十几秒的生成时间对协议整体性能影响不大。

Citadel要保证五件事：证明你确实有证但不暴露额外信息、服务方能撤销但证没被撤之前一直有效、你的活动不能被追踪、证不能被重复用、只泄露必要信息。这五个属性加上已封装成SDK的Moat开发者工具，构成了Dusk身份层的核心——它和DuskDS、DuskVM平级，不是独立做隐私，而是决定谁有资格做Moonlight的公开交易和Phoenix的隐私交易。

看到这里我停下来想了一个事。真正成熟的隐私系统不是所有东西都看不见，而是让不同角色只看到自己该看到的。未来资产上链，竞争点不是谁藏得多#dusk $DUSK @Dusk

Ao estudar o Dusk, o que prendeu minha atenção logo de cara foi o DuskEVM. Antes, eu estava acostumado a olhar para os projetos de sempre: primeiro o ambiente de execução — se os desenvolvedores conseguem ou não entrar, isso é o que define se uma cadeia tem futuro.

Depois de ler a documentação, voltei a olhar novamente. Desta vez, o que realmente me fez parar foi o DuskDS.

Eu costumava achar que o maior obstáculo de colocar finanças na blockchain eram velocidade e custo. Mas, ao desmembrar a arquitetura do Dusk, percebi que o problema de verdade é outra coisa: depois que uma transação é executada, quem confirma que ela já chegou ao estado final?

O Dusk separa execução e liquidação em duas camadas. O DuskEVM executa as aplicações, montado sobre o OP Stack; desenvolvedores Solidity usando a mesma estrutura de ferramentas do Hardhat e MetaMask conseguem implantar direto. O sequenciador processa as transações, e o batcher empacota os dados em um blob EIP-4844 e envia para o DuskDS. O DuskDS não se importa com o que roda acima; ele só se encarrega do consenso, da disponibilidade de dados e da confirmação do estado final.

Eu fiquei olhando para a parte do DuskDS por bastante tempo, até finalmente entender o que exatamente ele está fazendo. Ele executa o Succinct Attestation, um protocolo PoS baseado em comitês. Em cada rodada, um Provisioner propõe o bloco, um comitê valida, e outro comitê conclui. Assim que conclui, há finalização determinística — diferente do Bitcoin, que só tem finalização probabilística; em condições normais, não existe reorganização perceptível pelos usuários. Para se tornar Provisioner, é preciso ter a menor garantia (stake) de 1000 DUSK; os nós ficam online 7×24. Se ficar offline por muito tempo ou agir maliciosamente, a penalidade envolve perda de garantia.

Foi só chegando aqui que eu percebi — antes, eu achava que o maior valor da blockchain é fazer as transações ficarem mais rápidas, mas no mercado financeiro o que realmente dá medo não é a lentidão, e sim a incerteza. Numa negociação de valores mobiliários, os ativos podem até ter sido transferidos, mas o pagamento não sincroniza, ou então as partes veem estados diferentes; por mais eficiente que seja, ninguém se arrisca a usar.

A liquidação determinística do Dusk, em essência, está resolvendo exatamente esse problema. A finalização fica em dois a três segundos, somada ao fluxo nativo de entrega acoplado ao pagamento — é essa combinação que traz valor prático de verdade nos cenários de liquidação financeira.

Claro, essa arquitetura ainda precisa de validação do ecossistema. Fazer a infraestrutura funcionar é apenas o primeiro passo; o valor real depende de os ativos e as aplicações estarem dispostos a entrar.

Mas depois de pesquisar o Dusk, a maior mudança em mim foi: não me importar apenas com quantas transações uma cadeia consegue processar, e sim em saber se ela consegue inspirar confiança nos participantes do setor financeiro
#dusk $DUSK @Dusk

Depois que a Dusk anunciou o funcionamento da mainnet, eu não encaminhei a notícia na hora. Nos últimos anos, vi muitos projetos: no lançamento fica tudo animado, mas depois de alguns meses o bloco não cresce muito e os nós praticamente não mudam. Então, desta vez, não tive pressa em escrever; fiquei vários dias seguidos acompanhando os dados on-chain.

Primeiro, verifiquei se a altura do bloco continuava variando, se o ritmo de produção era estável e se a participação realmente acompanhou. Antes, para avaliar o valor de uma cadeia, eu tinha o hábito de olhar para a divulgação e para o volume de transações. Mas, ao observar estes dias, o que realmente não “mente” é se a rede consegue manter um estado de funcionamento contínuo. Esse julgamento é frio, mas quanto mais eu vejo, mais eu concordo.

O que realmente me fez parar foi o Succinct Attestation da Dusk. Ele é uma base do DuskDS, um protocolo PoS de comitê baseado em consenso: Provisioners selecionados aleatoriamente propõem, validam e confirmam blocos. Cada rodada de consenso tem três etapas: na fase de Proposal, um Provisioner selecionado cria e transmite o bloco candidato; na fase de Validation, um comitê verifica a validade do bloco e requer aprovação de maioria absoluta de dois terços; na fase de Ratification, outro comitê confirma e sela finalmente o bloco. Uma vez que tenha passado pela Ratification, o bloco entra em um estado final determinístico e não volta atrás.

Eu revisei esse detalhe duas vezes, porque o que ele diz não é “segurança com alta probabilidade”, e sim “uma vez confirmado, acabou de verdade”.

Isso é crucial para cenários financeiros. Muitas cadeias operam com a lógica de esperar um pouco mais e, na maioria das vezes, não dá rollback. Mas em títulos, compensação e liquidação e ativos regulatórios, não existe espaço para “provavelmente”. O que eles querem é um resultado claro: o que foi confirmado ontem não deveria ser desfeito hoje. Antes eu achava que a finalização era só um indicador técnico; só agora percebi que ela é o limite para as instituições se atrevem a colocar ativos reais lá.

Tornar-se Provisioner também não é difícil. É preciso fazer stake de pelo menos 1000 DUSK e rodar um nó. O nó deve ficar online 24/7, com no mínimo 2 CPUs, 4GB de memória e 50GB de armazenamento. Após o staking, a maturação leva cerca de 12 horas; depois disso, você pode participar do consenso. O comitê aprova por meio de sorteio aleatório com base no peso do stake, e cada rodada é diferente.

Nesses dias, a maior mudança para mim não é apenas acreditar mais na Dusk; é ficar mais claro o que eu devo observar. Para uma infraestrutura voltada a privacidade e finanças reguladas, o lançamento da mainnet é só o ponto de partida; o que realmente importa é se a rede consegue gerar continuamente um estado confiável#dusk $DUSK @Dusk

刚开始研究Dusk共识机制的时候，我对着白皮书看了半天也没搞明白什么叫确定性最终性。没办法，我只好在纸上画了三列时间轴对比表硬啃。

以太坊的Gasper走的是概率最终性，区块得堆好几个epoch才能说基本安全了。Solana的Tower BFT也要几十秒才能确认。Dusk的Succinct Attestation呢？区块一旦被批准，就是硬的、确定的、不会回头的那种最终性。

当时我盯着纸上这三条线看了很久。几秒钟的差距在加密交易里你可能根本感觉不到，多等一会儿就是了。但在证券结算的场景下，这几秒是亿级资产的最终安全锁。你在交易所卖了一笔股票，T+2才交割，这中间两天时间资产到底算谁的？如果结算那一刻链还能回滚，谁敢把真实资产放上去？散户交易说不太可能回滚就够了，但机构结算不行，不太可能这三个字在法律和合规层面等于什么都没保证。

后来我翻官方文档才搞清楚Succinct Attestation到底怎么跑的，看完那段才算松了口气，之前的困惑总算有了答案。它是无需许可的、基于委员会的PoS共识协议。系统随机选出一批叫Provisioner的节点来提议区块，另一批节点负责验证，最后一批委员会确认验证结果、正式批准区块。区块一旦走完 ratification 这一步，就是确定性最终性，正常操作下不会发生面向用户的重组。

Dusk主网2026年1月7号正式启动，每秒能处理超过20000笔交易。六年开发周期，终于从测试网走到了能跑真实资产的阶段。以前我对共识机制的理解就是谁出块谁拿奖励，觉得这东西跟普通用户没什么关系。但Dusk让我换了个角度看，共识机制的选择本质上是在回答一个最基本的问题：你这笔钱一旦放进去，到底能不能真的算数？Succinct Attestation给的答案是能，而且不用加大概率三个字。#dusk $DUSK @Dusk

Semana passada, terminei um empréstimo colateralizado de ETH na rede de testes do TermMax. Abri a carteira e dei uma olhada no saldo. Tinha aparecido uma coisa nova: um NFT. Eu nem me lembrava de ter resgatado/recebido aquilo. Na hora, minha cabeça ficou toda confusa; pensei que a carteira tivesse sido infectada ou que a rede de testes tivesse me dado algum “lixo” via air drop. Atualizei três vezes e ele continuava lá. Para ser sincero, comecei a ficar com um pouco de pânico: e se o ETH que eu colateralizei sumisse?

Aí fui procurar a documentação oficial. Passei quase meia hora lendo e até revirei postagens antigas da comunidade, até entender que era o GT que eu tinha ignorado antes. Você sabe qual é a lógica mais central dessa parada? Você pega um empréstimo, e o protocolo já te dá diretamente um NFT — dentro dele fica registrado quanto de ativo você colateralizou, quanto de FT você tomou emprestado e quais são os parâmetros de MLTV correspondentes a qual prazo. Cada empréstimo é um NFT independente.

Eu já tinha passado por uma situação parecida em outros protocolos de taxa fixa: eu tinha pago uma parte, mas o sistema ainda mostrava a taxa de colateral original. Aquilo me assustou, como se eu estivesse devendo de novo. Depois de um tempão procurando o suporte, entendi que era atraso de sincronização do estado no frontend. Mas aquela ansiedade de “será que eu já quitei ou não?” eu realmente não quero passar pela segunda vez.

Mais tarde, eu fui pensando e percebi que o GT tem coisas interessantes além disso. Dá para entender o GT como sua posição de alavancagem “empacotada” em um item negociável: se você não quiser esperar o vencimento, basta vender; se tiver alguém disposto a assumir, a dívida na posição e o colateral também são transferidos juntos. Isso não é nada parecido com empréstimo tradicional. No empréstimo tradicional, sua posição é uma série de estados dentro de um contrato; para passar para outra pessoa não tem como — você só consegue fechar a posição, retirar o colateral e a outra parte reabrir tudo do zero, e fica aquela trabalheira toda. O GT empacota a posição inteira como um NFT: quer transferir, transfere; quer vender, vende. Um posto, um NFT — bem claro — sem interferir um no outro.

Eu achava que o GT era só um comprovante de direitos comum. Só agora entendi o valor real: é entregar de forma completa e intacta a propriedade de todo o seu empréstimo nas mãos do próprio usuário. Depois que o mainnet sair, eu pretendo abrir algumas posições com prazos diferentes e acompanhar ponto a ponto, posição por posição, como o GT se comporta no processo completo de liquidação no vencimento. #termmax @TermMax

Quando eu olhei para blockchains de privacidade antes, eu sempre pensei que as provas de conhecimento zero já seriam suficientes para atender a maior parte das necessidades criptográficas: basta colocar os parâmetros da transação na prova e deixar a execução a cargo da ZK Virtual Machine. Mas depois que eu pesquisei o modelo de transações do Phoenix, da Dusk, mudei essa visão. O verdadeiro desafio não é gerar uma transação anônima, mas sim manter continuamente, em ambientes complexos, regras de permissões de privacidade que estão sempre mudando.

Acho que o modelo de transações do Phoenix é mais parecido com um sistema de controle de acesso por níveis de um prédio comercial. Contratos de privacidade comuns são como uma chave fixa: enquanto você gerar uma prova válida, consegue destrancar. Já o sistema Phoenix é como um administrador dinâmico de permissões: ele não apenas verifica se você tem uma prova válida; também determina se o cenário da transação, as permissões de divulgação, as exigências de auditoria e o nível de conformidade atendem aos requisitos. Para aplicações de privacidade na camada de blockchain, essa avaliação dinâmica de permissões é ainda mais importante do que apenas gerar uma prova anônima.

A Dusk escolheu separar a camada de privacidade da camada transparente de EVM, essencialmente para resolver um problema de longo prazo. No passado, muitas chains de privacidade escreviam todas as regras de privacidade diretamente no contrato base; isso torna o custo de modificação alto e o risco de atualização também cresce. Conforme os cenários de aplicação ficam mais complexos e as necessidades de privacidade dos usuários ficam mais diversas, um único modo anônimo dificilmente consegue acompanhar demandas de negócios que mudam com frequência. Após a separação entre contas de dois modos, os desenvolvedores podem ajustar com mais flexibilidade o nível de privacidade, de modo que a privacidade da transação deixe de ser uma permissão permanente totalmente anônima.

Mas esse tipo de design também traz novos desafios de engenharia. Com o aumento do número de transações entre camadas, o custo de sincronização de estado sobe; a compatibilidade entre versões se torna mais complexa; e os desenvolvedores precisam investir mais tempo para entender a lógica de interação entre os dois modos. Além disso, a velocidade de geração das provas ZK, a experiência de integração com o SDK da Rusk e se usuários institucionais estarão dispostos a migrar também afetam o resultado real de implementação.

Na minha visão, o que a Dusk realmente precisa validar não é se a ideia de privacidade com ZK é conceitualmente correta, mas se esse sistema de privacidade em dois modos consegue ser usado por muitos desenvolvedores por um longo tempo. No futuro, vou continuar observando e testando os dados de transações entre camadas na testnet, a situação de integração dos desenvolvedores e a frequência com que as permissões de privacidade mudam em aplicações reais. Uma questão que vale refletir é: se no futuro houver cada vez mais cenários de privacidade na cadeia, precisamos de capacidades criptográficas mais fortes ou de um jeito melhor de gerenciar permissões de privacidade.
#dusk $DUSK @Dusk

@TermMaxFi Antes, fiquei 30 dias na Aave com taxa de juros fixa e acabei esbarrando em uma codificação de parâmetros que não dava para ajustar; no fim, perdi algumas centenas de dólares em rendimento. Então eu sou especialmente sensível às premissas subjacentes dos produtos de taxa fixa. Quando traduzo o whitepaper do TermMax, vi uma frase que a equipe sempre usa como narrativa central — quanto mais eu leio, mais parece uma “cicatriz de Aquiles” escondida: “A segmentação por vencimento via AMM é o melhor caminho para realizar taxa fixa on-chain na atualidade.” O ponto de partida do raciocínio é bem direto: como a taxa flutuante não consegue fazer precificação de longo prazo, usa-se pools segmentados para travar o rendimento até o vencimento.

Mas existe um silêncio mortal: a equipe do TermMax nunca discutiu o que aconteceria, segundo minha análise pessoal, se no futuro os protocolos principais de empréstimo passarem a suportar nativamente parcelas de taxa fixa. A segmentação nativa permitiria que o pool de taxa flutuante separasse diretamente um subpool independente de taxa fixa, sem precisar implantar, adicionalmente, um pool próprio de recursos até o vencimento. Isso é o Santo Graal da precificação de longo prazo para os entusiastas de empréstimos DeFi. Assim que os protocolos de empréstimo dominantes concluírem a atualização, aquelas soluções que hoje não conseguem ser evitadas — que dependem de pools independentes de taxa fixa — ressuscitam imediatamente com “plena vida”. Qual você escolheria: um produto que abre posições de taxa fixa diretamente no pool de empréstimo existente, sem exigir migração de liquidez entre protocolos; ou uma solução que precisa fazer market making separado, em que cada negociação deve casar com o lado contraparte do pool independente até o vencimento?

É como quando os feature phones levaram a interação por botões ao extremo; quando chegou a tela sensível ao toque, foi um ataque em outra dimensão. A AMM segmentada por vencimento hoje é o “feature phone” — a conciliação mais elegante quando a capacidade de taxas nativas on-chain é limitada. Assim que essa “palha” da segmentação de taxa fixa nativa cai, a narrativa existente pode virar de um dia para o outro.
$TMX? O TermMax diz que sua captura de valor vem do uso contínuo de transações de taxa fixa — fazer market making trava por meio de garantias com TMX, a distribuição de taxas é feita por meio da aposta/estaca do TMX, e a receita do protocolo é continuamente destruída via TMX. Mas, depois que a segmentação nativa gerar de fato a capacidade nativa de taxa fixa, quem ainda iria contornar os pools independentes de fundos segmentados? O modelo econômico do TMX está construído sobre a premissa de que protocolos genéricos de empréstimo não conseguem fazer taxa fixa; ao derrubar essa premissa, a narrativa de deflação se desfaz.

Minha posição: a AMM segmentada por vencimento é a solução ótima local sob as restrições atuais; não trate como verdade eterna. O protocolo base de empréstimos evolui: o “obstáculo” de travar taxa fixa de longo prazo hoje pode ser superado amanhã com uma única iteração de versão. O TermMax consegue se transformar de “produto de taxa fixa” para “camada de infraestrutura de taxas on-chain #termmax @TermMax ”?

我最近在对着Dusk的多账户并行测试几组交易流，原本以为隐私链主要处理加密和匿名。后来把透明EVM账户和隐私ZK账户的交易放在一起跑，才发现真正麻烦的不是怎么加密，而是两条都“合法”的交易同时上链时，系统该怎么在不泄露明文的前提下完成校验。我以前觉得隐私网络只要证明通过就行，现在越来越觉得，并行交易的冲突处理才是长期落地的核心难题。

这有点像商圈里的两条并行车道。每条车道单独看通行规则都没问题，但如果相邻车道的车辆变道规则不协调，整条路就会堵死甚至撞车。隐私交易网络也是一样，单条ZK交易的证明合法，并不代表多笔交易并行提交后，链上状态依然能保持一致。

Dusk把Phoenix隐私UTXO模型、Moonlight透明EVM层、Citadel计费证明模块和VEP定向披露机制组合起来，本质是在允许用户自主选择交易隐私等级。这样做的好处很明显，普通用户可以用隐私账户保护资产轨迹，机构用户可以用透明账户完成合规结算，不用被单一隐私模式限制。问题也随之出现：当一笔隐私交易要调用透明合约地址，另一笔透明交易要读取隐私账户的余额，节点如何在不泄露明文的前提下完成状态同步？过去很多隐私链没有这个问题，因为要么全匿名要么全透明，根本不存在双模式并行。

我现在看到的Trade-off很明确。隐私灵活性提高后，状态校验复杂度会上升；双模式账户越多，ZK证明生成成本越高；跨层交易频繁后，Gas计量和审计追溯的边界也会变得模糊。跨层交易延迟、证明验证失败率、定向披露的校验耗时，这些指标可能比TPS更能反映隐私公链的落地成熟度。
未来我会持续观察测试网上的跨层交易数据、官方更新的冲突修复记录，以及节点对双模式并行交易的处理方式。#dusk $DUSK @Dusk

Acabei de fazer os testes de interações do TermMax no período de 7 dias do pool time. A maioria das pessoas fala sobre taxas de juros fixas on-chain, só se importa se o retorno é alto. Raramente alguém ousa mencionar: o que acontece se o pareamento das ordens estiver errado, se houver problemas na liquidação/compensação de fundos—quem assume a responsabilidade, e qual é a penalidade para quem comete o erro. Esse tipo de problema é comum no mercado tradicional de renda fixa, mas no mundo on-chain é raro ver algum protocolo responder de forma direta. Ao verificar o @TermMaxFi na camada do teste do mainnet e do testnet, só então senti que ali é onde realmente está a competência técnica. Aproveitei também para corrigir e complementar um ponto que eu tinha dito antes de maneira não tão precisa.

Para uma mesma ordem de taxa fixa, é necessário fazer verificação dupla: o Fixed-Term TimeLock Module on-chain e um oráculo independente. Só após a conclusão do pareamento, é que a transação sobe para registro (on-chain). No texto original oficial, está escrito que esse mecanismo completo de validação end-to-end só é considerado totalmente configurado quando a fase de testagem pública (public testing) termina por completo. Nesta etapa atual, ainda estamos cobrindo gradualmente os pools de todo o intervalo de prazos; não é que esteja totalmente aberto no primeiro dia em que o mainnet é lançado. A garantia que os market makers depositam fica no pool de garantias isoladas (isolated collateral) do próprio protocolo. Eu testei: a janela de controvérsia é de 24 horas. Se, após a execução da ordem, houver retirada maliciosa (cancelamento) ou, de propósito, for informada uma taxa de juros falsa para perturbar o mercado, e um nó de arbitragem on-chain confirmar com sucesso o desafio, essa garantia será confiscada diretamente. Isso se chama “confisco por inadimplemento” (违约罚没). O custo de fazer o mal é dinheiro de verdade que não volta.

Da última vez, ao escrever $TMX e esse sistema de segurança, eu deixei tudo amplo demais, levando as pessoas a pensar que o que o market maker deposita é apenas TMX. Mas isso não é a mesma coisa. Ao consultar os materiais oficiais de divulgação do token (veja a Seção de distribuição de tokens na página 17), a função do TMX nesta fase se divide em quatro partes: recompensas de mineração para provedores de liquidez; taxas de protocolo ao criar e ao registrar ordens; a garantia de TMX que o market maker precisa depositar quando presta serviços; e o direito de voto de governança sobre parâmetros de taxa obtidos após o staking. O que torna o TMX a base nativa de taxas e de staking de toda a rede—segundo o que o oficial escreve—é algo que só se torna totalmente efetivo quando a versão V2 com os pools de prazos cross-chain estiver rodando oficialmente. Ainda não chegamos lá.

Ao olhar as duas linhas do tempo em conjunto, o ciclo completo de taxas fixas deste projeto ainda está sendo montado por fases. Hoje, $TMX está mais voltado à governança e aos incentivos iniciais; o peso de manter a segurança da liquidação/compensação de fundos em toda a rede está agora do lado do contrato de lock de tempo isolado. #termmax @TermMax

Eu testeie o registro de nós da rede de testes Dusk por quase uma tarde inteira. Os cubos de gelo no meu iced americano na mesa derreteram completamente. A água que condensou na borda do copo encharcou o mousepad, deixando um anel molhado. Eu coloquei o mouse no dock de carregamento sem fio e fiquei ali parado por cinco minutos; de repente, me dei conta de uma pergunta que vinha me travando: há muitos projetos de blockchain de privacidade por aí — por que o Dusk acabou escolhendo a Rusk, uma máquina virtual nativa de privacidade, e não apenas acoplar um plugin de privacidade com ZK em cima do EVM? No começo, achei que era simplesmente uma escolha de rota técnica. Depois, reli várias vezes os materiais oficiais sobre o modelo de transações Phoenix e privacidade ponta a ponta e percebi que estava simplificando demais.

O ponto mais crítico da aplicação de privacidade não é, na verdade, a própria prova de conhecimento zero, mas o risco de vazamento de estado em toda a cadeia. Se você só adiciona um “invólucro” de privacidade na camada de transações do EVM, deixando rastros em texto claro por toda parte no armazenamento do contrato, na pilha de execução e nos logs de eventos, qualquer vazamento em qualquer etapa invalida todo o trabalho de proteção anterior. O Dusk começa com o design nativo de privacidade já na base, na máquina virtual Rusk; além disso, usa provas recursivas do PLONK para ancorar o estado. Para um nó concluir a validação de uma transação privada, basta 1,2 segundo — quase 4 vezes mais rápido que as soluções que usam um plugin ZK sobre o EVM. Em outras palavras, é um ajuste consciente entre profundidade de privacidade, eficiência de desenvolvimento e segurança, e não uma busca cega por “falar com compatibilidade EVM para acelerar o ecossistema” com retorno de curto prazo.

O que realmente me fez mudar de ideia foi outro detalhe. A equipe enfatiza repetidamente que os nós cuidam da validação de transações, não de guardar dados em texto claro em nome dos usuários. A execução da transação pode se apoiar em um espaço de estado criptografado para rodar, mas o controle dos ativos e a chave de visão direcionada continuam sempre nas mãos do próprio usuário. Foi isso que me fez entender que o Dusk não está apenas mudando a forma de implementar a funcionalidade de privacidade — está ajustando a camada mais central de confiança na blockchain pública: reduzir ao máximo a parte que exige que nós sejam confiáveis e ampliar o máximo possível a parte que pode ser verificada por criptografia.

No fim, a privacidade ponta a ponta é apenas uma apresentação de recursos do produto. Mas este modelo de confiança — “sem percepção do nó + usuário com controle próprio” — é o que @dusk_foundation realmente vale a pena pensar e que é mais difícil de copiar #dusk $DUSK @Dusk

Recentemente, eu estava relendo de novo o mecanismo de AMM de taxa fixa do @TermMaxFi. O que me prendeu por vários dias foi um problema bem bobo: para que empréstimos DeFi entrem em cenários financeiros mais “mainstream”, o que realmente falta—mais tipos de ativos para empréstimo, ou um método de precificação que não exija que o usuário assuma o risco de volatilidade das taxas? Depois de comparar várias vezes a Seção 4 do whitepaper com os dados reais de transações do site, eu fico com a impressão de que o que o TermMax quer resolver não é o problema superficial de “taxa alta vs. taxa baixa”; o ponto central é como tornar o custo do capital de empréstimos on-chain previsível. #TermMax

Antes, quando o DeFi brincava com empréstimos, o caminho era basicamente modelos de taxa variável. Ao tomar empréstimo, você só via a APY do momento e, na prática, não tinha como saber se daqui a três dias a taxa seria puxada para um nível absurdo por causa de uma grande ordem. Tanto Compound quanto Aave e Morpho melhoraram, sim, a eficiência de capital—mas o preço é que cada participante precisa assumir a incerteza da volatilidade das taxas. Os instrumentos de empréstimo podem até ter aumentado, mas a estabilidade do custo do capital, que antes era a parte mais importante, virou uma variável que muda a qualquer momento. O TermMax parece diferente justamente porque ele nem tenta “consertar” o modelo de taxa variável.

De acordo com o que a própria equipe diz, para cada data de vencimento existe um pool de liquidez independente com uma curva de taxa fixa. Usando mecanismos como market making no AMM por vencimento segmentado e precificação por estratificação de liquidez, o custo de empréstimo de diferentes prazos é limitado antecipadamente. A lógica de precificação da taxa não muda do começo ao fim; o que muda é o grau de previsibilidade que o usuário tem sobre o custo futuro do capital.

Acredito que o que realmente vale a pena “mexer” é a camada de precificação. O usuário não precisa adivinhar se o próximo bloco vai trazer um empréstimo grande o suficiente para “arrebentar” a taxa. Também não precisa apostar se o protocolo vai ajustar parâmetros do nada e mudar o modelo de taxas. O TermMax, ao fazer o market making automatizado por vencimento segmentado, e ao empilhar uma camada de reservas geradas pelo acúmulo de multas de liquidação, converte taxas de diferentes prazos em um custo fixo que o usuário consegue travar diretamente.

$TMX profundidade de liquidez, taxa de desvio de juros e reserva de risco—para falar a verdade, ainda precisam de tempo para serem validados; não dá para tirar conclusões agora. Mas o TermMax, pelo menos, me deu um alerta: depois que o DeFi de empréstimos se conectar com capital mais mainstream, talvez não seja necessário copiar exatamente aquela estratégia de taxas variáveis. Também dá para tentar, mantendo a segurança e a descentralização do modelo on-chain, fazer com que o usuário primeiro tenha acesso a um custo de capital determinado. #termmax @TermMax

Antes de entrar em protocolos DeFi, meu padrão era simples e brutal: quanto maior o TVL, mais seguro.

Esse raciocínio me sustentou por vários anos. Aave, Morpho e outros protocolos de ponta: seus TVLs chegam facilmente a dezenas ou centenas de bilhões. O dinheiro está lá dentro; o que poderia dar errado? Então, quando o TVL da TermMax era “apenas” 90 milhões, eu realmente nem olhei direito.

O que mudou minha opinião foi uma conversa casual.

Um amigo perguntou: “Por quanto tempo você vai deixar seus USDC?” Eu disse que esperaria uma oportunidade, sem ter certeza. “E qual é o custo de capital nesse período?” Eu travei — deixando os fundos no Aave para ganhar juros flutuantes: hoje pode ser 4%, amanhã talvez seja 3%. Eu simplesmente não conseguia responder “qual é o custo”. Eu apoiei o celular na mesa e não disse nada; durante a segunda metade do jantar, fiquei meio distraído.

Voltei e pesquisei a TermMax com seriedade, e só então percebi que o problema que ela resolve é completamente diferente do Aave.

A lógica central da TermMax é a tokenização de taxa de juros fixa. O token de dívida é dividido em FT e XT: o FT é um título de cupom zero (zero-coupon), que pode ser vendido com desconto antes do vencimento; o XT é um token que representa direitos sobre os rendimentos, cujo valor vai se aproximando de zero à medida que o vencimento se aproxima. A qualquer momento, 1 FT + 1 XT = 1 token de dívida — essa identidade garante uma precificação transparente no mercado de taxa fixa. O GT é um token de alavancagem no padrão ERC-721, que representa uma posição de empréstimo independente. O tomador trava o ativo como colateral no GT e, com base na taxa máxima de empréstimo sobre o valor do colateral (MLTV) definida pelo mercado, cunha a quantidade correspondente de FT. Se o valor do colateral cair e o LTV (loan-to-value) exceder a MLTV, a posição é liquidada.

A relação entre FT e XT, na primeira leitura, não me pareceu nada demais; na segunda, foi quando eu vi aquela frase — depois que entendi, toda a lógica ficou clara.

Esse mecanismo resolve um problema que o Aave nunca conseguiu resolver — a previsibilidade do custo de capital.

O Aave é mais como um banco on-chain, focado na eficiência do fluxo de fundos. A TermMax permite que ambas as partes do empréstimo concordem, já no início da transação, com uma taxa de juros fixa e um prazo fixo. Comecei a fazer as contas: se eu tivesse travado aquela quantia ociosa em uma taxa fixa pela TermMax há quase meio ano, eu não só saberia antecipadamente quanto receberia no vencimento, como também os fundos não ficariam parados durante o período em que as ordens com limite ficam aguardando — eles automaticamente entram no cofre da Morpho para gerar rendimento flutuante e, quando a correspondência for bem-sucedida, alternam de forma contínua para a taxa fixa.

TVL é um indicador de escala; taxa fixa é um indicador de determinismo. #termmax @TermMax

Desta vez, ao ver o anúncio de lançamento do módulo de conformidade do Citadel na mainnet da Dusk, eu queria investigar os detalhes da auditoria de segurança dos circuitos de provas de conhecimento zero, mas quando vi os primeiros parceiros de implantação citados oficialmente, fiquei atordoado — não eram empresas de segurança especializadas em auditoria criptográfica, e sim a bolsa digital licenciada na Holanda, NPEX, e a consultoria de conformidade com a MiCA da União Europeia, DAC8
Minha reação imediata foi estranhar: a Dusk é uma blockchain de privacidade ponta a ponta com transações executadas de forma privada; por que, no módulo de conformidade, o elenco de estreia veio de duas instituições financeiras licenciadas, e não de uma equipe de segurança focada em ofensiva e defesa criptográfica?
Depois de ler alguns blogs técnicos oficiais, entendi a intenção por trás desse arranjo. O módulo de conformidade zkUT da Dusk, na essência, é um executor de transações de privacidade. Mesmo que o circuito ZK esteja escrito de forma impecável, se a transação consegue — ou não — ser colocada legalmente em execução, no fim depende de o conjunto de provas que ele produz atender aos requisitos de conformidade do regulador. Por exemplo: uma transação de ações tokenizadas pode ter anonimidade perfeita, mas, se não cumprir as exigências de auditoria direcionada da MiCA, a licença de emissão simplesmente não é obtida e o capital das instituições não entra no negócio; da mesma forma, uma transferência de uma instituição que atende à lista branca, mesmo com anonimidade muito boa, não consegue circular no ecossistema de corretoras em conformidade sem o endosso de identidade em uma instituição licenciada.
Ao tornar essas duas empresas os parceiros do “primeiro lançamento”, a mainnet, na prática, faz um reconhecimento oficial de algo: no primeiro dia de operação do módulo de conformidade, se ele é confiável ou não, metade do mérito está nos próprios circuitos ZK e na lógica de staking de anonimato do Dusk, e a outra metade é colocada diretamente sobre esses parceiros de conformidade. Essa descoberta me fez reconsiderar a privacidade que ele se vende como “ponta a ponta”. As provas recursivas PLONK somadas ao modelo de transações privadas da Phoenix garantem que o processo de execução da transação não seja adulterado, e que a etapa de computação e privacidade seja confiável. Mas se a transação será reconhecida pelo regulador e se consegue se integrar ao sistema financeiro tradicional é outra barreira de implementação, totalmente independente; o código técnico da Dusk não controla isso. Só dá para garantir via a integração com parceiros de conformidade licenciados: para cada transação em conformidade, registrar as autorizações em uma prova verificável direcionada com carimbo de data e hora, e gravar essa prova na blockchain para conferência posterior pelos reguladores.
Eu achava que a confiabilidade desse sistema de privacidade era algo “em um único bloco”. Agora percebi que são duas camadas de confiança sobrepostas: privacidade confiável em termos técnicos não implica “admissão confiável” em termos de conformidade. Precisei separar as duas coisas. Depois de esclarecer essa camada, minha avaliação sobre o lançamento do módulo de conformidade
#dusk $DUSK @Dusk

Passei presque tout l’après-midi à déboguer des logs sur le testnet, et les glaçons de mon iced americano avaient complètement fondu sur la table. L’eau condensée le long des parois avait fini par former une auréole humide sur le tapis de la souris. Puis j’ai posé la souris sur le socle de charge sans fil et je suis resté assis là, hébété, pendant cinq minutes—avant de me rendre compte d’un point anormal : dans la chaîne PoS, les registres de mise des validateurs sont tous publiquement accessibles sur la blockchain. L’attaquant n’a qu’à retrouver les nœuds à partir des adresses de mise ; quant aux chaînes de confidentialité, même les montants des transactions sont chiffrés… mais on ne peut quand même pas laisser les identités des validateurs à découvert, non ? Auparavant, je supposais que la logique de mise d’une chaîne de confidentialité était à peu près la même que celle d’un PoS classique, jusqu’à ce que je tombe sur le module de mise anonyme de Citadel de Dusk. Là, je me suis rendu compte qu’il faisait aussi—au-delà de l’anonymisation de l’adresse—une confidentialité “bout en bout” jusque dans l’identité qui signe les blocs.

Au début, je pensais juste que c’était un système qui mélangeait l’adresse de mise avec d’autres, mais en examinant de près les circuits ZK du contrat de mise, j’ai compris que ce n’était pas aussi simple : l’objectif n’est pas seulement de “cacher” l’adresse. Il s’agit de garantir ceci : sans exposer votre adresse de mise ni le montant précis que vous mettez, vous pouvez prouver à tout le réseau que vous remplissez le seuil minimal et que vous êtes autorisé à participer à la consensus.

Le mécanisme Citadel, basé sur des preuves récursives PLONK, vise précisément à résoudre l’impasse que toutes les chaînes PoS doivent affronter : les registres publics de mise. Lorsque les utilisateurs mettent des DUSK, les tokens sont verrouillés dans un pool de mise anonyme unifié. Le montant, la durée de verrouillage et les associations d’adresse sont tous traités via des techniques d’obfuscation. Les autres nœuds ont seulement besoin de 8 secondes pour vérifier : ils ne voient ni l’association à l’adresse de mise, ni un lien permettant de faire correspondre la signature de production de bloc à une adresse précise.

Mais je dois dire la vérité : ce type de conception exige une très grande précision dans les circuits ZK. Si une contrainte est écrite de travers, il pourrait exister un risque de preuves falsifiées. De plus, l’ingénierie nécessaire pour punir exactement (et précisément) les nœuds malveillants est bien plus difficile que dans un système de mise publique. Cette partie est encore en cours de tests. Est-ce que cette voie peut fonctionner à grande échelle ? Il faudra le vérifier avec le temps. Mais au moins, cela montre que Dusk prend la confidentialité très au sérieux—dès la base du protocole de consensus. À ton avis, l’identité des validateurs sur une chaîne PoS axée confidentialité doit-elle, oui ou non, être publique ? Discutons-en dans la section commentaires.
#dusk $DUSK @Dusk

Ontem à noite fiquei até tarde trabalhando, dando uma “escapadinha” e rolei até o novo site do Dusk entrar no ar. Entrei pensando, no máximo, “ah, é só uma reformulação com outra pele”. No site antigo, pra achar documentação técnica eu tinha que clicar em três ou quatro links, e às vezes dava 404. Aí, no novo site, eu fiquei uns 20 minutos entendendo aqueles diagramas em camadas empilhados—consegui conectar todas as minhas noções soltas de projeto num todo coerente.

O novo site quase não joga conversa de marketing: ele abre a stack técnica, do nível mais baixo ao mais alto. Na base está o DuskDS, que lida com consenso, finalização (settlement) e disponibilidade de dados. A camada de consenso usa SBA, um mecanismo PoS baseado em comissões. Nele, Proof-of-Blind-Bid (prova de lance cego) seleciona anonimamente o produtor do bloco; a lista de validadores muda a cada rodada—foi desenhado assim para impedir que validadores sejam pré-determinados e atacados, e para evitar que, no PoS tradicional, grandes players monopolizem o poder de gerar blocos. A camada de transações é a Phoenix: baseada no modelo de anotações (notes) do UTXO. Os fundos ficam existindo como “notes” criptográficas; junto com compromissos de Pedersen pra ocultar valores, e invalidadores pra barrar double-spend. Os nós só verificam se as provas de conhecimento zero são válidas. Quando eu testei antes e tentei colocar texto puro direto numa transação, fui recusado—foi quando percebi que essa regra é “forjada” desde a camada de consenso.

Subindo: a camada Dusk Trade. Eu achava que era um privacy DEX comum só com “casca”. No walkthrough do site, vi que ela chama diretamente os canais de settlement da camada de baixo. A ordem (order book) já vem com criptografia por padrão, usando criptografia homomórfica com ElGamal. O preço e a quantidade dos pedidos na cadeia ficam como cifras; o motor de matching consegue calcular a correspondência mirando nas cifras. Depois que o preço e a quantidade fechados estão determinados, a transação é descriptografada—com os detalhes da ordem permanecendo sem exposição o tempo todo. Ainda acima tem uma camada chamada DuskEVM: uma camada de execução baseada no OP Stack modificada, fazendo settlement diretamente sobre o DuskDS. Se você conecta Sol, herda as capacidades de privacidade da camada inferior, sem precisar “reinventar a roda”. No topo está um fluxo de trabalho de mercado voltado à conformidade: transforma o Citadel num módulo nativo invocável. O usuário não precisa enviar foto de passaporte—ele prova por zero knowledge que “já concluiu a verificação de conformidade” diretamente para o sistema.

Eu sempre senti que o caminho técnico do Dusk era meio espalhado em partes. Só agora, vendo o novo site com o stack completo, entendi: desde o início, não é um projeto feito pra brincar de transferências anônimas, e sim pra montar uma base completa de finanças com privacidade e compliance. Depois de terminar, eu ainda comprei um pouco de DUSK—porque projetos que deixam toda a arquitetura técnica claramente exposta para todo mundo ver são mesmo raros. #dusk $DUSK @Dusk

真话说，我一开始也以为Dusk只是炒作匿名叙事的老套路。直到上周跟着Discord社区蹲主网RC2测试：凌晨三点冰美式都喝温了，Gas设低了卡了20分钟，还跑去找管理员吐槽。测着测着才发现，这玩意儿跟之前我玩过的隐私链根本不是一个东西。

大部分隐私链的加密是写在智能合约层的。相当于你家门锁装在客厅——真有贼撬了窗户翻进来，家里东西全看得见。去年我测某条热门隐私链，就是因为合约权限漏洞：测试网所有转账明文直接漏在区块浏览器里。我当时留的测试地址被垃圾空投骚扰了两个月。Dusk直接把Pedersen承诺加密焊死在SBA共识层：资产从进mempool开始就是加密状态。节点哪怕拿到全量区块数据，也只能读到“交易合法”的零知识证明，半毛钱明文金额、地址都摸不到。我故意往节点接口塞明文交易数据，直接被共识层丢了回来，连验证环节都进不去。

之前我最烦隐私链的KYC问题。去年用某合规隐私链，把护照照片传到第三方插件，转头就收到了海外理财垃圾短信。Dusk的ZkKYC直接嵌在Rusk虚拟机里：你的KYC凭证存在自己本地，交易时只生成个证明“我符合监管要求”，连项目方都拿不到你的身份信息。给监管开审计视图也只能看指定交易。现在他们刚合并FRI+PLONK混合证明的PR：单笔验证压到1.4毫秒，跑机密合约Gas比EVM套ZK层低67%。我部署测试债券合约，连20行代码都不到，Gas才花了0.28 $DUSK 。

之前在老隐私链套牢亏了小两千U，我一直觉得隐私和合规就是天生的死对头：要么做全匿名的灰产温床，要么做扒光用户隐私的“合规链”。跑完Dusk测试我才明白：隐私本就不该是灰产遮羞布。用户的资产和身份数据从来都该自己握着，合规也不该以牺牲隐私为代价。Dusk是真从底层把这个拧巴了快十年的死结剪开了@Dusk
#dusk $DUSK

A criptosfera já não tem liquidez, como o mercado de ações da China — #闪迪股价涨幅扩大至11%

No fim de semana, fui ao café embaixo de casa para “dar uma chance” ao ar-condicionado durante os testes da rede do Dusk, sentei e esperei — depois errei a senha três vezes seguidas. Foi preciso quase meia hora só para concluir a 21ª transação. Fiquei encarando por um bom tempo os logs de execução da máquina virtual Rusk; antes eu já tinha brincado com algumas antigas cadeias privadas: ou travavam por horas sem produzir blocos, ou faziam anonimato até o último nível de conformidade, de modo que não dava para abrir permissões de auditoria. No fim, eu já não tinha nenhuma expectativa com esses “blockchains de privacidade” — até cair na armadilha com as minhas próprias mãos e perceber que isto não é só uma carcaça para炒 conceito.

No começo, eu considerei o consenso SBA como uma espécie de PoS com outra pele. Depois de revisar as regras dos nós e rodar dez mil simulações de double-spend, só então entendi: o SBA (Segregated Byzantine Agreement, Acordo Bizantino Segregado) divide os nós em duas camadas. Uma camada é o comitê de produção de blocos, responsável por empacotar transações; a outra é o conjunto de validadores de amostragem, que realiza auditorias aleatórias. A semente dessas amostragens é gerada por um VDF (função de atraso verificável), então ninguém consegue prever antecipadamente quem será verificado. O navegador da testnet mostrou que havia 3 nós que perderam seus depósitos por enviarem blocos inválidos: dois foram punidos “suavemente” — faltaram alguns blocos, então foram removidos temporariamente da fila de consenso, e o valor de staking efetivo foi reduzido; o outro foi punido “duro” — foi pego em dupla assinatura (double-sign), e os tokens de staking foram diretamente reduzidos em 20% e destruídos. Mecanismos de punição como esses elevam bastante o custo de agir mal, e o preço de tentativa e erro é enorme.

Durante os testes de transações, por engano eu coloquei um 0 a mais. O valor imediatamente saiu do intervalo permitido pelo Range Proof, e a transação foi rejeitada instantaneamente, sem deixar nem sequer rastro de “transação inútil” na cadeia. O Range Proof do protocolo Phoenix “trava” rigidamente o intervalo de valores de transação; em combinação com o compromisso Pedersen, ele fixa a quantidade total de ativos de cada operação, impedindo criação “do nada”. Além disso, usando Stealth Address descartável (endereços furtivos renovados automaticamente a cada transação), eu consegui fazer 5 transferências de teste consecutivas: na cadeia, nem dá para associar essas 5 transações à mesma conta. As provas PLONK de agregação recursiva ficam comprimidas em 287 bytes; a verificação de cada transação leva apenas 1,8 ms. Rodar foi bem tranquilo, e também não encontrei congestionamento durante o pico da testnet.

A máquina virtual Rusk foi escrita do zero totalmente em Rust; ela suporta nativamente o padrão de ativos confidenciais. Ao implantar meu Token de teste, nem precisei escrever código de privacidade — nem chegava a 200 linhas. O Gas para rodar contratos ficou 63% menor do que quando se usa um ZK “por cima” no EVM, e ainda deixou uma porta de entrada de permissões de auditoria para o lado da conformidade. Privacidade e conformidade não precisam ser “ou uma coisa ou outra”; dá para ter as duas. Naquela noite em que a testnet terminou de rodar, eu fiquei bem mais tranquilo do que em qualquer projeto que eu tenha investido junto anteriormente.
#dusk $DUSK @Dusk