B A S I L KHAN

#dusk $DUSK @Dusk Hoje eu voltei e revisei o histórico de anúncios da NPEX/Dusk em ordem, em vez de ler primeiro o post de hype mais recente, e a linha do tempo real parece diferente quando alinhada cronologicamente.
Dezembro de 2025: Dusk e NPEX fazem parceria para lançar o que é descrito como a primeira bolsa de valores europeia impulsionada por blockchain, com a NPEX operando como um MTF holandês licenciado. Fevereiro de 2025: a Cordial Systems entra como camada de custódia. Novembro de 2025: Dusk e NPEX adotam os padrões CCIP e DataLink da Chainlink especificamente para que os dados oficiais da bolsa da NPEX possam ser publicados on-chain. O próprio dApp Dusk Trade é descrito como rodando no DuskEVM, começando com ativos tokenizados da NPEX, 21X e outros players institucionais, com números como €300M em ativos citados em coberturas anteriores.
Isso é, de fato, uma pilha regulatória bem séria — licenças de MTF, corretora, ECSP, com uma licença DLT-TSS descrita como em preparação. Não é uma parceria apenas no papel; a NPEX já opera um mercado secundário real, licenciado, para valores mobiliários nos Países Baixos.
Mas, ao passar por todas as fontes que consegui encontrar datadas nos últimos meses, não consegui localizar um único número confirmado sobre quantos ativos estão de fato ativos e negociáveis no Dusk Trade hoje, em comparação com quantos existem apenas como parceiros nomeados em anúncios. Todas as referências que encontrei descreviam capacidade, licenciamento e trabalho de integração — não uma contagem atual de listagens. Tratar "€300M em ativos" como já tokenizados e negociando seria ler um resultado como se fosse causa, e ainda não tenho evidências disso.
O que eu vou verificar daqui em diante: se o Dusk Trade publica uma contagem pública de listagens que possa ser consultada, do jeito que as bolsas normalmente fazem; se o site voltado a investidores da NPEX faz referência a negociações ao vivo baseadas em Dusk em vez de apenas à própria parceria; e se o feed da Chainlink DataLink está, de fato, empurrando dados de mercado ao vivo da NPEX on-chain agora, ou se ainda está em testes de integração.

#dusk $DUSK @Dusk Hoje eu tentei obter números ao vivo diretamente do explorador da testnet do DuskEVM, em vez de confiar nas threads de anúncio, e me deparei com algo que mudou o que eu estava realmente buscando.
O explorador da testnet roda no Blockscout, que normalmente disponibiliza os dados por uma API consultável — mas a própria página renderiza no lado do cliente, então eu não consegui extrair as contagens atuais de transações/contratos por uma busca direta. Essa é uma limitação real de verificar isso de fora de um navegador, e eu não quero afirmar um número que eu não verifiquei de fato.
O que eu encontrei, porém, foi algo mais interessante do que uma contagem bruta. A testnet pública do DuskEVM foi lançada em 5 de dezembro de 2025, descrita na época como "o passo final antes do lançamento da mainnet". Uma instância separada do Blockscout para o DuskEVM Mainnet já existe e está indexando dados a partir de hoje. Esse cronograma é mais apertado do que a moldura de "passo final antes da mainnet" sugeria há oito meses — e uma postagem com tag Dusk de 10 de agosto de 2026 ainda estava promovendo a testnet para testes de Solidity/Hardhat, o que levanta uma questão real sobre para qual ambiente os desenvolvedores estão sendo direcionados neste momento.
Eu também notei que a arquitetura do DuskEVM tem uma particularidade estrutural que vale destacar: atualmente ela roda apenas com sequenciador, sem mempool público. Isso é normal para um rollup do OP Stack nesta fase, mas significa que "atividade" aqui não é medida da mesma forma que em um L1 — uma contagem baixa de transações na testnet não necessariamente indica pouco interesse de desenvolvedores, já que cadeias apenas com sequenciador não mostram atividade pendente do jeito que o mempool do Ethereum mostra.
Em vez de chutar um número que eu não consigo verificar, o que eu estou acompanhando agora é: se os próprios canais do Dusk começam a direcionar desenvolvedores para o explorador da mainnet em vez da testnet, se a testnet recebe uma descontinuação explícita ou se continua rodando em paralelo, e se as contagens de contratos verificados na instância Blockscout da mainnet começam a subir com base em implantações reais, e não em scripts de teste.

