QIU球比特

@梨浅Grace

梨浅Grace

🌏【Tema】Convergência de Duas Olas: Reescrevendo as Regras Financeiras On-chain com Agentes de IA + Web3 OI

📅 【Horário】16 de agosto de 2026 19:30 (UTC+8)

🌕【Texto de Abertura】
O mar avançando e recuando, a era iterando; como os antigos dizem, as ondas do Yangtze impulsionam as novas, substituindo o velho. Quando a onda inteligente da sabedoria da inteligência artificial encontra a grande transformação revolucionária do Web3 descentralizado, duas correntes históricas se encontram e estão remodelando o cenário de todo o sistema financeiro on-chain. Ao olhar para o passado da indústria, as transações tradicionais on-chain sempre esbarraram na fadiga de monitorar telas manualmente, na interferência de emoções subjetivas e na dor de lidar com enormes volumes de dados sem conseguir analisá-los de forma clara — inúmeras pessoas do setor ficam presas na diferença de informações e na lentidão na tomada de decisões.

Agora, com a rápida ascensão da tecnologia de AI Agent, o ecossistema Web3 ganha uma solução totalmente nova: decisão inteligente, análise de dados e execução automática, fazendo com que as finanças on-chain entrem em uma nova fase de digitalização e inteligência. Oportunidade e mudanças coexistem; sob o vento da inovação, apenas a infraestrutura que realmente pode ser colocada em prática consegue atravessar os ciclos.

Nesta noite, reunimo-nos aqui para uma discussão profunda sobre AI + Web3. No estúdio, as estrelas se reúnem: temos a honra de convidar diversos OGs da indústria, especialistas experientes, grandes streamers do setor e craques de pesquisa e investimento para compartilhar suas visões. Fica ligado!

🎤 Apresentação Especial (Host)
🎙Apresentador(a) premium convidado(a)👉🏻梨浅Grace @梨浅Grace
🎙Coproponente👉🏻旭好传媒@旭好传媒
🎙Coproponente👉🏻OI Agent @oiagent_

👥【Convidados Especiais em Destaque】(Speakers)
🔹Web3 Peter 张 @Web3-PeterZhang ｜Web3 OG
Gerente de Produto sênior do OI Agent
🔹星睿@星睿｜Especialista sênior em blockchain da indústria
🔹华佗@HTWhale ｜Especialista sênior Web3 da comunidade 梁山
🔹ANNA汤圆 @Anna-汤圆｜Streamer premium/Gold da Binance Square no Web3
🔹NiKi葡萄@Niki葡萄｜Investidor sênior de Web3
🔹YZZ竹竹@竹竹YZZ ｜Observador sênior de pesquisa e investimento em blockchain

📌【Link da transmissão ao vivo na Binance Square】
https://app.binance.com/uni-qr/cspa/44484277780290?l=zh-CN&r=BLA7SFFI&source=host_share&uc=web_square_share_link&us=copylink

📌【Link da transmissão ao vivo no Loopspace】
https://loopspace.xyz/s/yHS7Q9xB9E

PINNED

Tenho uma dúvida sobre as palavras “reservas de BTC em quantia integral”: mesmo que exista de fato BTC em um endereço, por que o contrato de stablecoin em outra blockchain saberia que esse dinheiro realmente foi bloqueado e poderia ser usado para resgate ou liquidação de acordo com as condições estabelecidas? A arquitetura de stablecoins dos Trustless Bitcoin Vaults (TBV) no white paper da Babylon aborda primeiro “como a evidência de colateral pode ser vista”. Depois que o usuário deposita o BTC nativo em um Vault no Bitcoin, a cadeia de contratos inteligentes verifica esse depósito via um light client do Bitcoin e, então, cunha tokens ancorados em dólar conforme a taxa de colateral predefinida. O BTC não é transferido para a cadeia de contratos inteligentes e nem precisa ser entregue previamente a um custodiante para ser convertido em um ativo embrulhado. O mais importante aqui não é apenas haver um BTC na cadeia, mas sim que o sistema de stablecoins consiga verificar: a qual Vault pertence esse BTC, se ele ainda está bloqueado no momento e quanto limite de cunhagem corresponde. O TBV tenta fazer com que a prova de colateral participe diretamente das regras de cunhagem, em vez de exigir que o usuário apenas confie em um emissor que periodicamente publique um relatório de reservas. Claro que isso ainda é a direção de aplicação de stablecoins proposta no white paper, e não a stablecoin da Babylon já lançada. O que realmente precisa ser testado é se o light client e a validação cross-chain conseguem sincronizar com precisão o estado do Vault o tempo todo. Se acontecer algo no Bitcoin que diverja do que o contrato considera que aconteceu, até mesmo um endereço de colateral totalmente transparente não terá utilidade. Manter o BTC na cadeia original é apenas o primeiro passo; fazer com que o fato de colateral seja reconhecido de forma correta e contínua por outra blockchain é a etapa mais difícil e mais crítica deste plano. @babylonlabs_io #baby $BABY

