Binance Square
洛长安
66 Publicações

洛长安

10 A seguir
23 Seguidores
9 Gostaram
Publicações
·
--
Ver tradução
看到 Babylon 与 GoMining 的合作公告,我脑海里先跳出信贷审批的铁律:抵押品归抵押品,用途归用途,两笔账不能混着看。#baby 很多人被"原生 BTC 质押挖矿"吸引,以为 BTC 锁在 TBV 里、收益就自动流回来。@babylonlabs_io 但把方案拆开读,你会发现这是风险切割,不是风险消灭。 前半段是 Babylon 的领地:用户把 BTC 押进 Trustless Bitcoin Vaults,借出稳定币,底层资产不跨桥、不包装、不托管。这一步把保管风险压到协议层面,私钥不交出,Bitcoin 脚本说了算。$BABY 后半段却换了一条责任链:借出的稳定币投进 GoMining 的代币化矿业基金,基金有独立托管、估值和管理费,矿机运行好坏、电力成本波动、BTC 产出效率,全由链下结构承担。官方说的是"计划最高激活 1,000 BTC",注意是计划容量,不是实存数据。 所以 TBV 干掉的只是"BTC 会不会被项目方卷走",它没承诺"借出的钱一定能跑赢利息"。如果矿机收益覆盖不了借款成本,债务恶化,清算照样会来——BTC 虽在 TBV 里没丢,仓位可能因资不抵债被卖掉。$BTC 我觉得这个设计本身没问题,甚至很诚实:抵押层自托管,收益层交给专业运营商,权责边界划得清楚。真正让我担心的是前端界面会不会把这两层折叠成一句"BTC 原生挖矿收益",让用户产生一种"底层安全了,上面也安全"的错觉。 后续我不会盯着那 1,000 BTC 的上限看,我会去跟这几个数字:真实借款规模、基金费率结构、BTC 奖励的净回报、以及第一笔清算记录什么时候出现。BABY 能不能从这条链路里收到手续费,也得等用户真正开始借钱、开始付息之后才算数。$ETH 如果只能选一层最不放心的,你押哪边? A. TBV 脚本执行有没有漏洞 B. 矿业基金的收益能不能覆盖融资成本 C. 前端会不会把两层风险包装成一句话
看到 Babylon 与 GoMining 的合作公告,我脑海里先跳出信贷审批的铁律:抵押品归抵押品,用途归用途,两笔账不能混着看。#baby

很多人被"原生 BTC 质押挖矿"吸引,以为 BTC 锁在 TBV 里、收益就自动流回来。@BabylonLabs_io 但把方案拆开读,你会发现这是风险切割,不是风险消灭。

前半段是 Babylon 的领地:用户把 BTC 押进 Trustless Bitcoin Vaults,借出稳定币,底层资产不跨桥、不包装、不托管。这一步把保管风险压到协议层面,私钥不交出,Bitcoin 脚本说了算。$BABY

后半段却换了一条责任链:借出的稳定币投进 GoMining 的代币化矿业基金,基金有独立托管、估值和管理费,矿机运行好坏、电力成本波动、BTC 产出效率,全由链下结构承担。官方说的是"计划最高激活 1,000 BTC",注意是计划容量,不是实存数据。

所以 TBV 干掉的只是"BTC 会不会被项目方卷走",它没承诺"借出的钱一定能跑赢利息"。如果矿机收益覆盖不了借款成本,债务恶化,清算照样会来——BTC 虽在 TBV 里没丢,仓位可能因资不抵债被卖掉。$BTC

我觉得这个设计本身没问题,甚至很诚实:抵押层自托管,收益层交给专业运营商,权责边界划得清楚。真正让我担心的是前端界面会不会把这两层折叠成一句"BTC 原生挖矿收益",让用户产生一种"底层安全了,上面也安全"的错觉。

后续我不会盯着那 1,000 BTC 的上限看,我会去跟这几个数字:真实借款规模、基金费率结构、BTC 奖励的净回报、以及第一笔清算记录什么时候出现。BABY 能不能从这条链路里收到手续费,也得等用户真正开始借钱、开始付息之后才算数。$ETH

如果只能选一层最不放心的,你押哪边?

A. TBV 脚本执行有没有漏洞

B. 矿业基金的收益能不能覆盖融资成本

C. 前端会不会把两层风险包装成一句话
Passei dois dias comparando o white paper EOTS da Babylon com o Bitcoin Script e descobri um fato encoberto pelos números de rendimento: a comunidade fala de Babylon calculando principalmente a quantidade de bloqueio e o APY, mas “travar BTC” nunca foi um problema — o OP_CHECKLOCKTIMEVERIFY já roda na mainnet há mais de uma década.@babylonlabs_io O verdadeiro gargalo é: como implementar “confisco econômico” no BTC nativo, usando Bitcoin que não tem contratos inteligentes. Esse dilema é brutal.#baby Seguir com wBTC ou uma ponte multisig deixa o desenvolvimento mais simples, mas adiciona uma camada de confiança. A Babylon escolheu o caminho mais difícil: não tocar em custódia e forçar um mecanismo de confisco dentro das limitações do UTXO. A solução é Taproot + EOTS. O EOTS transforma “punição” de “responsabilização após o fato” em “autoaniquilação durante a execução” — assim que o Finality Provider faz um duplo assinatura, a criptografia garante exposição da chave privada; qualquer pessoa pode retirar diretamente o BTC caucionado. Não precisa de uma lógica de contrato, nem de arbitragem de terceiros. É também por isso que tantos projetos PoS antes não conseguiram “encaixar” a segurança do BTC — sem Slashing, a segurança emprestada é como construir sobre nada. Depois que a Babylon conecta essa perna, pela primeira vez o BTC deixa de ser um ativo de garantia silencioso e passa a ser um serviço de segurança vendável diretamente.$BABY Se funcionar, o Bitcoin deixa de ser apenas um SoV parado em carteiras resistindo à inflação e se torna uma capital social consenso com preço e negociável. A economia da segurança de toda a indústria será reescrita. Mas eu ainda tenho um ponto cego: o pré-requisito do EOTS é que os dois sinais conflitantes sejam transmitidos para a cadeia. Se um FP gerar duas assinaturas conflitantes quando estiver offline, mas transmitir apenas uma e guardar a outra como moeda de troca, esse mecanismo matemático de autoaniquilação ainda consegue impedi-lo? Vamos conversar na seção de comentários da Praça da Binance.$BTC $ETH
Passei dois dias comparando o white paper EOTS da Babylon com o Bitcoin Script e descobri um fato encoberto pelos números de rendimento: a comunidade fala de Babylon calculando principalmente a quantidade de bloqueio e o APY, mas “travar BTC” nunca foi um problema — o OP_CHECKLOCKTIMEVERIFY já roda na mainnet há mais de uma década.@BabylonLabs_io

O verdadeiro gargalo é: como implementar “confisco econômico” no BTC nativo, usando Bitcoin que não tem contratos inteligentes.

Esse dilema é brutal.#baby Seguir com wBTC ou uma ponte multisig deixa o desenvolvimento mais simples, mas adiciona uma camada de confiança. A Babylon escolheu o caminho mais difícil: não tocar em custódia e forçar um mecanismo de confisco dentro das limitações do UTXO.

A solução é Taproot + EOTS. O EOTS transforma “punição” de “responsabilização após o fato” em “autoaniquilação durante a execução” — assim que o Finality Provider faz um duplo assinatura, a criptografia garante exposição da chave privada; qualquer pessoa pode retirar diretamente o BTC caucionado. Não precisa de uma lógica de contrato, nem de arbitragem de terceiros.

É também por isso que tantos projetos PoS antes não conseguiram “encaixar” a segurança do BTC — sem Slashing, a segurança emprestada é como construir sobre nada. Depois que a Babylon conecta essa perna, pela primeira vez o BTC deixa de ser um ativo de garantia silencioso e passa a ser um serviço de segurança vendável diretamente.$BABY

Se funcionar, o Bitcoin deixa de ser apenas um SoV parado em carteiras resistindo à inflação e se torna uma capital social consenso com preço e negociável. A economia da segurança de toda a indústria será reescrita.

Mas eu ainda tenho um ponto cego: o pré-requisito do EOTS é que os dois sinais conflitantes sejam transmitidos para a cadeia. Se um FP gerar duas assinaturas conflitantes quando estiver offline, mas transmitir apenas uma e guardar a outra como moeda de troca, esse mecanismo matemático de autoaniquilação ainda consegue impedi-lo?

Vamos conversar na seção de comentários da Praça da Binance.$BTC $ETH
BitVM3 consegue reduzir as assertions on-chain para cerca de 56KB — um número bonito, sim. Mas a conta por trás desses “números bonitos” nunca desaparece por conta própria. #baby Quando eu reviso novamente os detalhes técnicos do BitVM3, notei uma zona cinzenta na narrativa: a documentação oficial enfatiza repetidamente que “o custo on-chain exige apenas algumas centenas de bytes” e que “a eficiência melhora mais de mil vezes”. Esses números não estão errados, mas o público tende a interpretar “tornar o on-chain mais barato” como “todo o sistema ficou mais leve”. Só que on-chain e off-chain são duas curvas de custo independentes; ao misturá-las, a avaliação sai distorcida. Do lado on-chain, de fato o BitVM3 reduz a assertion para cerca de 56KB. Na fase controversa, o fraud proof precisa apenas de alguns centenas de bytes. Em comparação com o BitVM2, que ia de 2 a 4MB, a economia é real. $BABY Mas, quando todo mundo foca nessas poucas centenas de bytes, quase ninguém pergunta: para onde foi o enorme volume de dados gerado pelo garbled circuit? A resposta é: ele foi empurrado para o off-chain. De acordo com a escala do circuito, uma única garbled table pode chegar a mais de 40GB. O operator e o challenger precisam baixar, armazenar e executar cálculos por bilhões de vezes. O on-chain ficou mais barato — não porque esses encargos “evaporaram”, mas porque foram apenas transferidos: saíram do navegador do bloco e foram para o disco local e os processadores dos participantes. Essa diferença de percepção é crucial. “Eficiente”, “lightweight” na literatura técnica descrevem apenas o espaço ocupado na cadeia. Mas quando o mercado ouve “eficiência”, a intuição é “a barreira diminuiu e mais gente pode rodar nós”. Na prática, ocorre o contrário: depois que o volume de computação offline aumenta, os participantes com capacidade de assumir o papel de operator ou challenger se tornam ainda mais raros. Traduzir diretamente “custo on-chain baixo” como “sistema leve” é o truque de desinformação mais comum desse tipo de narrativa. Minha conclusão é: o TBV materializa o ganho de eficiência de espaço on-chain via BitVM3, mas ao mesmo tempo transfere o custo pesado de computação e armazenamento para o off-chain — para o operator e o challenger. Essas duas contas precisam ser calculadas separadamente para avaliar de forma justa o custo real do modelo de segurança inteiro de @babylonlabs_io . Afinal, a robustez do sistema não depende apenas daqueles poucos bytes on-chain; depende também de quantas pessoas realmente estão dispostas e têm capacidade de assumir a responsabilidade de mais de 40GB no off-chain. Você acha que o argumento de “extremamente lightweight on-chain” vai fazer o mercado ignorar a verdadeira barreira do TBV no off-chain? $BTC $ETH
BitVM3 consegue reduzir as assertions on-chain para cerca de 56KB — um número bonito, sim. Mas a conta por trás desses “números bonitos” nunca desaparece por conta própria.

