Sattar Chaqer

O mercado está cozinhando hoje

$CLO
$1000RATS
$ACE

Três nomes apareceram de repente no meu radar.

Juro que a cripto tem um talento para te fazer descobrir o movimento depois que ele já começou.

Agora estou observando de perto.

Tenho notado um problema no DeFi que costuma ser ignorado: a taxa pela qual você toma emprestado pode mudar enquanto sua estratégia ainda está em execução.

As taxas de empréstimo e de empréstimo com taxa variável acompanham as condições do mercado. Isso gera incerteza. Um tomador pode acabar enfrentando custos de reembolso mais altos enquanto o retorno esperado de um credor pode mudar conforme as taxas se movem.

@TermMax aborda isso de uma forma diferente.

O modelo dele usa taxas fixas de empréstimo e de captação para vencimentos definidos. Em termos simples, você pode saber a taxa e também saber quando a posição termina.

Isso muda a equação do planejamento.

Para os tomadores, uma taxa fixa torna o custo do reembolso mais previsível durante o período acordado.

Para os credores, a estrutura fixa pode tornar os retornos mais fáceis de entender e planejar.

E eu acho que a data de vencimento é a parte que as pessoas subestimam.

Saber apenas a taxa te diz quanto.

Saber a taxa e o vencimento te diz quanto, por quanto tempo.

Essa distinção importa ao construir uma estratégia.

O TermMax não está apenas mudando como o lending no DeFi funciona. Ele está lidando com a incerteza criada por taxas que ficam se movendo o tempo todo e dando a ambos os lados termos mais claros desde o início.

É por isso que o DeFi com taxa fixa vale a pena acompanhar.

#TermMax

O que mais importa no lending?

Mais um dia, mais um par fazendo o gráfico ficar interessante.

$EDEN +27,59%
$ACE +27,08%

Os dois estão fazendo um movimento sólido em silêncio hoje. Enquanto isso, eu só estou observando e pensando qual deles eu deveria ter notado antes.

Antes eu achava que a seleção do comitê do Dusk era simplesmente mais stake = mais chances.

É mais nuançado do que isso.

O Dusk usa extração determinística para selecionar provedores com frequência de seleção proporcional ao stake.

Cada provedor elegível recebe créditos com base em uma pontuação pseudorrandômica e esses créditos determinam quem é selecionado para funções de consenso.

A parte interessante?

O processo é determinístico, mas as seleções futuras são difíceis de prever.

O Dusk usa SHA3 com entradas incluindo a semente do bloco anterior, o round e o step atuais, e o crédito que está sendo atribuído.

A semente então muda a cada bloco.

Há também um mecanismo de balanceamento que achei interessante.

Depois que um provedor recebe um crédito, seu peso é reduzido em 1 DUSK para a próxima seleção.

Então o sistema não é simplesmente:

Maior stake → influência permanente.

Em vez disso, ele combina peso de stake, aleatoriedade determinística e pesos de seleção em constante mudança.

O resultado é um processo de seleção de comitê em que o stake importa, mas saber quem será selecionado em seguida não é tão direto.

E para uma rede feita para a infraestrutura financeira, essa imprevisibilidade importa.

@Dusk $DUSK #dusk

O que mais molda a seleção do Dusk?

A lista de ganhadores está ficando interessante novamente.

$GPS +57,86%
$ACE +39,51%

Ambos estão tendo um dia bem bom enquanto eu fico aqui pensando por que sempre noto esses movimentos depois que eles acontecem.

Uma transação em blockchain costuma ser descrita como confirmada ou não. O modelo de consenso da Dusk deixa essa resposta mais sutil.

Um bloco pode passar por quatro estados: accepted (aceito), attested (atestada), confirmed (confirmado) e final. Cada etapa representa um nível diferente de confiança sobre se aquele bloco ainda pode ser substituído.

Um bloco accepted tem um attestation (atestado) de sucesso, mas ainda pode ser substituído por um bloco de iteração inferior com um atestado de sucesso. Um bloco attested tem um atestado de sucesso e todas as iterações anteriores falharam, então ele não pode ser substituído por um bloco de iteração inferior.