#dusk $DUSK @Dusk Hoje eu analisei os repositórios reais do GitHub por trás do Citadel em vez de apenas ler a página de anúncio, e a diferença entre as duas coisas foi maior do que eu esperava.
O Citadel foi apresentado formalmente em janeiro de 2023 com um artigo de pesquisa completo, um design de protocolo funcional, três partes definidas (usuário, provedor de licença e provedor de serviço) e um modelo privado de NFT construído especificamente para resolver um problema real que outros sistemas de SSI não tinham: mesmo quando provas de conhecimento zero ocultam o conteúdo de uma credencial, a própria credencial geralmente fica armazenada como um valor público e rastreável na cadeia. A contribuição do Citadel foi corrigir essa “fuga”.
As ferramentas também existem — Moat, o Citadel SDK, está no GitHub, com uma CLI e uma API de acesso remoto para construir sobre o protocolo, exigindo um nó Rusk em execução e uma carteira conectada. Isso não é conversa fiada; o código é real e aberto.
Mas ao verificar o hub de documentação atual, encontrei uma observação que me travou: o SDK “existe, mas precisa de atualizações para o modelo Rusk atual”. Essa é uma lacuna significativa entre “o protocolo foi projetado e publicado” e “o protocolo está ativamente mantido para a implementação atual da rede”. Um design criptográfico com três anos de idade ser tecnicamente sólido não diz se a camada de integração acompanha uma cadeia que desde então passou por uma mudança de arquitetura em múltiplas camadas.
Eu não acho que isso signifique que o Citadel foi abandonado — ferramentas de privacidade em nível de pesquisa muitas vezes ficam inativas entre ondas de trabalho de integração, especialmente enquanto a atenção do time estava em DuskDS/DuskEVM/DuskVM. Mas isso significa que citar o Citadel como evidência de “infraestrutura de conformidade em funcionamento” agora exagera onde o SDK realmente está.
O que estou acompanhando daqui para frente: se o Moat vai receber um commit atualizando-o para o modelo Rusk atual, se alguma instituição nomeada ou provedor de KYC realmente implanta o Citadel em produção em vez de referenciá-lo apenas como caso de uso, e se o Citadel é incorporado explicitamente no roadmap do DuskEVM/DuskVM ou se permanece como um artefato independente de 2023.

#dusk $DUSK @Dusk Se alguém te disser que um pagamento no Dusk está “confirmado”, você realmente liberaria mercadorias, assinaria um contrato ou faria uma transferência (wire) com base nessa palavra?
Voltei pelas etapas de finalidade depois de perceber que eu tinha tratado “confirmed” e “done” como se fossem intercambiáveis, o que não é realmente preciso nessa cadeia.
Um bloco passa por quatro estados separados: Accepted, Confirmed, Stable e Final. Apenas o estado Final é determinístico e garantidamente irreversível do ponto de vista criptográfico. Stable é o estado imediatamente anterior, e é explicitamente probabilístico, não absoluto. Isso quer dizer que o bloco está enterrado o bastante para que uma reversão seja extremamente improvável, não que a reversão seja matematicamente impossível.
Essa distinção importa muito mais quando dinheiro real está envolvido. Se você estiver aceitando uma transação Stable, mas ainda não Final, como liquidação liberando um ativo, confirmando uma operação, tratando os fundos como compensados, você está aceitando uma probabilidade, não uma garantia — mesmo que essa diferença não fique óbvia só de ler um rótulo de status em uma carteira (wallet) ou em um explorador (explorer). O número de blocos necessários para chegar ao verdadeiro status Final também não é fixo; o Dusk migrou para um modelo de “finalidade em rolagem” (rolling finality), em que a contagem varia de rodada para rodada conforme as condições da rede. Isso significa que não existe uma regra única do tipo “espere X blocos e você está seguro” na qual você possa confiar cegamente.
@Dusk _Foundation Eu não encontrei um número claro e publicado para o pior caso de quanto tempo o intervalo entre Stable e Final pode se estender, de fato, sob condições reais de rede; apenas que ele é variável por design.
Se você está usando o Dusk para qualquer coisa que envolva liquidação real, você está realmente verificando o estado Final antes de tratar os fundos como seguros ou você para no Stable porque a palavra parece “concluída” o bastante?

#dusk $DUSK @Dusk Se você enviar DUSK através da ponte DuskEVM, como você sabe de fato quando seus fundos estão seguros para gastar do outro lado — e o que acontece se você estiver errado?
Fui investigar isso depois de quase fazer uma suposição que poderia ter me custado caro. Meu instinto foi: se a inclusão aparece como confirmada no explorador de blocos, então os fundos devem ser utilizáveis. Acontece que essa é exatamente a forma errada de pensar.
A própria documentação para desenvolvedores da Dusk é bem direta sobre isso: inclusão e liquidação são dois estágios separados, e aplicativos que movem valor entre a camada DuskEVM e a DuskDS são instruídos explicitamente a verificar o status do protocolo ou da carteira diretamente — e não inferir finalidade apenas porque algum tempo já passou. A inclusão de transações no DuskEVM acontece rápido por ser um L2 baseado em sequenciador, mas isso não é o mesmo momento em que seus fundos estão de fato liquidados e seguros contra a camada base.
Na prática, é isto: se você estiver fazendo uma ponte de ativos e enviar ou gastar com base em "provavelmente já terminou", você está confiando em um palpite que o próprio protocolo avisa explicitamente para não fazer. A diferença entre "parece incluído" e "de fato liquidad" é justamente o tipo de janela em que agir cedo demais cria uma exposição real — usando fundos que ainda podem ser reorganizados ou invalidados antes de estarem verdadeiramente finais.
@Dusk _Foundation — não encontrei um número publicado sobre o tempo médio típico real entre a inclusão no DuskEVM e a finalidade de liquidação no DuskDS sob condições normais da rede; só encontrei a orientação de verificar o status em vez de contar o tempo decorrido.
Se o próprio protocolo diz para não estimar pelo tempo decorrido, a maioria das carteiras e das interfaces de bridge está realmente mostrando aos usuários o status real de liquidação, ou as pessoas ainda estão apenas olhando um cronômetro e chutando?

