Salman49

WHY 21X’S RULEBOOK MAKES DUSK MORE INTERESTING

I went into the 21X story thinking the interesting part was trading and settlement happening together. Then I started looking at the rules around that setup, and the Dusk connection became more interesting to me.

21X has its own Rulebook, Pre-Trade Controls and Default Management Policy. That tells me something important about what Dusk is actually building for @Dusk Putting a market onchain doesn't remove the rules around the market. Dusk is providing the infrastructure where those rules, trading activity and settlement can work together.

The Pre-Trade Controls are the part I keep coming back to. They check orders before execution. I like that detail because it shows where the blockchain stops being the whole story. Dusk can provide settlement and execution infrastructure, but the market still needs to decide what should be allowed through in the first place.

Then there’s the Default Management Policy. Someone failing to perform doesn't magically disappear because settlement happens onchain. There still has to be a process for dealing with that mess.

And this changes how I see the 21X connection. Dusk isn't replacing the rulebook with code. At least from what I can see, it's trying to put regulated market activity on infrastructure where execution, privacy and settlement can work closer together.

That makes me wonder about the bigger Dusk idea. Maybe the interesting part of regulated finance going onchain isn't removing all the old rules.

Maybe it's making the rules and the transaction live much closer together.

$DUSK #dusk

O Bitcoin acabou de ultrapassar os US$ 70 mil.

Mas aqui está a parte que eu estou observando.

A alta não foi impulsionada apenas por compradores à vista.

Mais de US$ 2,7 bilhões em shorts de cripto foram liquidados quando $BTC rompeu mais alto, transformando posicionamentos pessimistas em compras forçadas.

Isso cria um ciclo de realimentação bem desagradável.

O preço sobe.

Os shorts são apertados.

Os shorts compram de volta.

O preço sobe de novo.

O mercado começa a perseguir o movimento contra o qual estava apostando.

E agora — é aqui que fica interessante.

O BTC chegou a cerca de US$ 72,5 mil hoje, mas o RSI diário já estava perto de 79, mostrando o quanto a alta ficou superaquecida.

Então eu não estou interpretando US$ 70 mil como “mercado em alta confirmado”.

Estou vendo isso como um teste.

A demanda à vista consegue manter o BTC acima da zona de rompimento depois que os compradores forçados desaparecerem?

Porque os aperto de shorts podem iniciar uma alta.

Eles não conseguem provar que a alta vai durar.

Até o fim do mês, essa diferença vai importar muito mais do que a manchete do candle. #BTC

O TOKEN ESTÁ ONCHAIN. MAS QUEM ESTÁ OBSERVANDO O MERCADO?

Estou olhando para @Dusk e a combinação NPEX + Chainlink, e algo parece fácil de ignorar. Colocar um ativo financeiro onchain resolve o problema de propriedade. Não resolve automaticamente o problema de informação. O ledger sabe quem possui o título. Ele não sabe automaticamente quanto esse título vale fora da cadeia.

Ok, o ativo está onchain. Mas o preço ainda vem de algum lugar. É aí que DataLink faz mais sentido para mim. A Dusk diz que foi feita para levar dados oficiais do exchange NPEX para onchain. A parte útil não é apenas inserir um preço em um smart contract. É fornecer ao contrato uma conexão com o mercado onde o ativo existe. Caso contrário, a blockchain pode estar correta e ainda assim funcionar com uma imagem do mercado errada.

E é aqui que Data Streams muda a pergunta. Ele também não está trazendo dados de mercado para onchain? A diferença está em quão rápido essas informações precisam chegar. Data Streams é construído para dados de mercado de baixa latência e alta frequência. Se o mercado se mover primeiro e os dados chegarem depois, a transação pode ser executada conforme programado e ainda assim usar informações defasadas.

CCIP cria outra peça do quebra-cabeça. Ele trata a interoperabilidade entre cadeias, enquanto o padrão Cross-Chain Token lida com o movimento da DUSK por meio de mecanismos de queima e cunhagem (burn-and-mint). Assim, o ativo pode se mover entre redes sem fingir que a movimentação cross-chain, a descoberta de preço e os dados de mercado são um único problema.