Verificado

Tenho uma dúvida sobre as palavras “reservas de BTC em quantia integral”: mesmo que exista de fato BTC em um endereço, por que o contrato de stablecoin em outra blockchain saberia que esse dinheiro realmente foi bloqueado e poderia ser usado para resgate ou liquidação de acordo com as condições estabelecidas?
A arquitetura de stablecoins dos Trustless Bitcoin Vaults (TBV) no white paper da Babylon aborda primeiro “como a evidência de colateral pode ser vista”. Depois que o usuário deposita o BTC nativo em um Vault no Bitcoin, a cadeia de contratos inteligentes verifica esse depósito via um light client do Bitcoin e, então, cunha tokens ancorados em dólar conforme a taxa de colateral predefinida. O BTC não é transferido para a cadeia de contratos inteligentes e nem precisa ser entregue previamente a um custodiante para ser convertido em um ativo embrulhado.
O mais importante aqui não é apenas haver um BTC na cadeia, mas sim que o sistema de stablecoins consiga verificar: a qual Vault pertence esse BTC, se ele ainda está bloqueado no momento e quanto limite de cunhagem corresponde. O TBV tenta fazer com que a prova de colateral participe diretamente das regras de cunhagem, em vez de exigir que o usuário apenas confie em um emissor que periodicamente publique um relatório de reservas.
Claro que isso ainda é a direção de aplicação de stablecoins proposta no white paper, e não a stablecoin da Babylon já lançada. O que realmente precisa ser testado é se o light client e a validação cross-chain conseguem sincronizar com precisão o estado do Vault o tempo todo. Se acontecer algo no Bitcoin que diverja do que o contrato considera que aconteceu, até mesmo um endereço de colateral totalmente transparente não terá utilidade. Manter o BTC na cadeia original é apenas o primeiro passo; fazer com que o fato de colateral seja reconhecido de forma correta e contínua por outra blockchain é a etapa mais difícil e mais crítica deste plano.
@BabylonLabs_io #baby $BABY

🎙️ Vamos conversar sobre isso

Encerrado

01 h 33 min. 18 seg.

1.2k

Muita gente, ao ouvir “privacidade financeira”, tem a primeira reação: “As transações ficam escondidas, então como a supervisão vai conseguir verificar?” Mas o que as instituições realmente precisam nunca foi fazer com que todos fiquem invisíveis para sempre; é impedir que pessoas indevidas vejam, enquanto aqueles que precisam revisar consigam verificar dentro do escopo autorizado. O Hedger na DuskEVM mira exatamente esse conflito. Redes públicas comuns tornam públicos o saldo das contas, os valores das transações e o fluxo de fundos; a alocação de capital das empresas, as posições de instituições e até mesmo as intenções de negociação podem ser expostas. Se simplesmente esconder essas informações por completo, perde-se a capacidade de auditoria exigida pelo mercado regulado. O Hedger não faz a escolha entre “totalmente público” e “completamente anônimo”. De acordo com os materiais oficiais da Dusk, ele combina criptografia homomórfica e provas de conhecimento zero: a criptografia homomórfica permite que o sistema processe dados criptografados sem revelar os valores numéricos; as provas de conhecimento zero são usadas para provar que o cálculo segue as regras, sem divulgar as entradas subjacentes. Posições, saldos e valores de transferências podem permanecer confidenciais, ao mesmo tempo em que mantêm um caminho verificável para auditorias necessárias. Essa é também a chave para eu entender a privacidade programável da Dusk: privacidade não é apagar a transparência, e sim decidir novamente quem pode ver o quê, e sob quais condições verificar o quê. Ela é adequada para o mercado financeiro não porque a supervisão fica do lado de fora, mas porque concorrentes e observadores sem relação não devem ter a mesma visão que os reguladores. No momento, o site oficial da Dusk ainda marca a DuskEVM como Testnet, e o verdadeiro valor do Hedger depende das aplicações futuras. O mais digno de observar não é o quanto ele consegue esconder, e sim se, quando auditorias realmente acontecerem, será possível divulgar apenas as informações necessárias sem expor novamente, na cadeia pública, a estratégia completa de transações das instituições.#dusk $DUSK @Dusk_Foundation

