Ra44

A pontuação de DeFiSafety de 93% da TermMax é citada constantemente. A análise é mais útil do que o título.
Seis categorias. Código e Equipe 100%. Oráculos 100%. Controles de Administração 97%. Segurança 94%. Testes 89%. Documentação de Código 70%.
A documentação é a mais baixa por uma ampla margem, e é a única categoria que a maioria dos usuários realmente toca. Você nunca vai ler a suíte de testes. Você vai ler a documentação.
Encontrei evidências de apoio enquanto analisava isso. O FAQ diz que provedores de liquidez ganham rendimento a partir de um token de LP chamado lp-FT. Não consegui encontrar o lp-FT definido em nenhum outro lugar na documentação.

Nada disso torna o protocolo inseguro. Setenta ainda passa do limite, e as categorias que realmente protegem os fundos pontuaram mais alto — que é a ordem certa para ser forte.

Mas isso significa que a maior diferença na pilha está entre o que os contratos fazem e o que um leitor consegue descobrir.

A pontuação de documentação deveria pesar tanto quanto a pontuação de segurança para alguém que deposita dinheiro de varejo?

#termmax @TermMax

#dusk $DUSK @Dusk
Earlier, I used to think tokens only ever move. They are created once, then they change hands until someone stops trading them. Movement seemed like the whole vocabulary.
Looking at what securities actually do over their lives, I realised that vocabulary is missing a word.
A bond matures. A fund unit gets redeemed. The instrument does not get passed to a final owner and sit there. It is settled and then it ceases to exist, because the obligation behind it has been discharged.
So a system built for these assets cannot only handle transfer. It has to handle the moment an asset is legitimately destroyed, and it has to do that in a way that leaves a record convincing to whoever asks later.
What I found notable is how rarely this appears in tokenization discussions. Almost every explanation stops at issuance and trading, as if the interesting part were getting the asset on-chain and keeping it there.
But the end of an instrument is where the money actually comes back to the holder, and getting that step wrong is far more consequential than a slow transfer.
I do not know how this is handled in practice when the payment is made off-chain and the token is destroyed on-chain, which seems like the moment where the two records could most easily drift apart.
From here I started reading lifecycle rather than ownership. Issuance is where the story begins, and redemption is the part that actually has to work.

#dusk $DUSK @Dusk
When I first read that a licensed institution intends to bring a large amount of assets onto a chain, I treated that number as a result. Something that had happened.
Looking at it more carefully, I realised I was reading an intention as an outcome.
A figure like that describes assets that an institution plans to represent on-chain. It does not describe how often those assets move, how much value settles through the chain in a given month, or how much activity the network actually processes because of them.

Those are separate measurements, and they behave differently. An asset can be issued on-chain and then sit completely still for years, which is entirely normal for many instruments. Nothing has gone wrong. It simply means the headline figure and the network's activity are answering different questions.

What caught my attention is how easily the two get merged in discussion, including by me. A large number appears, and it feels like proof of adoption, when it is really a statement of intent by one institution.
That does not make it meaningless. An institution with a licence choosing to commit anything at all is a real signal, and a harder one to obtain than most crypto partnerships.

But I would want to see the second set of numbers before drawing conclusions, and I am not sure those are publicly available yet in a form I could rely on.
Maybe that is the more useful habit. When a number appears, asking whether it describes something that happened, or something that someone intends to happen.