Isso me faz ver a tokenização como algo menos “arrumadinho”. Emita o título. Registre a propriedade. Traga o preço do mercado. Mantenha essas informações atualizadas. Então deixe a aplicação agir com base nelas.

E, de repente, o token não está fazendo tanta coisa sozinho.

Por um tempo, tratei a tokenização principalmente como um problema de blockchain. Agora estou menos convencido. A parte mais difícil pode ser manter a blockchain conectada a tudo o que dá ao ativo seu significado financeiro.

Porque quando a negociação começa e o mercado se move, o smart contract não pode dizer: “Eu vou acompanhar depois.” $DUSK #dusk
$SKYAI $BNB

Milionário com Teste em Backtest, Operando ao Vivo

Seu backtest é um filme da Marvel. Operar ao vivo é a parte dos bastidores em que o orçamento de CGI acabou.

O backtest tem 91% de taxa de vitória porque só entra depois que a vela fecha verde. Sem escorregamento. Sem taxas. Sem a corretora dar aquele “ops, manutenção” três segundos antes do seu take profit. Ele preenche seu limite inteiro como se o book de ofertas estivesse segurando a porta para você. Fofo.

Aí você clica em “ao vivo”.

Reviravolta.

Seu limite erra porque seu roteador espirrou. Você envia a mercado, doa uma parte às taxas e vê sua vantagem evaporar antes mesmo de a operação carregar. O funding fica negativo como se estivesse levando sua posição para o lado pessoal. Três perdas se acumulam e seu cérebro desinstala “gestão de risco” para instalar “dobrar ou nada”. O backtest chama isso de “pullback saudável”. O app do seu banco chama de “saldo insuficiente”.

Fecha o mês. O PDF do backtest chega usando +14% e um sorriso convencido. O extrato do seu broker rasteja com -6%, um comprovante de funding, um imposto de saque e uma faixa de “obrigado por participar”. Mesma configuração. Mesmo ticker. Simulação diferente. Agora quatro partes estão brigando na justiça por um rastinho de pavio. O backtest está precificando um curso. O broker está contando comissões. Você está pesquisando no Google “como explicar isso pros pais”. O mercado está só cultivando seu stop.

Você no backtest: terno de fundo de hedge, seis monitores, dizendo “liquidez” no brunch.
Você ao vivo: cara que levou wicked às 9:15 da manhã e agora não consegue pagar o brunch.

A curva de patrimônio foi editada no Canva. As execuções foram escritas por uma conta fã. Sua disciplina era um template do Notion que você nunca abriu depois de duplicar.

“Backtest” não é análise. É hopium com rótulos nos eixos.

POR QUE O DUSK PRECISA DA IDEIA DE BLOBs DA ETHEREUM?

EIP-4844 foi o detalhe do DuskEVM que eu não conseguia situar direito no início. A Ethereum introduziu blobs para tornar a disponibilidade de dados mais barata. O Dusk já tem o DuskDS para liquidação e disponibilidade de dados, então. Por que trazer esse design para o Dusk?

A divisão em camadas me dá uma pista melhor. O DuskEVM lida com a execução da EVM, enquanto o DuskDS lida com liquidação e disponibilidade de dados. Isso significa que os blobs têm uma função específica aqui. Eles podem dar à camada de execução uma forma padrão de trabalhar com dados, sem colocar essa responsabilidade toda apenas no DuskEVM.

Rusk torna a implementação mais difícil de dispensar como um simples item de compatibilidade. Ele tem endpoints de blob para recuperar blobs por meio do compromisso ou do hash.

A Rusk Wallet também oferece suporte a transações com blobs. A Rusk também os verifica durante a checagem de pré-condições. Isso chamou minha atenção porque o blob agora faz parte do caminho da transação, não apenas algo que a EVM entende.

KZG deixa a conexão ainda mais específica. O EIP-4844 usa compromissos e provas KZG. As ferramentas do Dusk verificam compromissos de blob, enquanto as ferramentas de snapshot verificam a relação KZG antes de armazenar os objetos de blob.