Muita gente, ao ouvir “privacidade financeira”, tem a primeira reação: “As transações ficam escondidas, então como a supervisão vai conseguir verificar?” Mas o que as instituições realmente precisam nunca foi fazer com que todos fiquem invisíveis para sempre; é impedir que pessoas indevidas vejam, enquanto aqueles que precisam revisar consigam verificar dentro do escopo autorizado.
O Hedger na DuskEVM mira exatamente esse conflito. Redes públicas comuns tornam públicos o saldo das contas, os valores das transações e o fluxo de fundos; a alocação de capital das empresas, as posições de instituições e até mesmo as intenções de negociação podem ser expostas. Se simplesmente esconder essas informações por completo, perde-se a capacidade de auditoria exigida pelo mercado regulado.
O Hedger não faz a escolha entre “totalmente público” e “completamente anônimo”. De acordo com os materiais oficiais da Dusk, ele combina criptografia homomórfica e provas de conhecimento zero: a criptografia homomórfica permite que o sistema processe dados criptografados sem revelar os valores numéricos; as provas de conhecimento zero são usadas para provar que o cálculo segue as regras, sem divulgar as entradas subjacentes. Posições, saldos e valores de transferências podem permanecer confidenciais, ao mesmo tempo em que mantêm um caminho verificável para auditorias necessárias.
Essa é também a chave para eu entender a privacidade programável da Dusk: privacidade não é apagar a transparência, e sim decidir novamente quem pode ver o quê, e sob quais condições verificar o quê. Ela é adequada para o mercado financeiro não porque a supervisão fica do lado de fora, mas porque concorrentes e observadores sem relação não devem ter a mesma visão que os reguladores.
No momento, o site oficial da Dusk ainda marca a DuskEVM como Testnet, e o verdadeiro valor do Hedger depende das aplicações futuras. O mais digno de observar não é o quanto ele consegue esconder, e sim se, quando auditorias realmente acontecerem, será possível divulgar apenas as informações necessárias sem expor novamente, na cadeia pública, a estratégia completa de transações das instituições.#dusk $DUSK @Dusk

DUSK+6,11%

O streamer que melhor sabe explicar USD1 na internet @帮帮Bonnie @Jiayi Li bigbox🧧🧧🧧🧧

O conteúdo citado foi removido

Grande caixa de benefícios big box

O conteúdo citado foi removido

A parte mais fácil de relaxar a vigilância nas stablecoins é a palavra “稳” no próprio nome. O fato de o preço ficar temporariamente perto de um dólar não significa que as regras não vão mudar; enquanto reservas, cunhagem e resgate estiverem controlados por uma única empresa, o usuário, no fim, continua acreditando que ela vai cumprir. Quando li a Seção 6 do whitepaper da Babylon, o que realmente me interessou não foi criar mais um token que replique um dólar, e sim a tentativa das Trustless Bitcoin Vaults (TBV) de trocar a base de confiança por trás da stablecoin. De acordo com a arquitetura proposta no whitepaper, o usuário bloqueia o BTC nativo em uma Bitcoin Vault criada por ele mesmo; a cadeia de contratos inteligentes verifica esse colateral por meio de light clients; e então cunha tokens ancorados em dólar com base na taxa de colateral definida. O BTC não é entregue a um custodiante, nem precisa atravessar a ponte antes para virar um ativo tokenizado. Isso significa que a avaliação do colateral pelo usuário não precisa depender apenas de a emissora publicar um comprovante de reservas; o estado do Vault, a taxa de colateral e as regras de cunhagem e destruição podem ser verificadas on-chain. O que o TBV realmente muda não é “qual empresa emite a stablecoin”, mas a substituição de parte dos compromissos institucionais por fatos de colateral verificáveis. Claro, isso é apenas a direção de aplicação apresentada no whitepaper; no momento, a testnet pública na prática libera é o Aave v4 de empréstimos e não uma stablecoin da Babylon já em produção. No futuro, o que eu mais quero observar não é como ela será chamada, e sim se o oráculo, o mecanismo de liquidação e a ancoragem conseguem continuar seguindo regras públicas mesmo em cenários de alta volatilidade. Para que as stablecoins dependam menos de reputação, elas precisam primeiro garantir que o colateral e a saída aguentem verificação. #baby $BABY @babylonlabs_io