#dusk $DUSK @Dusk Testando fluxos de emissão de ativos em ambas as camadas lado a lado, percebi que os dois protocolos não são apenas a mesma ferramenta portadas para cadeias diferentes — eles estão resolvendo privacidade com criptografia genuinamente diferente por baixo.
O Zedger roda nativamente no DuskDS e é baseado em UTXO, o que significa que ele consegue oferecer anonimato completo de um modo estruturalmente difícil de replicar em um sistema baseado em contas. O Hedger roda no DuskEVM, em vez disso, construído para compatibilidade total com EVM e com as ferramentas padrão do ecossistema Ethereum — mas como o modelo baseado em contas da EVM não consegue suportar o mesmo nível de anonimato que o Zedger oferece, o Hedger segue uma rota técnica totalmente diferente. Ele combina criptografia homomórfica (ElGamal sobre curvas elípticas) com provas de conhecimento zero, de modo que saldos e transferências permaneçam criptografados de ponta a ponta enquanto ainda é possível computar e auditar — não apenas escondidos.
A parte que eu não esperava: as provas do Hedger são geradas no lado do cliente, no navegador, em menos de dois segundos. Isso é uma afirmação real de usabilidade, não uma frase de marketing — rápido o suficiente para que usuários institucionais não precisem de infraestrutura dedicada de provas apenas para transacionar com privacidade no lado da EVM.
Então a escolha real entre Zedger e Hedger não é “qual é mais privado”. É qual modelo de confiança e de ferramentas um emissor precisa. O Zedger oferece anonimato no nível de UTXO, mas requer ferramentas nativas do Dusk. O Hedger dá compatibilidade total com Ethereum e provas rápidas no navegador, mas abre mão desse mesmo teto de anonimato por causa do modelo de contas em que foi construído.
Ainda não vi uma resposta clara sobre como um emissor deveria realmente decidir entre os dois quando precisa de ambos: a composabilidade da EVM e o nível de anonimato do Zedger no mesmo ativo — se isso até é possível hoje, ou se força um tradeoff que ninguém resolveu completamente.

#dusk $DUSK @Dusk
Executando a geração de provas localmente para benchmarkar o desempenho do circuito, percebi algo que me fez voltar e ler os próprios materiais da equipe de criptografia, em vez das páginas de marketing.
Os números reais do PLONK é que sustentam o caso de conformidade, não apenas o ângulo de privacidade. O tempo de verificação fica em torno de 6 a 9 milissegundos, independentemente do tamanho do circuito — enquanto o tempo de prova escala com a complexidade do circuito (aproximadamente 5,46 segundos para um circuito de 2^16 portas em hardware modesto). Já o lado do verificador permanece rápido e constante. Essa assimetria importa mais para finanças reguladas do que as pessoas dão crédito: um auditor ou contraparte verificando uma prova não fica gastando computação relevante toda vez, mesmo conforme a lógica subjacente da transação fica mais complexa.
O que eu não esperava encontrar era que o próprio PLONK tinha uma vulnerabilidade real divulgada, não apenas um risco teórico. A equipe de pesquisa da Dusk encontrou uma falha crítica na forma como a transformação Fiat-Shamir foi implementada — a parte que transforma uma prova interativa em uma prova não interativa, fazendo hash dos desafios em vez de um verificador vivo enviá-los. A implementação original não fazia hash das entradas públicas cedo o bastante, o que enfraqueceu a garantia de solidez (soundness). A Trail of Bits coordenou a divulgação, a Dusk corrigiu antes do mainnet e publicou a correção em vez de deixá-la guardada.
É esse detalhe que não sai da minha cabeça — uma cadeia orientada à conformidade construída sobre um sistema de provas criptográficas que tinha um bug de solidez em código próximo de produção, detectado e corrigido antes de realmente importar. Não sei quantas outras implementações usando PLONK em outros lugares ainda estavam vulneráveis quando isso se tornou público, nem por quanto tempo a diferença entre a divulgação e a correção de forks próprios em outros projetos durou.