Depois vem confirmed (confirmado). Nessa etapa, é improvável que o bloco seja substituído, embora um ancestral ainda possa ser substituído. Por isso, confirmed é diferente de final.

Um bloco final vai um passo além: ele é confirmado e seu pai (parent) também é final. De acordo com a documentação, um bloco final não pode ser substituído em nenhuma circunstância.

Essa distinção é fácil de ignorar porque confirmed e final muitas vezes são tratados como a mesma coisa. A Dusk torna a progressão explícita.

Para aplicações financeiras, saber exatamente quando um bloco se torna irreversível não é um detalhe pequeno. Isso pode afetar quando uma liquidação pode ser considerada realmente concluída.

@Dusk $DUSK #dusk

Quando um bloco é verdadeiramente final?

O mercado de hoje está enviando sinais mistos.

$HEMI +27,74%
$CYS -52,75%

Um está disparando enquanto o outro está sendo completamente esmagado. Cripto realmente pode mudar o clima em segundos.

A identidade em uma blockchain nem sempre precisa significar colocar todos os detalhes sobre um usuário em exposição pública.

Por isso, a Citadel me chamou a atenção quando eu estava analisando a documentação do Dusk. O Glossário descreve a Citadel como a camada de identidade e acesso do Dusk, construída em torno de divulgação seletiva.

A ideia é simples, mas a distinção importa: comprovar quem alguém é ou se tem acesso não significa automaticamente tornar cada pedaço de informação de identidade visível para todos.

Para aplicações financeiras, isso pode se tornar importante. Uma rede pode precisar de controles de identidade e acesso enquanto ainda respeita a confidencialidade de informações sensíveis. Em vez de tratar transparência como uma escolha de tudo ou nada, a divulgação seletiva aponta para um modelo de visibilidade mais controlado.

O que acho interessante é que a Citadel fica ao lado da arquitetura mais ampla de privacidade do Dusk, em vez de substituí-la. O Dusk também define o Padrão do Contrato de Segurança Confidencial como uma estrutura que pode se adaptar às exigências do negócio, como restrições de privacidade e regras de conformidade.

Isso faz com que a identidade pareça menos uma caixa separada de KYC e mais parte da infraestrutura.

A pergunta real para mim é até onde a divulgação seletiva pode ir enquanto mantém aplicações financeiras tanto privadas quanto utilizáveis.

@Dusk $DUSK #dusk

A privacidade em uma blockchain não precisa significar que cada transação se torne invisível para todos, e essa distinção é importante para aplicações financeiras.

A Dusk aborda a privacidade por meio de diferentes níveis de visibilidade. A Moonlight oferece fluxos públicos transparentes de contas, enquanto a Phoenix oferece transferências protegidas com o uso de provas de conhecimento zero. Com a Phoenix, a correção de uma transação pode ser verificada sem expor publicamente o valor transferido, o remetente ou as notas específicas envolvidas.

A parte interessante é o que acontece quando alguém realmente precisa de evidências. A documentação da Dusk descreve a divulgação seletiva como uma forma de partes autorizadas, como emissores, espaços de negociação (venues), auditores ou supervisores, acessarem as informações necessárias sem tornar dados desnecessários públicos. As viewing keys podem ser usadas quando a regulamentação ou auditoria exige visibilidade controlada.

Isso cria uma ideia diferente de transparência. Em vez de presumir que tudo deve ser público para que uma blockchain continue auditável, a Dusk separa visibilidade pública de divulgação controlada.

Para mercados regulados, essa distinção pode importar. Um investidor pode não querer que todo saldo ou transferência seja exposto a toda a rede, enquanto um auditor ainda pode precisar de evidências específicas para verificar uma transação ou um processo financeiro.

Portanto, o objetivo não é simplesmente transações privadas. É, de forma mais precisa, manter informações sensíveis em sigilo enquanto preserva um caminho para verificação autorizada quando isso realmente for necessário.

@Dusk $DUSK #dusk

As transações públicas e privadas normalmente exigem sistemas diferentes, mas a Dusk coloca ambos os modelos na mesma rede.

