Web3天命人-阿明

#dusk $DUSK
@Dusk
Recentemente Dusk é o que vale mais a pena ver — não é “surgiu mais uma carteira”, e sim que a entrada da interface do DuskDS foi começando a ser padronizada. O Dusk Connect, aberto ao desenvolvedor na sequência em abril, permite que dApps encontrem, de forma unificada, carteiras compatíveis, solicitem contas, realizem assinaturas e iniciem transações; isso reduz o atrito para cada app criar uma integração personalizada em torno de uma carteira única.

A nova Dusk Wallet oferece transferências públicas/privadas, Shield/Unshield, staking e recebimento de recompensas. O Moonlight deixa o saldo da conta e as transferências visíveis, ideal para fluxos que precisam ser auditados; o Phoenix usa provas de conhecimento zero para proteger o valor e a associação das transações. Essas duas rotas finalmente colaboram na mesma camada de liquidação.

Para o Dusk, a verdadeira questão não é se há mais ou menos recursos, mas se os desenvolvedores estão dispostos a integrar, se carteiras diferentes conseguem interoperar e se essas capacidades podem entrar nos fluxos reais de emissão, custódia e liquidação de ativos.#DUSK

#dusk $DUSK @Dusk
Eu dei uma olhada com mais atenção no whitepaper do Dusk recentemente e achei que o que ele tem de realmente interessante não é apenas “uma blockchain de privacidade”, mas a tentativa de colocar privacidade, conformidade e ativos do mundo real na mesma infraestrutura base.
O Dusk protege a privacidade das transações com provas de conhecimento zero e, ao mesmo tempo, atende às exigências de regulação por meio de divulgação seletiva. 😁 O Phoenix e o Moonlight apoiam, respectivamente, transações privadas e públicas, enquanto o Succinct Attestation fica responsável pelo encerramento final rápido e determinístico. 😇 Além disso, com o DuskEVM e os cenários de RWA, o objetivo está bem claro: permitir que ativos regulados como valores mobiliários e fundos consigam 🤔 emitir, negociar e liquidar de verdade na cadeia.
Se a próxima etapa do RWA sair do “discurso” e avançar para uma “infraestrutura financeira real” 🤑, vale a pena acompanhar o Dusk continuamente.

#baby $BABY
Entenda o “staking” do BABY como “receber rendimento, governança a seu critério”, mas pode ter deixado passar um item de poder: se você não vota, o validador pode votar por você.

As regras de governança do Babylon Genesis foram escritas de forma bem direta: os detentores de BABY podem votar, mas, se o delegante não votar, o voto do validador é automaticamente herdado. Ou seja, fazer staking não é apenas entregar os tokens ao validador e pronto — você também incorpora parte das suas escolhas de governança na lógica padrão de delegação.

Essa regra padrão tem um intervalo de tempo que é fácil de ignorar. Se você votar antes do validador, o sistema não herda o voto do validador; se o validador já votou, depois disso você ainda pode usar seu próprio voto para substituí-lo. Mas, quando surgem propostas urgentes, o período de votação é de apenas 1 dia — pode acabar antes mesmo de você ver a notícia e terminar de ler as discussões. O período de votação para propostas comuns é de 3 dias, então o ritmo é relativamente mais folgado. Depois que o voto é enviado, também não dá para alterar, então “depois eu vejo” também tem um custo.

Meu entendimento é que, ao escolher um validador BABY, não basta olhar apenas as comissões e as recompensas esperadas: você também precisa verificar se ele continua acompanhando a governança, se vota em tempo hábil e qual é a posição pública dele quando representa o peso de delegação. Não é sobre adivinhar exatamente o que um validador específico vai fazer, e sim sobre identificar o risco de governança da delegação padrão: não participar também é, de certa forma, um resultado.

Na próxima vez em que eu for ver uma proposta, vou primeiro checar três pontos de tempo: quando a votação termina, se o validador já votou e se meu voto já foi registrado na blockchain; depois confirmo se a proposta é comum ou urgente. Se no seu wallet só há saldo com staking, mas não há alertas de governança, o “staking passivo” do BABY talvez também esteja, de forma passiva, entregando o poder de decisão.#baby $BABY @BabylonLabs_io

