Nova_eth_20
422 Publicações
Nova_eth_20
129 A seguir
1.5K+ Seguidores
450 Gostaram
Publicações
Tudo
Cotações
#baby $BABY @BabylonLabs_io
Estava comparando validadores para a minha delegação BABY e quase passei direto por "jailing", que é o boilerplate padrão do Cosmos que toda cadeia tem: missed blocks, timeout temporário, nada específico para Babylon. Aí eu li o que os validadores realmente assinam duas vezes, não apenas uma.
Todo validador do Genesis do Babylon faz dois trabalhos separados. Assinatura regular de blocos CometBFT, o trabalho comum que qualquer validador do Cosmos faz, e um segundo: votação BLS no final de cada época, em que as assinaturas dos validadores são agregadas em um checkpoint que recebe um carimbo de data/hora diretamente no Bitcoin. Essa segunda assinatura é a razão inteira pela qual as pessoas chamam esta cadeia de "Bitcoin-secured".
O jailing por inatividade se preocupa apenas com o primeiro trabalho, nos seus próprios termos, com a aplicação padrão de liveness, sem nada de dramático. O que eu não consegui definir com precisão foi a interação exata: se um jailing que acontece no meio de uma época desqualifica silenciosamente a contribuição BLS de toda aquela época, ou se só importa se ainda estiver ativo no momento em que a época termina. A documentação do Babylon confirma que os dois trabalhos são separados. Ela não esclarece esse limite de tempo específico em lugar nenhum que eu tenha encontrado.
De qualquer forma, os dois trabalhos compartilham um único registro de uptime. Um validador que foi preso por blocos perdidos comuns, a mesma regra que qualquer cadeia Cosmos executa, não está protegido de também perder a assinatura que realmente é ancorada no Bitcoin naquela época — por um motivo que não tem nada a ver com segurança do Bitcoin.
Eu não acho que seja um problema de design; não há um jeito limpo de prender alguém por um papel e não pelo outro na mesma chave. O que eu não tinha separado na minha cabeça antes é que o histórico de downtime não é apenas sobre recompensas perdidas. É um proxy grosseiro de com que frequência um validador realmente esteve presente para a assinatura que faz "Bitcoin-secured" ser verdade.
Verifiquei novamente o histórico de jailing da minha shortlist. Dois nomes tinham uma entrada cada, ambos com mais de um ano, ambos seguidos por longos períodos limpos depois. Sem bandeira vermelha. Só não era o mesmo zero que eu tinha assumido que uma porcentagem de uptime limpa já estava me dizendo.
$BLESS
🤔 Qual é a primeira coisa que você verifica antes de delegar seu bebê
Estava comparando validadores para a minha delegação BABY e quase passei direto por "jailing", que é o boilerplate padrão do Cosmos que toda cadeia tem: missed blocks, timeout temporário, nada específico para Babylon. Aí eu li o que os validadores realmente assinam duas vezes, não apenas uma.
Todo validador do Genesis do Babylon faz dois trabalhos separados. Assinatura regular de blocos CometBFT, o trabalho comum que qualquer validador do Cosmos faz, e um segundo: votação BLS no final de cada época, em que as assinaturas dos validadores são agregadas em um checkpoint que recebe um carimbo de data/hora diretamente no Bitcoin. Essa segunda assinatura é a razão inteira pela qual as pessoas chamam esta cadeia de "Bitcoin-secured".
O jailing por inatividade se preocupa apenas com o primeiro trabalho, nos seus próprios termos, com a aplicação padrão de liveness, sem nada de dramático. O que eu não consegui definir com precisão foi a interação exata: se um jailing que acontece no meio de uma época desqualifica silenciosamente a contribuição BLS de toda aquela época, ou se só importa se ainda estiver ativo no momento em que a época termina. A documentação do Babylon confirma que os dois trabalhos são separados. Ela não esclarece esse limite de tempo específico em lugar nenhum que eu tenha encontrado.
De qualquer forma, os dois trabalhos compartilham um único registro de uptime. Um validador que foi preso por blocos perdidos comuns, a mesma regra que qualquer cadeia Cosmos executa, não está protegido de também perder a assinatura que realmente é ancorada no Bitcoin naquela época — por um motivo que não tem nada a ver com segurança do Bitcoin.
Eu não acho que seja um problema de design; não há um jeito limpo de prender alguém por um papel e não pelo outro na mesma chave. O que eu não tinha separado na minha cabeça antes é que o histórico de downtime não é apenas sobre recompensas perdidas. É um proxy grosseiro de com que frequência um validador realmente esteve presente para a assinatura que faz "Bitcoin-secured" ser verdade.
Verifiquei novamente o histórico de jailing da minha shortlist. Dois nomes tinham uma entrada cada, ambos com mais de um ano, ambos seguidos por longos períodos limpos depois. Sem bandeira vermelha. Só não era o mesmo zero que eu tinha assumido que uma porcentagem de uptime limpa já estava me dizendo.
$BLESS
🤔 Qual é a primeira coisa que você verifica antes de delegar seu bebê
Validator uptime 📈
34%
Jailing history 🚨
0%
Commission fees 💰
33%
Reputation & community 🌟
33%
3 Votos • Votação encerrada
Ver tradução
$CYS
Mù 穆涵
·
--
$BABY #baby @BabylonLabs_io
Escolhi um provedor de finalidade (finality provider) com base no tamanho da delegação de BTC e no histórico de uptime, os números que todo painel mostra. Só depois eu li o que realmente mantém esse provedor rodando de dia a dia, e não é BTC.
Todo provedor de finalidade precisa de uma chave operacional separada, financiada com BABY, com valores pequenos, usada para pagar o gas pelo envio de randomness (aleatoriedade) nova em uma agenda recorrente. As submissões de votos são reembolsadas automaticamente; a própria documentação de operadores da Babylon confirma isso diretamente. Outras transações nessa mesma chave, incluindo os commits recorrentes de randomness, exigem gas que não volta. A documentação descreve isso quase como um detalhe; o texto manda financiar com um valor mínimo, manter rodando por muito tempo, e há uma frase avulsa ao lado da parafernália de segurança que eu fui procurar.
Se você não repõe essa recarga, o provedor não fica “secretamente comprometido” — a delegação de BTC dele ainda está exatamente tão grande e honesta quanto estava ontem. Eles apenas não conseguem continuar participando até alguém perceber que a carteira está vazia e fazer o aporte. Um provedor pode ser impecável em todos os indicadores que eu verifiquei antes de delegar e ainda assim apagar por algo tão pequeno quanto uma chave de gas que ninguém lembrou de reabastecer.
Os painéis de delegação mostram comissão, tamanho da delegação, histórico de uptime. Nenhum deles mostra se a chave operacional de um provedor está confortavelmente financiada ou rodando no limite, porque esse número nunca foi pensado para ser público.
Eu não acho que seja uma falha de design: manter a chave operacional mínima e separada das participações reais do provedor é uma escolha de segurança razoável, não negligência. O que isso significa para quem delega é algo menor, porém: o provedor que você escolheu pelo histórico de BTC também está, silenciosamente, no negócio de lembrar de comprar gas.
$HEI
Você sabia que a chave operacional de um provedor de finalidade pode ficar sem saldo mesmo quando a delegação de BTC parece perfeitamente saudável?
Escolhi um provedor de finalidade (finality provider) com base no tamanho da delegação de BTC e no histórico de uptime, os números que todo painel mostra. Só depois eu li o que realmente mantém esse provedor rodando de dia a dia, e não é BTC.
Todo provedor de finalidade precisa de uma chave operacional separada, financiada com BABY, com valores pequenos, usada para pagar o gas pelo envio de randomness (aleatoriedade) nova em uma agenda recorrente. As submissões de votos são reembolsadas automaticamente; a própria documentação de operadores da Babylon confirma isso diretamente. Outras transações nessa mesma chave, incluindo os commits recorrentes de randomness, exigem gas que não volta. A documentação descreve isso quase como um detalhe; o texto manda financiar com um valor mínimo, manter rodando por muito tempo, e há uma frase avulsa ao lado da parafernália de segurança que eu fui procurar.
Se você não repõe essa recarga, o provedor não fica “secretamente comprometido” — a delegação de BTC dele ainda está exatamente tão grande e honesta quanto estava ontem. Eles apenas não conseguem continuar participando até alguém perceber que a carteira está vazia e fazer o aporte. Um provedor pode ser impecável em todos os indicadores que eu verifiquei antes de delegar e ainda assim apagar por algo tão pequeno quanto uma chave de gas que ninguém lembrou de reabastecer.
Os painéis de delegação mostram comissão, tamanho da delegação, histórico de uptime. Nenhum deles mostra se a chave operacional de um provedor está confortavelmente financiada ou rodando no limite, porque esse número nunca foi pensado para ser público.
Eu não acho que seja uma falha de design: manter a chave operacional mínima e separada das participações reais do provedor é uma escolha de segurança razoável, não negligência. O que isso significa para quem delega é algo menor, porém: o provedor que você escolheu pelo histórico de BTC também está, silenciosamente, no negócio de lembrar de comprar gas.
$HEI
Você sabia que a chave operacional de um provedor de finalidade pode ficar sem saldo mesmo quando a delegação de BTC parece perfeitamente saudável?
Ver tradução
#baby @BabylonLabs_io
Read a slashing breakdown last night hunting for the exact BTC penalty number. Found it, 0.1% of staked BTC for double-signing. Then found the line sitting right next to it that I wasn't looking for: previously earned rewards are not clawed back.
The provider gets permanently banned, jailed for good, no more delegations, no more commissions. But whatever commission they already collected before the violation stays theirs. The penalty runs forward from the moment they're caught. It doesn't run backward through however long they were operating before that.
For a brand new provider, that gap barely matters, there's nothing accumulated yet to keep. For one who's been running delegations for a year, earning a commission cut on every reward cycle the whole time, the math changes. A single 0.1% slash hits everyone delegated to them, proportionally, provider and delegators both. What doesn't get touched is commission history, however much they walked away holding.
I don't know what any individual provider has actually earned over their tenure, that's not public anywhere I found, so I can't tell you whether this gap is trivial or real. What I can say is the deterrent was built to be forward-only on purpose. Clawing back historical rewards would mean reopening every past reward cycle, its own mess to design around.
Banned for good and broke are two different outcomes, and Babylon's own slashing design only guarantees the first one.
$CYS $BABY
Read a slashing breakdown last night hunting for the exact BTC penalty number. Found it, 0.1% of staked BTC for double-signing. Then found the line sitting right next to it that I wasn't looking for: previously earned rewards are not clawed back.
The provider gets permanently banned, jailed for good, no more delegations, no more commissions. But whatever commission they already collected before the violation stays theirs. The penalty runs forward from the moment they're caught. It doesn't run backward through however long they were operating before that.
For a brand new provider, that gap barely matters, there's nothing accumulated yet to keep. For one who's been running delegations for a year, earning a commission cut on every reward cycle the whole time, the math changes. A single 0.1% slash hits everyone delegated to them, proportionally, provider and delegators both. What doesn't get touched is commission history, however much they walked away holding.
I don't know what any individual provider has actually earned over their tenure, that's not public anywhere I found, so I can't tell you whether this gap is trivial or real. What I can say is the deterrent was built to be forward-only on purpose. Clawing back historical rewards would mean reopening every past reward cycle, its own mess to design around.
Banned for good and broke are two different outcomes, and Babylon's own slashing design only guarantees the first one.
$CYS $BABY
$BICO
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
Verifiquei a comissão de um provedor de finality antes de delegar na noite passada: 5%, pareceu razoável em comparação com os outros da lista. Quase deleguei apenas com esse número. Então descobri que o comando de registro que a Babylon realmente exige vem com algo por trás.
Todo provedor de finality define três números no registro, não um. A taxa de comissão atual, uma taxa máxima que ele nunca pode ultrapassar e uma taxa máxima de mudança — a rapidez com que ele é permitido subir em direção a esse teto. Os 5% que eu estava olhando nunca eram o quadro completo; era só um instantâneo num marcador, com seu próprio “limite superior” mais alto embutido desde o primeiro dia.
Nada impede um provedor de se registrar com 5% e uma taxa máxima de 50%, e então aumentar isso em passos legais pequenos a cada período, até que delegadores que entraram com 5% estejam ganhando com um número bem diferente. Nenhuma regra foi quebrada, nenhum golpe, apenas um teto que estava público o tempo todo.
Eu fui atrás de onde esse teto aparece de fato para um delegador decidir em quem confiar. Pelo que consegui encontrar, os próprios docs de staking da Babylon e a API que alimenta o painel exibem exatamente um campo nessa etapa: commission — menor significa recompensas maiores — nada mais detalhado do que isso. Não é a taxa máxima exibida num campo adjacente nos dados de registro do próprio provedor.
Eu não acho que isso torne o mecanismo predatório. Existe um limite para a taxa de mudança exatamente para impedir que a comissão “salte” da noite para o dia, e essa proteção é real. O que está faltando é menor: o número que efetivamente limita seus ganhos futuros nunca foi construído para aparecer na tela de onde você está decidindo. Os docs não dizem quantos provedores ativos já saíram da taxa inicial, nem o quão perto qualquer um deles está do seu teto agora, então não consigo dizer se isso é um risco atual ou apenas teórico.
Os 5% que você vê é uma foto. O teto sempre foi o acordo real.
Você sabia que a comissão do seu provedor de finality pode subir acima do número que você vê hoje? 📈
Verifiquei a comissão de um provedor de finality antes de delegar na noite passada: 5%, pareceu razoável em comparação com os outros da lista. Quase deleguei apenas com esse número. Então descobri que o comando de registro que a Babylon realmente exige vem com algo por trás.
Todo provedor de finality define três números no registro, não um. A taxa de comissão atual, uma taxa máxima que ele nunca pode ultrapassar e uma taxa máxima de mudança — a rapidez com que ele é permitido subir em direção a esse teto. Os 5% que eu estava olhando nunca eram o quadro completo; era só um instantâneo num marcador, com seu próprio “limite superior” mais alto embutido desde o primeiro dia.
Nada impede um provedor de se registrar com 5% e uma taxa máxima de 50%, e então aumentar isso em passos legais pequenos a cada período, até que delegadores que entraram com 5% estejam ganhando com um número bem diferente. Nenhuma regra foi quebrada, nenhum golpe, apenas um teto que estava público o tempo todo.
Eu fui atrás de onde esse teto aparece de fato para um delegador decidir em quem confiar. Pelo que consegui encontrar, os próprios docs de staking da Babylon e a API que alimenta o painel exibem exatamente um campo nessa etapa: commission — menor significa recompensas maiores — nada mais detalhado do que isso. Não é a taxa máxima exibida num campo adjacente nos dados de registro do próprio provedor.
Eu não acho que isso torne o mecanismo predatório. Existe um limite para a taxa de mudança exatamente para impedir que a comissão “salte” da noite para o dia, e essa proteção é real. O que está faltando é menor: o número que efetivamente limita seus ganhos futuros nunca foi construído para aparecer na tela de onde você está decidindo. Os docs não dizem quantos provedores ativos já saíram da taxa inicial, nem o quão perto qualquer um deles está do seu teto agora, então não consigo dizer se isso é um risco atual ou apenas teórico.
Os 5% que você vê é uma foto. O teto sempre foi o acordo real.
Você sabia que a comissão do seu provedor de finality pode subir acima do número que você vê hoje? 📈
#baby @BabylonLabs_io
Estou com BTC apostado via Babylon agora; então, quando encontrei a palavra "overflow" enterrada na documentação antiga do Cap-3 ontem à noite, eu não li como história. Li como uma pergunta sobre a minha própria situação: isso poderia acontecer comigo.
Durante a Fase 1, transações de staking que foram confirmadas depois de o limite já estar preenchido ainda travaram o BTC no contrato exatamente como aconteceu com todo mundo. Elas só não renderam nada: nenhum ponto, nenhuma alocação. Devolver as moedas também não era automático; a documentação é explícita: as apostas com overflow ainda precisavam ser desfeitas (unbonded) e sacadas, com o mesmo tempo de espera de uma posição ativa, por um stake que pagou zero durante todo o período em que ficou travado.
O que decidiu quem entrou não foi quando alguém clicou em "apostar". Foi em qual bloco do Bitcoin a transação foi realmente confirmada — um número que ninguém controla totalmente depois que sai da carteira. Duas pessoas poderiam transmitir minutos de diferença e cair em ordens diferentes, dependendo de taxas, congestionamento da mempool ou de qual miner encontrou primeiro o próximo bloco.
Os limites da Fase 1 acabaram, mas o mecanismo que criou o overflow não é exclusivo dessa fase. Qualquer rodada futura com limites, um novo onboarding do BSN com uma alocação fixa, uma integração com vagas limitadas, herda a mesma corrida no momento em que usa confirmações de bloco em vez de uma fila. Nada desse erro de design foi corrigido. Foi apenas superado quando os limites desapareceram.
Eu não acho que o design original foi injusto: um limite duro precisa de um corte, e confirmação por bloco não pode ser falsificada do jeito que um timestamp pode. O que fica comigo é algo menor: meu próprio BTC que está travado agora nunca foi protegido por habilidade nem por um bom timing. Ele apenas atravessou uma linha desenhada por miners, não por mim — e, na próxima vez que essa linha for desenhada, ainda será assim.
$SKYAI $BICO $BABY
"Esse risco de overflow impediria você de apostar em uma rodada futura com limite?" 🎯
Estou com BTC apostado via Babylon agora; então, quando encontrei a palavra "overflow" enterrada na documentação antiga do Cap-3 ontem à noite, eu não li como história. Li como uma pergunta sobre a minha própria situação: isso poderia acontecer comigo.
Durante a Fase 1, transações de staking que foram confirmadas depois de o limite já estar preenchido ainda travaram o BTC no contrato exatamente como aconteceu com todo mundo. Elas só não renderam nada: nenhum ponto, nenhuma alocação. Devolver as moedas também não era automático; a documentação é explícita: as apostas com overflow ainda precisavam ser desfeitas (unbonded) e sacadas, com o mesmo tempo de espera de uma posição ativa, por um stake que pagou zero durante todo o período em que ficou travado.
O que decidiu quem entrou não foi quando alguém clicou em "apostar". Foi em qual bloco do Bitcoin a transação foi realmente confirmada — um número que ninguém controla totalmente depois que sai da carteira. Duas pessoas poderiam transmitir minutos de diferença e cair em ordens diferentes, dependendo de taxas, congestionamento da mempool ou de qual miner encontrou primeiro o próximo bloco.
Os limites da Fase 1 acabaram, mas o mecanismo que criou o overflow não é exclusivo dessa fase. Qualquer rodada futura com limites, um novo onboarding do BSN com uma alocação fixa, uma integração com vagas limitadas, herda a mesma corrida no momento em que usa confirmações de bloco em vez de uma fila. Nada desse erro de design foi corrigido. Foi apenas superado quando os limites desapareceram.
Eu não acho que o design original foi injusto: um limite duro precisa de um corte, e confirmação por bloco não pode ser falsificada do jeito que um timestamp pode. O que fica comigo é algo menor: meu próprio BTC que está travado agora nunca foi protegido por habilidade nem por um bom timing. Ele apenas atravessou uma linha desenhada por miners, não por mim — e, na próxima vez que essa linha for desenhada, ainda será assim.
$SKYAI $BICO $BABY
"Esse risco de overflow impediria você de apostar em uma rodada futura com limite?" 🎯
😰 Yeah, dealbreaker
34%
😌 Nah, worth the risk
33%
🤔 Depends on the cap size
33%
🙈 Didn't know this existed
0%
3 Votos • Votação encerrada
$BLESS
Mù 穆涵
·
--
$BABY $BLESS #baby
Travei meu índice de co-staking há três semanas — 20.000 BABY por BTC, a proporção recomendada pela própria Babylon. Ontem à noite conferi meus ganhos. Menores do que o número que eu calculei no dia em que fiz o stake.
Minha posição não se mexeu nem um milímetro. Outra coisa se mexeu.
O bônus de co-staking de 2,35% não é uma taxa. É um pool de tamanho fixo, dividido proporcionalmente entre cada carteira que co-staking naquele momento. A Babylon diz isso de forma clara na própria documentação: quanto mais co-stakers, menor o prêmio individual. Acertando a proporção perfeitamente, sua parcela real ainda depende de quantas outras carteiras também a acertam — um número que muda sem você mexer na sua posição.
Não há um painel que acompanhe esse número em tempo real. Você vê o seu peso. Não vê o peso total do pool mudando por baixo.
Diferente de outros riscos da Babylon que se escondem dentro de infraestrutura ausente ou operadores concentrados, este se esconde à vista — a fórmula é totalmente pública. A única coisa que falta é saber quem mais está usando.
Uma coisa que vale observar: esses 2,35% não são um “piso”; é um número de governança. Ele só existe porque uma proposta no mês de setembro passado dividiu a inflação da Babylon em fatias fixas: 1% para stakers de BTC, 2% para stakers de BABY, 2,35% para co-stakers, e o restante dividido em outras categorias. Uma votação futura pode redimensionar essa fatia do mesmo jeito que esta criou. Ninguém propôs reduzi-la ainda, então isso continua sendo um lugar na sua mira, não uma mesa que você tem garantia de manter.
Existe ainda uma segunda aresta embutida na fórmula. O peso elegível fica limitado ao que for menor: seu BABY dividido por 20.000, ou seu BTC. Se você ultrapassar a proporção, o BABY extra só rende a taxa normal de staking. Se ficar aquém, apenas parte do seu BTC recebe o impulso.
Juntar BTC e BABY foi construído para fortalecer esse vínculo, e um pool compartilhado é uma forma razoável de financiá-lo. O design não é o problema. O problema é não conseguir ver sua parcela mudar antes de isso acontecer.
Se você acertou a proporção exatamente como eu fiz, você não está ganhando 2,35% fixos. Você está alugando um lugar em uma mesa que fica mais cheia no próprio cronograma dela, por pessoas que você nunca vai ver chegar.
Travei meu índice de co-staking há três semanas — 20.000 BABY por BTC, a proporção recomendada pela própria Babylon. Ontem à noite conferi meus ganhos. Menores do que o número que eu calculei no dia em que fiz o stake.
Minha posição não se mexeu nem um milímetro. Outra coisa se mexeu.
O bônus de co-staking de 2,35% não é uma taxa. É um pool de tamanho fixo, dividido proporcionalmente entre cada carteira que co-staking naquele momento. A Babylon diz isso de forma clara na própria documentação: quanto mais co-stakers, menor o prêmio individual. Acertando a proporção perfeitamente, sua parcela real ainda depende de quantas outras carteiras também a acertam — um número que muda sem você mexer na sua posição.
Não há um painel que acompanhe esse número em tempo real. Você vê o seu peso. Não vê o peso total do pool mudando por baixo.
Diferente de outros riscos da Babylon que se escondem dentro de infraestrutura ausente ou operadores concentrados, este se esconde à vista — a fórmula é totalmente pública. A única coisa que falta é saber quem mais está usando.
Uma coisa que vale observar: esses 2,35% não são um “piso”; é um número de governança. Ele só existe porque uma proposta no mês de setembro passado dividiu a inflação da Babylon em fatias fixas: 1% para stakers de BTC, 2% para stakers de BABY, 2,35% para co-stakers, e o restante dividido em outras categorias. Uma votação futura pode redimensionar essa fatia do mesmo jeito que esta criou. Ninguém propôs reduzi-la ainda, então isso continua sendo um lugar na sua mira, não uma mesa que você tem garantia de manter.
Existe ainda uma segunda aresta embutida na fórmula. O peso elegível fica limitado ao que for menor: seu BABY dividido por 20.000, ou seu BTC. Se você ultrapassar a proporção, o BABY extra só rende a taxa normal de staking. Se ficar aquém, apenas parte do seu BTC recebe o impulso.
Juntar BTC e BABY foi construído para fortalecer esse vínculo, e um pool compartilhado é uma forma razoável de financiá-lo. O design não é o problema. O problema é não conseguir ver sua parcela mudar antes de isso acontecer.
Se você acertou a proporção exatamente como eu fiz, você não está ganhando 2,35% fixos. Você está alugando um lugar em uma mesa que fica mais cheia no próprio cronograma dela, por pessoas que você nunca vai ver chegar.
#baby $BABY @BabylonLabs_io
Metade do meu BTC está apostado via Babylon agora. Eu nunca perguntei o que acontece com ele se metade do conjunto de validadores ficar offline de uma vez — até ontem à noite, lendo a metade do artigo de fundação da Babylon que eu tinha ignorado.
Checkpointing do Bitcoin corrige a segurança. Um único validador honesto enviando uma prova para o Bitcoin é suficiente para punir os mentirosos e definir qual histórico é o real. Liveness é uma questão separada: a cadeia continua produzindo blocos de qualquer forma.
Aqui está a parte que o Bitcoin não consegue tocar. Nenhum protocolo de proof-of-stake garante liveness quando validadores adversariais cruzam metade do conjunto ativo. Nem com o Bitcoin por trás, nem com qualquer serviço de timestamp — não a menos que os dados de cada validador sejam publicados na blockchain, e o throughput do Bitcoin nunca foi construído para carregar isso.
A prova vale contra a malícia. Ela não diz nada sobre validadores que simplesmente param de aparecer. A cadeia trava exatamente da mesma forma, seja qual for o motivo, e o Bitcoin não consegue te dizer qual deles aconteceu.
"Garantido pelo Bitcoin" parece uma promessa. São duas. O Bitcoin compra certeza sobre qual histórico é o verdadeiro. Ele não compra uma promessa de que a cadeia continua andando se metade dos validadores desaparecer de uma vez — queda, saída, ou um ataque que ninguém percebeu a tempo.
Um comitê que precisa de um único signatário honesto, um relayer que precisa de um para ficar online — isso se resolve com mais operadores entrando. Esse limite é matemática provada, não um problema de equipe. Observar mais não move esse teto.
Meu BTC fica bloqueado de qualquer forma. O Bitcoin vai me dar um recibo para o exato momento em que a cadeia morreu. Fazer a cadeia voltar a respirar nunca fez parte da prova.
$BLESS $HOME
Se metade dos validadores da Babylon ficou escura esta noite, o que acontece com o seu BTC?
Metade do meu BTC está apostado via Babylon agora. Eu nunca perguntei o que acontece com ele se metade do conjunto de validadores ficar offline de uma vez — até ontem à noite, lendo a metade do artigo de fundação da Babylon que eu tinha ignorado.
Checkpointing do Bitcoin corrige a segurança. Um único validador honesto enviando uma prova para o Bitcoin é suficiente para punir os mentirosos e definir qual histórico é o real. Liveness é uma questão separada: a cadeia continua produzindo blocos de qualquer forma.
Aqui está a parte que o Bitcoin não consegue tocar. Nenhum protocolo de proof-of-stake garante liveness quando validadores adversariais cruzam metade do conjunto ativo. Nem com o Bitcoin por trás, nem com qualquer serviço de timestamp — não a menos que os dados de cada validador sejam publicados na blockchain, e o throughput do Bitcoin nunca foi construído para carregar isso.
A prova vale contra a malícia. Ela não diz nada sobre validadores que simplesmente param de aparecer. A cadeia trava exatamente da mesma forma, seja qual for o motivo, e o Bitcoin não consegue te dizer qual deles aconteceu.
"Garantido pelo Bitcoin" parece uma promessa. São duas. O Bitcoin compra certeza sobre qual histórico é o verdadeiro. Ele não compra uma promessa de que a cadeia continua andando se metade dos validadores desaparecer de uma vez — queda, saída, ou um ataque que ninguém percebeu a tempo.
Um comitê que precisa de um único signatário honesto, um relayer que precisa de um para ficar online — isso se resolve com mais operadores entrando. Esse limite é matemática provada, não um problema de equipe. Observar mais não move esse teto.
Meu BTC fica bloqueado de qualquer forma. O Bitcoin vai me dar um recibo para o exato momento em que a cadeia morreu. Fazer a cadeia voltar a respirar nunca fez parte da prova.
$BLESS $HOME
Se metade dos validadores da Babylon ficou escura esta noite, o que acontece com o seu BTC?
🔐 Safety's covered, I'm fine
33%
🛑 Liveness could still stall
0%
🧊 Frozen either way
0%
⚡ Didn't know
67%
3 Votos • Votação encerrada
Verificado
@BabylonLabs_io $BABY #baby
Toda vez que você remove o BTC do Babylon (unbond), existem nove chaves entre seu Bitcoin e sua carteira. Seis delas precisam concordar antes que você recupere seus fundos.
Uma dessas nove pertence à Babylon Labs.
O discurso é "sem confiança (trustless)": nenhum custodiante, nenhuma empresa que mantenha seu BTC — apenas o Bitcoin Script aplicando as regras. E isso é real: nenhuma chave sozinha consegue tocar seus fundos. Mas o unbond é a única porta de volta para suas moedas antes que o timelock de 15 meses acabe, e a equipe que construiu essa porta também detém uma das chaves para abri-la.
Isso não é um escândalo. As outras oito chaves ficam com entidades nomeadas e conceituadas, e o comitê só pode aprovar ou negar transações padrão — ele nunca foi construído para conseguir sair com o BTC de alguém. Ainda assim, leia os próprios documentos do Babylon com atenção suficiente e você vai ver que o construtor foi listado como signatário no sistema que ele construiu, para não precisar de signatários.
Pergunte a um staker do Babylon por que ele moveu BTC para o protocolo, e "sem confiança (trustless)" geralmente é a primeira palavra que sai da boca. Pergunte quem está com a chave número um, e a maioria não saberá que a resposta é Babylon Labs.
$IDOL
O fato de o construtor deter uma das chaves de unbond muda a forma como você vê "sem confiança (trustless)"?
Toda vez que você remove o BTC do Babylon (unbond), existem nove chaves entre seu Bitcoin e sua carteira. Seis delas precisam concordar antes que você recupere seus fundos.
Uma dessas nove pertence à Babylon Labs.
O discurso é "sem confiança (trustless)": nenhum custodiante, nenhuma empresa que mantenha seu BTC — apenas o Bitcoin Script aplicando as regras. E isso é real: nenhuma chave sozinha consegue tocar seus fundos. Mas o unbond é a única porta de volta para suas moedas antes que o timelock de 15 meses acabe, e a equipe que construiu essa porta também detém uma das chaves para abri-la.
Isso não é um escândalo. As outras oito chaves ficam com entidades nomeadas e conceituadas, e o comitê só pode aprovar ou negar transações padrão — ele nunca foi construído para conseguir sair com o BTC de alguém. Ainda assim, leia os próprios documentos do Babylon com atenção suficiente e você vai ver que o construtor foi listado como signatário no sistema que ele construiu, para não precisar de signatários.
Pergunte a um staker do Babylon por que ele moveu BTC para o protocolo, e "sem confiança (trustless)" geralmente é a primeira palavra que sai da boca. Pergunte quem está com a chave número um, e a maioria não saberá que a resposta é Babylon Labs.
$IDOL
O fato de o construtor deter uma das chaves de unbond muda a forma como você vê "sem confiança (trustless)"?
🔑 No, still trustless
100%
🔒 Slightly concerning
0%
🚨 Yes, big issue
0%
❓ Didn't know this
0%
1 Votos • Votação encerrada
2h da manhã, ainda acordado, lendo a documentação de checkpoints da Babylon sem motivo nenhum além de eu não conseguir dormir. Uma frase interrompeu a minha rolagem: um vigilante honesto e ativo por toda a rede é suficiente para garantir checkpoints do Bitcoin bem-sucedidos e seguros.
Leia rápido: isso parece descentralização fazendo o trabalho dela. Dezenas de operadores independentes, só um precisa se comportar.
Voltei ao próprio artigo acadêmico de 2022 da Babylon, coautorado pelos fundadores, aquele que prova essa afirmação como um teorema formal em vez de uma frase de marketing. A prova se mantém com uma condição: existe um validador honesto ativo o tempo todo. O artigo diz isso de forma clara.
Só que não explica o que vem depois. “Um é matematicamente suficiente” e “um está atualmente online” são duas garantias diferentes. Só a primeira vem com uma prova anexada.
Em seguida, a mesma frase apareceu de novo, desta vez ao lado do covenant emulator e do IBC relayer, nomeados como programas separados: a operação segura exige pelo menos um operador honesto de cada programa listado, ou o sistema levanta um alarme. Não tenho certeza se isso cobre todos os três igualmente, ou se foi escrito pensando apenas no conjunto do vigilante. De qualquer forma, o número de pessoas não é divulgado.
A Babylon chama isso de voluntário: qualquer um pode executar um. Verdade, e ainda assim não diz quantos atualmente executam, nem se esse número se mantém durante um pico de taxas no Bitcoin que ninguém quer pagar.
Existe um motivo pelo qual ninguém publica essa contagem. Revelar quão fino é o “buffer” ajuda um atacante mais do que ajuda você.
Se você está fazendo staking pela Babylon agora, essa é a suposição por trás do seu BTC, algo que nenhum painel mostra: não se a matemática funciona, mas se alguém está realmente acordado para rodar isso — hoje à noite e todas as noites depois.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Você faria staking se a contagem de “um operador honesto” fosse desconhecida? 👀
Leia rápido: isso parece descentralização fazendo o trabalho dela. Dezenas de operadores independentes, só um precisa se comportar.
Voltei ao próprio artigo acadêmico de 2022 da Babylon, coautorado pelos fundadores, aquele que prova essa afirmação como um teorema formal em vez de uma frase de marketing. A prova se mantém com uma condição: existe um validador honesto ativo o tempo todo. O artigo diz isso de forma clara.
Só que não explica o que vem depois. “Um é matematicamente suficiente” e “um está atualmente online” são duas garantias diferentes. Só a primeira vem com uma prova anexada.
Em seguida, a mesma frase apareceu de novo, desta vez ao lado do covenant emulator e do IBC relayer, nomeados como programas separados: a operação segura exige pelo menos um operador honesto de cada programa listado, ou o sistema levanta um alarme. Não tenho certeza se isso cobre todos os três igualmente, ou se foi escrito pensando apenas no conjunto do vigilante. De qualquer forma, o número de pessoas não é divulgado.
A Babylon chama isso de voluntário: qualquer um pode executar um. Verdade, e ainda assim não diz quantos atualmente executam, nem se esse número se mantém durante um pico de taxas no Bitcoin que ninguém quer pagar.
Existe um motivo pelo qual ninguém publica essa contagem. Revelar quão fino é o “buffer” ajuda um atacante mais do que ajuda você.
Se você está fazendo staking pela Babylon agora, essa é a suposição por trás do seu BTC, algo que nenhum painel mostra: não se a matemática funciona, mas se alguém está realmente acordado para rodar isso — hoje à noite e todas as noites depois.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Você faria staking se a contagem de “um operador honesto” fosse desconhecida? 👀
✨ Yes, the math is enough
100%
🤌🏻I'd wnt live operator data
0%
⚠️ That’s a real concern
0%
❓ Didn’t know this
0%
1 Votos • Votação encerrada
Verificado
#baby $BABY @BabylonLabs_io
Eu costumava achar que “cortar” era o jeito de Babilônia punir a desonestidade. Isso mudou às 2h da manhã, ao rolar por uma auditoria independente de segurança sobre a implementação do EOTS — o tipo de documento que ninguém abre sem um motivo.
O mecanismo é elegante por si só. Um provedor de finalidade se compromete com um pedaço de aleatoriedade antes de assinar qualquer bloco em uma determinada altura. Assina uma vez, nada acontece. Assina duas vezes, com duas mensagens diferentes, e a matemática por trás das assinaturas Schnorr transforma a mesma aleatoriedade na chave privada exposta do provedor. A dupla assinatura intencional se torna auto-punitiva por construção, e há um motivo para isso: um protocolo só consegue ler assinaturas, não intenção; então uma regra rígida o suficiente para pegar um atacante não consegue distinguir um atacante de um acidente.
Esse é o equilíbrio que a auditoria destacou. Um ataque deliberado e uma alternância (failover) de nó de backup honesto disparando exatamente na mesma altura produzem o mesmo padrão exato de assinatura. Ambos parecem idênticos para o EOTS. Ambos são cortados da mesma forma, marcados definitivamente (tombstoned), sem reinstalação.
Isso não é teórico. A Hex Trust, uma custódia institucional que executa a infraestrutura de provedores de finalidade na Babylon, lista salvaguardas específicas contra exatamente isso: nenhuma reutilização de chave privada entre máquinas, failover manual em vez de automático, porque o failover automático é exatamente o que pode produzir dois signatários ativos para uma mesma chave ao mesmo tempo.
Aqui vai a parte sem resposta limpa. Não existe um padrão público de divulgação sobre que tipo de configuração de failover um provedor utiliza. Você consegue verificar comissão, disponibilidade (uptime), número de delegadores. Não isso — não antes de seu BTC já estar travado.
Delegar nunca foi apenas uma aposta de que o operador não iria te atacar. É também uma aposta de que a infraestrutura dele nunca terá um “dia ruim” enquanto seu BTC estiver travado, em um detalhe que o protocolo torna impossível de saber com antecedência.
$KOMA
Eu costumava achar que “cortar” era o jeito de Babilônia punir a desonestidade. Isso mudou às 2h da manhã, ao rolar por uma auditoria independente de segurança sobre a implementação do EOTS — o tipo de documento que ninguém abre sem um motivo.
O mecanismo é elegante por si só. Um provedor de finalidade se compromete com um pedaço de aleatoriedade antes de assinar qualquer bloco em uma determinada altura. Assina uma vez, nada acontece. Assina duas vezes, com duas mensagens diferentes, e a matemática por trás das assinaturas Schnorr transforma a mesma aleatoriedade na chave privada exposta do provedor. A dupla assinatura intencional se torna auto-punitiva por construção, e há um motivo para isso: um protocolo só consegue ler assinaturas, não intenção; então uma regra rígida o suficiente para pegar um atacante não consegue distinguir um atacante de um acidente.
Esse é o equilíbrio que a auditoria destacou. Um ataque deliberado e uma alternância (failover) de nó de backup honesto disparando exatamente na mesma altura produzem o mesmo padrão exato de assinatura. Ambos parecem idênticos para o EOTS. Ambos são cortados da mesma forma, marcados definitivamente (tombstoned), sem reinstalação.
Isso não é teórico. A Hex Trust, uma custódia institucional que executa a infraestrutura de provedores de finalidade na Babylon, lista salvaguardas específicas contra exatamente isso: nenhuma reutilização de chave privada entre máquinas, failover manual em vez de automático, porque o failover automático é exatamente o que pode produzir dois signatários ativos para uma mesma chave ao mesmo tempo.
Aqui vai a parte sem resposta limpa. Não existe um padrão público de divulgação sobre que tipo de configuração de failover um provedor utiliza. Você consegue verificar comissão, disponibilidade (uptime), número de delegadores. Não isso — não antes de seu BTC já estar travado.
Delegar nunca foi apenas uma aposta de que o operador não iria te atacar. É também uma aposta de que a infraestrutura dele nunca terá um “dia ruim” enquanto seu BTC estiver travado, em um detalhe que o protocolo torna impossível de saber com antecedência.
$KOMA
Verificado
$BABY $UAI $COTI #baby @BabylonLabs_io
No começo, eu assumi que o comitê de convênios era um passo inicial (bootstrap), algo que a Babylon aposentaria quando sua própria roadmap maturasse, do mesmo jeito que a maioria dos protocolos jovens promete descentralizar no seu próprio cronograma. A documentação diz algo mais silencioso e mais estranho do que isso.
O comitê existe porque o próprio Bitcoin não tem uma forma nativa de impor convênios, nenhum opcode que consiga forçar um UTXO a ser gasto apenas através de regras pré-acordadas. Então a Babylon construiu um multisig 6-de-9 para emular essa função que faltava, acompanhando pedidos de staking, coassinando o desbloqueio (unbonding) e as penalidades (slashing), ficando como “substituto” de uma capacidade que o Bitcoin Script simplesmente ainda não tem. Essa parte é engenharia honesta lidando com uma lacuna real, e a suposição de confiança é genuinamente mais leve do que um multisig de custódia normal: é uma “honestidade existencial”, em vez de honestidade por maioria; um único signatário honesto basta para impedir roubo.
O que me fez parar foi a condição de saída. A própria documentação da Babylon não diz que o comitê se aposenta quando a governança amadurece, nem quando um certo patamar de TVL é atingido, nem quando algum marco interno é entregue. Ela diz que o comitê permanece até que a funcionalidade de convênios fique disponível nativamente no Bitcoin, por meio de opcodes como OP-CAT ou OP-CTV que o Bitcoin Core não adotou e não tem um cronograma comprometido para adotar. A data de aposentadoria não está no roadmap da Babylon. Ela está dentro do processo de governança de outro protocolo, no qual a Babylon não tem voto e nem capacidade de acelerar.
Assim, a confiança não desapareceu quando a Babylon chamou isso de um sistema “seguro pelo Bitcoin”. Ela só se deslocou uma camada mais para longe: para fora de um multisig com membros definidos e para dentro de um soft fork do Bitcoin que pode ou não ser entregue nesta década. Seis de nove signatários conhecidos é, pelo menos, uma suposição de confiança que você consegue nomear. Uma atualização pendente de opcode sem prazo é uma suposição de confiança na qual você só consegue esperar.
O comitê de convênios permanece até o Bitcoin adicionar opcodes de convênios. Nenhum cronograma da Babylon controla isso.
Qual é a sua leitura? 👀
No começo, eu assumi que o comitê de convênios era um passo inicial (bootstrap), algo que a Babylon aposentaria quando sua própria roadmap maturasse, do mesmo jeito que a maioria dos protocolos jovens promete descentralizar no seu próprio cronograma. A documentação diz algo mais silencioso e mais estranho do que isso.
O comitê existe porque o próprio Bitcoin não tem uma forma nativa de impor convênios, nenhum opcode que consiga forçar um UTXO a ser gasto apenas através de regras pré-acordadas. Então a Babylon construiu um multisig 6-de-9 para emular essa função que faltava, acompanhando pedidos de staking, coassinando o desbloqueio (unbonding) e as penalidades (slashing), ficando como “substituto” de uma capacidade que o Bitcoin Script simplesmente ainda não tem. Essa parte é engenharia honesta lidando com uma lacuna real, e a suposição de confiança é genuinamente mais leve do que um multisig de custódia normal: é uma “honestidade existencial”, em vez de honestidade por maioria; um único signatário honesto basta para impedir roubo.
O que me fez parar foi a condição de saída. A própria documentação da Babylon não diz que o comitê se aposenta quando a governança amadurece, nem quando um certo patamar de TVL é atingido, nem quando algum marco interno é entregue. Ela diz que o comitê permanece até que a funcionalidade de convênios fique disponível nativamente no Bitcoin, por meio de opcodes como OP-CAT ou OP-CTV que o Bitcoin Core não adotou e não tem um cronograma comprometido para adotar. A data de aposentadoria não está no roadmap da Babylon. Ela está dentro do processo de governança de outro protocolo, no qual a Babylon não tem voto e nem capacidade de acelerar.
Assim, a confiança não desapareceu quando a Babylon chamou isso de um sistema “seguro pelo Bitcoin”. Ela só se deslocou uma camada mais para longe: para fora de um multisig com membros definidos e para dentro de um soft fork do Bitcoin que pode ou não ser entregue nesta década. Seis de nove signatários conhecidos é, pelo menos, uma suposição de confiança que você consegue nomear. Uma atualização pendente de opcode sem prazo é uma suposição de confiança na qual você só consegue esperar.
O comitê de convênios permanece até o Bitcoin adicionar opcodes de convênios. Nenhum cronograma da Babylon controla isso.
Qual é a sua leitura? 👀
Safest for now ✅
25%
Uncomfortable, but fair 😕
0%
🚩 Real red flag
75%
Didn’t know this🥱
0%
4 Votos • Votação encerrada
Na semana passada, eu estava escolhendo um provedor de finalidade, olhando para uma lista de cerca de 30 nomes verificados, e percebi que eu ia clicar naquele que já tinha o maior número de delegadores. O mesmo reflexo que transformou uma grande parcela do staking do Ethereum em uma história sobre a Lido.
Então eu realmente li o guia de staking da Babylon.
Ele aponta o risco diretamente: delegar aos provedores mais populares aumenta o risco de centralização. Não é uma observação de um crítico; a própria documentação deles diz isso.
➡ Cerca de 30 provedores têm um visto de verificação no app.
➡ Nada nessa lista limita quanto delegação qualquer um deles pode absorver.
Dou crédito à Babylon por dizer isso em voz alta; a maioria dos produtos de staking nunca avisa o usuário final antes de ele clicar.
O que ficou comigo: o visto existe para construir confiança. Mas se a maioria dos stakers optar por algum nome verificado que já tenha mais delegadores, o padrão exato pelo qual o Ethereum passou — aquilo que era para construir confiança — vira o mecanismo que concentra exatamente o risco que eles alertam.
Procurei números reais de participação de delegação: quanto os 5 ou 10 principais provedores de finalidade controlam juntos. Não encontrei nada público. Um texto próprio de uma exchange de criptomoedas sobre o protocolo chamou isso de "ainda exigindo discussões adicionais", um problema em aberto sinalizado por uma fonte externa — não algo que a Babylon tenha abordado em registros.
Eu dividi minha delegação entre três provedores menores em vez de um grande. Nesse nível, provavelmente é mais um gesto simbólico do que uma solução real, e eu sei disso.
@BabylonLabs_io $BABY #baby $ON
"Você delegaria de propósito a um provedor de finalidade menor?"
Então eu realmente li o guia de staking da Babylon.
Ele aponta o risco diretamente: delegar aos provedores mais populares aumenta o risco de centralização. Não é uma observação de um crítico; a própria documentação deles diz isso.
➡ Cerca de 30 provedores têm um visto de verificação no app.
➡ Nada nessa lista limita quanto delegação qualquer um deles pode absorver.
Dou crédito à Babylon por dizer isso em voz alta; a maioria dos produtos de staking nunca avisa o usuário final antes de ele clicar.
O que ficou comigo: o visto existe para construir confiança. Mas se a maioria dos stakers optar por algum nome verificado que já tenha mais delegadores, o padrão exato pelo qual o Ethereum passou — aquilo que era para construir confiança — vira o mecanismo que concentra exatamente o risco que eles alertam.
Procurei números reais de participação de delegação: quanto os 5 ou 10 principais provedores de finalidade controlam juntos. Não encontrei nada público. Um texto próprio de uma exchange de criptomoedas sobre o protocolo chamou isso de "ainda exigindo discussões adicionais", um problema em aberto sinalizado por uma fonte externa — não algo que a Babylon tenha abordado em registros.
Eu dividi minha delegação entre três provedores menores em vez de um grande. Nesse nível, provavelmente é mais um gesto simbólico do que uma solução real, e eu sei disso.
@BabylonLabs_io $BABY #baby $ON
"Você delegaria de propósito a um provedor de finalidade menor?"
🔀 Yes, spread it out
0%
🛡️ No, biggest is safest
0%
💰 Depends on commission
0%
🤷 Never thought about it
100%
1 Votos • Votação encerrada
#baby @BabylonLabs_io
Quase coloquei uma pequena quantidade de BTC em uma posição de empréstimo com lastro em uma vault semana passada. Antes de fazer isso, eu queria saber uma coisa: se o mercado se movesse rápido contra mim, o que realmente decide quando eu sou liquidado? Foi essa pergunta que me fez ir além do marketing e entrar no próprio site da Babylon — para onde a palavra "trustless" deixa de se aplicar. Não estava enterrado. Só não sobrevive à tradução em cada manchete construída em torno daquela palavra. ➡ A página de Aprendizado da própria Babylon diz claramente que o risco real está do lado do DeFi, não na própria vault, e dá a liquidação em empréstimos como exemplo. ➡ O whitepaper confirma isso: a liquidação precisa de uma assinatura de um oráculo de preço, tratada como uma dependência separada do design central da vault. Dê crédito à Babylon — eles escreveram isso eles mesmos. Ninguém teve que desenterrar isso deles. Aqui está a parte que ficou comigo, a parte que realmente mudou o quanto eu estava prestes a depositar. "Um oráculo de preço" soa abstrato, até que um relatório sobre exatamente esse sistema nomeie quais redes realmente mantêm essa relação com a Babylon: Band Protocol e Pyth, as mesmas redes de propósito geral que precificam dezenas de outras cadeias ao mesmo tempo. Os materiais da própria Babylon não os nomeiam diretamente, então trate esse pareamento específico como reportado, não confirmado pela própria Babylon. Se uma dessas fontes estiver atrasada ou errada durante um movimento rápido, minha liquidação ainda acontece exatamente como foi codificado. Agir corretamente com base em informação ruim. A camada base do Bitcoin não vota nesse resultado. A vault faz exatamente o que prometeu. O oráculo apenas entrega algo falso. Isso não é a vault falhando. É risco do DeFi, usando um rótulo de trustless, herdando qualquer histórico de indisponibilidade que seu feed de preço real já carregue de outras cadeias que nem sequer uso. Eu ainda fiz o depósito. Só que menor do que eu faria uma hora antes. Trustless descreve o que acontece com seu BTC. Nunca foi uma promessa sobre o que acontece com seu dinheiro depois que ele sai da vault.
$BROCCOLIF3B $ON $BABY
Quase coloquei uma pequena quantidade de BTC em uma posição de empréstimo com lastro em uma vault semana passada. Antes de fazer isso, eu queria saber uma coisa: se o mercado se movesse rápido contra mim, o que realmente decide quando eu sou liquidado? Foi essa pergunta que me fez ir além do marketing e entrar no próprio site da Babylon — para onde a palavra "trustless" deixa de se aplicar. Não estava enterrado. Só não sobrevive à tradução em cada manchete construída em torno daquela palavra. ➡ A página de Aprendizado da própria Babylon diz claramente que o risco real está do lado do DeFi, não na própria vault, e dá a liquidação em empréstimos como exemplo. ➡ O whitepaper confirma isso: a liquidação precisa de uma assinatura de um oráculo de preço, tratada como uma dependência separada do design central da vault. Dê crédito à Babylon — eles escreveram isso eles mesmos. Ninguém teve que desenterrar isso deles. Aqui está a parte que ficou comigo, a parte que realmente mudou o quanto eu estava prestes a depositar. "Um oráculo de preço" soa abstrato, até que um relatório sobre exatamente esse sistema nomeie quais redes realmente mantêm essa relação com a Babylon: Band Protocol e Pyth, as mesmas redes de propósito geral que precificam dezenas de outras cadeias ao mesmo tempo. Os materiais da própria Babylon não os nomeiam diretamente, então trate esse pareamento específico como reportado, não confirmado pela própria Babylon. Se uma dessas fontes estiver atrasada ou errada durante um movimento rápido, minha liquidação ainda acontece exatamente como foi codificado. Agir corretamente com base em informação ruim. A camada base do Bitcoin não vota nesse resultado. A vault faz exatamente o que prometeu. O oráculo apenas entrega algo falso. Isso não é a vault falhando. É risco do DeFi, usando um rótulo de trustless, herdando qualquer histórico de indisponibilidade que seu feed de preço real já carregue de outras cadeias que nem sequer uso. Eu ainda fiz o depósito. Só que menor do que eu faria uma hora antes. Trustless descreve o que acontece com seu BTC. Nunca foi uma promessa sobre o que acontece com seu dinheiro depois que ele sai da vault.
$BROCCOLIF3B $ON $BABY
✅ Bitcoin security
0%
📈 Oracle accuracy
0%
⚖️ Both equally
0%
❓Depends on the protocol
0%
0 Votos • Votação encerrada
Parcialmente verdadeiro
#baby $BABY @BabylonLabs_io
Quase coloquei uma pequena quantia de BTC em uma posição de empréstimo com garantia por um vault na semana passada. Antes de fazer isso, eu queria saber uma coisa: se o mercado se movesse rápido contra mim, o que exatamente decide quando eu sou liquidado?
Foi essa pergunta que me fez procurar além do marketing e ir até o próprio site da Babylon, para ver onde a palavra "trustless" deixa de ser aplicável.
Não estava escondida. Apenas não sobrevive à tradução em cada manchete construída em torno daquela palavra.
➡ A página de Aprenda da própria Babylon diz de forma direta que o risco real está no lado do DeFi, e não no próprio vault, e dá liquidação em empréstimos como exemplo.
➡ O whitepaper confirma: liquidação precisa de uma assinatura de um oráculo de preços, tratada como uma dependência separada do design central do vault.
Dê crédito à Babylon — eles escreveram isso por conta própria. Ninguém precisou desenterrar isso deles.
Aqui está a parte que ficou comigo, a parte que realmente mudou quanto eu estava prestes a depositar. "Um oráculo de preços" parece abstrato, até que um relatório sobre exatamente esse sistema cita quais redes realmente mantêm essa relação com a Babylon: Band Protocol e Pyth, as mesmas redes de propósito geral que precificam dezenas de outras cadeias ao mesmo tempo. Os materiais da própria Babylon não as nomeiam diretamente, então trate esse par específico como relatado, não confirmado pela própria Babylon.
Se um desses feeds estiver atrasado ou errado durante um movimento rápido, minha liquidação ainda dispara exatamente como foi codificado. Agindo corretamente, com base em informações ruins. A camada base do Bitcoin não tem voto nesse resultado. O vault faz exatamente o que prometeu. O oráculo apenas entrega algo falso.
Isso não é o vault falhando. É risco do DeFi, usando um rótulo de trustless, herdando qualquer histórico de indisponibilidade que seu próprio feed de preço já carrega de outras cadeias que eu nem uso.
Ainda fiz o depósito. Só menor do que eu faria uma hora antes.
Trustless descreve o que acontece com o seu BTC. Nunca foi uma promessa sobre o que acontece com seu dinheiro depois que ele sai do vault.
$EUL
Um vault trustless ainda pode depender de oráculos?
Quase coloquei uma pequena quantia de BTC em uma posição de empréstimo com garantia por um vault na semana passada. Antes de fazer isso, eu queria saber uma coisa: se o mercado se movesse rápido contra mim, o que exatamente decide quando eu sou liquidado?
Foi essa pergunta que me fez procurar além do marketing e ir até o próprio site da Babylon, para ver onde a palavra "trustless" deixa de ser aplicável.
Não estava escondida. Apenas não sobrevive à tradução em cada manchete construída em torno daquela palavra.
➡ A página de Aprenda da própria Babylon diz de forma direta que o risco real está no lado do DeFi, e não no próprio vault, e dá liquidação em empréstimos como exemplo.
➡ O whitepaper confirma: liquidação precisa de uma assinatura de um oráculo de preços, tratada como uma dependência separada do design central do vault.
Dê crédito à Babylon — eles escreveram isso por conta própria. Ninguém precisou desenterrar isso deles.
Aqui está a parte que ficou comigo, a parte que realmente mudou quanto eu estava prestes a depositar. "Um oráculo de preços" parece abstrato, até que um relatório sobre exatamente esse sistema cita quais redes realmente mantêm essa relação com a Babylon: Band Protocol e Pyth, as mesmas redes de propósito geral que precificam dezenas de outras cadeias ao mesmo tempo. Os materiais da própria Babylon não as nomeiam diretamente, então trate esse par específico como relatado, não confirmado pela própria Babylon.
Se um desses feeds estiver atrasado ou errado durante um movimento rápido, minha liquidação ainda dispara exatamente como foi codificado. Agindo corretamente, com base em informações ruins. A camada base do Bitcoin não tem voto nesse resultado. O vault faz exatamente o que prometeu. O oráculo apenas entrega algo falso.
Isso não é o vault falhando. É risco do DeFi, usando um rótulo de trustless, herdando qualquer histórico de indisponibilidade que seu próprio feed de preço já carrega de outras cadeias que eu nem uso.
Ainda fiz o depósito. Só menor do que eu faria uma hora antes.
Trustless descreve o que acontece com o seu BTC. Nunca foi uma promessa sobre o que acontece com seu dinheiro depois que ele sai do vault.
$EUL
Um vault trustless ainda pode depender de oráculos?
✅ Yes, already knew
0%
🤯 No,I asumed it covered both
0%
0 Votos • Votação encerrada
⚡✨
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Não consegui dormir na noite passada, então puxei três textos separados sobre o lado do Aave Temp Check da Babylon lado a lado, mais por hábito do que por qualquer outra coisa.
Uma palavra não parava de me incomodar.
Bitcoin.com, Cointribune e LiveBitcoinNews descrevem todo o fluxo de liquidação de TBV da mesma maneira. Um liquidante sem permissão troca um cofre apreendido por WBTC instantaneamente, com um pequeno prêmio. Um conjunto separado de "arbitrageurs com permissão" então compra essa posição e resgata o BTC real depois, na linha do tempo do próprio Bitcoin.
Dê crédito à Babylon pela primeira metade: as verificações de liquidação sem permissão funcionam exatamente como foi anunciado.
É a segunda metade que me fez procurar mais fundo do que a proposta do Aave. O próprio whitepaper de agosto da Babylon sobre Trustless Bitcoin Vaults nem sequer diz "permissioned" — ele afirma que as liquidações passam por "liquidadores whitelisted" que monitoram o preço e o estado do cofre. Palavra diferente, mesmo formato. Um analista independente que trocou mensagens com a equipe da Babylon no X levantou o mesmo ponto diretamente com eles: o suficiente dessas partes whitelisted agirem corretamente é uma suposição de confiança que o marketing não menciona.
Então a palavra acabou sendo precisa. A questão real é por que esse papel precisa ser restrito de qualquer forma, quando o lado do swap para WBTC não é. A linguagem de scripting do Bitcoin não consegue avaliar um estado arbitrário fora da cadeia. O BitVM3 contorna isso envolvendo um verificador de prova de conhecimento zero dentro de um circuito ofuscado, mas ainda assim alguém precisa gerar e enviar essa prova para acionar o resgate. O lado do swap para WBTC é fácil de deixar sem permissão — qualquer liquidante com capital faz a operação. Enviar a prova é o problema mais difícil que o BitVM3 ainda não resolveu.
Isso não é sobre saber se o cofre é trustless. A Babylon não escondeu o whitelisting no próprio whitepaper. A ausência de confiança não desaparece aqui. Ela apenas termina um passo antes do que a maior parte da cobertura faz parecer.
$EUL
O que define um cofre de BTC realmente sem confiança?
Não consegui dormir na noite passada, então puxei três textos separados sobre o lado do Aave Temp Check da Babylon lado a lado, mais por hábito do que por qualquer outra coisa.
Uma palavra não parava de me incomodar.
Bitcoin.com, Cointribune e LiveBitcoinNews descrevem todo o fluxo de liquidação de TBV da mesma maneira. Um liquidante sem permissão troca um cofre apreendido por WBTC instantaneamente, com um pequeno prêmio. Um conjunto separado de "arbitrageurs com permissão" então compra essa posição e resgata o BTC real depois, na linha do tempo do próprio Bitcoin.
Dê crédito à Babylon pela primeira metade: as verificações de liquidação sem permissão funcionam exatamente como foi anunciado.
É a segunda metade que me fez procurar mais fundo do que a proposta do Aave. O próprio whitepaper de agosto da Babylon sobre Trustless Bitcoin Vaults nem sequer diz "permissioned" — ele afirma que as liquidações passam por "liquidadores whitelisted" que monitoram o preço e o estado do cofre. Palavra diferente, mesmo formato. Um analista independente que trocou mensagens com a equipe da Babylon no X levantou o mesmo ponto diretamente com eles: o suficiente dessas partes whitelisted agirem corretamente é uma suposição de confiança que o marketing não menciona.
Então a palavra acabou sendo precisa. A questão real é por que esse papel precisa ser restrito de qualquer forma, quando o lado do swap para WBTC não é. A linguagem de scripting do Bitcoin não consegue avaliar um estado arbitrário fora da cadeia. O BitVM3 contorna isso envolvendo um verificador de prova de conhecimento zero dentro de um circuito ofuscado, mas ainda assim alguém precisa gerar e enviar essa prova para acionar o resgate. O lado do swap para WBTC é fácil de deixar sem permissão — qualquer liquidante com capital faz a operação. Enviar a prova é o problema mais difícil que o BitVM3 ainda não resolveu.
Isso não é sobre saber se o cofre é trustless. A Babylon não escondeu o whitelisting no próprio whitepaper. A ausência de confiança não desaparece aqui. Ela apenas termina um passo antes do que a maior parte da cobertura faz parecer.
$EUL
O que define um cofre de BTC realmente sem confiança?
Ver tradução
$EUL $CHILLGUY Goooo
and give me feedback
and give me feedback
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Não consegui dormir na noite passada, então puxei três textos separados sobre o lado do Aave Temp Check da Babylon lado a lado, mais por hábito do que por qualquer outra coisa.
Uma palavra não parava de me incomodar.
Bitcoin.com, Cointribune e LiveBitcoinNews descrevem todo o fluxo de liquidação de TBV da mesma maneira. Um liquidante sem permissão troca um cofre apreendido por WBTC instantaneamente, com um pequeno prêmio. Um conjunto separado de "arbitrageurs com permissão" então compra essa posição e resgata o BTC real depois, na linha do tempo do próprio Bitcoin.
Dê crédito à Babylon pela primeira metade: as verificações de liquidação sem permissão funcionam exatamente como foi anunciado.
É a segunda metade que me fez procurar mais fundo do que a proposta do Aave. O próprio whitepaper de agosto da Babylon sobre Trustless Bitcoin Vaults nem sequer diz "permissioned" — ele afirma que as liquidações passam por "liquidadores whitelisted" que monitoram o preço e o estado do cofre. Palavra diferente, mesmo formato. Um analista independente que trocou mensagens com a equipe da Babylon no X levantou o mesmo ponto diretamente com eles: o suficiente dessas partes whitelisted agirem corretamente é uma suposição de confiança que o marketing não menciona.
Então a palavra acabou sendo precisa. A questão real é por que esse papel precisa ser restrito de qualquer forma, quando o lado do swap para WBTC não é. A linguagem de scripting do Bitcoin não consegue avaliar um estado arbitrário fora da cadeia. O BitVM3 contorna isso envolvendo um verificador de prova de conhecimento zero dentro de um circuito ofuscado, mas ainda assim alguém precisa gerar e enviar essa prova para acionar o resgate. O lado do swap para WBTC é fácil de deixar sem permissão — qualquer liquidante com capital faz a operação. Enviar a prova é o problema mais difícil que o BitVM3 ainda não resolveu.
Isso não é sobre saber se o cofre é trustless. A Babylon não escondeu o whitelisting no próprio whitepaper. A ausência de confiança não desaparece aqui. Ela apenas termina um passo antes do que a maior parte da cobertura faz parecer.
$EUL
O que define um cofre de BTC realmente sem confiança?
Não consegui dormir na noite passada, então puxei três textos separados sobre o lado do Aave Temp Check da Babylon lado a lado, mais por hábito do que por qualquer outra coisa.
Uma palavra não parava de me incomodar.
Bitcoin.com, Cointribune e LiveBitcoinNews descrevem todo o fluxo de liquidação de TBV da mesma maneira. Um liquidante sem permissão troca um cofre apreendido por WBTC instantaneamente, com um pequeno prêmio. Um conjunto separado de "arbitrageurs com permissão" então compra essa posição e resgata o BTC real depois, na linha do tempo do próprio Bitcoin.
Dê crédito à Babylon pela primeira metade: as verificações de liquidação sem permissão funcionam exatamente como foi anunciado.
É a segunda metade que me fez procurar mais fundo do que a proposta do Aave. O próprio whitepaper de agosto da Babylon sobre Trustless Bitcoin Vaults nem sequer diz "permissioned" — ele afirma que as liquidações passam por "liquidadores whitelisted" que monitoram o preço e o estado do cofre. Palavra diferente, mesmo formato. Um analista independente que trocou mensagens com a equipe da Babylon no X levantou o mesmo ponto diretamente com eles: o suficiente dessas partes whitelisted agirem corretamente é uma suposição de confiança que o marketing não menciona.
Então a palavra acabou sendo precisa. A questão real é por que esse papel precisa ser restrito de qualquer forma, quando o lado do swap para WBTC não é. A linguagem de scripting do Bitcoin não consegue avaliar um estado arbitrário fora da cadeia. O BitVM3 contorna isso envolvendo um verificador de prova de conhecimento zero dentro de um circuito ofuscado, mas ainda assim alguém precisa gerar e enviar essa prova para acionar o resgate. O lado do swap para WBTC é fácil de deixar sem permissão — qualquer liquidante com capital faz a operação. Enviar a prova é o problema mais difícil que o BitVM3 ainda não resolveu.
Isso não é sobre saber se o cofre é trustless. A Babylon não escondeu o whitelisting no próprio whitepaper. A ausência de confiança não desaparece aqui. Ela apenas termina um passo antes do que a maior parte da cobertura faz parecer.
$EUL
O que define um cofre de BTC realmente sem confiança?
#baby $BABY @BabylonLabs_io
Não consegui dormir na noite passada, então puxei três textos separados sobre o lado do Aave Temp Check da Babylon lado a lado, mais por hábito do que por qualquer outra coisa.
Uma palavra não parava de me incomodar.
Bitcoin.com, Cointribune e LiveBitcoinNews descrevem todo o fluxo de liquidação de TBV da mesma maneira. Um liquidante sem permissão troca um cofre apreendido por WBTC instantaneamente, com um pequeno prêmio. Um conjunto separado de "arbitrageurs com permissão" então compra essa posição e resgata o BTC real depois, na linha do tempo do próprio Bitcoin.
Dê crédito à Babylon pela primeira metade: as verificações de liquidação sem permissão funcionam exatamente como foi anunciado.
É a segunda metade que me fez procurar mais fundo do que a proposta do Aave. O próprio whitepaper de agosto da Babylon sobre Trustless Bitcoin Vaults nem sequer diz "permissioned" — ele afirma que as liquidações passam por "liquidadores whitelisted" que monitoram o preço e o estado do cofre. Palavra diferente, mesmo formato. Um analista independente que trocou mensagens com a equipe da Babylon no X levantou o mesmo ponto diretamente com eles: o suficiente dessas partes whitelisted agirem corretamente é uma suposição de confiança que o marketing não menciona.
Então a palavra acabou sendo precisa. A questão real é por que esse papel precisa ser restrito de qualquer forma, quando o lado do swap para WBTC não é. A linguagem de scripting do Bitcoin não consegue avaliar um estado arbitrário fora da cadeia. O BitVM3 contorna isso envolvendo um verificador de prova de conhecimento zero dentro de um circuito ofuscado, mas ainda assim alguém precisa gerar e enviar essa prova para acionar o resgate. O lado do swap para WBTC é fácil de deixar sem permissão — qualquer liquidante com capital faz a operação. Enviar a prova é o problema mais difícil que o BitVM3 ainda não resolveu.
Isso não é sobre saber se o cofre é trustless. A Babylon não escondeu o whitelisting no próprio whitepaper. A ausência de confiança não desaparece aqui. Ela apenas termina um passo antes do que a maior parte da cobertura faz parecer.
$EUL
O que define um cofre de BTC realmente sem confiança?
Não consegui dormir na noite passada, então puxei três textos separados sobre o lado do Aave Temp Check da Babylon lado a lado, mais por hábito do que por qualquer outra coisa.
Uma palavra não parava de me incomodar.
Bitcoin.com, Cointribune e LiveBitcoinNews descrevem todo o fluxo de liquidação de TBV da mesma maneira. Um liquidante sem permissão troca um cofre apreendido por WBTC instantaneamente, com um pequeno prêmio. Um conjunto separado de "arbitrageurs com permissão" então compra essa posição e resgata o BTC real depois, na linha do tempo do próprio Bitcoin.
Dê crédito à Babylon pela primeira metade: as verificações de liquidação sem permissão funcionam exatamente como foi anunciado.
É a segunda metade que me fez procurar mais fundo do que a proposta do Aave. O próprio whitepaper de agosto da Babylon sobre Trustless Bitcoin Vaults nem sequer diz "permissioned" — ele afirma que as liquidações passam por "liquidadores whitelisted" que monitoram o preço e o estado do cofre. Palavra diferente, mesmo formato. Um analista independente que trocou mensagens com a equipe da Babylon no X levantou o mesmo ponto diretamente com eles: o suficiente dessas partes whitelisted agirem corretamente é uma suposição de confiança que o marketing não menciona.
Então a palavra acabou sendo precisa. A questão real é por que esse papel precisa ser restrito de qualquer forma, quando o lado do swap para WBTC não é. A linguagem de scripting do Bitcoin não consegue avaliar um estado arbitrário fora da cadeia. O BitVM3 contorna isso envolvendo um verificador de prova de conhecimento zero dentro de um circuito ofuscado, mas ainda assim alguém precisa gerar e enviar essa prova para acionar o resgate. O lado do swap para WBTC é fácil de deixar sem permissão — qualquer liquidante com capital faz a operação. Enviar a prova é o problema mais difícil que o BitVM3 ainda não resolveu.
Isso não é sobre saber se o cofre é trustless. A Babylon não escondeu o whitelisting no próprio whitepaper. A ausência de confiança não desaparece aqui. Ela apenas termina um passo antes do que a maior parte da cobertura faz parecer.
$EUL
O que define um cofre de BTC realmente sem confiança?
⚡ Permissionless liquidation
100%
🔓 Permissionless redemption
0%
🤔 Not sure yet
0%
⚖️ Both are equally important
0%
1 Votos • Votação encerrada
junte-se
英鸿³³₇
·
--
[Repetir] 🎙️ Vamos falar sobre as relações de amor e ódio do mercado primário, e sobre o DCA de bnb no mercado secundário
02 h 17 min. 48 seg. · 12.8k reproduções
$DEXE Goooooo 👉🏻
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
dois pools do mesmo ativo, separados por alguns cliques, com zero conexão entre eles até agora. Aave carrega cerca de US$ 5B em WBTC que mal se mexe no lado do empréstimo. A Babylon detém US$ 4B+ em BTC apostado, rendendo nada além dos prêmios do staking.
essa é a proposta real enterrada no Temp Check da Babylon — não "BTC sem confiança", mas combinar oferta ociosa em uma plataforma com colateral ocioso em outra.
o design Hub-and-Spoke da Aave na V4 é o que torna isso possível sem a Babylon tocar no pool principal de empréstimos da Aave. dois novos Spokes são implantados como módulos isolados — a Babylon controla a lógica de colateral em BTC, e o Hub principal da Aave permanece intocado por qualquer risco que isso introduza.
vale notar: isso não é uma proposta comunitária flutuando despercebida. o próprio fundador da Aave apoiou publicamente, destacando especificamente a implementação dos Spokes como um novo padrão para a V4 — não apenas mais uma listagem de ativo.
ainda é etapa de Temp Check. a ARFC e uma votação on-chain precisam acontecer antes que qualquer BTC realmente se mova por aqui.
se ambos os pools continuarem parados por alguns meses após isso passar pela governança, o problema nunca foi a infraestrutura. era apetite.
$DEXE
O que mais importa se isso entrar no ar?
dois pools do mesmo ativo, separados por alguns cliques, com zero conexão entre eles até agora. Aave carrega cerca de US$ 5B em WBTC que mal se mexe no lado do empréstimo. A Babylon detém US$ 4B+ em BTC apostado, rendendo nada além dos prêmios do staking.
essa é a proposta real enterrada no Temp Check da Babylon — não "BTC sem confiança", mas combinar oferta ociosa em uma plataforma com colateral ocioso em outra.
o design Hub-and-Spoke da Aave na V4 é o que torna isso possível sem a Babylon tocar no pool principal de empréstimos da Aave. dois novos Spokes são implantados como módulos isolados — a Babylon controla a lógica de colateral em BTC, e o Hub principal da Aave permanece intocado por qualquer risco que isso introduza.
vale notar: isso não é uma proposta comunitária flutuando despercebida. o próprio fundador da Aave apoiou publicamente, destacando especificamente a implementação dos Spokes como um novo padrão para a V4 — não apenas mais uma listagem de ativo.
ainda é etapa de Temp Check. a ARFC e uma votação on-chain precisam acontecer antes que qualquer BTC realmente se mova por aqui.
se ambos os pools continuarem parados por alguns meses após isso passar pela governança, o problema nunca foi a infraestrutura. era apetite.
$DEXE
O que mais importa se isso entrar no ar?
Parcialmente verdadeiro
#baby $BABY @BabylonLabs_io
estava lendo as notas de migração do Aave do v3 para o v4 ontem à noite, quase por tédio, e uma linha do próprio paper de vault da Babylon ficou comigo depois que fechei a aba: as condições de gasto de um vault TBV, incluindo o contrato de destino, são fixadas no exato momento em que ele é criado; literalmente é isso que o torna trustless. ninguém consegue redirecionar o BTC depois sem esse caminho previamente acordado. o que isso, silenciosamente, significa é que se o Aave algum dia migrar contratos novamente do jeito que acabou de fazer de v3 para v4, um vault existente não consegue acompanhar: ele tem que ser desfeito no cronograma próprio do Bitcoin e ser recriado, apontando para o novo destino, toda vez que o protocolo de destino fizer upgrade. trustlessness aqui não é grátis; é negociado por rigidez, e ninguém está realmente precificando isso. eu não consegui encontrar detalhes públicos sobre se a Babylon ou o Aave planejaram alguma ferramenta para tornar essa transição mais suave. isto não é sobre o quão seguro um vault parece no dia em que você o cria; é sobre o que acontece no dia em que o outro lado precisa mudar.
$DEXE
Qual é o grande trade-off aqui?
estava lendo as notas de migração do Aave do v3 para o v4 ontem à noite, quase por tédio, e uma linha do próprio paper de vault da Babylon ficou comigo depois que fechei a aba: as condições de gasto de um vault TBV, incluindo o contrato de destino, são fixadas no exato momento em que ele é criado; literalmente é isso que o torna trustless. ninguém consegue redirecionar o BTC depois sem esse caminho previamente acordado. o que isso, silenciosamente, significa é que se o Aave algum dia migrar contratos novamente do jeito que acabou de fazer de v3 para v4, um vault existente não consegue acompanhar: ele tem que ser desfeito no cronograma próprio do Bitcoin e ser recriado, apontando para o novo destino, toda vez que o protocolo de destino fizer upgrade. trustlessness aqui não é grátis; é negociado por rigidez, e ninguém está realmente precificando isso. eu não consegui encontrar detalhes públicos sobre se a Babylon ou o Aave planejaram alguma ferramenta para tornar essa transição mais suave. isto não é sobre o quão seguro um vault parece no dia em que você o cria; é sobre o que acontece no dia em que o outro lado precisa mudar.
$DEXE
Qual é o grande trade-off aqui?
🔒 Stronger security
33%
🔄 Easier upgrades
0%
⚖️ Need both
0%
🤔 Still researching
67%
6 Votos • Votação encerrada
Inicia sessão para explorar mais conteúdos