A parte mais fácil de relaxar a vigilância nas stablecoins é a palavra “稳” no próprio nome. O fato de o preço ficar temporariamente perto de um dólar não significa que as regras não vão mudar; enquanto reservas, cunhagem e resgate estiverem controlados por uma única empresa, o usuário, no fim, continua acreditando que ela vai cumprir.
Quando li a Seção 6 do whitepaper da Babylon, o que realmente me interessou não foi criar mais um token que replique um dólar, e sim a tentativa das Trustless Bitcoin Vaults (TBV) de trocar a base de confiança por trás da stablecoin. De acordo com a arquitetura proposta no whitepaper, o usuário bloqueia o BTC nativo em uma Bitcoin Vault criada por ele mesmo; a cadeia de contratos inteligentes verifica esse colateral por meio de light clients; e então cunha tokens ancorados em dólar com base na taxa de colateral definida. O BTC não é entregue a um custodiante, nem precisa atravessar a ponte antes para virar um ativo tokenizado.
Isso significa que a avaliação do colateral pelo usuário não precisa depender apenas de a emissora publicar um comprovante de reservas; o estado do Vault, a taxa de colateral e as regras de cunhagem e destruição podem ser verificadas on-chain. O que o TBV realmente muda não é “qual empresa emite a stablecoin”, mas a substituição de parte dos compromissos institucionais por fatos de colateral verificáveis.
Claro, isso é apenas a direção de aplicação apresentada no whitepaper; no momento, a testnet pública na prática libera é o Aave v4 de empréstimos e não uma stablecoin da Babylon já em produção. No futuro, o que eu mais quero observar não é como ela será chamada, e sim se o oráculo, o mecanismo de liquidação e a ancoragem conseguem continuar seguindo regras públicas mesmo em cenários de alta volatilidade. Para que as stablecoins dependam menos de reputação, elas precisam primeiro garantir que o colateral e a saída aguentem verificação. #baby $BABY @BabylonLabs_io

Eu costumava ver o BTC se tornar colateral do Aave e, instintivamente, entendia que o BTC já tinha sido transferido para o Aave. Só depois de ler a camada do adaptador é que percebi que o Aave não recebe aquele BTC em si, e sim o seu estado de colateral.
Após a ativação do Trustless Bitcoin Vaults (TBV), o BTC nativo permanece travado no Taproot Vault do Bitcoin. O Aave v4 Adapter cria um registro interno de colateral com base na quantidade de BTC dentro do Vault, para que o mercado de empréstimos possa calcular o valor do colateral e o fator de saúde. Esse registro corresponde um a um ao BTC travado, mas não pode ser transferido para qualquer endereço, nem aparece na carteira do usuário ou no mercado secundário.
Em outras palavras, entre as duas cadeias o que é reconhecido é o fato, e não um ativo copiado: o Bitcoin é responsável por armazenar o BTC, e o Ethereum é responsável por ler “se este BTC atualmente está em um estado de colateral válido”. Quando o Vault é retirado ou liquidado, o registro correspondente de colateral também é encerrado.
Acho que é exatamente a parte em que o Babylon mais vale a pena compreender repetidamente. A posição do BTC não muda; o que muda é se ele pode obter um uso verificável sem sair do Bitcoin. No futuro, o que realmente precisa ser observado é se o produto consegue permitir que o usuário veja de relance onde está o meu BTC e o que o Aave está usando.
@BabylonLabs_io #baby $BABY