#dusk $DUSK Uma blockchain pode ser genuinamente privada e ainda assim permitir que os reguladores vejam exatamente o que eles precisam ver legalmente?
Não esperava que a resposta dependesse de criptografar uma chave com outra chave. A maioria das moedas de privacidade resolve a privacidade removendo completamente a visibilidade: ninguém vê nada, jamais. @Dusk funciona sob uma suposição diferente: a privacidade deve ser seletiva, não absoluta.
A carga útil (payload) de uma transação de um usuário é criptografada com uma chave do usuário, e essa chave é, por sua vez, criptografada com uma chave de auditor separada, de modo que apenas um auditor autorizado pode descriptografá-la. A cadeia permanece protegida do público, mas provas de conhecimento zero permitem que os usuários provem que a chave do auditor foi usada corretamente e que a carga segue as regras sem expor o conteúdo para ninguém mais. Estruturalmente, isso é diferente de anonimato: alguém pode ver, sob condições definidas, mesmo que a cadeia pública nunca mostre.
Isso também se estende à identidade. Citadel, a camada de identidade da Dusk, permite que alguém conclua KYC uma vez e, depois, comprove elegibilidade usando provas de conhecimento zero, sem reexpor dados pessoais toda vez. Isso também fecha uma lacuna em sistemas anteriores de privacidade de identidade, em que até provas à prova de vazamento ainda ficavam anexadas a valores públicos rastreáveis na cadeia.
Aqui está a tensão que eu não vi ser resolvida: a divulgação seletiva só protege você se a chave do auditor nunca for comprometida ou usada indevidamente. Uma moeda de privacidade não tem uma chave desse tipo; sua garantia é que ninguém vê, ponto. A Dusk troca essa garantia absoluta pela usabilidade regulatória — que é o ponto inteiro para instituições — mas sua privacidade acaba se apoiando parcialmente em quão rigidamente o acesso do auditor é governado, e não apenas na matemática.
Se a privacidade na Dusk depende em parte de quem detém as chaves do auditor, quanto da privacidade orientada à conformidade é criptografia e quanto é confiança institucional vestida com uma prova de conhecimento zero?

#dusk $DUSK @Dusk Migrar seus próprios tokens entre cadeias pode realmente custar dinheiro sem nenhum hack envolvido?

Passei uma tarde inteira analisando o código do contrato de migração da Dusk antes de escrever isto, porque "nativo vs. envolto" geralmente é explicado como se fosse apenas uma diferença cosmética. Não é.
Aqui está o detalhe que se destacou: o DUSK nativo usa 9 casas decimais, mas o DUSK ERC20/BEP20 usa 18. O contrato de migração converte com base em um fator fixo e, se o valor que você está migrando não for um múltiplo limpo de 1 LUX, o contrato arredonda para baixo silenciosamente. Migre uma quantia com poeira abaixo desse limite, e o excedente não volta para você como DUSK nativo. Ele simplesmente desaparece, por design — não por bug.
O modelo de confiança também merece ser nomeado. O DUSK nativo na mainnet é a fonte real da verdade quando você faz a ponte do DUSK nativo para o BEP20: o protocolo bloqueia seus tokens da mainnet primeiro e, só então, aciona um mint na BSC. O token BEP20 envolto só existe por causa desse bloqueio; ele não é lastreado de forma independente. Isso cria um perfil de risco fundamentalmente diferente de simplesmente manter DUSK nativo diretamente, mesmo que ambos mostrem o mesmo saldo na sua carteira.
Depois há a parte que nem é um tradeoff de design: é um risco operacional. Fazer a ponte do DUSK nativo para o BEP20 requer colocar o endereço de destino da BSC em um campo de memo. Se você omitir isso, ou colocar errado, a documentação é direta: a ponte ignora a transação e os fundos são perdidos. Sem revert de contrato inteligente, sem reembolso automático. Apenas some, porque o mint do outro lado não tinha para onde ir.
Eu não acho que a maioria dos detentores verifica qual versão está realmente segurando antes de mover fundos entre exchanges e carteiras — eles apenas veem "DUSK" e presumem que é intercambiável.

Se o DUSK nativo é a fonte real da verdade e as versões envoltas existem apenas por causa de uma prova de bloqueio e mint, por que o ecossistema ainda torna tão fácil perder fundos por causa de um único campo de memo ausente?