#baby Quando eu reviso novamente os detalhes técnicos do BitVM3, notei uma zona cinzenta na narrativa: a documentação oficial enfatiza repetidamente que “o custo on-chain exige apenas algumas centenas de bytes” e que “a eficiência melhora mais de mil vezes”. Esses números não estão errados, mas o público tende a interpretar “tornar o on-chain mais barato” como “todo o sistema ficou mais leve”. Só que on-chain e off-chain são duas curvas de custo independentes; ao misturá-las, a avaliação sai distorcida.

Do lado on-chain, de fato o BitVM3 reduz a assertion para cerca de 56KB. Na fase controversa, o fraud proof precisa apenas de alguns centenas de bytes. Em comparação com o BitVM2, que ia de 2 a 4MB, a economia é real. $BABY Mas, quando todo mundo foca nessas poucas centenas de bytes, quase ninguém pergunta: para onde foi o enorme volume de dados gerado pelo garbled circuit?

A resposta é: ele foi empurrado para o off-chain. De acordo com a escala do circuito, uma única garbled table pode chegar a mais de 40GB. O operator e o challenger precisam baixar, armazenar e executar cálculos por bilhões de vezes. O on-chain ficou mais barato — não porque esses encargos “evaporaram”, mas porque foram apenas transferidos: saíram do navegador do bloco e foram para o disco local e os processadores dos participantes.

Essa diferença de percepção é crucial. “Eficiente”, “lightweight” na literatura técnica descrevem apenas o espaço ocupado na cadeia. Mas quando o mercado ouve “eficiência”, a intuição é “a barreira diminuiu e mais gente pode rodar nós”. Na prática, ocorre o contrário: depois que o volume de computação offline aumenta, os participantes com capacidade de assumir o papel de operator ou challenger se tornam ainda mais raros. Traduzir diretamente “custo on-chain baixo” como “sistema leve” é o truque de desinformação mais comum desse tipo de narrativa.

Minha conclusão é: o TBV materializa o ganho de eficiência de espaço on-chain via BitVM3, mas ao mesmo tempo transfere o custo pesado de computação e armazenamento para o off-chain — para o operator e o challenger. Essas duas contas precisam ser calculadas separadamente para avaliar de forma justa o custo real do modelo de segurança inteiro de @BabylonLabs_io . Afinal, a robustez do sistema não depende apenas daqueles poucos bytes on-chain; depende também de quantas pessoas realmente estão dispostas e têm capacidade de assumir a responsabilidade de mais de 40GB no off-chain.

Você acha que o argumento de “extremamente lightweight on-chain” vai fazer o mercado ignorar a verdadeira barreira do TBV no off-chain? $BTC $ETH
Eu reli um modelo econômico na noite passada e um número me travou—não era uma data para desbloquear no calendário, e sim aquele coeficiente aparentemente aleatório na taxa de co-staking. A versão que circula na comunidade é simples: #baby é o ingresso do FP; atingindo a quantidade de staking, dá para aceitar pedidos. Passei a noite sobrepondo a curva de liberação com a quantidade de BTC travada on-chain e percebi que o que realmente importa não é “quantas moedas serão liberadas no próximo mês”, e sim “quantas dessas moedas foram reestacadas de volta”. O intervalo entre esses dois valores é a verdadeira simulação de estresse no modelo de segurança TBV. Muitos tratam $BABY como voto de governança ou como critério de elegibilidade. Mas, ao comparar com as regras de co-staking, cada vez mais parece que isso é uma camada de amortecimento colateral. O Finality Provider (na cadeia hospedeira) precisa travar BABY para participar. À primeira vista, parece que o projeto está “criando demanda de compra”; na prática, está preenchendo uma lacuna que um script nativo do Bitcoin não consegue resolver: a rede Bitcoin consegue verificar se um UTXO pode ser gasto, mas não entende se o FP na cadeia hospedeira assinou duplamente. Essa decisão só pode ser feita pelo consenso de outra cadeia, e a punição resultante desse consenso precisa de um ativo econômico quantificável para ser executada. BABY é exatamente esse ativo. $BTC O TBV tranca o BTC em um UTXO nativo, usando scripts para guardar o principal; ao mesmo tempo, exige que o FP estake BABY na cadeia hospedeira, como alvo de slash quando houver malícia. Durante todo o processo, a rede Bitcoin ainda não sabe o que acontece na outra cadeia, mas pode, ao receber uma prova válida, decidir liberar ou reverter pelo Spend Path pré-definido. O que o estaking de BABY faz é traduzir a “decisão de punição do consenso da cadeia hospedeira” em “perda real em dinheiro no bolso do FP”. O que realmente fica travado nunca é o preço do BABY, e sim o principal em BTC que não se deteriora por mudanças no estado da cadeia hospedeira; e o que realmente fica estacado não é o token BABY em si, mas o endosso econômico de confiança de toda a rede na atuação do FP. $ETH No fim, quando salvei o print da sobreposição, não apaguei a primeira versão com o eixo marcado errado. Agora, ao olhar de novo, o maior valor não é prever alta ou queda, e sim me lembrar: a mudança real trazida pelo BABY não foi oferecer ao mercado um novo ativo especulativo, mas sim dar ao primeiro limite de segurança nativo do Bitcoin uma camada verificável de responsabilização econômica. Esse também é o motivo de eu continuar acompanhando @babylonlabs_io
Eu reli um modelo econômico na noite passada e um número me travou—não era uma data para desbloquear no calendário, e sim aquele coeficiente aparentemente aleatório na taxa de co-staking.
A versão que circula na comunidade é simples: #baby é o ingresso do FP; atingindo a quantidade de staking, dá para aceitar pedidos. Passei a noite sobrepondo a curva de liberação com a quantidade de BTC travada on-chain e percebi que o que realmente importa não é “quantas moedas serão liberadas no próximo mês”, e sim “quantas dessas moedas foram reestacadas de volta”. O intervalo entre esses dois valores é a verdadeira simulação de estresse no modelo de segurança TBV.
Muitos tratam $BABY como voto de governança ou como critério de elegibilidade. Mas, ao comparar com as regras de co-staking, cada vez mais parece que isso é uma camada de amortecimento colateral. O Finality Provider (na cadeia hospedeira) precisa travar BABY para participar. À primeira vista, parece que o projeto está “criando demanda de compra”; na prática, está preenchendo uma lacuna que um script nativo do Bitcoin não consegue resolver: a rede Bitcoin consegue verificar se um UTXO pode ser gasto, mas não entende se o FP na cadeia hospedeira assinou duplamente. Essa decisão só pode ser feita pelo consenso de outra cadeia, e a punição resultante desse consenso precisa de um ativo econômico quantificável para ser executada. BABY é exatamente esse ativo.
$BTC
O TBV tranca o BTC em um UTXO nativo, usando scripts para guardar o principal; ao mesmo tempo, exige que o FP estake BABY na cadeia hospedeira, como alvo de slash quando houver malícia. Durante todo o processo, a rede Bitcoin ainda não sabe o que acontece na outra cadeia, mas pode, ao receber uma prova válida, decidir liberar ou reverter pelo Spend Path pré-definido. O que o estaking de BABY faz é traduzir a “decisão de punição do consenso da cadeia hospedeira” em “perda real em dinheiro no bolso do FP”. O que realmente fica travado nunca é o preço do BABY, e sim o principal em BTC que não se deteriora por mudanças no estado da cadeia hospedeira; e o que realmente fica estacado não é o token BABY em si, mas o endosso econômico de confiança de toda a rede na atuação do FP.
$ETH
No fim, quando salvei o print da sobreposição, não apaguei a primeira versão com o eixo marcado errado. Agora, ao olhar de novo, o maior valor não é prever alta ou queda, e sim me lembrar: a mudança real trazida pelo BABY não foi oferecer ao mercado um novo ativo especulativo, mas sim dar ao primeiro limite de segurança nativo do Bitcoin uma camada verificável de responsabilização econômica. Esse também é o motivo de eu continuar acompanhando @BabylonLabs_io
前天跟一位做Cosmos节点的朋友聊到个反直觉的数据:每月10号@babylonlabs_io 解锁后,链上质押合约的流入量反而比前两周日均值高出近四成。解锁被解读为供给冲击,但数据走向是反的。 翻@BabylonLabs_io的代币分配说明,BABY的经济模型只占很小篇幅,项目方把绝大多数笔墨留给了BTC质押和EOTS。这种篇幅分配就在说话:#baby 的核心叙事是"借用Bitcoin安全",BABY只是激励载体。但如果载体价格不稳,核心叙事的可持续性就会动摇。 BTC锁在Bitcoin链上解决"安全从哪来",BABY发给质押者和FP解决"谁持续买单"。EOTS是硬约束,BABY收益曲线是软约束,两根轴必须同时转。 数据面:总供应100亿,每月10日释放约1.36亿枚。Phase 1跑了一年多,FP破250,TVL最高70亿,目前稳在30亿以上。David Tse带队,Paradigm 7000万领投,a16z跟1500万。 纸面自洽不等于无风险。每月1.36亿枚进入市场,如果质押者胃纳不够,多余供给会流向二级市场。更隐蔽的是:FP收益与委托量挂钩,而委托量取决于BABY计价的APR。币价下行时,APR美元价值缩水,大仓位BTC质押者会不会重新算账——留在Babylon赚缩水的BABY,还是撤出来等更好机会?EOTS能惩罚作恶,惩罚不了"理性退出"。$BTC 最省事的判断是"解锁压力大"或"长期看好"。但真正值得盯的是三个信号:解锁后48小时内,质押合约净流入与交易所净流入的比值是否在扩大;FP委托量中新地址占比是否在上升;TVL增速放缓时,BTC质押者平均锁仓周期有没有缩短。这些链上行为比白皮书上的分配表更能回答:$BABY 是被当作"安全机器的燃料"消耗,还是仅在解锁日历上循环流转。$ETH
前天跟一位做Cosmos节点的朋友聊到个反直觉的数据:每月10号@BabylonLabs_io 解锁后,链上质押合约的流入量反而比前两周日均值高出近四成。解锁被解读为供给冲击,但数据走向是反的。

翻@BabylonLabs_io的代币分配说明,BABY的经济模型只占很小篇幅,项目方把绝大多数笔墨留给了BTC质押和EOTS。这种篇幅分配就在说话:#baby 的核心叙事是"借用Bitcoin安全",BABY只是激励载体。但如果载体价格不稳,核心叙事的可持续性就会动摇。

BTC锁在Bitcoin链上解决"安全从哪来",BABY发给质押者和FP解决"谁持续买单"。EOTS是硬约束,BABY收益曲线是软约束,两根轴必须同时转。

数据面:总供应100亿,每月10日释放约1.36亿枚。Phase 1跑了一年多,FP破250,TVL最高70亿,目前稳在30亿以上。David Tse带队,Paradigm 7000万领投,a16z跟1500万。