Eu costumava entender cross-chain como algo em que uma mensagem é enviada e a outra blockchain simplesmente executa o que foi ordenado. Só depois de estudar o mecanismo de resgate é que percebi que o mais difícil não é enviar a mensagem para o Bitcoin, e sim fazer com que o Bitcoin tenha um motivo para aceitar essa mensagem.
Trustless Bitcoin Vaults (TBV), durante o resgate, precisam primeiro provar que o evento de resgate correspondente na Ethereum já foi concluído; do lado do Bitcoin, então são emitidos Claim e Assert, com uma janela de contestação em seguida. A lógica aqui não é: “alguém disse que já foi pago, então libere os tokens”, e sim que essa alegação precisa vir acompanhada de provas e aguentar possíveis questionamentos.
Acho que essa é a parte mais interessante do TBV: ele não faz o Bitcoin fingir que consegue ler diretamente a Ethereum; em vez disso, ele quebra a confirmação cross-chain em três etapas — alegação, verificação e refutação. A lentidão não é um problema ocasional de experiência; ela faz parte do processo de verificação.
Para quem está acostumado a considerar que, uma vez confirmada a transação, acabou, essa estrutura muda as expectativas: a liberação do BTC não depende apenas de uma transação específica na Ethereum ser bem-sucedida, mas de essa transação poder ser provada de forma completa e ainda passar com sucesso por refutações que possam surgir.
O que realmente vale observar não é só se, no fim, o dinheiro cai ou não, mas também se, quando o resgate entra no fluxo, o usuário consegue enxergar em que fase está: Claim, Assert ou a etapa de desafio. Se a segurança cross-chain ficar apenas nos bastidores, ainda é difícil para a maioria das pessoas comuns formar uma confiança de verdade.
@BabylonLabs_io #baby $BABY

Eu antes entendi “sair” do penhor como um ato bem leve: não quer mais usar, então apenas mover os ativos de volta para a carteira a partir da página de empréstimos. Depois de ver todo esse processo de saída, eu achei que ele é mais parecido com uma liquidação clara de posição.
Nos Trustless Bitcoin Vaults (TBV), para sair completamente é preciso primeiro quitar o principal e os juros de toda a reserva de empréstimos; depois disso, o aplicativo inicia o Withdraw. O Vault não fica simplesmente ocioso esperando a próxima vez para ser novamente penhorado — em vez disso, ele segue diretamente para o processo de resgate do lado do Bitcoin. Ou seja, clicar em “sair” não é apenas colocar o colateral de lado; é encerrar o status de empréstimo desse Vault.
Embora isso pareça apenas um fluxo do produto, por trás ele muda a forma como os usuários avaliam a liquidez. Um Withdraw em uma interface comum faz você pensar facilmente em uma movimentação reversível a qualquer momento; já o TBV projeta isso como uma transição de estado com condições, que impulsiona os resgates subsequentes.
Portanto, se a saída está realmente disponível não deve ser avaliado só por ver se o botão está aceso: é necessário também verificar se a dívida já zerou, se o colateral restante está saudável e se o processo de resgate do lado do Bitcoin já foi iniciado. A verdadeira liquidez é ter essas condições entendidas — e a partir disso poder escolher.
O que eu realmente queria saber é: quando o usuário vê “Pending Withdraw”, ele entende de fato que não é a página travando, e sim que o BTC já saiu da posição de empréstimo para outra etapa de jornada de saída, com etapas de validação. Uma boa interface não só deve dizer que “está sendo processado”; ela também deve explicar em que estado o dinheiro se encontra agora.
@BabylonLabs_io #baby $BABY

🎙️ Negócios à vista nos EUA, com calma para comer a carne!

Encerrado

02 h 46 min. 46 seg.

11.9k