#dusk $DUSK @Dusk
O que significa “trustless” (sem confiança) de verdade quando uma ponte está movendo seus ativos entre duas camadas de execução diferentes?
Eu continuei voltando a essa pergunta depois de ler como a Dusk conecta a DuskDS à DuskEVM, porque “ponte trustless” vira uma frase de marketing quase em todo lugar, e raramente sobrevive a uma leitura mais atenta.
Veja o que está acontecendo de fato: a DuskDS é a camada de consenso e liquidação — é nela que vivem a finalização, a segurança e a disponibilidade de dados. A DuskEVM fica por cima, como um ambiente de execução separado para contratos Solidity. Mover um ativo entre elas não é a mesma coisa que movê-lo dentro do próprio estado de uma única cadeia — significa que uma camada precisa provar para a outra que uma mudança de estado realmente aconteceu, sem que qualquer uma das partes apenas aceite a palavra da outra.
A parte “nativa” é o que realmente importa aqui. Em vez de depender de um conjunto de validadores externo ou de um custodiante multisig segurando ativos tokenizados — o projeto clássico de ponte que causou a maioria dos exploits cross-chain nesta indústria — a ponte é construída diretamente sobre as garantias de liquidação do próprio protocolo. A finalidade da DuskDS (o estado “Final”, garantido criptograficamente e irreversível) é o que a ponte usa para confirmar que uma transferência é realmente segura para ser reconhecida do outro lado.
Isso configura um modelo de confiança bem diferente do de uma ponte garantida por um conjunto separado de signatários. Mas também significa que a segurança da ponte só é tão forte quanto as próprias premissas de consenso da DuskDS — se algum dia houver um cenário em que a finalização baseada em comitês seja contestada ou atrasada, a ponte herda essa mesma incerteza, e não um risco separado.
Ainda não encontrei uma resposta clara para isso: qual é a latência real entre a DuskDS atingir “Final” e um ativo se tornar utilizável na DuskEVM, e essa lacuna cria alguma janela em que um agente racional poderia explorar o timing em vez de quebrar a criptografia em si?
Uma ponte é tão “trustless” quanto é a camada de liquidação que fica abaixo dela, ou a DuskEVM adiciona também seu próprio risco independente por cima disso?

#baby @BabylonLabs_io Se um validador se tornar malicioso, todo mundo que delegou para ele é punido junto, ou apenas as pessoas que ele realmente mira?
Não esperava que a resposta envolvesse truques de criptografia em vez de apenas "sim, todo mundo perde a própria participação". De forma ingênua, eu assumi que o slashing funcionava como na maioria das cadeias PoS: um validador ruim, uma penalidade coletiva para qualquer pessoa que tivesse delegado para ele.
A Babylon faz algo diferente usando assinaturas adaptor. Quando um staker delega, tanto o staker quanto o comitê de convênio pré-aprovam o acordo, mas a única assinatura necessária depois para realmente acionar o slashing é a assinatura do próprio validador delegado. Para impedir que um validador inescrupuloso faça slashing de forma unilateral dos fundos de um staker inocente, o staker criptografa a pré-aprovação usando a chave pública EOTS do validador. Isso significa que, se o validador algum dia tentar mirar esse staker específico de forma maliciosa, descriptografar a assinatura para fazer isso obriga a chave privada do próprio validador a vazar — e isso, por sua vez, torna a participação inteira delegada por ele mesmo e a participação de cada outro delegador ligado a ele também passíveis de slashing.
Em outras palavras, atacar uma pessoa aciona a exposição do próprio validador em todo mundo que está acoplado a ele. Não é isolamento por política; é isolamento imposto fazendo o ataque se tornar autodestrutivo para o agressor.
O que eu ainda não consegui encontrar uma resposta satisfatória é se esse design cria um incentivo perverso em que, uma vez comprometido, um validador não tem mais nada a perder e acaba maximizando os danos a cada delegador ao mesmo tempo, em vez de mirar apenas um.
Se fazer slashing de uma pessoa pode se espalhar para todo mundo sob aquele validador, quanto o enquadramento de "slashing isolado" realmente se sustenta na prática?
#baby $BABY

#baby $BABY Como você faz um "slash" (sanção) de um validador no Bitcoin quando o Bitcoin não tem lógica de slashing embutida?
Demorei mais do que o esperado para realmente entender este ponto, porque a resposta não é um contrato inteligente — é um esquema de assinatura que faz algo inteligente com matemática em vez de código.
@BabylonLabs_io usa o que é chamado de Assinatura Oportunista Extraível de Uma Única Vez (EOTS), construída sobre as assinaturas nativas do Schnorr do Bitcoin. Aqui está o truque central: um provedor de finalidade gera um par de chaves único para cada altura de bloco em que vota. Enquanto eles assinarem apenas um bloco por altura, a assinatura permanece totalmente segura e nada vaza. Mas se eles assinarem dois blocos conflitantes na mesma altura, a matemática desmorona. Reutilizar essa chave por altura para assinar duas mensagens diferentes expõe diretamente sua chave privada, por causa de como a matemática da assinatura Schnorr funciona quando um nonce é reutilizado.
A própria rodada de finalidade exige assinaturas de mais de dois terços do peso de BTC apostado para que um bloco seja realmente finalizado; ou seja, qualquer violação de segurança, por definição, exige mais de um terço do stake para ter feito dupla assinatura. É isso que torna a garantia de "totalmente punível" (fully slashable) garantida matematicamente em vez de ser uma promessa de política: quando a chave vaza, qualquer pessoa — não apenas Babylon, não apenas um validador — pode construir e transmitir a transação de slashing. Não é necessária votação de comitê nessa etapa, nem processo de apelação; é só matemática exposta.
O que eu não vi uma resposta clara: a geração de chaves para cada altura de bloco cria uma sobrecarga operacional significativa para provedores de finalidade que operam em múltiplas BSNs ao mesmo tempo, e essa própria sobrecarga poderia se tornar uma superfície de ataque, por exemplo, se um provedor sob carga reutilizar aleatoriedade por engano em vez de má-fé?
A segurança do EOTS é puramente uma garantia de matemática, ou ela depende silenciosamente de provedores de finalidade também terem uma infraestrutura sólida de gerenciamento de chaves?
$BABY