纸面自洽不等于无风险。每月1.36亿枚进入市场,如果质押者胃纳不够,多余供给会流向二级市场。更隐蔽的是:FP收益与委托量挂钩,而委托量取决于BABY计价的APR。币价下行时,APR美元价值缩水,大仓位BTC质押者会不会重新算账——留在Babylon赚缩水的BABY,还是撤出来等更好机会?EOTS能惩罚作恶,惩罚不了"理性退出"。$BTC

最省事的判断是"解锁压力大"或"长期看好"。但真正值得盯的是三个信号:解锁后48小时内,质押合约净流入与交易所净流入的比值是否在扩大;FP委托量中新地址占比是否在上升;TVL增速放缓时,BTC质押者平均锁仓周期有没有缩短。这些链上行为比白皮书上的分配表更能回答:$BABY 是被当作"安全机器的燃料"消耗,还是仅在解锁日历上循环流转。$ETH
Sempre que abro a DefiLlama e vejo a coluna da Babylon com US$ 3,36 bilhões, eu paro por dois segundos. Esse número fica em “Staking” e tem uma cor bem bonita, mas ele mede a oferta — não as transações. $BABY Este TVL é a quantidade total de BTC travada no Bitcoin Staking Protocol; na essência, é o “orçamento de segurança” que a Babylon disponibiliza ao mercado. $BTC Isso mostra que há muito BTC disposto a se tornar provedor de segurança, mas não indica quanto de fato as chains de consumo estão comprando essa função — e muito menos representa receita do protocolo. Os motivos das duas partes são diferentes. Para os stakers, é questão de self-custody e recompensas; para as chains de consumo, é segurança econômica — mas elas precisam fechar a conta: a própria inflação de tokens ou a receita do protocolo consegue cobrir o custo de comprar segurança em BTC. Tratar o tamanho do staking como “capacidade de faturamento” é como usar a metragem de um data center da Amazon para calcular a receita anual da AWS: os ativos são pesados, mas ainda não houve fluxo de caixa. Atualmente, o número de chains de consumo conectadas à Babylon é limitado, e a maioria ainda está na fase de validação. O Finality Provider até está online, mas a atividade delegada das chains de consumo, as taxas reais de validação geradas e quantas voltam para o ecossistema BABY ainda estão sendo observadas no começo. @babylonlabs_io A lista de integrações continua aumentando, mas existe um caminho do “encaixe técnico” até a “atividade econômica”. Algumas chains se interessaram pela narrativa de segurança do BTC, mas talvez não tenham intenção de pagar continuamente. Parcerias podem ser tratadas como hipótese de demanda; não dá para registrar como receita antecipadamente. Eu vou dividir em duas tabelas: a primeira é a oferta de segurança — tamanho do staking em BTC, número de Finality Providers ativos e distribuição das delegações; a segunda é a demanda de segurança — quantidade de chains de consumo conectadas, necessidade ativa de validação, taxas efetivamente pagas e proporções de distribuição. A primeira já tem escala; a segunda ainda está sendo construída. $ETH Em torno de #baby , o ponto-chave não é continuar citando o “orçamento de segurança” de US$ 3,36 bilhões, e sim fazer a segunda tabela crescer. Só quando as chains de consumo estiverem dispostas a pagar continuamente pela segurança do BTC, e quando as taxas conseguirem retornar para o ecossistema BABY, é que isso não será apenas trocar a mesma base de BTC por outra forma de estatística.
Sempre que abro a DefiLlama e vejo a coluna da Babylon com US$ 3,36 bilhões, eu paro por dois segundos. Esse número fica em “Staking” e tem uma cor bem bonita, mas ele mede a oferta — não as transações. $BABY

Este TVL é a quantidade total de BTC travada no Bitcoin Staking Protocol; na essência, é o “orçamento de segurança” que a Babylon disponibiliza ao mercado. $BTC Isso mostra que há muito BTC disposto a se tornar provedor de segurança, mas não indica quanto de fato as chains de consumo estão comprando essa função — e muito menos representa receita do protocolo.

Os motivos das duas partes são diferentes. Para os stakers, é questão de self-custody e recompensas; para as chains de consumo, é segurança econômica — mas elas precisam fechar a conta: a própria inflação de tokens ou a receita do protocolo consegue cobrir o custo de comprar segurança em BTC. Tratar o tamanho do staking como “capacidade de faturamento” é como usar a metragem de um data center da Amazon para calcular a receita anual da AWS: os ativos são pesados, mas ainda não houve fluxo de caixa.

Atualmente, o número de chains de consumo conectadas à Babylon é limitado, e a maioria ainda está na fase de validação. O Finality Provider até está online, mas a atividade delegada das chains de consumo, as taxas reais de validação geradas e quantas voltam para o ecossistema BABY ainda estão sendo observadas no começo.

@BabylonLabs_io A lista de integrações continua aumentando, mas existe um caminho do “encaixe técnico” até a “atividade econômica”. Algumas chains se interessaram pela narrativa de segurança do BTC, mas talvez não tenham intenção de pagar continuamente. Parcerias podem ser tratadas como hipótese de demanda; não dá para registrar como receita antecipadamente.

Eu vou dividir em duas tabelas: a primeira é a oferta de segurança — tamanho do staking em BTC, número de Finality Providers ativos e distribuição das delegações; a segunda é a demanda de segurança — quantidade de chains de consumo conectadas, necessidade ativa de validação, taxas efetivamente pagas e proporções de distribuição. A primeira já tem escala; a segunda ainda está sendo construída. $ETH

Em torno de #baby , o ponto-chave não é continuar citando o “orçamento de segurança” de US$ 3,36 bilhões, e sim fazer a segunda tabela crescer. Só quando as chains de consumo estiverem dispostas a pagar continuamente pela segurança do BTC, e quando as taxas conseguirem retornar para o ecossistema BABY, é que isso não será apenas trocar a mesma base de BTC por outra forma de estatística.
O Chen fez no mês passado um plano anual de uma academia. O contrato dizia: "Sem treinador; o próprio associado solicita o cancelamento da turma". Ele ainda se gabou: "Nem precisa ficar olhando a cara do treinador." #baby Ontem, ele realmente foi lá e pediu o reembolso. A recepção lhe passou uma lista: número do contrato original, registros de check-in de cada aula, formulário com assinatura do treinador — além de você mesmo fazer login no sistema e enviar o pedido. Só é válido se ninguém indeferir em 72 horas. O Chen revirou o álbum do celular e só achou um print do pagamento de meio ano atrás. Ele me mandou um áudio: "Isso nem é cancelamento autônomo. É enfiar o trabalho da recepção e do financeiro tudo em cima de mim." Ao ouvir isso, pensei no Babylon Trustless Bitcoin Vault. O BTC não saiu da rede principal; o script pré-assinado dá ao usuário, teoricamente, um direito completo de resgate, um direito de contestação e um direito de retirada. Mas a tradução de "sem precisar confiar em terceiros" vira: "você mesmo é o terceiro". Os pares de chaves criados ao criar o vault $BABY , as provas de estado, os parâmetros de time lock, os comprovantes de isolamento de UTXO — tudo isso não sincroniza automaticamente com a carteira. Muda o navegador, perde o celular: na hora, o resgate autônomo teórico vira "precisa pedir ao administrador para abrir o back-end". E, por enquanto, a porta pública ainda é apenas ambiente de teste. Mesmo que os dados da testnet pareçam perfeitos @babylonlabs_io , quanto BTC foi travado são apenas métricas de laboratório. O que eu realmente quero ver não é "quantos Vaults foram criados com sucesso", e sim "em estado de exceção, quantos usuários conseguem fazer o resgate integral de forma independente e voltar com segurança para a rede principal, sem ticket no Discord e sem administrador do Telegram". A prova mais dura do self-custody nunca é quem está com a chave privada quando o dinheiro entrou. É às três da manhã, com falha no sistema, com o navegador travando, e quando ninguém responde no grupo — você consegue, sozinho, pegar o BTC de volta sem pedir favor. $BTC Esse é o custo real do Trustless. A plataforma transfere a confiança de "nós confiamos neles" para "nós confiamos que não vamos cometer erros bobos". Para o velho que já está acostumado a fazer backup de três frases-semente, é uma boa. Mas para o iniciante que só sabe "clicar uma vez para sacar", esse mecanismo é mais parecido com "um contrato salvo na nuvem" — no dia a dia você acha que dá para baixar a qualquer momento; só quando precisa usar é que descobre que a senha está em outro computador já formatado. $ETH Apareçam na seção de comentários: vocês testaram o fluxo de saída do TBV na prática algumas vezes?
O Chen fez no mês passado um plano anual de uma academia. O contrato dizia: "Sem treinador; o próprio associado solicita o cancelamento da turma". Ele ainda se gabou: "Nem precisa ficar olhando a cara do treinador." #baby

Ontem, ele realmente foi lá e pediu o reembolso. A recepção lhe passou uma lista: número do contrato original, registros de check-in de cada aula, formulário com assinatura do treinador — além de você mesmo fazer login no sistema e enviar o pedido. Só é válido se ninguém indeferir em 72 horas. O Chen revirou o álbum do celular e só achou um print do pagamento de meio ano atrás. Ele me mandou um áudio: "Isso nem é cancelamento autônomo. É enfiar o trabalho da recepção e do financeiro tudo em cima de mim."

Ao ouvir isso, pensei no Babylon Trustless Bitcoin Vault.

O BTC não saiu da rede principal; o script pré-assinado dá ao usuário, teoricamente, um direito completo de resgate, um direito de contestação e um direito de retirada. Mas a tradução de "sem precisar confiar em terceiros" vira: "você mesmo é o terceiro". Os pares de chaves criados ao criar o vault $BABY , as provas de estado, os parâmetros de time lock, os comprovantes de isolamento de UTXO — tudo isso não sincroniza automaticamente com a carteira. Muda o navegador, perde o celular: na hora, o resgate autônomo teórico vira "precisa pedir ao administrador para abrir o back-end".

E, por enquanto, a porta pública ainda é apenas ambiente de teste. Mesmo que os dados da testnet pareçam perfeitos @BabylonLabs_io , quanto BTC foi travado são apenas métricas de laboratório. O que eu realmente quero ver não é "quantos Vaults foram criados com sucesso", e sim "em estado de exceção, quantos usuários conseguem fazer o resgate integral de forma independente e voltar com segurança para a rede principal, sem ticket no Discord e sem administrador do Telegram".

A prova mais dura do self-custody nunca é quem está com a chave privada quando o dinheiro entrou. É às três da manhã, com falha no sistema, com o navegador travando, e quando ninguém responde no grupo — você consegue, sozinho, pegar o BTC de volta sem pedir favor. $BTC

Esse é o custo real do Trustless. A plataforma transfere a confiança de "nós confiamos neles" para "nós confiamos que não vamos cometer erros bobos". Para o velho que já está acostumado a fazer backup de três frases-semente, é uma boa. Mas para o iniciante que só sabe "clicar uma vez para sacar", esse mecanismo é mais parecido com "um contrato salvo na nuvem" — no dia a dia você acha que dá para baixar a qualquer momento; só quando precisa usar é que descobre que a senha está em outro computador já formatado. $ETH