Eu achava que, nos empréstimos com garantia em BTC, a decisão mais importante acontecia no momento de decidir se emprestaria e quanto emprestaria. Depois de ler todo o fluxo de criação, percebi que muitas escolhas mais difíceis de desfazer na verdade estão todas antes do início do empréstimo.
Trustless Bitcoin Vaults (TBV), na criação, exige que o usuário decida se o BTC ficará em um Vault ou se será dividido em vários Vaults de acordo com a ordem de liquidação; em seguida, também exige que o usuário assine os caminhos de retirada e de pagamento do BTC e armazene os materiais necessários para retirar-se depois, de forma autônoma. Depois que os Vaults são ativados, o BTC só pode se mover ao longo do caminho para o qual as partes já concordaram no momento da criação.
Isso me fez compreender de novo o que significa “autocustódia”. Não é apenas se, ao sair, você ainda consegue voltar e recuperar o seu BTC; é também se, antes de entrar, você consegue enxergar claramente: em que situações pode ocorrer a liquidação, para onde o BTC finalmente pode ir e, se o provedor não responder, se ainda há ferramentas em suas mãos.
Para quem está acostumado a entender empréstimos como algo em que dá para ajustar a alocação a qualquer momento, esse tipo de arranjo não é nada confortável: parte da flexibilidade é trocada por regras de saída mais determinadas, devido às exigências antecipadas de assinatura, divisão em várias carteiras e backup. O verdadeiro custo de entendimento acontece justamente antes do primeiro clique.
A sensação de segurança do TBV não vem de adiar todas as escolhas, e sim de consolidar as decisões-chave com antecedência. O que vale observar a seguir é se a interface do produto consegue ajudar usuários comuns a entender essas promessas antes de assinar, e não apenas ver um botão de Deposit.
@BabylonLabs_io #baby $BABY

Ao observar o processo de criação do Babylon, acho que um problema realmente fácil de ignorar é o seguinte: se o BTC já tiver iniciado o processo, mas o Vault não conseguir ser ativado no final, o que acontece com os fundos?
Os Trustless Bitcoin Vaults (TBV), antes de serem ativados oficialmente, colocam o BTC em uma saída HTLC de um Pre-PegIn, em vez de bloqueá-lo diretamente no Vault final. Se, em seguida, as assinaturas, confirmações ou preparações fora da cadeia não forem concluídas dentro da janela, quem depositou poderá seguir o caminho de reembolso com o time lock previsto e recuperar o BTC por conta própria; o time lock de reembolso na rede de testes pública é de cerca de 3 dias.
Isso parece um caso extremo, mas eu acredito que é crucial. O que mais se teme em fluxos cross-chain não é apenas ser atacado, e sim ficar preso no meio do caminho. Ter uma rota de retirada que não dependa do provedor de serviços quando a inicialização falha — isso determina se os usuários se atrevem a dar o próximo passo.
Depois, vou ficar especialmente atento para ver se, nesses testes, esse tipo de cenário de falha é explicado com clareza: os usuários sabem por quanto tempo precisam esperar, quando podem reembolsar e o que precisam preparar. Concluir com sucesso é importante; conseguir sair com segurança quando falhar também é igualmente importante.
@BabylonLabs_io #baby $BABY

Verificado

Ao projetar a arquitetura TBV, um design que parece menos “fluido” na primeira impressão ficou mais marcante para mim: após a criação do BTC Vault, ele não é um credencial genérico que possa ser movido livremente para outras aplicações DeFi.
Quando Trustless Bitcoin Vaults (TBV) estão integrados ao Aave v4, o Vault já fica vinculado a essa integração do aplicativo na fase de criação; depois, se surgirem novas aplicações, também será necessário ter seus próprios contratos de adaptação e um processo de registro. Não é simplesmente “embalar” o BTC primeiro em um recibo que circula por todo lado e então deixar que todos os protocolos lidem com ele.
À primeira vista, isso pode sacrificar um pouco de composabilidade, mas eu prefiro entendê-lo como um tipo de limite: para qual aplicação serve cada BTC, quais parâmetros de risco e quais processos de resgate estão envolvidos — tudo isso é deixado claro desde o começo.
Isso também me faz prestar mais atenção à qualidade das expansões futuras do TBV, e não apenas quantos protocolos foram integrados. Quando aparecer um novo aplicativo, se é possível transformar etapas como empréstimo, liquidação e saída em adaptações independentes e verificáveis — talvez seja mais importante do que simplesmente adicionar mais uma porta.
@BabylonLabs_io #baby $BABY