#baby $BABY Eu costumava pensar no “supply” ocioso do Bitcoin como uma limitação fixa — um ativo que seria sempre mais valioso mantido parado do que colocado para trabalhar. Então eu olhei para o que, na prática, “ocioso” realmente soma.

Hoje, mais de 99% do Bitcoin em circulação está completamente não apostado. Isso não é um erro de arredondamento — é a maior reserva de capital dormente em todo o mercado cripto, algo em torno de um trilhão de dólares em peso econômico fazendo apenas uma coisa: ficar parado nas carteiras.

Foi isso que mudou a forma como eu enxerguei: todas as outras grandes redes construíram a própria segurança do zero, competindo por capital apostado que precisava ser criado, incentivado e cultivado a partir de zero ao longo de anos. O Bitcoin não tem esse problema. O capital já existe. Ele já é a reserva de valor mais confiável do setor. A única peça que faltava era um mecanismo para colocá-lo para trabalhar sem quebrar as garantias de custódia que o tornaram confiável desde o início.

Essa é a aposta @BabylonLabs_io que está fazendo — não de que o Bitcoin precisa de um novo caso de uso, mas de que o caso de uso já estava ali, inutilizado o tempo todo, bloqueado por uma lacuna técnica e não por falta de demanda.

Eu não acho que isso se desenrole da noite para o dia. A adoção real depende de lançarem BSNs suficientes, de provedores de finalidade suficientes provarem que são confiáveis, e de delegadores realmente fazerem a diligência sobre a qual tenho escrito em todas as campanhas. O mecanismo já está em funcionamento. Se ele vai escalar até uma fração significativa daquele trilhão de dólares ainda é uma pergunta em aberto — não uma conclusão inevitável.

O que eu estou acompanhando para a próxima fase não é o número total de BSNs anunciados — é qual porcentagem desse ocioso 99% começa de fato a se mover.
$1000RATS $IDOL
@BabylonLabs_io #1000sats

#HedgeFundsAddBullishOilBets #OpenAIFindsMoreAgentsEscapedContainment #AmazonRaises2026CapexTo$220B

Quanto do Bitcoin ocioso vai migrar para o Babylon?

#baby $BABY @BabylonLabs_io

Eu costumava achar que “staking” automaticamente significava entregar suas moedas para outra pessoa até você sacar. Então eu examinei o que acontece de fato com meu BTC no exato momento em que ele entra em uma transação de staking do Babylon.

Ele nunca sai do meu controle.

O BTC é bloqueado diretamente por um script nativo do Bitcoin, sem custodiante que detenha as chaves, sem token “wrapped” representando o ativo real, e sem contrato de ponte que possa ser explorado. O bloqueio existe na própria cadeia do Bitcoin, imposto pelas próprias regras do Bitcoin — as mesmas regras que já garantem cada transação que eu já fiz.

O que acontece de verdade é um script Taproot com dois caminhos de gasto embutidos. Um me permite recuperar meu BTC quando o timelock termina. O outro só é ativado se o validador para o qual eu deleguei violar o protocolo — esse é o caminho do slashing, e é o único cenário em que meus fundos se movem fora do meu caminho pretendido.

Eu não levo isso para significar risco zero. Ainda há um comitê de covenant envolvido na imposição de certas condições, e delegar a um provedor de finalidade ruim ainda traz consequências. Mas existe uma diferença real entre “confiar em uma empresa com suas chaves” e “confiar em um mecanismo definido, auditável e imposto por script do Bitcoin”. O staking custodial pede para você acreditar em uma promessa. Isto pede para você verificar o código.

Para qualquer pessoa que tenha mantido BTC especificamente porque não queria depender de ninguém além, este é o detalhe que realmente importa: não o número do rendimento, mas se ganhar esse rendimento silenciosamente reintroduz a dependência exata que o Bitcoin foi construído para eliminar.