#baby $BABY
Se você começou a reavaliar a carteira por causa das discussões recentes sobre a COLDCARD, não se apresse em equiparar “carteira fria” a “capaz de fazer staking do BABY”.
A posição oficial da COLDCARD é bem clara: uma carteira de hardware voltada apenas para Bitcoin, cujo núcleo é a assinatura offline e a proteção das chaves privadas do Bitcoin. As ferramentas oficiais de BABY Staking da Babylon também não incluem a COLDCARD na lista de suportes atual; na mesma tabela, “BABY Address” e “BABY Staking” na Keplr, Cosmostation e Leap são “Coldlar” — isto é, endereço BABY Staking. Coldlar e COLDCARD não são o mesmo produto; os nomes parecem, mas os limites de função não podem ser confundidos.
Para usuários de BABY, o que realmente precisa ser verificado são três níveis de compatibilidade: se é possível criar ou conectar endereços Babylon; se é possível iniciar uma delegação de BABY; e se é possível concluir um co-staking combinado BTC-BABY no mesmo endereço. O site oficial da Babylon descreve o uso do BABY como staking, co-staking BTC-BABY e governança, mas isso não significa que qualquer carteira de hardware para Bitcoin consiga, por si só, suportar diretamente essas operações.
Portanto, a avaliação mais segura é: a COLDCARD é adequada para armazenamento e assinatura offline focados em Bitcoin-only; já o BABY Staking deve, em primeiro lugar, seguir a tabela de ferramentas atuais da Babylon e escolher as soluções já marcadas como suportadas, confirmando também a versão, a rede e os requisitos de endereço. A documentação oficial também alerta claramente que a lista pode mudar. Na próxima vez que virar tendência, primeiro verifique se “BABY Address” e “BABY Staking” são dois itens — não olhe apenas para o fato de a carteira estar sendo chamada de “carteira fria”.@BabylonLabs_io

#baby $BABY
Colocar o BTC como garantia em um protocolo de empréstimos: o que as pessoas mais facilmente ignoram não é a taxa de juros do empréstimo, e sim se “uma outra cadeia consegue ou não confirmar o status desse BTC”.

O site do Babylon explica agora, de forma bem direta, o fluxo dos Trustless Bitcoin Vaults (TBV): primeiro, travar o BTC nativo dentro do Vault; depois, tornar o estado da garantia verificável na Ethereum; por fim, obter liquidez em stablecoins via Aave v4. Essa sequência deixa claro que o principal argumento do TBV não é “ter mais uma porta de empréstimo”, e sim a tentativa de transformar o fato de que o BTC está garantido em um status que um protocolo externo consegue ler.

Isso não é a mesma coisa que empacotar (wrap) o BTC em um token e fazer bridge entre cadeias. A descrição do site sobre o Babylon Bitcoin staking também enfatiza que não há necessidade de wrapping, pegging ou bridging; mas “manter o BTC sob custódia enquanto se obtém liquidez” e “fazer com que o protocolo de empréstimos consiga aceitar com segurança essa garantia” são duas proposições diferentes, que não devem ser confundidas.

Neste momento, o mais importante a lembrar não é um número específico de rendimento, e sim que o site ainda oferece a entrada “Launch TBV Testnet”. O fato de a testnet conseguir rodar o fluxo não significa que a mainnet já esteja aberta, nem que a taxa de garantia, a liquidação, os oráculos e as condições de saída tenham passado por um período suficientemente longo de validação em cenário real. Especialmente depois de tomar stablecoins, qualquer oscilação do preço do BTC, status anômalo do contrato ou bloqueio do caminho de saída transformará “garantia verificável” em risco prático.

Os três indicadores que vale acompanhar a seguir são: se o BTC nativo continua nas condições esperadas do Vault; se o status da garantia lido pelo lado da Ethereum permanece consistente ao longo do tempo; e se, fora da testnet, aparecem parâmetros públicos da mainnet e divulgações de riscos. O verdadeiro marco do TBV não é conseguir clicar na página de empréstimo, e sim se essas três camadas de status podem ser verificadas de forma independente.#baby $BABY @BabylonLabs_io

#baby $BABY
Hoje é fim de semana, ainda terei que fazer hora extra. Quando eu chegar em casa, vou pedir comida por delivery. O erro mais comum não é deixar de pegar o cupom, e sim usar dois celulares para pegar cupons, mas no fim não cair no mesmo pedido. A proposta de co-staking (joint staking) de BTC da BABY também tem um problema semelhante de “conciliação”: como o BTC e a BABY estão travados, isso não significa necessariamente que o sistema vai calculá-los juntos.

Nas regras oficiais da Babylon, o ponto-chave não é a ideia verbal de “a mesma pessoa”, e sim se as duas delegations estão relacionadas ao mesmo endereço da BABY. Se os endereços forem diferentes, a recompensa do co-staking pode simplesmente ser 0; além disso, BTC e BABY não podem ficar apenas em VERIFIED — ambos precisam entrar no estado ACTIVE, que é contabilizável.