#dusk $DUSK @Dusk
So which rules actually apply to a tokenized bond in Europe?
In the past, I assumed the answer was simple. Europe passed a large crypto regulation, so crypto in Europe is covered by it, and a tokenized asset is crypto. That is roughly how the topic gets discussed, and I never questioned it.
But reading about what Dusk is trying to build, I started to see that the assumption breaks in an important place.
Europe's crypto-asset framework was written for things that did not already have a legal home — utility tokens, stablecoins, and the businesses providing services around them. It filled a gap.
A tokenized bond or a tokenized share is not in that gap. It is a financial instrument, and financial instruments were already regulated long before any of this existed, under a completely different body of rules built for securities markets. Putting one on a blockchain does not move it into the newer framework. It stays where it always was.
What I found particularly notable is how much this explains about the way a project like Dusk is structured. If the asset stays inside securities regulation, then the chain cannot simply be compliant by itself. It has to work alongside licensed venues and licensed intermediaries who already hold the permissions that this asset class requires.
That reframes partnerships for me. They are not marketing milestones. They are the mechanism by which the thing becomes legal to use at all.
I am not qualified to say where the responsibility divides between the protocol and the institutions using it, and I would want a specialist rather than a confident opinion on that.
But from here I stopped reading regulatory claims as a single yes or no. The rules that apply depend on what the asset is, and tokenizing something does not change what it is.

#dusk $DUSK @Dusk Antes, eu achava que uma transferência em blockchain tinha apenas dois resultados possíveis: ela é bem-sucedida ou falha. Sucesso significava que o valor foi movido. Falha significava que algo deu errado. Mas, quanto mais eu investigava como a Dusk descreve transferências de ativos regulados, mais eu percebi que esse modelo é simplista demais para os mercados financeiros.
Em uma cadeia comum, uma transação rejeitada não lhe diz praticamente nada. O gas acabou, uma instrução require foi acionada, o estado mudou por baixo de você. Você fica tentando adivinhar o quê exatamente aconteceu.
Para um ativo regulado, essa ambiguidade não é aceitável. A documentação da Dusk descreve verificações de transferência que falham com razões claras e — a parte que achei mais interessante — verificações que podem ser simuladas antes de qualquer transação ser enviada.
O que achei particularmente notável é a implicação desse segundo ponto. Isso significa que a elegibilidade não é algo que você descobre tentando fazer uma transferência e vendo ela falhar. Você pode fazer a pergunta primeiro e receber uma resposta, sem sequer tocar no ledger.
Isso reflete como o lado tradicional já funciona. Um corretor não envia uma ordem e espera que o sistema de conformidade permita. A verificação acontece antes; e, quando uma negociação é recusada, alguém consegue explicar com precisão por quê — a contraparte não estava credenciada, o período de carência ainda não havia transcorrido, a jurisdição estava restrita. "Rejeitada" sem um motivo não é uma resposta utilizável em um processo regulado.
A falha vira informação, e não um acidente. E uma rejeição que traz um motivo é, de forma argumentável, mais útil do que um sucesso que não traz nenhum.
Ainda não consigo avaliar o quão detalhadas essas razões são na prática, nem quanto disso está disponível para uma aplicação hoje, em vez de estar descrito apenas como uma meta de design.
A partir daí, comecei a enxergar o design de outra forma. A conformidade on-chain talvez não seja sobre bloquear transações ruins. Talvez seja sobre tornar o resultado previsível antes de qualquer pessoa se comprometer com ele.

#dusk $DUSK @Dusk Solidity developers don't want to relearn an entire toolchain just to try a new chain.

So making DuskEVM OP Stack-compatible looked like a smart move at first glance.

Developers can use Solidity and familiar EVM tooling instead of starting from zero. But DuskEVM is only the execution layer. Final settlement and data availability run through DuskDS, Dusk's base layer with deterministic finality.

That is a genuine attempt at the best of both worlds.

Keep Ethereum's developer experience, while anchoring applications to infrastructure designed around financial settlement.

But the architecture creates a second question.

Every time execution and settlement live on different layers, the connection between them becomes critical. Value, state and proofs have to move safely between DuskEVM and DuskDS.

And historically, bridges and cross-layer interfaces have been some of crypto's most fragile infrastructure.

Dusk itself learned a version of that lesson in January when its separate Dusk↔BSC bridge suffered a signing-wallet compromise. That was not an exploit of DuskEVM or its DuskDS settlement path, so the two should not be confused.

But the principle still matters: the base chain can remain secure while infrastructure connecting two environments becomes the weaker point.