Apareçam na seção de comentários: vocês testaram o fluxo de saída do TBV na prática algumas vezes?
Traduzi uma leva de dados que deixaram a boca do velho investidor amarga: @babylonlabs_io trancou dezenas de bilhões de BTC nativo, mas nos últimos dois trimestres a cadeia POS que realmente usa BABY para liquidar o aluguel de segurança ainda não tem mais “gente” constante no meu bar de balcão. A linha de história de $BABY é o “aluguel” em forma de “moeda compartilhada” de um mercado de segurança — a cadeia POS quer alugar a sensação de segurança do Bitcoin, mas primeiro precisa desembolsar BABY. Eu rodei o fluxo da mainnet: o BitVM3 grava o estado de staking no livro-razão do Bitcoin; o BABE gera as provas de conhecimento zero e as envia para a cadeia POS; a matemática faz o trabalho de assinatura contratual — no lado do BTC, de fato, é bem sólido. Mas a ação de “pagar” travou. O tesouro da cadeia POS é majoritariamente estável ou tokens nativos; para pagar aluguel em BABY, precisa primeiro fazer swap na DEX, depois fazer a ponte cross-chain, e ainda absorver a volatilidade mensal de mais de cem milhões de unidades desbloqueadas. Fiz a conta para uma cadeia POS de porte médio: orçamento trimestral de segurança de trezentos mil dólares; usando BABY como liquidação, o custo com slippage + taxa cross-chain + erosão pelo preço do token explode para quatrocentos e cinquenta mil. Com pagamento direto em stablecoin, a planilha do CFO fica bem melhor. Resultado: o volume de staking em BTC só sobe, mas diante do “caixa” #baby está aquele frio constante. A receita do protocolo cresce, mas os canais estão desviando a compra de BABY. Você segura as moedas esperando “explosão de uso”, só que o que chega é: cadeias POS usando stablecoin como “atalho de porta dos fundos”. Agora eu seguro só um punhado de fichas como vigia. O BitVM3 levou a segurança no lado do BTC ao máximo, mas a fricção do BABY como “meio de pagamento” não ficou muito mais lisa do que transferências internacionais tradicionais. Antes de a abstração de cadeia comprimir “trocar moedas + cross-chain + pagamento” em uma ação de um clique, mesmo que o conto do “token de utilidade” fique mais sexy, não vence a frieza dos CFOs ao apertar a calculadora.$BTC Irmãos, vocês acham que o BABY precisa virar o “óleo subjacente de pagamento sem atrito” primeiro, ou a gente força escassez artificial com recompra do protocolo? Falem na área de comentários do Binance Square. [TL;DR] O BABY da Babylon é um token de aluguel de segurança compartilhada; o BitVM3 e o BABE resolvem o problema de confiança no lado do BTC, mas não resolvem a fricção no pagamento do BABY: slippage de troca, custos cross-chain e volatilidade no desbloqueio fazem as cadeias POS tenderem a liquidar com stablecoin. A narrativa de utilidade do BABY e a necessidade real de pagamento têm um desalinhamento estrutural; antes da abstração de cadeia reduzir a fricção, o caminho de captura de valor ainda não está claro.$ETH
Traduzi uma leva de dados que deixaram a boca do velho investidor amarga: @BabylonLabs_io trancou dezenas de bilhões de BTC nativo, mas nos últimos dois trimestres a cadeia POS que realmente usa BABY para liquidar o aluguel de segurança ainda não tem mais “gente” constante no meu bar de balcão.

A linha de história de $BABY é o “aluguel” em forma de “moeda compartilhada” de um mercado de segurança — a cadeia POS quer alugar a sensação de segurança do Bitcoin, mas primeiro precisa desembolsar BABY. Eu rodei o fluxo da mainnet: o BitVM3 grava o estado de staking no livro-razão do Bitcoin; o BABE gera as provas de conhecimento zero e as envia para a cadeia POS; a matemática faz o trabalho de assinatura contratual — no lado do BTC, de fato, é bem sólido.

Mas a ação de “pagar” travou. O tesouro da cadeia POS é majoritariamente estável ou tokens nativos; para pagar aluguel em BABY, precisa primeiro fazer swap na DEX, depois fazer a ponte cross-chain, e ainda absorver a volatilidade mensal de mais de cem milhões de unidades desbloqueadas. Fiz a conta para uma cadeia POS de porte médio: orçamento trimestral de segurança de trezentos mil dólares; usando BABY como liquidação, o custo com slippage + taxa cross-chain + erosão pelo preço do token explode para quatrocentos e cinquenta mil. Com pagamento direto em stablecoin, a planilha do CFO fica bem melhor.

Resultado: o volume de staking em BTC só sobe, mas diante do “caixa” #baby está aquele frio constante. A receita do protocolo cresce, mas os canais estão desviando a compra de BABY. Você segura as moedas esperando “explosão de uso”, só que o que chega é: cadeias POS usando stablecoin como “atalho de porta dos fundos”.

Agora eu seguro só um punhado de fichas como vigia. O BitVM3 levou a segurança no lado do BTC ao máximo, mas a fricção do BABY como “meio de pagamento” não ficou muito mais lisa do que transferências internacionais tradicionais. Antes de a abstração de cadeia comprimir “trocar moedas + cross-chain + pagamento” em uma ação de um clique, mesmo que o conto do “token de utilidade” fique mais sexy, não vence a frieza dos CFOs ao apertar a calculadora.$BTC

Irmãos, vocês acham que o BABY precisa virar o “óleo subjacente de pagamento sem atrito” primeiro, ou a gente força escassez artificial com recompra do protocolo? Falem na área de comentários do Binance Square.

[TL;DR]
O BABY da Babylon é um token de aluguel de segurança compartilhada; o BitVM3 e o BABE resolvem o problema de confiança no lado do BTC, mas não resolvem a fricção no pagamento do BABY: slippage de troca, custos cross-chain e volatilidade no desbloqueio fazem as cadeias POS tenderem a liquidar com stablecoin. A narrativa de utilidade do BABY e a necessidade real de pagamento têm um desalinhamento estrutural; antes da abstração de cadeia reduzir a fricção, o caminho de captura de valor ainda não está claro.$ETH
Os velhos amigos que fazem estratégia de DeFi à tarde vieram à minha casa só para tomar um café de cortesia. Quando ele deu uma olhada no meu monitor e viu o gráfico de BABY, soltou: "Você está cobrando aluguel à vontade, né? O senhorio desmonta metade da parede todo mês pra você — você já calculou isso?" Eu fiquei com a mão parada no mouse e fiquei atordoado por três segundos. O whitepaper do Babylon — @babylonlabs_io — dá ao BABY uma posição bem sensual: o BSN paga aluguel ao BABY com finalidade final (finality), oferecendo uma moeda forte de segurança compartilhada ao mercado. Parece que, quanto mais cadeias PoS houver e quanto maior for a demanda por staking, mais estável será a base essencial (needs) do BABY. Em teoria, não há nada de errado. Mas quando você abre a torneira e olha o fluxo, é outra história. Hoje, todo dia 10 de cada mês são liberados de forma fixa 136 milhões de tokens — $BABY . A equipe, investidores e fundos do ecossistema já estão enfileirados para liquidar. O BSN paga o aluguel comprando finalidade final, e sim, isso consome BABY. Só que a queima e o lock-up que isso gera, comparados com a quantidade de oferta despejada no mercado todo mês, é como colocar uma xícara para segurar uma cachoeira. Mais doloroso ainda é o staking dos usuários. Você trava BTC no Babylon, e as recompensas em BABY que você recebe parecem ter um APY alto — mas a velocidade de diluição do preço do token é mais rápida do que a sua própria acumulação por juros compostos. Você acha que está arrecadando aluguel de segurança, mas na prática está fornecendo liquidez para o fluxo de tokens que está sendo desbloqueado. Quanto mais bem-sucedido o Babylon, mais BSNs entram e, teoricamente, maior será a demanda por BABY — mas não se esqueça de que o time ainda segura cotas de desbloqueio para os próximos anos. A curva de demanda sobe, e a curva de oferta literalmente acelera como foguete. O amigo, com o copo de café, deu o golpe final: "Isso é o quê de segurança compartilhada? É segurança compartilhada com pressão de venda por desbloqueio. O aluguel que o BSN paga nem dá pra pagar as taxas do imóvel do lote que será desbloqueado." Depois que ele foi embora, eu refiz a leitura dos dados de circulação do #baby e fiquei olhando o calendário de desbloqueio por dez minutos. A criptografia subjacente pode ser até elegante. Mas se a tokenomics for uma bomba centrífuga de mão única, o BABY não é uma moeda de aluguel do mercado seguro — é um imposto de liquidez de todo o ecossistema. Os stakers acham que estão participando da segurança compartilhada com BTC, mas na verdade estão usando a liquidez travada para comprar um canal de saída para os detentores de tokens do começo. $BTC Por mais sólida que seja a base, ela não aguenta a parede estrutural sendo desmontada lá em cima todo mês. $ETH
Os velhos amigos que fazem estratégia de DeFi à tarde vieram à minha casa só para tomar um café de cortesia. Quando ele deu uma olhada no meu monitor e viu o gráfico de BABY, soltou: "Você está cobrando aluguel à vontade, né? O senhorio desmonta metade da parede todo mês pra você — você já calculou isso?"

Eu fiquei com a mão parada no mouse e fiquei atordoado por três segundos.

O whitepaper do Babylon — @BabylonLabs_io — dá ao BABY uma posição bem sensual: o BSN paga aluguel ao BABY com finalidade final (finality), oferecendo uma moeda forte de segurança compartilhada ao mercado. Parece que, quanto mais cadeias PoS houver e quanto maior for a demanda por staking, mais estável será a base essencial (needs) do BABY. Em teoria, não há nada de errado.

Mas quando você abre a torneira e olha o fluxo, é outra história.

Hoje, todo dia 10 de cada mês são liberados de forma fixa 136 milhões de tokens — $BABY . A equipe, investidores e fundos do ecossistema já estão enfileirados para liquidar. O BSN paga o aluguel comprando finalidade final, e sim, isso consome BABY. Só que a queima e o lock-up que isso gera, comparados com a quantidade de oferta despejada no mercado todo mês, é como colocar uma xícara para segurar uma cachoeira.

Mais doloroso ainda é o staking dos usuários. Você trava BTC no Babylon, e as recompensas em BABY que você recebe parecem ter um APY alto — mas a velocidade de diluição do preço do token é mais rápida do que a sua própria acumulação por juros compostos. Você acha que está arrecadando aluguel de segurança, mas na prática está fornecendo liquidez para o fluxo de tokens que está sendo desbloqueado.

Quanto mais bem-sucedido o Babylon, mais BSNs entram e, teoricamente, maior será a demanda por BABY — mas não se esqueça de que o time ainda segura cotas de desbloqueio para os próximos anos. A curva de demanda sobe, e a curva de oferta literalmente acelera como foguete.

O amigo, com o copo de café, deu o golpe final: "Isso é o quê de segurança compartilhada? É segurança compartilhada com pressão de venda por desbloqueio. O aluguel que o BSN paga nem dá pra pagar as taxas do imóvel do lote que será desbloqueado."

Depois que ele foi embora, eu refiz a leitura dos dados de circulação do #baby e fiquei olhando o calendário de desbloqueio por dez minutos.

A criptografia subjacente pode ser até elegante. Mas se a tokenomics for uma bomba centrífuga de mão única, o BABY não é uma moeda de aluguel do mercado seguro — é um imposto de liquidez de todo o ecossistema. Os stakers acham que estão participando da segurança compartilhada com BTC, mas na verdade estão usando a liquidez travada para comprar um canal de saída para os detentores de tokens do começo. $BTC