A combinação (ratio) também tem efeito de “limite por menor lado”: w = min (quantidade de BABY ÷ 20.000, quantidade de BTC). Por exemplo, 0,1 BTC com 1.000 BABY gera um peso conjunto real de apenas 0,05 BTC. Para consumir todo o peso de 0,1 BTC, você precisa de cerca de 2.000 BABY. Colocar “a mais” de um lado não ultrapassa o limite do outro; para valores pequenos, o cálculo é proporcional, não necessariamente precisa atingir um limite inteiro.

Eu acredito que o que realmente vale monitorar no co-staking da BABY não é o número de rendimento individual divulgado na propaganda, mas se endereço, status e ratio estão todos alinhados ao mesmo tempo. 2,35% também deve ser entendido como o parâmetro anual de inflação do pool de recompensas compartilhadas, e não como um APR fixo para cada pessoa. Conforme mudam os participantes e o peso total de toda a rede, a alocação individual também muda. O próximo passo mais importante é registrar o estado das delegations, o peso real e o peso total da rede. Qualquer atualização de parâmetro pode tornar inválida uma estimativa antiga de rendimento.#baby @BabylonLabs_io

#baby $BABY
Baby fez uma “Golden Cross” e começou a ganhar dinheiro de novo. Aí eu abri meu próprio app de compras e convidei duas pessoas para juntar um pedido e bater o desconto. Eu selecionei os produtos e os cupons corretamente, mas na hora de fechar a compra descobri que o desconto não foi aplicado. A razão é bem simples: um usuário fez o pedido e o outro usuário resgatou o cupom. A plataforma, na prática, não sabe que eles pertencem à mesma compra.
O staking conjunto BTC-BABY também trava nesse detalhe. Não é só dizer “BTC está sendo stakeado e BABY também” que automaticamente ganha uma recompensa extra; para o staking conjunto valer, os endereços do BABY nas duas operações de staking precisam ser exatamente iguais. Se os endereços forem diferentes, o resultado nos documentos oficiais é direto ao ponto: a recompensa do staking conjunto é 0.
E não basta olhar só “VERIFIED” e fechar a página. A delegação do BTC precisa continuar até ficar em ACTIVE, e a delegação do BABY também precisa estar em active; só então o sistema combina os dois lados em um peso de staking conjunto. “Já verificado” parece que resolveu, mas na verdade ainda não entrou na etapa de contabilização de pesos.
A fórmula real é: w = min (quantidade de stake do BABY ÷ 20.000, quantidade de stake do BTC). Por exemplo: com 0,1 BTC e 1.000 BABY, o peso do staking conjunto fica apenas 0,05 BTC; para usar todo o peso desses 0,1 BTC, você precisa de 2.000 BABY. Ao contrário disso: colocar mais BABY não faz o peso ultrapassar a quantidade de BTC já stakeada.
Aqui não existe um limite do tipo “pelo menos 1 BTC ou 20.000 BABY”; valores menores também são calculados proporcionalmente. Distribuir o BABY para vários validadores não tem problema, desde que venha do mesmo endereço; o sistema vai somar a quantidade.
Tem mais um número que é o mais fácil de confundir: 2,35% não é um APR fixo do indivíduo, e sim a reserva anual de recompensas de inflação compartilhada por todos os participantes do staking conjunto. Quanto cada um recebe depende de qual proporção seu peso representa no peso total da rede; quanto mais participantes houver, menor será a parcela que cada um recebe com o mesmo peso.
Portanto, esse mecanismo não é “basta stakear dois coins”, e sim: precisa casar também endereço, status e proporção. Vou focar em checar quatro coisas: se o endereço do BABY é o mesmo, se o BTC já chegou a ACTIVE, se o peso real não foi travado por alguma “margem curta”, e se o peso total da rede não mudou de forma evidente. Os parâmetros também podem ser atualizados; antes de operar, ainda é preciso seguir o que está na página oficial. O que mais costuma ser esquecido no staking conjunto, geralmente não é a ação de stake, mas se o sistema realmente juntou as duas partes/contas no mesmo endereço.#baby @BabylonLabs_io