Dusk describes the DuskDS↔DuskEVM bridge as native and trustless, without external custodians or wrapped assets.

That is encouraging, but as more applications and value move onto DuskEVM, the security assumptions behind that settlement path become more important, not less.

EVM compatibility lowers the barrier for builders.

It also gives Dusk another boundary that has to be defended perfectly.

Is EVM compatibility simply a necessary trade-off for adoption — or does every privacy-first chain that adds an EVM layer also expand the attack surface it has to protect?

$DUSK @Dusk

Duas frases das páginas de TGE da TermMax que vão mudar o que algumas pessoas vão fazer esta semana.
Uma. Se você vir um Genesis Reward na página de verificação — descrito como uma recompensa especial para contribuintes antigos e de longo prazo — ele já está incluído na alocação total mostrada no topo.
Não adicionado. Incluído.
Isso é o oposto do que uma linha de bônus parece dizer intuitivamente. E se você está acima do limite de aquisição e precisa decidir entre perder 70% e adquirir 85%, inflar seu próprio número-base muda a resposta que você chega.
Duas. Não há limite de tempo para reivindicar seu TMX que pode ser reivindicado instantaneamente. A página de Management diz isso diretamente — volte e reivindique quando quiser.
Essa é uma boa decisão de design de verdade, e mais rara do que deveria ser. Muitos lançamentos colocam uma data de expiração em tokens não reivindicados, o que empurra todo mundo para negociar no pior dia possível em termos de gás e de preço.
Junte tudo e você obtém a coisa que a maioria das pessoas vai entender ao contrário esta semana.
A decisão é urgente. 23 de agosto, 23:59 UTC. Se perder, o maior período de bloqueio será atribuído a você.
A transação não é urgente. De forma alguma.
Então a pressa pertence à escolha, não à reivindicação. Espere que muitas pessoas corram para reivindicar no primeiro dia, seja lá o que o mercado estiver fazendo, enquanto tratam a data limite como algo para resolver depois.
Exatamente o inverso.
Qual data limite você está tratando como realmente verdadeira?

#termmax @TermMax

Pequeno detalhe, desproporcionalmente interessante.
Transações de crepúsculo podem carregar um memo de até 512 bytes. Existem quatro tipos de transação no total: uma transferência regular, uma chamada de contrato, uma implantação de contrato e uma transferência com memo.
Por que existe um campo de memo em uma cadeia construída em torno de confidencialidade?
Corretoras. A nota de engenharia que o introduziu diz que o objetivo é permitir que uma corretora direcione contas internas enquanto usa uma única chave ou endereço de recebimento. Quem já depositou em uma corretora na Cosmos ou no XRP conhece exatamente esse ritual — um endereço compartilhado e uma tag que diz qual cliente é.
Então, numa cadeia cujo discurso inteiro é "nem tudo precisa ser público", a realidade operacional da integração com corretoras produziu um campo em que você escreve, às claras, a qual conta este pagamento pertence.
Eu não acho que seja hipocrisia. É o mesmo princípio @Dusk que insiste: divulgação deve ser uma escolha, aplicada onde faz sentido, não um padrão aplicado em todo lugar. Um memo de depósito é um lugar em que ser legível é exatamente o ponto.
Mas 512 bytes é bastante espaço, e campos de propósito geral nunca ficam no lugar deles. Memos em outras cadeias viraram referências de fatura, IDs de pedido, mensagens e, ocasionalmente, coisas que ninguém planejou. Qualquer coisa que acabar ali é registrada em um livro-razão público permanentemente, por usuários que não estarão pensando sobre isso.
A questão interessante não é o campo. É o que as pessoas colocam nele quando o volume chega, e se alguém está observando.
Se você integrou uma cadeia com depósitos baseados em memo — qual é a coisa mais estranha que você já viu alguém escrever em um?

#dusk $DUSK @Dusk