Então as peças parecem se encaixar. O DuskEVM lida com a execução. O DuskDS lida com liquidação e disponibilidade de dados. Transações com blobs, recuperação e verificação KZG conectam essas responsabilidades.

Eu não descreveria o EIP-4844 como algo que o Dusk adicionou apenas por familiaridade com a Ethereum. Há um motivo arquitetural mais profundo para isso.

Mas por que esse design específico da Ethereum para uma rede que está construindo sua própria arquitetura em torno de mercados regulados?

#dusk . $DUSK @Dusk

E SE UMA TRANSAÇÃO EM BLOCOCHAIN NÃO ESTIVER ERRADA, SÓ ANTECIPADA?

Estou observando uma pequena mudança no Rusk v1.7.0 que me faz parar por um segundo. Ela trata de transações Moonlight que chegam com um nonce futuro. Em vez de rejeitá-las imediatamente, o Rusk pode enfileirá-las temporariamente enquanto a diferença (gap) do nonce se fecha.

Isso me faz pensar na diferença entre inválida e “demais cedo”. Se o nó ainda estiver aguardando uma transação anterior, a próxima pode simplesmente estar adiantada na sequência. O Rusk usa uma fila de retentativas limitada (bounded) para isso. Ele também emite um evento diferido enquanto a transação aguarda.

A comparação mais fácil para mim é uma transferência bancária. A transferência número dois chega ao sistema antes da número um. Eu não assumo automaticamente que a número dois é ruim. Primeiro, eu quero saber se o sistema está apenas aguardando a número um.

Isso me deixa com outro detalhe @Dusk interessante. A API HTTP pode retornar 202 Accepted quando uma transação é propagada. Mas isso não significa que ela já esteja no mempool nem finalizada. A documentação da Dusk até diz que a visão local mempoolTxs exclui transações com nonce futuro que ficam na prequeue.

Agora eu fiquei preso na parte do “diferido”. Se uma carteira ou uma exchange vê esse evento, o que ela deve fazer de fato com a transação? Deve esperar a transação avançar, ou existe outro sinal em que ela deva confiar?

Estou inclinado a apenas ficar de olho nisso. Mas eu ainda gostaria de saber como integrações reais lidam com esse período de espera.#dusk

$METAB $STAR $DUSK

POR QUE UM EVENTO EM BLOCKCHAIN NÃO É A MESMA COISA QUE FINALIDADE

Eu costumava pensar que uma exchange precisava, principalmente, saber quando uma transação de blockchain acontecia. Mas ao ver o Dusk, isso me fez questionar. Se uma transação ainda pode mudar, não tenho certeza se uma exchange deveria tratar esse evento como dinheiro definitivo.

Foi por isso que RUES (Rusk Universal Event System) chamou minha atenção. O Dusk lista especificamente o RUES para infraestrutura, indexadores e exchanges. Para mim, a parte interessante é o que a exchange faz depois de receber o evento.

O ciclo de vida de transações do Dusk separa incluída, executada, confirmada e finalizada. A documentação diz para monitorar a transação executada, verificar erros, confirmar que o bloco foi finalizado e re-escutar caso um bloco reverta. Eu entendo por que isso importa: creditar uma exchange cedo demais pode transformar um estado temporário em um saldo real.

Fico pensando nisso como rastreamento de encomendas. Se meu pacote diz “a caminho para entrega”, eu sei que ele está se movendo, mas eu não marcaria como entregue ainda. Talvez eu esteja sendo cauteloso demais, mas eu entendo por que uma exchange iria querer essa mesma lacuna entre “em movimento” e “entregue”.

O detalhe de idempotência me fez parar novamente. O Dusk orienta os scanners de depósitos a usarem o ID da transação do Dusk como chave de idempotência, e não o memo, e a escrever o crédito e o checkpoint do bloco de forma atômica. Assim, se o scanner travar e escanear o mesmo intervalo novamente, essa transação não deveria virar um segundo depósito.

E agora estou me perguntando se eu estava olhando para o RUES de forma simples demais. Se uma exchange precisa pensar separadamente sobre evento, finalidade, reversões e processamento duplicado, quanto do trabalho real está acontecendo depois que o blockchain diz que algo aconteceu? @Dusk #dusk $DUSK