Moonlight é o modelo de transação de conta pública da Dusk. Uma transação identifica o remetente e o destinatário por meio de suas chaves públicas, enquanto campos como valor nonce limite de gas preço do gas e assinatura ajudam a rede a verificar e processar a transação. O modelo também oferece proteções como intratabilidade (unforgeability) prevenção de gastos duplos (double spending) não-maleabilidade (non malleability) e prevenção de ataques de replay.

Phoenix adota uma abordagem diferente. Ela se baseia na arquitetura UTXO, semelhante ao Bitcoin, mas adiciona mecanismos de privacidade. Em vez de expor qual nota específica foi gasta, a rede rastreia nullifiers para impedir gastos duplos sem identificar publicamente a nota exata dentro da árvore de Merkle.

Também há uma diferença importante na verificação. As transações Phoenix incluem uma prova de conhecimento zero (zero knowledge proof), permitindo que a rede verifique que a transação segue as regras sem depender do mesmo tipo de checagens diretas usadas pela Moonlight.

Assim, Moonlight e Phoenix não são versões concorrentes da Dusk. Elas fornecem modelos de transação diferentes para diferentes requisitos de visibilidade.

@Dusk $DUSK #dusk

Blockchains públicas e finanças reguladas frequentemente parecem querer coisas opostas. Uma favorece a visibilidade aberta, enquanto a outra precisa de auditabilidade da confidencialidade e conformidade.

O Dusk foi projetado em torno dessa lacuna.

O whitepaper do Dusk descreve uma blockchain focada em privacidade, pronta para conformidade, destinada a conectar plataformas descentralizadas com mercados financeiros tradicionais. Em vez de tratar privacidade e regulamentação como camadas separadas, o Dusk coloca auditabilidade de transações confidenciais e conformidade na base de sua infraestrutura.

O modelo de transações é uma parte importante desse design. O Dusk oferece suporte ao Moonlight, seu modelo público baseado em contas, ao lado do Phoenix, seu modelo UTXO blindado. Isso permite que a rede tenha maneiras diferentes de lidar com a visibilidade das transações, dependendo do caso de uso.

Isso importa para aplicações financeiras porque privacidade não necessariamente significa que a informação desapareça. A abordagem do Dusk está mais para controlar o que é visível e para quem, preservando a capacidade de atender aos requisitos dos mercados regulados.

Para mim, isso torna a proposta do Dusk mais interessante do que simplesmente chamá-la de blockchain de privacidade. Ela tenta fazer privacidade, conformidade e infraestrutura financeira funcionarem juntas no nível do protocolo.

@Dusk $DUSK #dusk

O mercado de hoje estava cheio de surpresas.

$CYS +95.27%
$UAI -33.33%

Um token está voando enquanto outro está levando uma grande queda. É assim que é a cripto. Eu só estava observando os gráficos hoje.

As pessoas muitas vezes presumem que duas blockchains precisam se entender antes de conseguirem trabalhar juntas. Quanto mais eu estudava a arquitetura do Babylon, menos convincente se tornava essa suposição.

O Bitcoin nunca foi projetado para interpretar a execução do Ethereum nem para manter uma cópia do estado dele. Tentar fazê-lo mudaria exatamente os princípios que tornam o Bitcoin previsível. Em vez disso, o Babylon aborda o problema por outro caminho. Em vez de ensinar o Bitcoin a entender outra blockchain, ele dá ao Bitcoin algo que ele já sabe avaliar: prova criptográfica. O objetivo não é entendimento compartilhado. É verificação independente.

Essa diferença mudou a forma como eu penso sobre interoperabilidade. Dois sistemas não precisam necessariamente falar a mesma língua para chegar à mesma conclusão. Eles só precisam de evidências que possam ser verificadas de acordo com as próprias regras. Nesse sentido, as provas ficam menos parecidas com mensagens e mais como testemunhas matemáticas que nenhum dos lados precisa interpretar confiando cegamente.

Quanto mais eu reflito sobre esse design, mais acho que a infraestrutura cross-chain talvez tenha estado fazendo a pergunta errada. Em vez de nos perguntarmos como as blockchains podem entender umas às outras, talvez devêssemos perguntar como elas podem verificar a mesma realidade permanecendo completamente independentes.