O DUSK nativo tem 9 casas decimais. Um DUSK é 1.000.000.000 LUX.
ERC20 e BEP20 $DUSK têm 18.
Fiquei encarando essas duas linhas na página de tokenomics por mais tempo do que eu esperava, porque são o tipo de detalhe que nunca gera uma discussão, mas absolutamente gera um ticket de suporte.
Duas consequências que fico virando de cabeça para baixo.
Uma: LUX é a resolução de todo o mercado de taxas. O preço do gas é definido em LUX por unidade de gas, e a taxa é o gas usado vezes o preço do gas. Nove casas decimais é o mais fino que @Dusk pode ser precificado. Para uma cadeia mirando liquidação de valores — onde a matemática de cupons, divisões de dividendos e participações fracionárias são comuns — esse limite é um parâmetro real de projeto, não um detalhe.
Nove é suficiente para um token. Se é suficiente para cada instrumento que eventualmente liquida contra ele é outra questão.
Duas: reduzir de 18 para 9 não é uma mudança sem perda. Qualquer coisa abaixo da nona casa decimal no Ethereum ou na BSC não encontra um “lugar” na mainnet. Alguém precisa decidir se esse pó arredonda, trunca ou bloqueia — e essa regra importa mais exatamente para as pessoas para quem o guia de migração foi escrito.
Eu li o guia de migração e o guia da ponte BEP20 e não encontrei essa regra declarada de forma clara. Pode ser tratada corretamente e simplesmente não documentada. Pode estar documentada em algum lugar a que eu não cheguei.
Por isso eu prefiro perguntar a supor.
Se você migrou ERC20 ou BEP20 DUSK para a mainnet — seu saldo caiu exatamente, ou os últimos dígitos foram para algum lugar?

#dusk @Dusk $BTC

Um clique, três coisas separadas

Alavancagem de um clique soa como uma ação. A documentação descreve três.
Você fornece tokens de dívida. O protocolo pega um flash loan para o restante. O valor combinado então compra o ativo de colateral, e essa compra é bloqueada em um Gearing Token.
O passo dois é o que vale a pena considerar. É uma compra de mercado. Ela é roteada por um adaptador de swap — o escopo auditado cita adaptadores da Kyberswap e da Odos — e quais adaptadores são permitidos é controlado por uma função de administrador.

Assim, sua taxa fica fixa na entrada. Seu preço de entrada não fica. Um momento de baixa liquidez no DEX do colateral aparece como uma execução pior na posição que você acabou de abrir, e a certeza de taxa não conserta isso.
Ainda assim, é claramente melhor do que ficar fazendo looping manual entre quatro protocolos. Menos transações, menos gás, um único ponto de falha atômico em vez de cinco.
Mas "taxa fixa" descreve o financiamento, não o preenchimento.
Você verifica a profundidade do DEX do colateral antes de abrir uma posição alavancada, ou só verifica o APR?

#termmax @TermMax #DEX