Por mais sólida que seja a base, ela não aguenta a parede estrutural sendo desmontada lá em cima todo mês. $ETH
Ver tradução
这几年在链上翻合约翻到眼花,我慢慢练出一个本能——不太关心某个协议的TVL堆得多壮观,反而先看那笔锁仓背后,有没有人真正在为"安全"付账。见过太多"质押即治理"最后沦为"质押即人质",根子从来不是私钥泄露,是经济模型里埋着"用未来通胀填今天窟窿"的暗门,这扇暗门只要推开一次,所有锁仓都变锁命。 啃 Babylon 的 BTC 安全租赁协议时,让我刹住车的正是这一层。@babylonlabs_io 它不是给比特币生态多装一个收益水龙头,而是在搭一座"安全按次结算"的收费站。PoS链想借BTC的共识信用给自己撑场子?可以,但得按区块轮次交过路费,验证者的算力背书、质押者的机会成本,都得用可流通资产实打实结清,不能拿自家代币的远期承诺充数。BABY在这里的定位,更像收费站里的计费系统——不是让你囤通行票炒溢价的,是用来确认"哪辆车走了哪段路、该扣多少通行费"的结算锚。链上过去一直缺这道"安全服务"的明码标价,Babylon想补的不是让BTC自动下蛋的幻觉,是给比特币的影响力一个不被赖账的定价标尺。 我也不会把它吹成万能药。PoS链自己的原生代币跌成了废纸,收费站自然无车可收;$BABY 如果沦为验证者空手套白狼的提款码,计费系统就成了摊派工具。真正要盯的不是锁仓峰值多耀眼,是大规模资金沉淀后,这套结算机制还能不能让"安全"保持服务属性,而不是退化成定向输血。 我认为,#baby 的终局价值,取决于多少条链愿意持续用真实购买力租赁BTC的安全性,而不是靠印钞机变相逃单。以后链越多,我越在意的不是比特币能当多少条链的保镖,是谁能证明这份安保合同,甲方每次都按约付款,而不是签了一堆永远兑现不了的空头支票。$BTC $ETH
这几年在链上翻合约翻到眼花,我慢慢练出一个本能——不太关心某个协议的TVL堆得多壮观,反而先看那笔锁仓背后,有没有人真正在为"安全"付账。见过太多"质押即治理"最后沦为"质押即人质",根子从来不是私钥泄露,是经济模型里埋着"用未来通胀填今天窟窿"的暗门,这扇暗门只要推开一次,所有锁仓都变锁命。

啃 Babylon 的 BTC 安全租赁协议时,让我刹住车的正是这一层。@BabylonLabs_io 它不是给比特币生态多装一个收益水龙头,而是在搭一座"安全按次结算"的收费站。PoS链想借BTC的共识信用给自己撑场子?可以,但得按区块轮次交过路费,验证者的算力背书、质押者的机会成本,都得用可流通资产实打实结清,不能拿自家代币的远期承诺充数。BABY在这里的定位,更像收费站里的计费系统——不是让你囤通行票炒溢价的,是用来确认"哪辆车走了哪段路、该扣多少通行费"的结算锚。链上过去一直缺这道"安全服务"的明码标价,Babylon想补的不是让BTC自动下蛋的幻觉,是给比特币的影响力一个不被赖账的定价标尺。

我也不会把它吹成万能药。PoS链自己的原生代币跌成了废纸,收费站自然无车可收;$BABY 如果沦为验证者空手套白狼的提款码,计费系统就成了摊派工具。真正要盯的不是锁仓峰值多耀眼,是大规模资金沉淀后,这套结算机制还能不能让"安全"保持服务属性,而不是退化成定向输血。

我认为,#baby 的终局价值,取决于多少条链愿意持续用真实购买力租赁BTC的安全性,而不是靠印钞机变相逃单。以后链越多,我越在意的不是比特币能当多少条链的保镖,是谁能证明这份安保合同,甲方每次都按约付款,而不是签了一堆永远兑现不了的空头支票。$BTC $ETH
研究BABY的时候,我一直有一个疑问:它到底是在释放比特币的沉睡价值,还是在制造一种新型的"安全租金"? Babylon让BTC持有者把原生比特币锁进主链时间锁,不跨桥、不封装,为PoS链提供经济安全并获取收益。万亿市值的BTC终于能无许可地进入PoS安全市场,资产不动,私钥不丢。 但问题不在BTC离没离开钱包,而在"安全"是谁在定价、谁在分发。你锁的是原生BTC,但经济安全投票权被抽象成了中间代理。如果Finality Provider准入、Slash执行、安全路由集中在早期节点和基金会手里,这套系统本质就是"安全租赁平台"——你出BTC当抵押品,平台决定租给谁、违约怎么罚。$BABY 一位做机构质押的朋友说:"Babylon把'再质押'翻译成了比特币原生语言,但没解决核心矛盾:质押者拿底层收益,承担多层协议叠加的关联风险。BTC脚本再干净,也挡不住BSN层面的治理攻击或节点串谋。" 这也是共享安全协议的共同命题。@babylonlabs_io 用时间锁把质押留在主网,但"质押"和"提供安全"是两件事。谁来验证这些质押确实在保护某条链的共识,谁来执行Slash,仍依赖半链上协调。去中心化只停留在资产层,没延伸到安全决策层。 #baby 选这条路有现实合理性。比特币脚本图灵不完备,不硬分叉就能实现复杂质押逻辑,已触技术天花板。对机构来说,"自托管+合规+有收益"比"完全去信任"更有说服力。它真正值得关注的,是让最去中心化的资产成为PoS安全资源,同时让持有者保留名义控制权。 最终决定价值的,不是质押了多少BTC,而是接入Babylon的PoS生态是真的需要BTC级别的经济安全,还是只要一个"比特币背书"的营销标签。前者是基础设施层,后者只是包装更精致的生息工具,锁的是信仰,放的是租金幻觉。$BTC $ETH
研究BABY的时候,我一直有一个疑问:它到底是在释放比特币的沉睡价值,还是在制造一种新型的"安全租金"?

Babylon让BTC持有者把原生比特币锁进主链时间锁,不跨桥、不封装,为PoS链提供经济安全并获取收益。万亿市值的BTC终于能无许可地进入PoS安全市场,资产不动,私钥不丢。

但问题不在BTC离没离开钱包,而在"安全"是谁在定价、谁在分发。你锁的是原生BTC,但经济安全投票权被抽象成了中间代理。如果Finality Provider准入、Slash执行、安全路由集中在早期节点和基金会手里,这套系统本质就是"安全租赁平台"——你出BTC当抵押品,平台决定租给谁、违约怎么罚。$BABY

一位做机构质押的朋友说:"Babylon把'再质押'翻译成了比特币原生语言,但没解决核心矛盾:质押者拿底层收益,承担多层协议叠加的关联风险。BTC脚本再干净,也挡不住BSN层面的治理攻击或节点串谋。"

这也是共享安全协议的共同命题。@BabylonLabs_io 用时间锁把质押留在主网,但"质押"和"提供安全"是两件事。谁来验证这些质押确实在保护某条链的共识,谁来执行Slash,仍依赖半链上协调。去中心化只停留在资产层,没延伸到安全决策层。

#baby 选这条路有现实合理性。比特币脚本图灵不完备,不硬分叉就能实现复杂质押逻辑,已触技术天花板。对机构来说,"自托管+合规+有收益"比"完全去信任"更有说服力。它真正值得关注的,是让最去中心化的资产成为PoS安全资源,同时让持有者保留名义控制权。

最终决定价值的,不是质押了多少BTC,而是接入Babylon的PoS生态是真的需要BTC级别的经济安全,还是只要一个"比特币背书"的营销标签。前者是基础设施层,后者只是包装更精致的生息工具,锁的是信仰,放的是租金幻觉。$BTC $ETH
Ver tradução
昨晚,大壮凌晨给我甩了份 Babylon 技术解析,我看完,后颈汗毛全竖了。 必须承认,这项目有股狠劲。白皮书撂得干脆:"Native Bitcoin staking without bridging"。五万多枚 BTC 锁进脚本,市值五十多亿美金。把比特币改装成 PoS 炮塔,这脑洞我服气。团队也没藏着:8% 年通胀、百亿供应、流通不到四成,剩下的筹码定时进站。 但翻到脚本层,啤酒不香了。@babylonlabs_io BABY 玩远程质押——比特币没有智能合约,逻辑全靠原生脚本拼凑。#baby 你的 BTC 交给了 UTXO 里的时间锁。脚本路径一旦偏差,五十六亿质押池就是一口高压锅。比特币脚本不适合复杂金融,每块积木的间隙都是塌方点。 更隐蔽的裂缝在罚没。作恶者被 Babylon 共识罚没,但比特币主网读不懂其状态。罚没指令隔着无法原生验证的共识鸿沟。安全假设从密码学滑向了跨链信任——恰恰是 Babylon 声称要消灭的。白皮书语焉不详,只画了张经济博弈的大饼。 BABY 代币 8% 通胀配合解锁潮,像后厨关不紧的水龙头。BSN 拍卖销毁?前提是得有 PoS 链愿意买安全。$BABY 接入不及预期,燃烧追不上通胀,治理权不过是被稀释的电子画片。没有销毁下限,价值底裤系在叙事能不能忽悠到新链这根细线上。 五十六亿 TVL 对应不到一亿市值,赔率诱人。但前提是:你得信脚本不会在极端行情下抽风,也得信解锁列车不会碾碎散户。 密码学能证明 BTC 数量,但证明不了脚本五年后仍按你理解的方式运行。 以上仅为个人看法,不构成投资建议。你愿意为不桥接的理想主义,赌上脚本层那颗未爆弹吗?欢迎聊聊。$BTC $ETH
昨晚,大壮凌晨给我甩了份 Babylon 技术解析,我看完,后颈汗毛全竖了。

必须承认,这项目有股狠劲。白皮书撂得干脆:"Native Bitcoin staking without bridging"。五万多枚 BTC 锁进脚本,市值五十多亿美金。把比特币改装成 PoS 炮塔,这脑洞我服气。团队也没藏着:8% 年通胀、百亿供应、流通不到四成,剩下的筹码定时进站。

但翻到脚本层,啤酒不香了。@BabylonLabs_io

BABY 玩远程质押——比特币没有智能合约,逻辑全靠原生脚本拼凑。#baby 你的 BTC 交给了 UTXO 里的时间锁。脚本路径一旦偏差,五十六亿质押池就是一口高压锅。比特币脚本不适合复杂金融,每块积木的间隙都是塌方点。

更隐蔽的裂缝在罚没。作恶者被 Babylon 共识罚没,但比特币主网读不懂其状态。罚没指令隔着无法原生验证的共识鸿沟。安全假设从密码学滑向了跨链信任——恰恰是 Babylon 声称要消灭的。白皮书语焉不详,只画了张经济博弈的大饼。

BABY 代币 8% 通胀配合解锁潮,像后厨关不紧的水龙头。BSN 拍卖销毁?前提是得有 PoS 链愿意买安全。$BABY 接入不及预期,燃烧追不上通胀,治理权不过是被稀释的电子画片。没有销毁下限,价值底裤系在叙事能不能忽悠到新链这根细线上。