A delegação (staking) de BTC da Babylon é muito forte, mas, na hora de sair, você ainda precisa seguir o Bitcoin Nesta semana, a $BABY está bem em alta. No protocolo, já existem 56,853 BTC participando do staking; o TVL é de cerca de 5,6 bilhões de dólares, o que torna este o maior conjunto de uma estrutura de BTC staking atualmente. Só olhando para o painel de dados, realmente é muito bonito. Mas eu acompanhei o fluxo de saída e, em vez disso, acabei travando justamente na parte de unstake. @babylonlabs_io sempre enfatizava um ponto: o seu BTC não sai da blockchain do Bitcoin, não precisa de wrapping, não tem custodiante, e ainda é self-custody. Essa afirmação tecnicamente não tem problema. O problema é que, quando você realmente quer sair, a liquidez não volta na hora. O unstaking do BTC precisa esperar os próprios blocos e o ritmo de liquidação do Bitcoin, então o unbonding costuma levar vários dias. Mesmo que o Genesis de #baby no lado do Cosmos seja rápido, isso não muda o tempo do lado do Bitcoin. Sair do BABY staking leva cerca de 2 dias. Mas o unstaking do BTC não é tão fácil. Isso acaba sendo bem sutil. Na divulgação, dizem trustless, flexível e sem risco de custódia; de fato, isso se sustenta na estrutura. Porque os ativos não foram enviados por bridge e nem foram entregues a um terceiro custodiante. Mas, na experiência prática, a “flexibilidade” ainda fica limitada pelo ritmo de liquidação do Bitcoin. A criptografia pode resolver bem o problema de confiança. Só que ela não resolve o problema da espera. No começo eu achava que era uma lacuna de UX; depois pensei melhor e talvez nem seja uma falha, e sim um custo que você precisa aceitar ao escolher fazer self-custody e não depender de bridge. Se você quer realmente manter a segurança nativa do BTC, precisa aceitar o cronograma do próprio Bitcoin. Então agora eu ainda estou pensando em uma questão: Quando, no final, o protocolo acaba recaindo sobre a camada de settlement do Bitcoin, o chamado trustless consegue, naturalmente, entregar apenas uma parte? Independentemente de como o design do protocolo no topo seja bonito, aqueles últimos dias de espera provavelmente acabam sendo as regras que o Bitcoin impõe para todo mundo.#baby $BABY @babylonlabs_io

Verificado

A delegação (staking) de BTC da Babylon é muito forte, mas, na hora de sair, você ainda precisa seguir o Bitcoin
Nesta semana, a $BABY está bem em alta.
No protocolo, já existem 56,853 BTC participando do staking; o TVL é de cerca de 5,6 bilhões de dólares, o que torna este o maior conjunto de uma estrutura de BTC staking atualmente. Só olhando para o painel de dados, realmente é muito bonito.
Mas eu acompanhei o fluxo de saída e, em vez disso, acabei travando justamente na parte de unstake.
@BabylonLabs_io sempre enfatizava um ponto: o seu BTC não sai da blockchain do Bitcoin, não precisa de wrapping, não tem custodiante, e ainda é self-custody.
Essa afirmação tecnicamente não tem problema.
O problema é que, quando você realmente quer sair, a liquidez não volta na hora. O unstaking do BTC precisa esperar os próprios blocos e o ritmo de liquidação do Bitcoin, então o unbonding costuma levar vários dias. Mesmo que o Genesis de #baby no lado do Cosmos seja rápido, isso não muda o tempo do lado do Bitcoin.
Sair do BABY staking leva cerca de 2 dias.
Mas o unstaking do BTC não é tão fácil.
Isso acaba sendo bem sutil.
Na divulgação, dizem trustless, flexível e sem risco de custódia; de fato, isso se sustenta na estrutura. Porque os ativos não foram enviados por bridge e nem foram entregues a um terceiro custodiante.
Mas, na experiência prática, a “flexibilidade” ainda fica limitada pelo ritmo de liquidação do Bitcoin.
A criptografia pode resolver bem o problema de confiança.
Só que ela não resolve o problema da espera.
No começo eu achava que era uma lacuna de UX; depois pensei melhor e talvez nem seja uma falha, e sim um custo que você precisa aceitar ao escolher fazer self-custody e não depender de bridge.
Se você quer realmente manter a segurança nativa do BTC, precisa aceitar o cronograma do próprio Bitcoin.
Então agora eu ainda estou pensando em uma questão:
Quando, no final, o protocolo acaba recaindo sobre a camada de settlement do Bitcoin, o chamado trustless consegue, naturalmente, entregar apenas uma parte?
Independentemente de como o design do protocolo no topo seja bonito, aqueles últimos dias de espera provavelmente acabam sendo as regras que o Bitcoin impõe para todo mundo.#baby $BABY @BabylonLabs_io

Verificado