@Dusk
Someitei o reparto do prêmio do Dusk esperando que caísse em 100%. Gerador de blocos 70%, fundo de desenvolvimento 10%, comitê de validação 5%, comitê de ratificação 5%. Isso dá 90%. Os 10% que faltavam era a parte que eu havia assumido que estava fixa. Não está.
Aquela última fatia também vai para o gerador de blocos — mas apenas até 10%, com base nos créditos incluídos no certificado do bloco. Qualquer parcela não distribuída é queimada.
Então a emissão no Dusk é parcialmente condicional ao desempenho. Um bloco cujo certificado traz um conjunto completo de votos do comitê paga o prêmio inteiro. Um bloco que reúne menos créditos paga menos, e a diferença não é carregada para frente nem redirecionada — ela é destruída. Cada bloco é um pequeno referendo sobre participação no comitê, liquidado em oferta.
Por isso o título da emissão e o número voltado ao staker são duas perguntas diferentes. O Dusk emite 500.000.000 DUSK ao longo de 36 anos com decaimento geométrico, r = 0,5, com halving a cada quatro anos. Período 1: 19,8574 DUSK por bloco em 12.614.400 blocos, 250,48M DUSK no total. Isso é a emissão. Mas 10% de cada prêmio de bloco é direcionado ao fundo de desenvolvimento, e uma fração desconhecida dos 10% condicionais é queimada. "Quanto a cadeia emite por bloco" e "o que chega a um staker" se resolvem de maneiras diferentes — e a segunda depende de quão bem a rede atestou aquele bloco específico.
Acho isso mais honesto do que uma promessa fixa de APY. Ele precifica a participação real no consenso em vez de anunciar um número e esperar que a rede cumpra. Mas honestidade e modelabilidade não são a mesma coisa. Dimensionar um negócio de validador agora exige uma suposição sobre a completude média dos certificados — uma variável que não tem página de marketing.
O Dusk está cortejando validadores institucionais para mercados regulados. Desempenho-condicional, prêmio parcialmente queimado é o incentivo certo para esse público, ou instituições precisam de previsibilidade mais do que de elegância?

#dusk $DUSK

Continuei a rolar além daquela linha até ela deixar de parecer encanamento.
FT é a metade sobre a qual todo mundo fala. Uma reivindicação sem cupom, comprada abaixo do valor de face e resgatada ao valor de face. Um título.
XT é o que sobra da mesma unidade de dívida depois que essa reivindicação é separada. A perna de juros. Deposite um token de dívida; ambas as metades são cunhadas, e o XT vai se esgotando até nada à medida que o vencimento se aproxima.
Aqui está o que fez tudo fazer sentido. A identidade se mantém em todos os momentos, não só no final. Um FT e um XT queimam de volta no token de dívida, ao par. Sem leilão, sem oráculo. O resgate fica limpo porque as duas metades sempre somam um.
Então eles acabam em mãos opostas. No fluxo de empréstimo, a perna XT é trocada por outra coisa na mesma transação em que ela é cunhada, e o credor sai segurando apenas FT. O alavancador adquire XT, porque manter a metade que decai contra uma garantia é como o ciclo é construído.
Alguém precisa ser o dono da perna que expira sem valor em uma data conhecida. Esse é o alavancador, não o credor.
Ainda em dúvida: os docs chamam XT de obrigação de juros em uma página e de indicador de alavancagem em outra. Não consigo dizer em qual deles os traders se baseiam na precificação.
Se FT é o título, então quem realmente está precificando XT, e contra o quê?

#termmax @TermMax

O pré-mines de @TermMax tem um detalhe digno de nota: 40M TMX (4% da oferta de 1B), reservados para incentivos a usuários iniciais, com zero vesting — resgatável 1:1 pouco depois do TGE, conforme os próprios documentos da TermMax.

Aqui o contexto importa: uma camada separada de bónus em TMX, oferecida pelo parceiro de vault de terceiros Neutral Trade (não TermMax), *usa* vesting linear de 6 meses, sem cliff. Portanto, vesting claramente era uma opção suportada pela TMX — mas a decisão de estruturação foi da Neutral Trade, não da TermMax. Eu não interpretaria o desenho do pool principal sem vesting como um sinal deliberado de #termmax .

Duas leituras são igualmente plausíveis: o time não está preocupado com pressão de venda concentrada no início, ou um pool sem vesting é simplesmente mais fácil de administrar. Não há evidências suficientes para favorecer uma delas.

Segurança: auditorias da Spearbit/Cantina são citadas nos documentos da Neutral Trade, não em um relatório publicado pela TermMax — provavelmente verdadeiro, mas de segunda mão. A pontuação 93% da DeFiSafety, listada no próprio site da TermMax, é sólida.

Financiamento: ~US$ 6,8M no total — US$ 2,55M anjo (2022) + seed com avaliação de US$ 38M, liderada pela Cumberland (2023). O valor da seed é contestado: US$ 4,25M (CryptoRank) vs US$ 4,45M em outros lugares, associado à entidade-mãe "Term Structure". Pequena lacuna ainda sem resolução.