Talvez o futuro da interoperabilidade não pertença às redes que mais se comunicam. Talvez pertença àquelas que precisam confiar na comunicação o mínimo possível.

@BabylonLabs_io $BABY #baby

Faz 2 dias que não recebo pontos de trading 2026/07/31 e 2026/08/01. Aqui estão as capturas de tela

As pessoas muitas vezes presumem que, se o Bitcoin for participar em algum lugar, o próprio Bitcoin precisa se mover primeiro. Essa suposição moldou o design de cross chain por anos. Agora eu começo a achar que a movimentação não é a parte importante.

O que me chamou atenção ao ler a documentação do Babylon é que a arquitetura separa a titularidade da participação econômica. O BTC nativo permanece bloqueado na rede do Bitcoin sob suas premissas originais de segurança, enquanto seu valor econômico pode apoiar empréstimos, stablecoins, derivativos perpétuos e outras aplicações financeiras por meio dos Trustless Bitcoin Vaults. O objetivo não é realocar o Bitcoin. É estender o que o Bitcoin pode contribuir sem mudar o que o Bitcoin é.

Essa distinção mudou a forma como penso sobre interoperabilidade. Talvez tenhamos passado tempo demais projetando maneiras melhores de mover ativos entre ecossistemas e de menos tempo projetando sistemas que possam funcionar com ativos onde eles já existem.

Se essa ideia continuar a amadurecer, o papel do Bitcoin nas finanças descentralizadas talvez não dependa mais de quantas cadeias ele consegue alcançar. Pode depender de quanto atividade econômica pode se desenvolver enquanto o Bitcoin nunca sai de casa.

Talvez o futuro do BTCFi não seja sobre mover Bitcoin. Talvez seja sobre mover tudo, exceto Bitcoin.

@BabylonLabs_io $BABY #baby

As pessoas frequentemente presumem que, no momento em que o Bitcoin entra na DeFi, ele precisa deixar de ser Bitcoin. Tokens encapsulados, ativos sintéticos e custodiante(s) fizeram com que essa suposição parecesse quase inevitável. Agora, começo a pensar que a própria suposição merece mais escrutínio.

O que me chamou atenção na arquitetura da Babylon é que ela aborda o problema pela direção oposta. Em vez de criar outra representação do BTC, ela pergunta se o Bitcoin nativo pode permanecer na sua própria rede enquanto, ainda assim, suporta empréstimos, stablecoins, perpétuos e outras aplicações financeiras por meio de Trustless Bitcoin Vaults. O desafio não é dar ao Bitcoin uma nova identidade. É provar que a identidade existente dele já é suficiente.

Essa distinção mudou a forma como penso sobre garantias (colateral). Talvez a verdadeira inovação não seja inventar uma versão melhor do Bitcoin. Talvez seja projetar uma infraestrutura que se adapta ao Bitcoin, em vez de exigir que o Bitcoin se adapte primeiro.

Se essa abordagem tiver sucesso, a conversa sobre BTCFi pode mudar completamente. A pergunta não será mais como recriar Bitcoin em algum outro lugar. Será até onde o Bitcoin nativo pode participar sem nunca se tornar um ativo diferente.

Talvez o futuro do Bitcoin na DeFi não seja definido por representação. Talvez seja definido por preservar a autenticidade enquanto amplia a utilidade.

@BabylonLabs_io $BABY #baby

Muitas pessoas descrevem o Babylon Genesis como apenas mais uma blockchain. Depois de ler a documentação, não acho que seja a forma mais interessante de enxergá-la.

A maioria das blockchains está principalmente preocupada em produzir seus próprios blocos. O Babylon Genesis certamente faz isso, mas a documentação descreve repetidamente algo mais amplo. Ele atua como uma camada de coordenação para o staking do Bitcoin, marcação de tempo, segurança e distribuição de recompensas. Em vez de competir com o Bitcoin, ele organiza como a segurança do Bitcoin pode ser aplicada em outros sistemas.