@BabylonLabs_io Estava comparando o modelo de Finality Provider da Babylon com uma delegação PoS normal, e uma coisa se destacou: a estrutura de incentivos não é simétrica da forma como as pessoas presumem.
Na maioria dos sistemas PoS delegados, se seu validador se comporta mal, você compartilha a punição—o seu stake é cortado junto com o dele. Esse é o ponto: isso força os delegadores a realmente verificarem em quem estão delegando. A configuração da Babylon mantém essa mesma ideia central para o Bitcoin: o seu BTC fica exposto a risco de slashing com base no Finality Provider que você escolhe, mesmo sem você entregar a custódia das moedas em si.
Por que isso importa: a auto-custódia normalmente é comercializada como "segurança", ponto final. Mas a auto-custódia não elimina sua exposição ao mau comportamento de terceiros; ela apenas remove especificamente o risco de custódia. Você pode manter controle total do seu BTC e ainda assim perdê-lo para slashing se delegar com descuido. Esse é um risco significativamente diferente de "minha exchange foi hackeada", mas não é risco zero, e eu acho que a mensagem sobre staking no Bitcoin às vezes confunde essa linha.
O trade-off que vale a pena nomear: isso coloca a devida diligência de verdade sobre os stakers. Escolher um Finality Provider não é uma escolha cosmética—é uma decisão ativa de risco: disponibilidade (uptime), comportamento de assinatura e segurança operacional passam a ser seu problema por extensão. Muitos detentores de BTC que estão fazendo staking pela primeira vez não estão acostumados a pensar assim, porque o próprio BTC treinou as pessoas a considerarem principalmente o risco de custódia e mais nada.
Então o desenho de incentivos é sólido no papel — ele deveria, em teoria, criar um mercado em que Finality Providers confiáveis ganham confiança e os ruins ficam sem delegação. Se esse mercado realmente se forma depende de os stakers fazerem a diligência que o design pressupõe que eles farão.#baby $BABY

Passei tempo nos @BabylonLabs_io docs hoje tentando entender o que os Provedores de Finalidade realmente fazem. O papel é menos óbvio do que parece à primeira vista.

Em uma cadeia PoS normal, os validadores fazem stake do token nativo da cadeia para ganhar poder de voto. Os Provedores de Finalidade fazem algo diferente. Eles recebem delegações de BTC dos stakers e usam esse Bitcoin delegado como o peso econômico por trás dos votos deles para a finalização de blocos.

O staker nunca transfere o BTC. Nenhuma chave privada se move. O BTC fica bloqueado em um script com autocustódia no Bitcoin. O que é delegado é apenas o poder de voto que o BTC representa. O Provedor de Finalidade vota. O Bitcoin sustenta esse voto economicamente, sem nunca sair do controle do staker.

O que mudou meu modo de pensar é o que isso significa para as redes PoS que dependem dessa segurança. A segurança delas já não depende apenas de quanto o token nativo vale. Ela depende do peso econômico do Bitcoin estando por trás de cada voto de finalidade. Isso é uma base de segurança fundamentalmente diferente daquela que a maioria das cadeias PoS tem acesso hoje.

O lado do slashing completa o quadro. Se um Provedor de Finalidade faz double sign, o EOTS expõe a chave privada deles e as condições de slashing são executadas automaticamente. O poder de voto delegado a eles veio com consequências reais associadas.

O que eu continuei pensando é na posição do staker em tudo isso. Você delega a um Provedor de Finalidade cujo comportamento você não consegue controlar diretamente. A criptografia protege seu principal. Mas a sua escolha do provedor ainda importa para a saúde das redes que estão sendo securizadas.

Se o poder de voto é delegado, mas o BTC nunca se move, como é que a responsabilização realmente funciona para o staker ao escolher onde delegar?

#baby $BABY

#baby $BABY / @BabylonLabs_io
Lendo a documentação da Babylon hoje, eu ficava parando em uma pergunta.

O Bitcoin não tem contratos inteligentes. Então como um protocolo impõe slashing em um BTC que nunca saiu da blockchain do Bitcoin?
O Covenant Committee é a resposta, mas não do jeito que eu inicialmente imaginei.

Toda transação de staking é revisada pelo comitê antes de se tornar ativa. Eles verificam se as condições de unbonding e de slashing estão de acordo com as regras da Babylon. Se eles atingirem o quórum, eles pré-assinam tanto a transação de unbonding quanto a de slashing ali mesmo. As assinaturas deles já ficam em vigor antes mesmo do início do período de staking.

Esse detalhe de pré-assinatura mudou a forma como eu entendi todo o modelo. O comitê não fica monitorando má conduta e reagindo a ela. Eles assinam tudo antecipadamente. Depois disso, a única assinatura que falta para executar o slashing é a própria do Finality Provider. E essa assinatura só fica disponível se o provedor assinar duas vezes, que é exatamente o que o EOTS foi projetado para revelar.

O que ficou comigo é a proteção embutida para os stakers. O comitê não consegue roubar seu stake. Eles não conseguem causar um slashing indevido. A chave do seu próprio EOTS é necessária na condição de slashing, e só você a possui. Mesmo um comitê totalmente comprometido não consegue mover seu Bitcoin contra a sua vontade...

Eu continuei vendo “staking de Bitcoin sem confiança (trustless)” por todo lado e aceitei isso literalmente. Aí eu realmente li a documentação do script de staking.

Existe um comitê de convênios.

Um grupo de partes cujas chaves públicas do Bitcoin ficam embutidas diretamente na transação de staking. Função: coassinar certas rotas de gasto para que o protocolo possa aplicar slashing e des-bonding (unbonding) sem precisar de consenso on-chain toda vez.

Sem elas, todo o mecanismo não funciona — o des-bonding não seria rápido e o slashing não seria aplicável.

Então aqui vai o verdadeiro tradeoff que ninguém coloca no título: a Babylon remove o custodiante, mas não remove todas as partes confiáveis. Ela reduz a confiança para um comitê definido, com restrições criptográficas, em vez de uma única empresa com um livro-razão que você não consegue auditar.