POR QUE A TRANSPARÊNCIA PODE SE TORNAR UM PROBLEMA NAS FINANÇAS

A cripto fez a transparência parecer a resposta óbvia. Todo mundo vê a mesma atividade, então todo mundo consegue confiar no mesmo registro.
Mas não tenho certeza se essa lógica funciona da mesma forma nos mercados financeiros.

Se todo mundo consegue ver uma grande ordem, uma posição relevante ou um movimento sensível de uma empresa antes que ele seja concluído, essa informação pode mudar o comportamento de outras pessoas. A transparência pode ajudar o mercado a entender o que aconteceu, mas uma visibilidade excessiva também pode expor a pessoa que fez o movimento.

Por isso, a abordagem de privacidade da Dusk chamou minha atenção. Ela não parece tratar privacidade como simplesmente esconder tudo. A atividade pública pode continuar visível, enquanto transações sensíveis podem permanecer privadas, e informações específicas ainda podem ser compartilhadas quando uma parte autorizada precisar.

A Hedger me deixa essa ideia ainda mais interessante. A Dusk está construindo fluxos confidenciais de EVM em torno disso, com o objetivo de manter a atividade sensível em sigilo enquanto ainda torna possível verificar. A direção também inclui mais atividade de mercado privada, em vez de colocar todos os detalhes diante de todos.

Minha conclusão é bem simples:
Um bom mercado financeiro pode não precisar de mais transparência. Talvez precise de melhor controle sobre quem deve ver o quê.

Porque a transparência deve ajudar as pessoas a verificarem o mercado.

Ela não deve, automaticamente, dar vantagem a cada participante sobre todo mundo. DYOR.
@Dusk #dusk $DUSK

PENSEI QUE O CREPÚSCULO TINHA DEMAIS CAMINHOS. AÍ QUESTIONEI O QUE REALMENTE SIGNIFICA SIMPLES.

Notei algo ao ler sobre a infraestrutura de blockchain: geralmente chamamos um sistema de simples quando a arquitetura parece simples. Uma cadeia, um único caminho de execução, menos partes móveis. Parece ótimo. Mas comecei a me perguntar: simples para quem?

Foi isso que me chamou atenção no Dusk. No começo, ter um caminho EVM e um caminho nativo me pareceu uma complexidade desnecessária. Por que não escolher apenas um?

Então encontrei a própria comparação do Dusk. Integrações nativas sob medida poderiam levar de 6 a 12 meses e custar até 50× mais do que implantações em EVM, enquanto implantações em EVM poderiam ser concluídas em semanas.

Isso me fez olhar para o problema de outra forma.

O custo de um blockchain nem sempre está dentro do próprio blockchain. Muita coisa fica ao redor dele. Carteiras, exchanges, ferramentas de desenvolvimento, APIs, sistemas internos — todas aquelas conexões “chatas” que precisam funcionar antes que alguém se importe com a tecnologia por baixo.

E acho que é essa parte que subestimamos.

Se deixar uma cadeia mais simples significa que cada sistema externo precisa se esforçar mais para se conectar a ela, nós realmente removemos complexidade? Ou só movemos isso para outro lugar?

É por isso que hoje acho a arquitetura do Dusk mais interessante. Não porque ela tem dois caminhos, mas porque ela levanta uma questão maior sobre como a infraestrutura financeira deve ser construída.

Talvez a melhor arquitetura não seja a que tem o menor número de caminhos. É a que faz com que menos pessoas tenham que reconstruir o que já funciona.

DYOR.

$DUSK
@Dusk
#dusk

O TOKEN PODE SER FUNGÍVEL. A PESSOA QUE O DETÉM NÃO.

Fico preso em uma coisa específica sobre ativos regulados na cadeia.

Duas pessoas podem deter a mesma segurança.
Mas elas podem não ter os mesmos direitos.

O design de ativos regulados da Dusk traz elegibilidade, credenciais de identidade, vinculação de carteira e verificações de transferência para dentro do fluxo de trabalho. Então, apenas deter o token nem sempre é suficiente. A pessoa que o recebe também pode precisar atender às regras do ativo.