Essa distinção mudou a forma como penso sobre a rede. O valor do Babylon Genesis talvez não venha de ser mais um destino para ativos. Ele vem de ajudar participantes independentes a chegarem à mesma visão de segurança e estado, enquanto eventos importantes são ancorados ao livro-razão do Bitcoin por meio de marcação de tempo e checkpointing.

Quanto mais eu refleti sobre esse desenho, menos parecia uma Layer 1 tradicional. Pareceu mais uma infraestrutura que coordena confiança do que que compete por ela. A produção de blocos é apenas uma das responsabilidades. O papel maior é fazer com que recompensas de segurança e a coordenação apoiada pelo Bitcoin funcionem como um único sistema.

Talvez o Babylon Genesis não seja definido pelos blocos que ele produz. Talvez seja definido por tudo o que ele coordena silenciosamente entre eles.

@BabylonLabs_io $BABY #baby

As pessoas muitas vezes presumem que, se um protocolo tem um operador, então esse operador também deve ser a parte em quem você confia seus ativos. Quanto mais eu estudei o design do cofre da Babylon, mais percebi que essas duas responsabilidades são intencionalmente separadas.

Um Provedor de Cofre tem um trabalho importante. Ele coordena o trabalho off-chain necessário para criar e mais tarde resgatar um cofre, incluindo geração de provas, tratamento de transações pré-assinadas e coordenação com os Application Vault Keepers. Mas, de acordo com a documentação, ele nunca detém nem controla o Bitcoin do depositante. As condições de gasto são definidas quando o cofre é criado, fazendo com que o papel do provedor seja operacional, e não custodial.

Essa distinção mudou a forma como eu penso sobre infraestrutura. A coordenação é necessária porque sistemas complexos precisam de participantes para manter os processos em andamento. Confiança é diferente. Confiança determina quem pode, em última instância, decidir o destino dos seus ativos.

A arquitetura da Babylon parece traçar um limite deliberado entre essas ideias. Um Provedor de Cofre ajuda o protocolo a funcionar, mas não obtém autoridade sobre o BTC em si. Mesmo que um provedor fique indisponível mais tarde, a documentação descreve um caminho de autoafirmação (self claim) do depositante, projetado para permitir que os usuários recuperem seu Bitcoin de forma independente.

Talvez um sinal de um design de protocolo mais maduro não seja remover completamente os papéis operacionais. É garantir que esses papéis nunca se tornem posições de custódia.

@BabylonLabs_io $BABY #baby

As pessoas muitas vezes presumem que, se você tem Bitcoin como garantia, mantê-lo tudo em um único lugar é a escolha mais simples. Quanto mais eu olhava para o design do cofre da Babylon, menos convencido eu ficava.

A documentação recomenda dividir o Bitcoin em dois cofres em vez de depender de apenas um. No começo isso soou como uma complexidade extra. Depois eu percebi que o design não é sobre criar mais cofres. É sobre criar mais controle. Cofres dentro de uma posição de empréstimo podem ser organizados de modo que a liquidação alcance um antes do outro, permitindo que um cofre sacrificial designado absorva as perdas enquanto um cofre protegido permanece intocado se as condições melhorarem antes de precisar de mais liquidação.

Isso muda a forma como eu penso sobre a garantia. Em vez de tratar cada satoshi como igualmente exposto, a Babylon introduz limites dentro da própria posição. O objetivo não é apenas sobreviver a uma liquidação. É evitar transformar cada contratempo de mercado em um evento de tudo ou nada.

Talvez uma boa concepção de garantia não seja medida pela quantidade de Bitcoin que você bloqueia. Talvez seja medida pelo grau de intenção com que você decide qual Bitcoin deve suportar a primeira camada de risco.

@BabylonLabs_io $BABY #baby

A maioria das pessoas assume que reunir ativos torna um sistema mais eficiente. Isso parece razoável até você começar a pensar no que acontece quando algo dá errado.

Os Cofres Bitcoin sem confiança (Trustless) da Babylon seguem um caminho claramente diferente. Em vez de colocar os BTC de muitos usuários em uma reserva compartilhada, cada cofre está ligado ao seu próprio UTXO. No começo, isso pode parecer um detalhe de implementação. Quanto mais eu examinava, mais parecia uma abordagem deliberada para gerenciar riscos, e não apenas para armazenar Bitcoin.