Quando eu estava lendo as instruções de resgate do Babylon, o que mais me fez parar não foi “dá para usar o BTC nativo para empréstimos ou não”, e sim se o usuário realmente ainda tem um botão de saída quando o provedor de serviço não responde.
O caminho de resgate convencional dos Trustless Bitcoin Vaults (TBV) normalmente é conduzido pelo Vault Provider para efetuar a retirada do lado do Bitcoin; mas a documentação também deixa um modo de saque autônomo: quando a outra parte estiver offline, ficar lenta ou se recusar a agir, o depositante pode iniciar o saque por conta própria.
Isso me faz pensar que o foco do TBV não é apenas “não entregar o BTC ao intermediário”, mas sim escrever com antecedência no protocolo o que fazer quando o intermediário falhar. Só que essa rota alternativa não é algo que dá para recuperar temporariamente apenas com uma carteira: cada Vault corresponde a um arquivo de chaves WOTS de uso único, além dos materiais de resgate baixados no momento da criação.
Por isso, o que eu realmente gostaria de observar é se os usuários vão tratar esses materiais como um backup de segurança de verdade. O valor do autocustódio, no fim das contas, depende de a pessoa ter conseguido manter aquela chave que ainda pode ser usada.

@BabylonLabs_io #baby $BABY

A rede de testes mais valiosa para validar não é se o botão de empréstimo consegue ser clicado.

Para mim, o Public Testnet dos Trustless Bitcoin Vaults (TBV) vale mais por permitir que detentores de BTC recuperem o controle por conta própria quando as coisas não saem como esperado — e não apenas por saber se é possível pegar os ativos de teste.

Muitas rotas entre cadeias ou de custódia funcionam perfeitamente quando tudo está operando normalmente. O verdadeiro teste do modelo de confiança é: quando o provedor demora a responder, o processo de criação fica travado, ou alguém envia uma solicitação de resgate que não deveria ser aprovada, o usuário tem algum caminho que não dependa da cooperação do outro?

No design do TBV, a rota de saída é preparada com antecedência no momento da criação. Se a ativação não for concluída, existe um caminho de reembolso; e, na fase de resgate, se o Vault Provider não agir, desde que o usuário tenha guardado de forma segura as chaves e os documentos necessários, ele também pode seguir pelo resgate autônomo.

Isso não é um argumento que se resolve com uma frase como “descentralizado”. É, na verdade, deixar as escolhas para o usuário em cenários do pior caso. O valor da rede de testes está justamente em permitir que esses mecanismos de contingência sejam realmente vivenciados e verificados.

É claro que, no momento, ainda é um ambiente de testes; os ativos de teste não têm valor real. Em vez de apenas olhar se a interface é fluida, eu quero saber: você vai realmente fazer um backup cuidadoso daqueles documentos que determinam se você consegue resgatar de forma autônoma?

@BabylonLabs_io #baby $BABY

A rede de testes realmente precisa verificar não é apenas se é possível pegar moedas emprestadas.

A Public Testnet dos Trustless Bitcoin Vaults (TBV) já colocou um caminho completo diante do usuário: travar o BTC do signet no vault, ativar o colateral, tomar ativos de teste emprestados no Aave v4, fazer o reembolso e então concluir todo o fluxo de resgate.

Acredito que o valor disso não está só em o BTC conseguir ser emprestado como USDC/USDT. Mais importante ainda: isso permite que a lógica de colateral nativo do BTC seja percorrida de verdade. Ou seja, como os vaults do lado do Bitcoin são criados, como o estado do colateral é efetivado no Ethereum e como esses dois momentos são conectados.

A rota do TBV não é transformar o BTC em um token de outra cadeia. O BTC permanece nas saídas Taproot da rede do Bitcoin; o Aave v4 é responsável pelo produto de empréstimo na camada superior, e não por mover o BTC original para o Ethereum.

A rede de testes também expõe de forma bem clara as fricções reais do produto: confirmação, ativação, saúde da posição e resgate não podem ser resumidos por uma única frase como “intercadeias”. O que realmente importa é conseguir tornar esses passos críveis, compreensíveis e concluíveis—esse é o ponto que precisa ser verificado de verdade.

Todos os ativos são ativos de teste, sem valor monetário real. Você prefere primeiro experimentar o fluxo de empréstimo ou primeiro ver como o estado do colateral do BTC é verificado?

@BabylonLabs_io #baby $BABY