Maior incógnita: não há cronograma público de vesting/cliff para os 96% restantes (equipe, investidores, tesouraria) — isso importa mais no longo prazo do que o pré-mines de 40M.

A questão real: quanto do pool de 40M é acumulado até o TGE. Isso determina se isso é apenas um pequeno abalo de liquidez ou um potencial fator relevante de movimentação de mercado.

#dusk $DUSK @Dusk O consenso do Dusk, A Atestação Concisa (SA), é um protocolo de prova de participação (proof-of-stake) sem permissão baseado em comitês. Os provedores elegíveis são escolhidos por meio de uma ordenação determinística ponderada por stake (stake-weighted sortition) para formar pequenos comitês por rodada; esses comitês propõem, validam e ratificam blocos usando assinaturas agregadas em vez de exigir que o conjunto completo de validadores participe ponderando em cada bloco. A documentação do Dusk descreve transações progredindo por quatro estados: Aceito (recebido e válido), Confirmado (incluído em um bloco com blocos posteriores construindo sobre ele), Estável (enterrado fundo o bastante para ser muito improvável de reverter) e Final (garantido de forma irreversível determinística e criptograficamente). Isso é explicitamente contrastado com o consenso no estilo Nakamoto, no qual os blocos nunca são absolutamente finais e são tratados como "provavelmente seguros" após confirmações suficientes se acumularem.

A maioria das cadeias oferece aos usuários exatamente um sinal — a contagem de confirmações — e deixa ao usuário decidir o que é "suficiente". O modelo de quatro estágios do Dusk torna explícito o que normalmente fica implícito: diferentes atores precisam de limiares de certeza diferentes em momentos diferentes. Uma transferência de varejo pode razoavelmente tratar "Confirmado" como suficiente; uma liquidação de valores mobiliários quase certamente precisa de "Final". Em comparação com sistemas puramente probabilísticos, a SA troca parte da superfície de descentralização (apenas um comitê atesta por bloco) por um ponto explícito e delimitado em que a finalidade deixa de ser probabilística e se torna absoluta.

Expor quatro estados de finalização é mais honesto sobre como a liquidação realmente funciona, mas também desloca uma decisão para o usuário ou para a camada da aplicação — qual estágio é "suficiente" para esta transação. A divulgação da estrutura real da finalização ajuda os usuários a tomarem decisões melhor calibradas, ou a granularidade adicional acaba, na maior parte, sendo abstraída por carteiras e apps?

#dusk $DUSK @Dusk

Eu não tinha pensado muito na camada de rede até notar que o Dusk não move blocos e votos como a maioria das cadeias faz. Em vez de inundar cada mensagem para cada peer, ele usa algo chamado Kadcast, construído sobre um roteamento estruturado no estilo Kademlia.

Por si só, isso soa como um detalhe de backend que ninguém fora do time central pensa. Mas começa a importar mais quando você coloca isso ao lado de como a Atuação (Succinct Attestation) realmente funciona. Consenso baseado em comitês depende de um pequeno grupo de provedores trocando votos rápido o suficiente para finalizar um bloco em segundos. Se a camada de rede por baixo for lenta ou desperdiçar largura de banda republicando a mesma mensagem para todo mundo, essa janela apertada de votação fica mais difícil de cumprir à medida que o conjunto de validadores cresce ou se espalha geograficamente.

O Kadcast roteia mensagens por caminhos determinísticos com base na distância na rede, em vez de inundação aleatória, e o resultado documentado é uma redução significativamente menor de largura de banda por mensagem. Para uma cadeia que depende de comitês trocando votos a cada rodada, isso não é um ganho apenas cosmético — é algo mais próximo de uma pré-condição para que as garantias de finalização realmente se mantenham em escala, e não apenas em um pequeno testnet.