Quando a garantia é agrupada, o problema de um participante pode, aos poucos, virar uma preocupação de todos. Cofres isolados mudam essa relação. Cada cofre segue seu próprio ciclo de vida, seu próprio processo de verificação e seu próprio caminho de resgate. O risco permanece associado ao Bitcoin específico que está sendo usado, em vez de se espalhar entre depósitos não relacionados.

Isso me fez pensar se o isolamento realmente é sobre custódia. Talvez seja sobre preservar limites claros. Um protocolo não se torna mais resiliente porque reúne tudo. Às vezes, resiliência vem de garantir que posições independentes permaneçam independentes mesmo quando participam do mesmo sistema.

Talvez a parte mais importante do design dos cofres da Babylon não seja que o Bitcoin continue no Bitcoin. É que cada cofre carrega apenas sua própria responsabilidade.

@BabylonLabs_io $BABY #baby

As pessoas frequentemente descrevem sistemas cross-chain como se a parte mais difícil fosse enviar informações de uma rede para outra. Não estou convencido de que esse seja o verdadeiro desafio.

O Bitcoin não tem uma forma nativa de entender o que acontece no Ethereum. Ele não foi construído para interpretar a história de outra blockchain, e pedir que ele faça isso mudaria as próprias premissas que o tornam confiável.

O que me chamou a atenção na arquitetura da Babylon é que ela não tenta ensinar ao Bitcoin uma nova linguagem. Em vez disso, ela trata provas criptográficas como a única coisa que vale a pena apresentar. O objetivo não é uma mensagem melhor entre cadeias. É fornecer ao Bitcoin evidências que ele possa verificar sem depender da interpretação de outra pessoa.

Essa perspectiva me fez repensar a interoperabilidade. Talvez redes independentes não precisem entender umas às outras. Elas só precisam de uma forma confiável de validar a mesma realidade por meio de prova criptográfica.

Se isso for verdade, então a verificação de provas não é apenas um componente técnico escondido sob a superfície. Ela silenciosamente se torna a base que permite que sistemas separados coordenem entre si preservando seus próprios modelos de segurança.

Talvez o futuro da infraestrutura cross-chain não seja definido por quão bem as blockchains se comunicam, mas por quanto elas precisam confiar na comunicação em si.

@BabylonLabs_io $BABY #baby

Uma coisa que se destaca enquanto estudo o Babylon é que as limitações do Bitcoin podem, na verdade, ser uma de suas maiores forças. O Bitcoin Script nunca foi projetado para ser uma plataforma de contratos inteligentes de propósito geral. Sua simplicidade muitas vezes foi vista como uma restrição, mas a arquitetura do Babylon sugere outra perspectiva: em vez de pedir ao Bitcoin que se torne algo que ele não é, construir um sistema que respeite esses limites.

Essa filosofia de design chamou minha atenção. Em vez de estender o Bitcoin com novos opcodes ou depender de ativos “wrapped”, os Trustless Bitcoin Vaults usam as capacidades existentes de scripting do Bitcoin junto com verificação criptográfica em nível de protocolo para coordenar interações com aplicações externas. A documentação enfatiza que resgates e transições de estado entre cadeias são verificados usando os primitivos de script existentes do Bitcoin, em vez de exigir uma bifurcação (fork).

Quanto mais penso nisso, mais acredito que restrições frequentemente geram uma engenharia melhor. Quando um protocolo não pode depender de programabilidade ilimitada, ele precisa resolver problemas por meio de coordenação cuidadosa, em vez de adicionar complexidade à camada base. Essa abordagem parece diferente de tentar fazer toda blockchain funcionar do mesmo jeito.

Talvez a verdadeira inovação não seja fazer o Bitcoin se comportar como uma plataforma de contratos inteligentes. Talvez seja projetar sistemas que entendam o Bitcoin bem o suficiente para trabalhar com suas regras, em vez de reescrevê-las.

Restrições técnicas fortes acabam levando a um design de protocolo mais resiliente ou elas desaceleram a inovação a longo prazo?

@BabylonLabs_io $BABY #baby