五十六亿 TVL 对应不到一亿市值,赔率诱人。但前提是:你得信脚本不会在极端行情下抽风,也得信解锁列车不会碾碎散户。

密码学能证明 BTC 数量,但证明不了脚本五年后仍按你理解的方式运行。

以上仅为个人看法,不构成投资建议。你愿意为不桥接的理想主义,赌上脚本层那颗未爆弹吗?欢迎聊聊。$BTC $ETH
A narrativa de staking nativo do BABY está sendo boicotada pela própria complexidade da experiência Você tem BTC na mão e quer fazer ele gerar rendimentos. Abra a página de staking #baby , primeiro selecione o Finality Provider, depois analise o risco de slash e, por fim, fique mexendo com o script de tempo de bloqueio. Lao Zhang copiou a seed três vezes, mas no fim nem chegou a clicar em confirmar—não é que não goste de auto-custódia; é que, depois de calcular a conta, concluiu: depois de se esforçar por horas, o rendimento é incerto, então por quê? Antes, $BABY chamou atenção na cena, apostando em “staking nativo de BTC, sem bridge e sem abrir mão da chave privada”. O brilho de Stanford e um TVL de mais de 50 mil BTC chegaram a transformar aquilo num benchmark do BTCFi. Só que a maioria dos detentores quer retorno previsível, operação “no-brainer” e riscos claramente visíveis. O BABY, no momento, não entrega isso. A implementação na ecossistema BSN está lenta de um jeito gritante. O que realmente está rodando é apenas o Genesis; parcerias como a Sui ainda estão na fase de slides. A narrativa de PoS usando a segurança do BTC é bem sedutora, mas muitas novas redes preferem usar staking com tokens nativos em vez de arcar com o custo adicional para integrar o Babylon. A roda do ecossistema não engrena, e nem dá para falar em receita de taxas de segurança. Os dados on-chain também não estão bons. O crescimento das endereços ativos de staking em @babylonlabs_io desacelerou; o aumento novo depende principalmente de pontos do Season e da expectativa de airdrop. Se as recompensas diminuem, usuários que entraram só pelo incentivo vão embora sem hesitar. A liquidez do BTC travado na cadeia fica congelada; quando alguém precisa com urgência, o processo de destravar é demorado demais. A maioria não aguenta esse atrito. A lógica inteira já virou feedback negativo: barreira de experiência alta → crescimento orgânico fraco → manter as pessoas via subsídios → pressão de venda do BABY aumenta → preço da moeda cai, reduzindo ainda mais o apelo do staking. Pulsos do mercado anteriores foram apenas um desabafo de emoção de curto prazo; não conseguem reverter a tendência de enfraquecimento dos fundamentos. Eu olho para dois sinais: (1) o BSN ter uma PoS de ponta que realmente faça o lançamento do mainnet e gere taxas de segurança contínuas; (2) na parcela de novos endereços de staking, a proporção de entradas naturais, sem depender de incentivos de airdrop, ser mais da metade. $BTC só considero acompanhar com uma posição pequena se ambos ocorrerem; se faltar um, continuo observando, sem comprar a ideia do “brilho de Stanford”. A narrativa de staking nativo do BABY está sendo rebatida pela própria experiência. Fluxo complicado, implementação do BSN lenta, crescimento de usuários sustentado por incentivos—feedback negativo já está formado. A menos que as principais cadeias lancem mainnets e a entrada natural passe de metade, é para observar. $ETH
A narrativa de staking nativo do BABY está sendo boicotada pela própria complexidade da experiência

Você tem BTC na mão e quer fazer ele gerar rendimentos. Abra a página de staking #baby , primeiro selecione o Finality Provider, depois analise o risco de slash e, por fim, fique mexendo com o script de tempo de bloqueio. Lao Zhang copiou a seed três vezes, mas no fim nem chegou a clicar em confirmar—não é que não goste de auto-custódia; é que, depois de calcular a conta, concluiu: depois de se esforçar por horas, o rendimento é incerto, então por quê?

Antes, $BABY chamou atenção na cena, apostando em “staking nativo de BTC, sem bridge e sem abrir mão da chave privada”. O brilho de Stanford e um TVL de mais de 50 mil BTC chegaram a transformar aquilo num benchmark do BTCFi. Só que a maioria dos detentores quer retorno previsível, operação “no-brainer” e riscos claramente visíveis. O BABY, no momento, não entrega isso.

A implementação na ecossistema BSN está lenta de um jeito gritante. O que realmente está rodando é apenas o Genesis; parcerias como a Sui ainda estão na fase de slides. A narrativa de PoS usando a segurança do BTC é bem sedutora, mas muitas novas redes preferem usar staking com tokens nativos em vez de arcar com o custo adicional para integrar o Babylon. A roda do ecossistema não engrena, e nem dá para falar em receita de taxas de segurança.

Os dados on-chain também não estão bons. O crescimento das endereços ativos de staking em @BabylonLabs_io desacelerou; o aumento novo depende principalmente de pontos do Season e da expectativa de airdrop. Se as recompensas diminuem, usuários que entraram só pelo incentivo vão embora sem hesitar. A liquidez do BTC travado na cadeia fica congelada; quando alguém precisa com urgência, o processo de destravar é demorado demais. A maioria não aguenta esse atrito.

A lógica inteira já virou feedback negativo: barreira de experiência alta → crescimento orgânico fraco → manter as pessoas via subsídios → pressão de venda do BABY aumenta → preço da moeda cai, reduzindo ainda mais o apelo do staking. Pulsos do mercado anteriores foram apenas um desabafo de emoção de curto prazo; não conseguem reverter a tendência de enfraquecimento dos fundamentos.

Eu olho para dois sinais: (1) o BSN ter uma PoS de ponta que realmente faça o lançamento do mainnet e gere taxas de segurança contínuas; (2) na parcela de novos endereços de staking, a proporção de entradas naturais, sem depender de incentivos de airdrop, ser mais da metade. $BTC só considero acompanhar com uma posição pequena se ambos ocorrerem; se faltar um, continuo observando, sem comprar a ideia do “brilho de Stanford”.

A narrativa de staking nativo do BABY está sendo rebatida pela própria experiência. Fluxo complicado, implementação do BSN lenta, crescimento de usuários sustentado por incentivos—feedback negativo já está formado. A menos que as principais cadeias lancem mainnets e a entrada natural passe de metade, é para observar. $ETH
Caminho de glória de nove anos da Binance, forjado para escrever um novo capítulo das finanças globais, e abrir o futuro #BinanceTurns9
Caminho de glória de nove anos da Binance, forjado para escrever um novo capítulo das finanças globais, e abrir o futuro #BinanceTurns9
Newton Protocol: terceirizar a conformidade para o código é terceirizar o risco para quem?Primeiro, vou te fazer uma pergunta: se seu diretor jurídico te dissesse que vamos terceirizar a triagem de lavagem de dinheiro, os limites de transação e a verificação de listas de sanções para um tipo de middleware on-chain composto por scripts de políticas Rego, um ambiente de execução confiável (TEE) e provas de conhecimento zero — e que, se der algo errado, a equipe não se responsabiliza porque “o código já passou por auditoria” — você sentiria que tem algo estranho nisso? De qualquer forma, quando eu leio a documentação @NewtonProtocol , essa sensação de desconforto não sai da minha cabeça. Eu realmente passei bastante tempo desmontando essa arquitetura: como o mecanismo de estratégia faz o roteamento, como os provedores de rede chegam a um consenso, como a prova é agregada e como o re-staking é penalizado e confiscado. Cada módulo, olhando separadamente, parece fazer sentido. Mas, quanto mais eu olho, mais sinto que o Newton Protocol parece estar realizando uma troca de risco bem elaborada — transferindo a responsabilidade de conformidade legal que originalmente ficaria com as instituições para o risco técnico que passa a ser compartilhado por usuários e desenvolvedores. Isso não é resolver um problema; é reescrever a definição do problema.

Newton Protocol: terceirizar a conformidade para o código é terceirizar o risco para quem?

Primeiro, vou te fazer uma pergunta: se seu diretor jurídico te dissesse que vamos terceirizar a triagem de lavagem de dinheiro, os limites de transação e a verificação de listas de sanções para um tipo de middleware on-chain composto por scripts de políticas Rego, um ambiente de execução confiável (TEE) e provas de conhecimento zero — e que, se der algo errado, a equipe não se responsabiliza porque “o código já passou por auditoria” — você sentiria que tem algo estranho nisso? De qualquer forma, quando eu leio a documentação @NewtonProtocol , essa sensação de desconforto não sai da minha cabeça.
Eu realmente passei bastante tempo desmontando essa arquitetura: como o mecanismo de estratégia faz o roteamento, como os provedores de rede chegam a um consenso, como a prova é agregada e como o re-staking é penalizado e confiscado. Cada módulo, olhando separadamente, parece fazer sentido. Mas, quanto mais eu olho, mais sinto que o Newton Protocol parece estar realizando uma troca de risco bem elaborada — transferindo a responsabilidade de conformidade legal que originalmente ficaria com as instituições para o risco técnico que passa a ser compartilhado por usuários e desenvolvedores. Isso não é resolver um problema; é reescrever a definição do problema.
Na madrugada de quinta-feira, fiquei agachado do lado do tanque de fermentação de uma oficina de cerveja artesanal, ajudando um parceiro de “pagamentos transfronteiriços” a montar a @NewtonProtocol da sua “caixa-forte de conformidade”. Os documentos dizem “pronto para uso”; no entanto, só fazer o Rego funcionar com uma combinação “lista de permissões + limite” me tomou a noite inteira. O Rego foi criado para escrever políticas de recursos em nuvem voltadas a TI corporativa: sintaxe declarativa, nega por padrão (deny) e depois libera item a item com allow. O #Newt quer trazê-lo para a cadeia como o núcleo da autorização, porque é melhor de escrever que Solidity e mais flexível. Mas quem paga o preço dessa flexibilidade? Tentei escrever uma regra que ao mesmo tempo verifica identidade, limite, risco da contraparte e preço das garantias: quatro condições aninhadas, e o módulo imediatamente virou uma teia de aranha de referências cruzadas. Mudar um limite exige seguir o encadeamento de import por três níveis. Eu nem consigo raciocinar totalmente com as regras que eu mesmo escrevi. Quando saiu uma brecha, fui atrás do operador? Do autor da política? Ou do time Newton que vende promessa? Outra coisa: o mito de “segundos”. A intenção é empacotar tudo como uma tarefa, jogá-la para os operadores do EigenLayer que fazem restake; cada um roda o Rego, gera a prova e faz a agregação de assinaturas BLS, e por fim devolve tudo na cadeia. Soa sensual, mas se eu reviro a documentação, não encontrei dados de testes de estresse. Quanto mais complexa a política, mais tempo um operador individual leva para avaliar; quanto mais operadores, mais imprevisível fica o atraso para sincronizar e reunir as assinaturas. O “em segundos” do documento é dado de laboratório em pausa artificial, ou é a normalidade em políticas reais e complexas? A janela de controvérsia também me deixa incomodado. Se um operador julga errado, você tem que esperar o período de desafio acabar e alguém enviar uma prova de fraude para corrigir. Não é isso “executar primeiro, liquidar depois”? Seu dinheiro é transferido antes, e depois as verbas ficam no ar, meio suspensas. Isso é gestão de risco? Isso é fazer o usuário virar voluntário pago. E privacidade… ainda mais engraçado. O $NEWT fala em TEE + ZK para proteger privacidade, mas a política usa validação de identidade, score de risco e status de KYC que vêm de APIs de terceiros externas. Quanto mais flexível a política, menos o cidadão comum consegue auditar; no fim, ainda precisa confiar na instituição que te dá a nota. Proteção de privacidade, no fim, só preservou o nada — e a confiança saiu da cadeia para virar uma caixa-preta fora dela. Tranquei o celular. O frio do tanque de fermentação deixou meus dedos dormentes. Mais uma história que transforma complexidade em algo simples — só que, no papel de embrulho, há um logo em dourado de TEE e ZKP. $BTC $ETH
Na madrugada de quinta-feira, fiquei agachado do lado do tanque de fermentação de uma oficina de cerveja artesanal, ajudando um parceiro de “pagamentos transfronteiriços” a montar a @NewtonProtocol da sua “caixa-forte de conformidade”. Os documentos dizem “pronto para uso”; no entanto, só fazer o Rego funcionar com uma combinação “lista de permissões + limite” me tomou a noite inteira.