E isso me faz questionar como falamos sobre liquidez.

Normalmente, eu pergunto:

“Quanto dinheiro está disponível?”

Mas talvez isso seja apenas metade da história.

E se a melhor pergunta for:

“Quantas pessoas de fato estão autorizadas a receber esse ativo?”

Pode haver bastante capital esperando na lateral. Ainda assim, o verdadeiro grupo de compradores pode continuar pequeno.

A Citadel adiciona mais uma camada. Os participantes podem comprovar coisas como residência, faixa etária ou credenciamento por meio de divulgação seletiva. Eles não necessariamente precisam expor tudo sobre si.

É aí que isso fica interessante para mim.

Talvez o próximo problema de liquidez nas finanças tokenizadas não seja encontrar compradores suficientes.

É encontrar compradores suficientes que realmente estejam autorizados a se tornar proprietários.

@Dusk #dusk $DUSK

EU SEGUI UM BOTÃO “COMPRAR” ATÉ A NOITE. COMEÇOU A COMPLICAR RÁPIDO.

Eu vi o botão “Comprar” na Dusk Trade e, sinceramente, pensei: tudo bem, deve ser só mais um marketplace de ativos tokenizados.

Então eu olhei para o que precisa acontecer ao redor daquele botão.

Antes de eu poder comprar um ativo regulado, existe KYC e elegibilidade. Minha carteira precisa se conectar. O pagamento precisa corresponder ao ativo. Algumas informações precisam permanecer privadas, enquanto outras podem precisar chegar a um emissor, a uma plataforma (venue) ou a outra parte autorizada. E, depois de tudo isso, a negociação ainda precisa ser liquidada. A Dusk Trade foi projetada exatamente para esse tipo de fluxo, enquanto a DuskDS lida com a liquidação e a definitividade por baixo dele.

Isso me fez pausar.

O token em si não é a parte mais difícil.

Qualquer um pode dizer: “esta segurança agora está on-chain”. As perguntas desconfortáveis começam depois disso: Quem pode comprá-la? Quem pode transferi-la? O que o emissor pode ver? Quando o pagamento realmente é correspondido ao ativo?

É também por isso que a ideia nativa de emissão da Dusk chamou minha atenção. A documentação deles não trata um ativo como apenas um token sentado em cima de um sistema antigo. Eles observam todo o ciclo de vida — emissão, custódia, negociação, liquidação, divulgação e reporte — e questionam quanto disso pode realmente viver em torno do ledger.

E a Dusk Trade ainda está em pré-lançamento, então não estou fingindo que eu já usei esse mercado. Estou analisando o sistema que eles estão tentando construir.

Porque aquele pequeno botão “Comprar” esconde uma pergunta surpreendentemente grande:

As regras em torno de um ativo financeiro podem migrar para o on-chain junto com o próprio ativo?

DYOR. @Dusk #dusk $DUSK

A IDEIA MAIS INTERESSANTE DO TBV NÃO É O BOTÃO DE TOMAR EM EMPRÉSTIMO

A parte mais interessante do TBV, para mim, não é o botão de tomar em empréstimo. É a ordem de liquidação. Na testnet pública atual, o TBV mantém os cofres pequenos de propósito: tamanho mínimo do cofre é 0,01 BTC, tamanho máximo do cofre é 0,4 BTC, uma posição pode usar até 10 cofres, o fator de colateral em BTC é de 78% e a liquidação começa quando o fator de saúde cai abaixo de 1,0. O TBV também trava BTC na Bitcoin sem fazer wrapping ou bridging, e o Aave v4 é o primeiro app DeFi registrado por cima dele.

O que mais me chamou a atenção foi como a Babylon quer que você estruture o próprio BTC. A documentação recomenda primeiro um cofre sacrificial e, em seguida, um cofre protegido. Se a liquidação acontecer, o protocolo percorre os cofres em ordem e apreende apenas a quantidade mínima necessária para restaurar o fator de saúde desejado. O cofre protegido pode permanecer intacto. Você ainda pode reordenar os cofres depois, caso as condições do mercado mudem. Isso parece muito diferente do modelo comum de colateral “um único movimento pequeno e tudo vai embora”.