Isso é uma diferença real — um comitê multisig com regras publicadas não é o mesmo tipo de risco que um custodiante que pode congelar sua conta. Mas também não é confiança zero, e tratar como se fosse assim faz as pessoas se prepararem para serem surpreendidas mais tarde.

A maioria das pessoas fazendo staking hoje não vai verificar quem está nesse comitê nem qual é o limiar de assinaturas necessário para mover os fundos.

Eu verifiquei. Vale a pena fazer isso antes de travar BTC em qualquer coisa.

Trustless não é binário. É um espectro, e a Babylon só avançou mais um pouco nele do que as pontes custodiais — não até o fim.

#baby $BABY @BabylonLabs_io

#baby $BABY hoje eu consultei os documentos de staking @BabylonLabs_io hoje e um detalhe remodelou como eu estava pensando sobre o que “nativo” realmente significa aqui.

Todo caminho existente para obter rendimento com Bitcoin exige uma troca de ativos em algum momento. O wrapping transforma seu BTC em um derivativo sintético cujo valor depende da ponte que o mantém. A bridging move algo que representa seu BTC para outra cadeia enquanto o original fica bloqueado em algum lugar. Em ambos os casos, no fim você fica com uma reivindicação sobre Bitcoin, não com o próprio Bitcoin.

O mecanismo de staking da Babylon funciona de forma diferente. Seu BTC é bloqueado diretamente no Bitcoin usando a própria linguagem de scripts do Bitcoin, timelocks e agregação de assinaturas, sem precisar de um sistema de smart contract do lado do Bitcoin. O BTC nunca vira outra coisa. Ele permanece exatamente o que é: um UTXO de Bitcoin, dentro de um script com custódia própria que o staker controla.

O que esse BTC está fazendo enquanto fica bloqueado é a parte interessante. Ele fornece segurança econômica para redes de proof of stake como staking delegado atrás dos Finality Providers. Se um Finality Provider fizer double sign, o stake por trás dele pode ser slashed. A existência do Bitcoin como colateral econômico real é o que torna a segurança confiável para as redes que dependem disso.

O detalhe do unbonding ficou comigo. O saque padrão no vencimento do timelock não exige nenhuma cooperação da Babylon nem de nenhum operador externo. O unbonding antecipado exige uma coassinatura do Covenant Committee e, depois, uma espera de 7 dias antes que os fundos possam ser sacados. O staker sempre consegue sair pelo caminho padrão, mesmo se todas as partes externas desaparecerem.

Essa independência é a propriedade que a maioria das abordagens de BTC wrapped não consegue replicar. O caminho de saída é codificado no script do Bitcoin no momento de criação do cofre, não fica na custódia de outra pessoa.

Se o rendimento do staking no Bitcoin finalmente for possível sem nunca sair do Bitcoin, o que acontece com a demanda por alternativas wrapped ao longo do tempo????

#baby $BABY
Passei pelos documentos da Babylon hoje e um número ficava me interrompendo. Apenas 1% do Bitcoin é usado em DeFi.

O Bitcoin é o maior ativo cripto por valor de mercado. Também é, com ampla margem, o mais ocioso na finança descentralizada. A razão não é apatia. É o custo de entrada. Cada caminho existente para entrar na DeFi exige que um detentor de Bitcoin faça uma destas coisas: entregue a custódia a um terceiro, faça uma ponte entre cadeias, envolva o ativo em uma versão sintética ou confie em um intermediário cuja solvência vira o risco real. Estas são exatamente as concessões que detentores de Bitcoin, por anos, passaram a recusar.

O que @BabylonLabs_io está construindo parte de um ponto de partida diferente. O BTC nunca sai do Bitcoin. Ele é travado em um script Taproot que o depositante coassina no momento da criação do vault (cofre). Cada caminho legítimo de gasto é pré-assinado antes do vault ficar ativo. Depois disso, nenhuma parte consegue fabricar um novo gasto. O protocolo não pode mover o BTC para fora, emprestá-lo em outro lugar, ou reaproveitá-lo. A garantia faz apenas o que o script permite.

Do lado do Ethereum, um contrato de protocolo rastreia cada vault e permite que uma aplicação DeFi integrada trate-o como colateral. Transições de estado entre cadeias são impostas por meio de criptografia, e não por um intermediário confiável. A suposição de confiança muda da solvência de um custodiante para a criptografia do protocolo e as duas redes subjacentes.
O enquadramento que ficou comigo é o que a Babylon chama de vault no sentido original. Não é um contrato de capital em pool em que muitos usuários compartilham risco juntos. É uma saída de Bitcoin segregada, de propriedade do depositante. Mais perto do compartimento seguro de um banco do que de uma pool de liquidez de DeFi.

Se 99% do Bitcoin está fora da DeFi porque todo caminho existente exige abrir mão de algo, como fica esse espaço se esse custo de entrada simplesmente desaparecer???