O que eu não tenho uma imagem clara é como isso se comporta sob condições mais difíceis: um conjunto de validadores espalhado por continentes, qualidade de conexão desigual ou comportamento adversarial genuíno na camada de rede, em vez de simples ineficiência. Protocolos de roteamento estruturado trazem suas próprias trocas quando nós se comportam mal ou caem de forma imprevisível. Saber se a eficiência do Kadcast se mantém quando a rede fica maior e mais bagunçada do que é hoje parece algo que só vamos saber de verdade quando testes de escala reais fizerem isso.

Vamos detalhar isso direito, porque “ativo tokenizado” é usado de forma frouxa.

O jeito antigo é a tokenização por encapsulamento. Você pega um ativo. Você o encapsula dentro de um token. Esse token passa a representar a propriedade. Mas todo o resto — negociação, compensação (clearing), custódia, liquidação — continua exatamente onde sempre esteve, em sistemas separados, reconciliados depois. O token é uma representação. Ele não é o registro operacional real do ativo.

A alternativa é a emissão nativa. Em vez de envolver um processo existente, todo o ciclo de vida vive on-chain desde o início. Emissão, propriedade, transferências, liquidação, administração (servicing), relatórios — um único registro contínuo, não cinco registros desconectados que precisam ser costurados manualmente.

Por que essa diferença importa na prática?

Pense no que acontece quando um título (bond) muda de mãos em cada modelo. No encapsulamento, o token se move, mas em algum lugar fora da cadeia, um custodiante, uma câmara de compensação e um registrador precisam atualizar independentemente seus próprios registros para bater. É nessa etapa de reconciliação que normalmente surgem custos, atrasos e disputas.

Na emissão nativa, há um único registro. Quando a propriedade muda, cada fato a jusante — liquidação, relatórios, administração — reflete isso imediatamente, porque não sobra nada separado para reconciliar.

Essa é a vantagem teórica. Aqui vai a limitação honesta: as instituições não trocam de modelo porque um é arquiteturalmente mais limpo. Elas trocam quando o custo de continuar no modelo antigo passa a superar o custo de mudar. A infraestrutura legada “gruda” por razões que não têm nada a ver com qual design é melhor no papel.

Então, a forma útil de pensar nisso não é qual modelo é mais inteligente. É qual modelo realmente é adotado em escala — e essa é uma pergunta bem mais difícil de responder a partir de um whitepaper.

#dusk $DUSK @Dusk

Real Activity
Em vez de reler o pitch deck, passei uma noite apenas olhando para os números. Foi aí que a lacuna apareceu.
O Dusk é apresentado em toda parte como uma esteira de RWA de padrão institucional — parcerias e integrações com nomes reconhecíveis. Mas o que, na prática, está se movendo on-chain agora parece pequeno — um par DUSK/USDT na Binance carregando apenas uma fatia modesta do volume total de mercado, enquanto o resto fica disperso de forma tênue em venues menores. Ainda não está em lugar nenhum perto de onde uma narrativa “institucional” deveria estar.
O staking segue o mesmo formato em uma escala menor. O Hyperstaking foi construído para ser acessível — piso de entrada baixo, permissionless, uma janela de maturidade relativamente curta. Enquanto isso, as iniciativas maiores de tokenização ainda são descritas principalmente no futuro, ainda “em fase de rollout”.
Há também um ângulo de segurança que vale a pena analisar. Avaliações independentes de segurança mostram atualmente uma cobertura de auditoria, pontuação de seguros e cobertura de bug bounty de forma bem modesta. Isso não é incomum — muitos L1s são lançados antes que sua pilha completa de segurança amadureça — mas é uma lacuna perceptível para uma cadeia que busca bancos custodiante e títulos tokenizados especificamente.
Nada disso soa como algo alarmante; soa mais como algo inicial. Infraestrutura leva tempo para ser construída. O que realmente vale acompanhar é quem acaba usando a camada de liquidação primeiro — os stakers que já estão ativos hoje, ou as instituições que ainda esperam que a documentação e as “rails” de conformidade terminem de sair do papel.
A lacuna entre a narrativa institucional e a atividade on-chain atual é apenas um atraso normal do começo, ou isso diz algo sobre o quanto a adoção institucional real já vai longe?