O Rego foi criado para escrever políticas de recursos em nuvem voltadas a TI corporativa: sintaxe declarativa, nega por padrão (deny) e depois libera item a item com allow. O #Newt quer trazê-lo para a cadeia como o núcleo da autorização, porque é melhor de escrever que Solidity e mais flexível. Mas quem paga o preço dessa flexibilidade? Tentei escrever uma regra que ao mesmo tempo verifica identidade, limite, risco da contraparte e preço das garantias: quatro condições aninhadas, e o módulo imediatamente virou uma teia de aranha de referências cruzadas. Mudar um limite exige seguir o encadeamento de import por três níveis. Eu nem consigo raciocinar totalmente com as regras que eu mesmo escrevi. Quando saiu uma brecha, fui atrás do operador? Do autor da política? Ou do time Newton que vende promessa?

Outra coisa: o mito de “segundos”. A intenção é empacotar tudo como uma tarefa, jogá-la para os operadores do EigenLayer que fazem restake; cada um roda o Rego, gera a prova e faz a agregação de assinaturas BLS, e por fim devolve tudo na cadeia. Soa sensual, mas se eu reviro a documentação, não encontrei dados de testes de estresse. Quanto mais complexa a política, mais tempo um operador individual leva para avaliar; quanto mais operadores, mais imprevisível fica o atraso para sincronizar e reunir as assinaturas. O “em segundos” do documento é dado de laboratório em pausa artificial, ou é a normalidade em políticas reais e complexas?

A janela de controvérsia também me deixa incomodado. Se um operador julga errado, você tem que esperar o período de desafio acabar e alguém enviar uma prova de fraude para corrigir. Não é isso “executar primeiro, liquidar depois”? Seu dinheiro é transferido antes, e depois as verbas ficam no ar, meio suspensas. Isso é gestão de risco? Isso é fazer o usuário virar voluntário pago.

E privacidade… ainda mais engraçado. O $NEWT fala em TEE + ZK para proteger privacidade, mas a política usa validação de identidade, score de risco e status de KYC que vêm de APIs de terceiros externas. Quanto mais flexível a política, menos o cidadão comum consegue auditar; no fim, ainda precisa confiar na instituição que te dá a nota. Proteção de privacidade, no fim, só preservou o nada — e a confiança saiu da cadeia para virar uma caixa-preta fora dela.

Tranquei o celular. O frio do tanque de fermentação deixou meus dedos dormentes. Mais uma história que transforma complexidade em algo simples — só que, no papel de embrulho, há um logo em dourado de TEE e ZKP. $BTC $ETH
Diga a verdade: na semana passada ajudei um velho amigo que trabalha com derivativos a entender a documentação de integração. Ele me jogou um diagrama da arquitetura da GRVT e disse: “Pronto, agora a velocidade de matching de um CEX com self-custody/DEX? A liquidez de nível institucional fica literalmente soldada na cadeia.” Fiquei encarando aquele diagrama fechado em quatro camadas por um tempão e pensei: emmm… não é basicamente pegar o “matching de caixa-preta” do CEX e levar para fora da cadeia, só que com um casaco de Validium? Depois de pesquisar toda a documentação @grvt_io , descobri que o argumento de venda dessa coisa realmente é bonito: o motor de matching off-chain alimenta as ordens, o Validium garante disponibilidade de dados, o cofre/GLP fornece liquidez para receber fluxo e o sistema de pontos “trava” usuários; parece tudo bem amarrado. Mas quanto mais eu leio, mais sinto que a GRVT, no fundo, coloca para cada transação um “quarto escuro off-chain” — o matching roda num servidor centralizado, e só o settlement vai para a blockchain. A lógica de matching é uma caixa-preta para o usuário. Newton, ao menos, mostra o Rego. O motor de matching da GRVT nem abre o código-fonte — isso não é só um CEX tradicional trocando uma carteira self-custody? É realmente diferente de a dYdX v3 trocar o “sobrenome”? O que eu mais queria entender é a “liquidez institucional” de #grvt . O cofre GLP faz com que os usuários joguem dinheiro numa “caixa-preta” de estratégias, dizendo que há compartilhamento de ganhos de market-making. Mas quem ajusta os parâmetros da estratégia? Quem controla a exposição ao risco? Revirei a documentação e só vi APY; não vi nenhuma tabela de desconto/precificação para liquidação. Até parece bonito dizer que ativos RWA ficam on-chain, mas, quando chegar um cenário extremo, quando suas obrigações (off-chain custody) e ouro forem liquidados, o desconto de liquidação vai ser calculado com base no book de qual exchange? No Newton, o operator ao menos dá algum tipo de collateral; no GLP, se a estratégia der prejuízo, o autor da estratégia compensa você ou o prejuízo fica com os próprios usuários? Procurei esse “quem paga a conta” por muito tempo e não encontrei resposta. Quanto ao sistema de pontos, eu realmente não consigo confiar 100%. Cashback e camadas em cascata, travas de “membros”, explosão de convites… esse combo parece menos com uma exchange e mais com um esquema de captação de recursos. A diluição dos pontos não tem “teto duro”; as válvulas ficam com a equipe do projeto. Hoje emite cem milhões, amanhã emite um bilhão: a tal “rentabilidade real” vem de market-making ou é só o principal de quem entra depois sustentando o resto? O TEE do Newton pelo menos tenta parecer responsável. Já a GRVT transforma o modelo econômico em “um cheque desenhado na areia” — a maré recua e quem fica nadando pelado? $BTC Irmão, eu fico pensando: a GRVT está criando um campo de competição mais justo para varejo, ou montou para instituições e market-makers uma esteira de captura de valor mais discreta e menos visível, com uma “pele” de “híbrido descentralizado”? $ETH
Diga a verdade: na semana passada ajudei um velho amigo que trabalha com derivativos a entender a documentação de integração. Ele me jogou um diagrama da arquitetura da GRVT e disse: “Pronto, agora a velocidade de matching de um CEX com self-custody/DEX? A liquidez de nível institucional fica literalmente soldada na cadeia.” Fiquei encarando aquele diagrama fechado em quatro camadas por um tempão e pensei: emmm… não é basicamente pegar o “matching de caixa-preta” do CEX e levar para fora da cadeia, só que com um casaco de Validium?

Depois de pesquisar toda a documentação @grvt_io , descobri que o argumento de venda dessa coisa realmente é bonito: o motor de matching off-chain alimenta as ordens, o Validium garante disponibilidade de dados, o cofre/GLP fornece liquidez para receber fluxo e o sistema de pontos “trava” usuários; parece tudo bem amarrado. Mas quanto mais eu leio, mais sinto que a GRVT, no fundo, coloca para cada transação um “quarto escuro off-chain” — o matching roda num servidor centralizado, e só o settlement vai para a blockchain. A lógica de matching é uma caixa-preta para o usuário. Newton, ao menos, mostra o Rego. O motor de matching da GRVT nem abre o código-fonte — isso não é só um CEX tradicional trocando uma carteira self-custody? É realmente diferente de a dYdX v3 trocar o “sobrenome”?

O que eu mais queria entender é a “liquidez institucional” de #grvt . O cofre GLP faz com que os usuários joguem dinheiro numa “caixa-preta” de estratégias, dizendo que há compartilhamento de ganhos de market-making. Mas quem ajusta os parâmetros da estratégia? Quem controla a exposição ao risco? Revirei a documentação e só vi APY; não vi nenhuma tabela de desconto/precificação para liquidação. Até parece bonito dizer que ativos RWA ficam on-chain, mas, quando chegar um cenário extremo, quando suas obrigações (off-chain custody) e ouro forem liquidados, o desconto de liquidação vai ser calculado com base no book de qual exchange? No Newton, o operator ao menos dá algum tipo de collateral; no GLP, se a estratégia der prejuízo, o autor da estratégia compensa você ou o prejuízo fica com os próprios usuários? Procurei esse “quem paga a conta” por muito tempo e não encontrei resposta.

Quanto ao sistema de pontos, eu realmente não consigo confiar 100%. Cashback e camadas em cascata, travas de “membros”, explosão de convites… esse combo parece menos com uma exchange e mais com um esquema de captação de recursos. A diluição dos pontos não tem “teto duro”; as válvulas ficam com a equipe do projeto. Hoje emite cem milhões, amanhã emite um bilhão: a tal “rentabilidade real” vem de market-making ou é só o principal de quem entra depois sustentando o resto? O TEE do Newton pelo menos tenta parecer responsável. Já a GRVT transforma o modelo econômico em “um cheque desenhado na areia” — a maré recua e quem fica nadando pelado?
$BTC

Irmão, eu fico pensando: a GRVT está criando um campo de competição mais justo para varejo, ou montou para instituições e market-makers uma esteira de captura de valor mais discreta e menos visível, com uma “pele” de “híbrido descentralizado”? $ETH
Newton enfiou a confiança numa caixa-preta e ainda quer que a gente chame isso de “verificável”? A uma e meia da madrugada, o último tanque de fermentação da cervejaria artesanal parou de zumbir. Eu encarei, por vinte minutos inteiros, o endereço do contrato do verificador do ZKP do Newton Protocol na tela do meu notebook e, de repente, me senti como um idiota. Dez anos atrás eu saí das finanças tradicionais justamente porque detestava a caixa-preta — aquelas regras de controle de risco escondidas nos sistemas centrais do banco; você nunca sabe por que a transferência que você pediu é recusada. Agora o Newton me diz que, com ZKP e TEE, eles criaram uma “camada de automação verificável”. Mas quanto mais eu vejo, mais parece que eles apenas tiraram a caixa-preta do porão do banco e a levaram para o alto da torre de marfim da criptografia — e ainda colocaram mais dois cadeados.

Newton enfiou a confiança numa caixa-preta e ainda quer que a gente chame isso de “verificável”?