É por isso que o TBV parece maior do que uma simples demo de empréstimos para mim. Um cofre de BTC é criado para um app em peg-in e não pode ser movido para outro app depois, então o colateral não é apenas passível de empréstimo. Ele também é escalonado com uma finalidade. Eu volto mais para essa parte do que para a tela de empréstimo: não é se o BTC pode ser usado, mas quanto dele consegue sobreviver quando a posição começa a se mover na direção errada. DYOR.

@BabylonLabs_io #baby $BABY

PORQUE O “TRUSTLESS” AINDA DEPENDE DE COMO O PRODUTO É ESTRUTURADO

Administrador de fundo.

Foi essa a frase que me fez desacelerar.
A ideia da Babylon é fácil de entender. Trustless Bitcoin Vaults (TBV) são projetados para permitir que o Bitcoin permaneça Bitcoin enquanto é usado em aplicações financeiras, sem fazer wrapping nem abrir mão da custódia. É essa a parte que a documentação oficial explica claramente.

Então eu avancei para a integração planejada com o GoMining.

O anúncio diz que usuários institucionais devem travar BTC por meio do TBV, contrair empréstimos contra ele e alocar os recursos tomados emprestados em produtos de mineração gerenciados pelo GoMining. Também afirma que o veículo deve ser estruturado como um fundo tokenizado do GoMining, com um Fund Administrator independente, um Custodian e auditores. Ao mesmo tempo, diz que uma integração para varejo está sendo apenas considerada.

Foi aí que minha pergunta mudou.

Não era sobre se o TBV é trustless. Era sobre como o fundo interagiria com o TBV.

O anúncio público explica o objetivo, mas não descreve o fluxo completo de varejo. Ele não mostra publicamente como um futuro usuário de varejo sairia do app do GoMining para entrar em um TBV, nem se essa experiência será diferente da estrutura institucional.

Talvez esses detalhes sejam publicados quando o produto de varejo for lançado. No momento, eu simplesmente não consigo verificá-los na documentação pública.

A Celsius mudou um hábito para mim. Sempre que vejo palavras como Fund Administrator ou Custodian, eu passo mais tempo lendo a estrutura jurídica do que a seção de recompensas. Em produtos que combinam design de protocolo com produtos financeiros, esses documentos muitas vezes respondem a perguntas diferentes.

Então eu não estou esperando um APY mais alto.

Estou esperando o documento que explique o fluxo de varejo desde o primeiro toque no app até o cofre final de BTC. #baby $BABY @BabylonLabs_io

NFA.DYOR.

Por que o Staking de BTC + Provedores de Finalidade tornam a reputação da infraestrutura mensurável

Abri a documentação da Babylon na quinta-feira passada esperando mais um manual de “stake BTC, ganhar rendimento”. Fui desviado pelos Provedores de Finalidade. Rastreei uma delegação de ponta a ponta no testnet e percebi que isso não é staking passivo. Os detentores de Bitcoin escolhem manualmente quem executa a infraestrutura.

Seu stake de BTC não fica ativo quando você o bloqueia. Ele atinge o MsgCreateBTCDelegation, fica no BTCDelegationRegistry, espera por 6 confirmações de BTC e só então se vincula a um Provedor de Finalidade específico antes de qualquer poder de voto ser ativado. Essa ligação não é conversa de marketing. É estado do protocolo. Você pode consultá-la.

Então o EOTS ficou claro para mim. Se um FP assina duas vezes, você não entra com um recurso de governança. O protocolo extrai a chave secreta deles de forma criptográfica. Evidência, não argumentos. O QueryFinalityProviders já expõe chaves públicas, poder de voto e status de slashing. Eu continuei procurando um “índice de reputação” e percebi que a Babylon não precisa de um. Ela registra o comportamento bruto: uptime, slashes, fluxo de delegação. É a partir disso que a reputação é construída.

Isso parece escolher AWS vs GCP. Ninguém confia em slogans. Você verifica incidentes, uptime, MTTR. A Babylon ainda não classifica FPs, mas coloca os dados objetivos on-chain em vez de opiniões no Discord.