#dusk $DUSK @Dusk

#dusk $DUSK Aqui vai algo que costuma ser ignorado na maioria dos explicadores do DUSK: isto não é uma cadeia com um único modelo de privacidade acoplado. É uma cadeia que executa simultaneamente dois modelos distintos de transação, porque pagamento e segurança não são o mesmo tipo de objeto e não falham da mesma forma.
Phoenix é o modelo estilo UTxO para transferências ofuscadas do dia a dia — saldos e contraparte(s) ficam ocultos, as notas são rastreadas em uma árvore Merkle e os nullifiers evitam gastos duplos sem revelar qual nota foi gasta. Ele foi construído para alto rendimento e confidencialidade em transferências comuns de valor.
Zedger é diferente por intenção. Ele é modelado especificamente para valores mobiliários tokenizados, em que o ponto não é apenas esconder um saldo — é provar que eventos do ciclo de vida (emissão, restrições de transferência, ações corporativas, resgate) aconteceram corretamente sob um arcabouço regulatório, sem vazar a cap table para a cadeia pública. Um token de segurança tem obrigações que o Phoenix nunca foi projetado para carregar: restrições de transferência vinculadas ao status do investidor, a capacidade de um emissor congelar ou recuperar sob condições legais específicas, exigências de auditoria que permanecem mesmo quando os saldos permanecem selados.
Rodar os dois em uma única camada de liquidação é a aposta real de engenharia. O Dusk não está escolhendo entre "cadeia de pagamentos privados" e "cadeia de títulos em conformidade" — ele está defendendo que você precisa de ambos os primitivos disponíveis no mesmo ambiente de execução, porque um mercado regulado toca ambos os tipos de transação no mesmo dia de negociação. O contrato de transferência gerencia ambos os fluxos através do mesmo modelo de integridade baseado em árvore Merkle, o que é uma arquitetura mais limpa do que fazer a ponte entre duas cadeias com duas garantias de privacidade diferentes.
A questão em aberto é se essa complexidade de modelo duplo vira um ônus de manutenção conforme ambas as especificações evoluem independentemente, ou se é genuinamente mais robusto do que uma camada de privacidade única para tudo.
Alguém sabe de outro L1 que esteja enviando dois modelos de transação de produção deliberadamente separados por classe de ativo, em vez de um único primitivo genérico de privacidade esticado sobre tudo?
@Dusk $NVDAB

A equipe da Babylon enquadrou o BABE — seu novo sistema de verificação de prova — como a chave que torna Trustless Bitcoin Vaults práticos: cerca de 1000x menor armazenamento, 1000x mais rápido na configuração, saindo de horas para segundos. Leia isso por si só e parece uma atualização já entregue.
Depois conferi o próprio plano de rollout deles na mesma chamada. O BABE ainda não é um recurso ativo no mainnet — ele está passando por etapas: primeiro um alpha em testnet (fortalecendo o lado do Bitcoin, ZK, verificação), depois um beta em testnet (APIs e documentação prontas para o mainnet) e, por fim, um alvo no mainnet após isso. Os números de compressão são resultados reais de laboratório. Se eles se sustentam em escala de produção, sob condições reais de rede, com testes adversariais reais, é uma alegação diferente e ainda em aberto.
Não é um sinal de alerta — é assim que a criptografia séria normalmente é lançada, em etapas, e não de uma vez. Mas "1000x menor" como manchete e "ainda em alpha" como status são ambos verdade ao mesmo tempo, e apenas um deles entra na thread.
Onde é um bom lugar para acompanhar a graduação real do BABE, etapa por etapa, em vez de depender do post do anúncio?
@BabylonLabs_io #baby $BABY

9 todos dn #BibanceTurns9