A uma e meia da madrugada, o último tanque de fermentação da cervejaria artesanal parou de zumbir. Eu encarei, por vinte minutos inteiros, o endereço do contrato do verificador do ZKP do Newton Protocol na tela do meu notebook e, de repente, me senti como um idiota. Dez anos atrás eu saí das finanças tradicionais justamente porque detestava a caixa-preta — aquelas regras de controle de risco escondidas nos sistemas centrais do banco; você nunca sabe por que a transferência que você pediu é recusada. Agora o Newton me diz que, com ZKP e TEE, eles criaram uma “camada de automação verificável”. Mas quanto mais eu vejo, mais parece que eles apenas tiraram a caixa-preta do porão do banco e a levaram para o alto da torre de marfim da criptografia — e ainda colocaram mais dois cadeados.
grvt A "armadilha de diferença de tempo" na correspondência e na liquidação. Pensamentos frios depois de eu vasculhar o código Às duas e meia da madrugada, a tela do computador de desenvolvimento no porão lançava uma luz branca; o café preto ao lado já tinha esfriado e ficado com uma película de óleo. Quando o monitor Bot disparou o alerta, um certo grande detentor em contrato perpétuo foi perfurado por um mecanismo e estourou (liquidação forçada); a liquidação na cadeia ainda estava na fila. Água fria no rosto — é exatamente aquela zona mais ambígua da "arquitetura híbrida". À aposta explícita do airdrop, os veteranos de antes (os "Deg") já haviam criado a conta @grvt_io . A versão oficial vende o ciclo fechado de "correspondência na cadeia de fora e liquidação na cadeia de dentro"; os zk-SNARKs comprimem a execução em uma prova de conhecimento zero e jogam para o zkSync. Soa como motor de foguete montado numa Corolla. Mas, rasgando a roupa de baixo, as rachaduras entre o motor de correspondência e a camada de liquidação são suficientes para fazer a nuca dos velhos novatos ficar gelada. A correspondência fora da cadeia roda com dezenas de milhares de transações por segundo, mas gerar o zkProof, enviá-lo ao zkSync e esperar a confirmação leva minutos de atraso. Quando você vê a posição estourar e o stop-loss disparar, a liquidação na cadeia ainda está na fila. Se o motor fora da cadeia inserir um "needle"/interferência, a liquidação efetiva na cadeia já é irreversível. É como ver o dado sair alto: os chips só caíram no bolso antes de o banqueiro conseguir mudar o livro-caixa. Eu disse ao meu amigo, o Lao Liu: "Isso não é só trocar o nome da clearing tradicional por um Validium Committee?" O TEE bloqueia parte das maldades, mas o próprio limite de confiança do hardware é uma caixa-preta. Os dados da L2BEAT não mentem; as permissões de upgrade do contrato ainda são controladas por multi-assinaturas do time. De "confiar no banqueiro de terno" para "confiar no time de código de capuz" — é só trocar a divindade que eles adoram. Mais irônico ainda é o Unified Margin (Margem Unificada). Spot, perpétuo e opções compartilham garantia na mesma conta; o motor fora da cadeia faz cálculos complexos de margem cruzada. Se em um cenário extremo em cadeia, com falências em cascata, a clearing fora da cadeia e a liquidação na cadeia ficarem em estados inconsistentes, o Socialized Loss Haircut corta quem e quanto — e o controle das chaves/interruptores de código está nas mãos de quem; você precisa saber no seu íntimo. A tecnologia sempre fica dando voltas. Naquela época, era para fugir da latência de liquidação T+2 que correram para o utopismo da blockchain. Agora, #grvt montou de novo a "faixa de amortecimento em duas camadas": correspondência fora da cadeia e liquidação na cadeia. Usando a criptografia, reinventaram a clearing. É evolução descentralizada ou finanças institucionais no on-chain reencarnando com o corpo de outra coisa? $BTC A absoluta ausência de confiança não existe; só mudamos de confiar em banqueiros de terno, para confiar em um time fundador que controla multi-assinaturas. Reconhecer claramente a existência do "muro na cadeia" e saber quem está com a maçaneta é a regra mais pragmática de sobrevivência do velho novato. $ETH
grvt A "armadilha de diferença de tempo" na correspondência e na liquidação. Pensamentos frios depois de eu vasculhar o código

Às duas e meia da madrugada, a tela do computador de desenvolvimento no porão lançava uma luz branca; o café preto ao lado já tinha esfriado e ficado com uma película de óleo. Quando o monitor Bot disparou o alerta, um certo grande detentor em contrato perpétuo foi perfurado por um mecanismo e estourou (liquidação forçada); a liquidação na cadeia ainda estava na fila. Água fria no rosto — é exatamente aquela zona mais ambígua da "arquitetura híbrida".

À aposta explícita do airdrop, os veteranos de antes (os "Deg") já haviam criado a conta @grvt_io . A versão oficial vende o ciclo fechado de "correspondência na cadeia de fora e liquidação na cadeia de dentro"; os zk-SNARKs comprimem a execução em uma prova de conhecimento zero e jogam para o zkSync. Soa como motor de foguete montado numa Corolla. Mas, rasgando a roupa de baixo, as rachaduras entre o motor de correspondência e a camada de liquidação são suficientes para fazer a nuca dos velhos novatos ficar gelada.

A correspondência fora da cadeia roda com dezenas de milhares de transações por segundo, mas gerar o zkProof, enviá-lo ao zkSync e esperar a confirmação leva minutos de atraso. Quando você vê a posição estourar e o stop-loss disparar, a liquidação na cadeia ainda está na fila. Se o motor fora da cadeia inserir um "needle"/interferência, a liquidação efetiva na cadeia já é irreversível. É como ver o dado sair alto: os chips só caíram no bolso antes de o banqueiro conseguir mudar o livro-caixa.

Eu disse ao meu amigo, o Lao Liu: "Isso não é só trocar o nome da clearing tradicional por um Validium Committee?" O TEE bloqueia parte das maldades, mas o próprio limite de confiança do hardware é uma caixa-preta. Os dados da L2BEAT não mentem; as permissões de upgrade do contrato ainda são controladas por multi-assinaturas do time. De "confiar no banqueiro de terno" para "confiar no time de código de capuz" — é só trocar a divindade que eles adoram.

Mais irônico ainda é o Unified Margin (Margem Unificada). Spot, perpétuo e opções compartilham garantia na mesma conta; o motor fora da cadeia faz cálculos complexos de margem cruzada. Se em um cenário extremo em cadeia, com falências em cascata, a clearing fora da cadeia e a liquidação na cadeia ficarem em estados inconsistentes, o Socialized Loss Haircut corta quem e quanto — e o controle das chaves/interruptores de código está nas mãos de quem; você precisa saber no seu íntimo.

A tecnologia sempre fica dando voltas. Naquela época, era para fugir da latência de liquidação T+2 que correram para o utopismo da blockchain. Agora, #grvt montou de novo a "faixa de amortecimento em duas camadas": correspondência fora da cadeia e liquidação na cadeia. Usando a criptografia, reinventaram a clearing. É evolução descentralizada ou finanças institucionais no on-chain reencarnando com o corpo de outra coisa? $BTC

A absoluta ausência de confiança não existe; só mudamos de confiar em banqueiros de terno, para confiar em um time fundador que controla multi-assinaturas. Reconhecer claramente a existência do "muro na cadeia" e saber quem está com a maçaneta é a regra mais pragmática de sobrevivência do velho novato. $ETH
Ver tradução
凌晨三点,我蹲在地下室开发机前复盘去年那笔被"全自动"量化机器人打穿的单子。那天市场剧烈波动,机器人压根没执行预设止损,风控逻辑全跑在开发者私服里,链上连根毛都查不到。所以后来刷到@NewtonProtocol 打"可验证自动化"旗号,我这个老韭菜第一反应不是拍大腿喊革命,是下意识摸出计算器,算这到底是真的链上刚性,还是换了个马甲的黑箱。 #Newt 想做的,本质上是把AI代理的手脚捆进zkPermissions的笼子里:操作边界预写死,每步都甩个零知识证明出来,证明自己没越界。但翻完白皮书,我发现一个更隐蔽的问题:它把"可信"从开发者身上剥下来,贴到了TEE硬件和Prover网络上。信任这玩意儿不会消失,只会转移——从信人变成信英特尔SGX,本质上还是押注某个中心化节点。 Keystore Rollup要当跨链账户的统一翻译官,可每条链的账户模型、签名算法都不一样,白皮书对"怎么无缝兼容"几乎没展开。更耐人寻味的是那个"渐进式去中心化",路线图里就一句"生态系统将随时间加深去中心化"。$NEWT 我在伦敦看合规文件看了这么多年,这种表述跟"画在沙滩上的支票"没什么区别。测试网还有用户反馈,跑一轮简单策略验证,Gas比直接调合约贵了将近18%,高频玩家这笔"安全税"交不交得起,得自己掂量。$BTC 方向确实戳中痛点,但"可验证"本身就是巨型工程黑洞——证明者谁跑?排序器谁控?跨链状态怎么对账?主网没落地、独立验证入口没开放之前,我选择把私钥捂在热钱包里,继续观望。毕竟在链上世界,从"信人"变成"信硬件",摔下来的时候一样疼,而且更不好找谁说理。$ETH
凌晨三点,我蹲在地下室开发机前复盘去年那笔被"全自动"量化机器人打穿的单子。那天市场剧烈波动,机器人压根没执行预设止损,风控逻辑全跑在开发者私服里,链上连根毛都查不到。所以后来刷到@NewtonProtocol 打"可验证自动化"旗号,我这个老韭菜第一反应不是拍大腿喊革命,是下意识摸出计算器,算这到底是真的链上刚性,还是换了个马甲的黑箱。

#Newt 想做的,本质上是把AI代理的手脚捆进zkPermissions的笼子里:操作边界预写死,每步都甩个零知识证明出来,证明自己没越界。但翻完白皮书,我发现一个更隐蔽的问题:它把"可信"从开发者身上剥下来,贴到了TEE硬件和Prover网络上。信任这玩意儿不会消失,只会转移——从信人变成信英特尔SGX,本质上还是押注某个中心化节点。

Keystore Rollup要当跨链账户的统一翻译官,可每条链的账户模型、签名算法都不一样,白皮书对"怎么无缝兼容"几乎没展开。更耐人寻味的是那个"渐进式去中心化",路线图里就一句"生态系统将随时间加深去中心化"。$NEWT 我在伦敦看合规文件看了这么多年,这种表述跟"画在沙滩上的支票"没什么区别。测试网还有用户反馈,跑一轮简单策略验证,Gas比直接调合约贵了将近18%,高频玩家这笔"安全税"交不交得起,得自己掂量。$BTC

方向确实戳中痛点,但"可验证"本身就是巨型工程黑洞——证明者谁跑?排序器谁控?跨链状态怎么对账?主网没落地、独立验证入口没开放之前,我选择把私钥捂在热钱包里,继续观望。毕竟在链上世界,从"信人"变成"信硬件",摔下来的时候一样疼,而且更不好找谁说理。$ETH
Inicia sessão para explorar mais conteúdos
Junta-te a utilizadores de criptomoedas de todo o mundo na Binance Square
⚡️ Obtém informações úteis e recentes sobre criptomoedas.
💬 Com a confiança da maior exchange de criptomoedas do mundo.
👍 Descobre perspetivas reais de criadores verificados.
E-mail/Número de telefone
Mapa do sítio
Preferências de cookies
Termos e Condições da Plataforma