Pare de me importar com o rendimento em BTC depois disso. Comecei a observar a qual FP meu stake se liga, porque as ações deles são públicas, verificáveis e comparáveis. Isso é responsabilidade da infraestrutura que você pode medir, em vez de promessa através de $BABY not promise.

Fonte: Documentação da Babylon, novembro de 2025. Não é aconselhamento financeiro. DYOR. @BabylonLabs_io #baby $BABY

POR QUE A BABYLON DIVIDE A VERIFICAÇÃO EM ETAPAS ESPECIALIZADAS EM VEZ DE FAZER TUDO DE UMA VEZ

Eu abri o @BabylonLabs_io docs porque queria entender o staking do Bitcoin. Estranhamente, não foi o staking que ficou comigo. Eu me prendi em algo muito menor. Eu estava seguindo um checkpoint e percebi que ele nunca ia direto para o Bitcoin. Ele ficava se movendo de uma parte do protocolo para outra.

No começo, pensei que tinha perdido alguma coisa. Por que não deixar um único componente fazer tudo? Mas, quanto mais diagramas eu olhava, mais parecia algo intencional. O epoching termina primeiro. Ele espera o fim de um epoch e mantém o conjunto de validadores estável antes mesmo de um checkpoint ser criado. Considerando que o Bitcoin só produz um bloco a cada cerca de 10 minutos, não faria muito sentido empurrar cada evento do protocolo para lá.

Depois, o checkpoint se move novamente. O módulo de Checkpointing coleta assinaturas BLS em um único checkpoint. Um Vigilante o envia para o Bitcoin usando OP_RETURN. Mais tarde, o BTC Light Client verifica os cabeçalhos do Bitcoin de forma independente. Eu continuava esperando um lugar onde tudo se juntasse, mas Babylon nunca funciona exatamente assim.

A mesma coisa aconteceu quando cheguei ao resto da arquitetura. O BTC Staking não estava tentando verificar checkpoints. Os Finality Providers não estavam gerenciando delegações. O EOTS não era outro módulo de staking. Cada parte parecia confortável fazendo um trabalho e depois saindo do caminho. O protocolo nunca pede para um único componente saber de tudo.

Eu acho que é nessa parte que a arquitetura finalmente fez sentido para mim. Não porque eu entendi outro módulo, mas porque eu parei de procurar o módulo principal. Toda vez que uma peça terminava seu trabalho, outra assumia em silêncio. Acabei passando mais tempo observando essas transições do que os próprios componentes.

DYOR.

#baby $BABY

POR QUE O CARIMBO DE TEMPO DO BITCOIN + CHECKPOINTING DIVIDE A FINALIDADE EM DUAS CAMADAS

Eu sempre achei que a finalidade era simples. Quando termina, acabou.

Depois que eu li sobre como o Protocolo de Carimbo de Tempo do Bitcoin e o Checkpointing funcionam juntos, mudei minha forma de pensar sobre finalidade.

Toda blockchain quer confirmações rápidas. Os usuários também querem confiança de que a história não vai mudar depois. Fazer ambos com um único sistema é mais difícil do que parece.

A Babylon Labs não tenta tornar o Bitcoin mais rápido. Ela dá ao Bitcoin uma função diferente.

Quando um epoch alcança a finalidade por meio dos Provedores de Finalidade, a Babylon Chain continua em execução. O módulo x/checkpointing então cria uma raiz de Merkle do epoch. O Protocolo de Carimbo de Tempo do Bitcoin escreve apenas esse compromisso criptográfico no Bitcoin usando OP_RETURN. O Bitcoin não precisa de todos os blocos nem de todas as transações desse epoch.

Essa foi a parte que achei interessante.

Se cada etapa tivesse que esperar pelo Bitcoin, cada cadeia conectada desaceleraria. A Babylon evita isso permitindo que a rede avance primeiro. O Bitcoin é usado para ancorar o checkpoint concluído mais tarde.