#baby $BABY
Um carro que estava parado em casa. No fim de semana, vendo este carro usado: o comprador diz apenas “tá a caminho” ao telefone, mas isso não significa que o dinheiro já tenha caído na conta. O preço foi negociado, o contrato foi assinado — a operação realmente vai se concretizar? No fim, depende de a outra parte conseguir tirar dinheiro em espécie imediatamente.
A liquidação do TBV funciona de modo semelhante. Quando o fator de saúde cai abaixo de 1.0, isso só indica que o interruptor de liquidação foi ligado; não significa que o BTC já foi liquidado com sucesso e convertido em caixa. O BTC nativo na Bitcoin: para resgatar, é necessário passar por claim, challenge e payout; normalmente leva alguns dias, não dá para concluir, na mesma transação, a ação de quitar dívidas na Ethereum.
A abordagem atual do Babylon é colocar uma camada intermediária de LLP. Por padrão, o BTCVaultSwap fornece liquidação imediata a partir da reserva de WBTC do Aave Hub: o liquidante primeiro quita a dívida e recebe o WBTC; o vault descontado entra em escrow; depois, o arbitrador registrado compra esse vault e o resgate do lado da Bitcoin vai sendo concluído aos poucos. Em outras palavras: primeiro adianta-se o WBTC para acertar as contas aqui na Ethereum.
Mas essa camada de adiantamento não é um poço sem fundo. A documentação oficial é bem direta: se a liquidez do WBTC no Aave Hub ou a permissão (allowance) do Vault Swap não for suficiente, a transação de liquidação sem permissão (permissionless) vai reverter. O arbitrador ainda consegue seguir por direct redemption, mas haverá bem menos gente disposta a “pegar a” posição.
Há ainda um degrau de UTXO que é fácil de ignorar. Um vault não pode ser liquidado pela metade; se a posição tiver apenas um vault, até um leve desvio pode disparar o fechamento completo do vault, e o UTXO inteiro é alocado para liquidação. O valor do excesso de colateral não zera totalmente: ele é compensado para abatimento da dívida por um mecanismo de precificação justa ou reembolsado com WBTC. Por isso, o Portal oficial recomenda, por padrão, dividir em “sacrificar um vault + proteger o vault”.
Os parâmetros e o demo acima estão baseados na testnet pública do TBV; o signet BTC, o mock WBTC e as stablecoins não têm valor monetário.
Então, ao olhar o TBV agora, eu não fico só de olho no fator de saúde: também verifico a profundidade de WBTC no Hub, o Vault Swap allowance e por quanto tempo um vault no escrow consegue ser comprado. A linha de liquidação é apenas um interruptor: depois de acioná-la, só então é que se decide se há dinheiro e comprador, e se o sistema aguenta em cenários de estresse de mercado.#baby @BabylonLabs_io

A SanDisk foi além, mas não ficou no prejuízo enquanto ganhava $SNDK

#baby $BABY
Hoje eu troquei de celular e percebi algo muito sério: o mais assustador não é ter de fazer login novamente, e sim descobrir de repente que a senha continua lá, o código de verificação também continua lá, mas os arquivos de backup realmente essenciais não abrem. As coisas são minhas, mas recuperá-las se torna extremamente trabalhoso.
Por isso hoje, quando eu olho para o TBV, não me preocupa apenas se “o BTC consegue não atravessar a ponte”, e sim se, quando der problema, o usuário ainda tem, nas próprias mãos, a última chave.
Na documentação do Babylon, há algumas rotas de recuperação bem práticas. Se o cartão ficar travado no meio da ativação e passar da janela, é possível solicitar reembolso; na hora do resgate, se o Vault Provider não tiver iniciado o claim, o usuário pode usar as próprias chaves WOTS e o arquivo claimer, executar os comandos manualmente no terminal para concluir o claim, o assert e o payout. Se ocorrer um erro no claim e o desafiante não tratar a tempo, o usuário ainda pode usar os arquivos BABE que foram preservados para iniciar o challenge por conta própria.
Isso é mais útil do que uma frase “trustless”. Porque nos cenários realmente problemáticos, muitas vezes não é o sistema rodando normalmente que dá dor de cabeça — e sim quando o provedor fica offline, a prova trava ou o sistema entra em estado de pausa. A ideia do TBV é: o operador pode dar problema, mas o usuário não pode ficar com apenas um caminho — esperar o atendimento.
Claro que a recuperação autônoma não significa ausência de barreiras. Os arquivos WOTS e os artifacts do claimer precisam ser copiados e guardados; o fluxo do terminal não é clicar uma vez; e os fundos na rede de testes não têm valor real. Contratos de aplicação, oráculos, regras de liquidação e multisig de governança ainda precisam ser avaliados separadamente.
Em seguida, vou observar três detalhes: se os arquivos de recuperação são fáceis de manter, se o fluxo de linha de comando consegue ser reproduzido por um usuário comum e quanto tempo leva, do início do claim até o BTC realmente chegar. Só quando a “última chave” é entregue ao usuário, a #baby não é apenas uma história de autocustódia. $BABY @BabylonLabs_io