Para mim, essa é a ideia real por trás desse design.
Checkpointing não é apenas sobre economizar espaço de blocos do Bitcoin. É sobre decidir quando o Bitcoin deve ser envolvido. A coordenação rápida acontece na Babylon Chain. O Bitcoin ajuda a proteger o registro depois que o trabalho já foi feito.

É por isso que eu acho que o Protocolo de Carimbo de Tempo do Bitcoin e o Checkpointing não apenas melhoram a finalidade. Eles separam dois trabalhos diferentes que muitas blockchains tentam lidar com o mesmo processo.

DYOR.

#baby $BABY @BabylonLabs_io

A luta garantida pelo Bitcoin de que ninguém está pronto para se preparar

Eu abri a documentação da Babylon porque queria entender uma coisa.

O que, na prática, significa “segurança garantida pelo Bitcoin”?

A resposta foi mais simples do que eu esperava. O Bitcoin ajuda a proteger a rede. A cadeia ainda executa seu próprio código, apps e atualizações. São duas funções diferentes.

Então surgiu outra pergunta na minha cabeça.

Se uma cadeia usando segurança baseada em Bitcoin for hackeada, quem fica com o prejuízo na reputação?

A cadeia?

Ou o Bitcoin?

É aí que eu acho que as coisas ficam confusas.

Imagine o primeiro título:

Cadeia garantida pelo Bitcoin é hackeada.

A maioria das pessoas não vai abrir a matéria. Elas não vão checar se o problema veio de um contrato inteligente, do próprio código da cadeia ou da camada de segurança baseada em Bitcoin. Elas só vão lembrar de duas palavras: Bitcoin e hackeada.

Por isso, acho que o maior desafio não é técnico.

É o significado dessas duas palavras.

A documentação explica como o Bitcoin ajuda a proteger a rede. Ela não diz que o Bitcoin corrige todo bug ou controla o que os desenvolvedores constroem em cima.

São coisas separadas.

A tecnologia pode funcionar exatamente como foi projetada, mas o título ainda pode contar uma história completamente diferente.

Talvez eu esteja pensando longe demais.

Mas o cripto nunca discutiu apenas sobre código.
Passamos anos debatendo palavras como Bitcoin “real”, Layer 2 e descentralização.
Não vou me surpreender se “segurado pelo Bitcoin” virar a próxima. _DYOR.

#baby $BABY @BabylonLabs_io

Quem Fica Rico quando Você Paga uma Multa? Babilônia Diz: Ninguém

Na semana passada eu recebi uma multa de ₹500 (challan). Eu avancei no semáforo vermelho. O dinheiro foi para o governo.

Então meu banco ficou com ₹400 por um EMI com 1 dia de atraso. A data de vencimento estava escondida em um texto pequeno. Meu erro foi o lucro deles.

Naquele dia eu entendi uma coisa. Se alguém ganha com meu erro, nunca vai me ajudar a evitá-lo.

Aí comecei a usar Babylon. Babylon permite que você coloque seu Bitcoin como garantia (stake) para ajudar a proteger outras blockchains. Você ganha recompensas quando segue as regras.

Mas e se você quebrar as regras? A Babylon tem uma penalidade chamada slashing.

A documentação da Babylon diz: se um validador fraudar, o Bitcoin deles que está em stake é cortado (slashed). Slashed significa que ele é queimado. Os docs são claros — esse Bitcoin não vai para a equipe da Babylon. Não vai para outros usuários. Ele simplesmente se perde para sempre.

Esta é a diferença fundamental.

Com minha multa de trânsito, o governo ganha. Com meu banco, o banco ganha. Então eles lucram quando eu falho.

Com a Babylon, ninguém ganha com a penalidade. O Bitcoin é destruído. Então o único motivo da regra é manter o sistema seguro, e não fazer dinheiro.

Um sistema em que a punição não tem vencedor é um sistema construído sobre confiança.

Agora, antes de eu usar qualquer app ou serviço, eu pergunto: "Quem fica com o dinheiro se eu cometer um erro?"

Se a resposta for "a empresa", eu não confio.
Se a resposta for "ninguém", como na Babylon, eu sei que a regra é limpa. #baby $BABY @BabylonLabs_io