Khánh Trang1510
25 Publicações
Khánh Trang1510
Aberto ao trading
Trader Frequente
4.3 ano(s)
107 A seguir
19 Seguidores
24 Gostaram
Publicações
Portfólio
Certa vez, um comprador me enviou mais do que o valor acordado em uma negociação P2P da Binance e pediu que eu reembolsasse a diferença diretamente para uma conta bancária diferente daquela de onde o pagamento veio. No começo, parecia um erro honesto. Não era.
Esse é um padrão conhecido que vale a pena nomear claramente, já que também pega traders experientes, não apenas iniciantes. O excesso de pagamento em si é projetado para gerar urgência e confusão, na esperança de que o vendedor faça o reembolso do valor extra rapidamente antes de perceber que o pagamento original pode ser revertido ou contestado depois, deixando o vendedor tendo enviado tanto as criptomoedas quanto um reembolso em dinheiro por um pagamento que na verdade nunca se liquida. A Binance P2P protege os vendedores aqui por meio do seu sistema de escrow, que mantém o ativo cripto separado de qualquer conversa de um lado sobre reembolsos, e também por exigir que tudo relacionado à negociação fique dentro da plataforma e de seus canais oficiais. No momento em que alguém solicita um reembolso para uma conta diferente daquela do remetente original, isso é uma quebra clara do comportamento normal de negociação e um sinal vermelho que vale a pena interromper imediatamente.
Minha regra desde essa negociação é simples. Eu nunca reembolso nada fora do pedido original. Se o valor de um pagamento parecer incorreto, eu não ajo com base no meu próprio julgamento: eu cancelo ou entro em contato com o suporte da Binance e deixo que eles verifiquem a discrepância antes mesmo de eu tocar no ativo cripto. Eu sempre confirmo se o nome do remetente em qualquer pagamento corresponde ao contraparte verificada no pedido, pois um nome incompatível é um aviso por si só. Eu guardo um print do valor exato recebido na minha própria conta, e não do valor alegado no chat. Qualquer solicitação para mover dinheiro fora da plataforma, reembolsar ou não, é denunciada em vez de ser concluída silenciosamente.
Confiar no processo, mais do que na história de um desconhecido, nunca me custou nada.
@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI
Esse é um padrão conhecido que vale a pena nomear claramente, já que também pega traders experientes, não apenas iniciantes. O excesso de pagamento em si é projetado para gerar urgência e confusão, na esperança de que o vendedor faça o reembolso do valor extra rapidamente antes de perceber que o pagamento original pode ser revertido ou contestado depois, deixando o vendedor tendo enviado tanto as criptomoedas quanto um reembolso em dinheiro por um pagamento que na verdade nunca se liquida. A Binance P2P protege os vendedores aqui por meio do seu sistema de escrow, que mantém o ativo cripto separado de qualquer conversa de um lado sobre reembolsos, e também por exigir que tudo relacionado à negociação fique dentro da plataforma e de seus canais oficiais. No momento em que alguém solicita um reembolso para uma conta diferente daquela do remetente original, isso é uma quebra clara do comportamento normal de negociação e um sinal vermelho que vale a pena interromper imediatamente.
Minha regra desde essa negociação é simples. Eu nunca reembolso nada fora do pedido original. Se o valor de um pagamento parecer incorreto, eu não ajo com base no meu próprio julgamento: eu cancelo ou entro em contato com o suporte da Binance e deixo que eles verifiquem a discrepância antes mesmo de eu tocar no ativo cripto. Eu sempre confirmo se o nome do remetente em qualquer pagamento corresponde ao contraparte verificada no pedido, pois um nome incompatível é um aviso por si só. Eu guardo um print do valor exato recebido na minha própria conta, e não do valor alegado no chat. Qualquer solicitação para mover dinheiro fora da plataforma, reembolsar ou não, é denunciada em vez de ser concluída silenciosamente.
Confiar no processo, mais do que na história de um desconhecido, nunca me custou nada.
@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI
Ver tradução
Three letters saved me from a bad trade. The buyer's verified name on Binance P2P read Nguyen Van Minh, and the transfer that landed in my account came from an account labeled Nguyen Van Anh. Close enough to miss if you are skimming, different enough to matter completely.
Binance P2P ties every account to a verified identity through KYC, and that identity is supposed to match the payment account used during a trade. When I confirm payment now, I do not just check the amount. I check the sender name character by character against the name shown on the buyer's verified profile. This single habit exists because escrow only protects you if you actually use the information it gives you access to.
I paused the trade and asked about the mismatch directly in the official Binance P2P chat, which keeps a full record in case the situation needed escalating later. His explanation involved a family member's account, which happens sometimes, but Binance P2P's own transaction rules treat third party payments and name mismatches as violations regardless of the reason behind them. I did not release the crypto. I opened an appeal instead, explained the discrepancy clearly, and attached both the payment record and the profile screenshot showing the name difference.
Support reviewed it and the order was unwound, with the buyer's payment refunded rather than the trade completing. No loss on my end, and no funds released against a payment I could not fully verify.
I understand now why Binance P2P enforces this rule so strictly instead of leaving it as a suggestion. Third party payments make it nearly impossible to know who actually sent the money, which breaks the entire chain of accountability that KYC verification is supposed to guarantee in the first place. Treating a mismatch as minor undoes the protection the whole system was built around.
Reading names carefully takes ten extra seconds. Skipping that one step is how careful, experienced sellers still end up losing crypto to trades that looked completely normal at first glance.
@Binance Vietnam #BinanceP2PAnToan
$ACE
Binance P2P ties every account to a verified identity through KYC, and that identity is supposed to match the payment account used during a trade. When I confirm payment now, I do not just check the amount. I check the sender name character by character against the name shown on the buyer's verified profile. This single habit exists because escrow only protects you if you actually use the information it gives you access to.
I paused the trade and asked about the mismatch directly in the official Binance P2P chat, which keeps a full record in case the situation needed escalating later. His explanation involved a family member's account, which happens sometimes, but Binance P2P's own transaction rules treat third party payments and name mismatches as violations regardless of the reason behind them. I did not release the crypto. I opened an appeal instead, explained the discrepancy clearly, and attached both the payment record and the profile screenshot showing the name difference.
Support reviewed it and the order was unwound, with the buyer's payment refunded rather than the trade completing. No loss on my end, and no funds released against a payment I could not fully verify.
I understand now why Binance P2P enforces this rule so strictly instead of leaving it as a suggestion. Third party payments make it nearly impossible to know who actually sent the money, which breaks the entire chain of accountability that KYC verification is supposed to guarantee in the first place. Treating a mismatch as minor undoes the protection the whole system was built around.
Reading names carefully takes ten extra seconds. Skipping that one step is how careful, experienced sellers still end up losing crypto to trades that looked completely normal at first glance.
@Binance Vietnam #BinanceP2PAnToan
$ACE
Eu protejo uma compra na Binance P2P antes de eu clicar em Enviar. Os compradores muitas vezes se concentram em receber cripto, mas a transferência em dinheiro (fiat) é a parte que eu controlo e que pode ser difícil de reverter. Um destinatário errado, uma conta de terceiro ou uma instrução fora da plataforma pode transformar uma ordem protegida em um pagamento não suportado.
Meu primeiro check acontece no anúncio. Eu inspeciono o perfil do vendedor, o histórico de negociações visível, os sinais de conclusão, limites, método de pagamento e termos. Um preço um pouco melhor não compensa instruções pouco claras. Depois que eu abro a ordem, a garantia (escrow) reserva a cripto do vendedor, a KYC identifica os usuários, o chat da ordem registra a conversa e o Recurso de Apelação (Appeal) oferece um caminho para o Suporte da Binance. Eu mantenho cada etapa conectada àquela ordem.
Antes de pagar, eu comparo 4 itens: o número da ordem ao vivo, o valor exato em fiat, os detalhes do destinatário listados e o prazo de pagamento. Eu envio a partir de uma conta em meu nome verificado. Se o vendedor fornecer uma conta diferente no chat, pedir para eu pagar a um amigo, ou quiser várias transferências para nomes não relacionados, eu paro. Eu nunca continuo por um canal privado nem envio depois que a ordem expirar.
Depois que eu faço a transferência, eu verifico a transação no meu app de pagamento, guardo o ID e marco como pago apenas quando o dinheiro tiver saído de fato sob a ordem correta. Eu informo o vendedor no chat da ordem e depois aguardo a liberação. Eu não cancelo uma ordem paga só porque o vendedor pede, e não pago duas vezes para “destravar” a cripto em garantia. Essas solicitações criam uma lacuna entre o pagamento e a evidência na plataforma.
Se o vendedor não liberar ou contestar o recebimento, eu salvo a tela da ordem, o registro da transação, o beneficiário, o valor, o horário e o chat. Eu uso Appeal ou o Suporte oficial da Binance e respondo com as evidências solicitadas. A garantia (escrow) foi projetada para manter a cripto durante a análise, então pânico é desnecessário e um segundo acordo paralelo é perigoso.
Minha regra para o comprador é precisa: uma ordem ativa, um pagador verificado, um destinatário listado, um pagamento exato. Eu deixo o processo da Binance P2P conectar a prova em fiat à cripto em garantia do começo ao fim.
@Binance Vietnam #BinanceP2PAnToan
$BLESS
Meu primeiro check acontece no anúncio. Eu inspeciono o perfil do vendedor, o histórico de negociações visível, os sinais de conclusão, limites, método de pagamento e termos. Um preço um pouco melhor não compensa instruções pouco claras. Depois que eu abro a ordem, a garantia (escrow) reserva a cripto do vendedor, a KYC identifica os usuários, o chat da ordem registra a conversa e o Recurso de Apelação (Appeal) oferece um caminho para o Suporte da Binance. Eu mantenho cada etapa conectada àquela ordem.
Antes de pagar, eu comparo 4 itens: o número da ordem ao vivo, o valor exato em fiat, os detalhes do destinatário listados e o prazo de pagamento. Eu envio a partir de uma conta em meu nome verificado. Se o vendedor fornecer uma conta diferente no chat, pedir para eu pagar a um amigo, ou quiser várias transferências para nomes não relacionados, eu paro. Eu nunca continuo por um canal privado nem envio depois que a ordem expirar.
Depois que eu faço a transferência, eu verifico a transação no meu app de pagamento, guardo o ID e marco como pago apenas quando o dinheiro tiver saído de fato sob a ordem correta. Eu informo o vendedor no chat da ordem e depois aguardo a liberação. Eu não cancelo uma ordem paga só porque o vendedor pede, e não pago duas vezes para “destravar” a cripto em garantia. Essas solicitações criam uma lacuna entre o pagamento e a evidência na plataforma.
Se o vendedor não liberar ou contestar o recebimento, eu salvo a tela da ordem, o registro da transação, o beneficiário, o valor, o horário e o chat. Eu uso Appeal ou o Suporte oficial da Binance e respondo com as evidências solicitadas. A garantia (escrow) foi projetada para manter a cripto durante a análise, então pânico é desnecessário e um segundo acordo paralelo é perigoso.
Minha regra para o comprador é precisa: uma ordem ativa, um pagador verificado, um destinatário listado, um pagamento exato. Eu deixo o processo da Binance P2P conectar a prova em fiat à cripto em garantia do começo ao fim.
@Binance Vietnam #BinanceP2PAnToan
$BLESS
A pesquisa acadêmica em blockchain tem um problema de reputação: trabalhos brilhantes, provas elegantes e, depois, nada que um usuário comum alguma vez toque. Pergunte a qualquer pessoa que tenha assistido a uma conferência de criptografia e ela vai dizer que grande parte do que é publicado continua publicado.
A Babylon parece um alvo fácil para essa suposição no papel. O cofundador David Tse passou 18 anos lecionando na UC Berkeley antes de, por mais de uma década, atuar na Stanford, onde ainda dirige um laboratório de pesquisa, e a Babylon nem sequer tem um CEO: Tse atua como cientista de pesquisa enquanto o cofundador Fisher Yu lidera a engenharia como CTO. Essa é uma estrutura acadêmica, não a de uma startup típica.
O cronograma diz o contrário. BABE, o protocolo de verificação de prova Groth16 de Tse para o Bitcoin, chegou à testnet alfa da Babylon em fevereiro de 2026, alegando uma redução de cerca de 1.000x no custo de configuração e armazenamento para verificar provas de conhecimento zero no Bitcoin. Em 2 de junho, aproximadamente quatro meses depois, essa mesma pesquisa sustentou a integração pública da Aave v4 dos Trustless Bitcoin Vaults' na testnet, envolvendo a16z crypto, Ledger e GoMining ao mesmo tempo.
A Babylon não é um laboratório de pesquisa que apenas acontece de ter um token; é evidência de que uma estrutura de laboratório ainda pode entregar no ritmo de uma startup quando os incentivos se alinham. Se as economias de custo do BABE se mantêm quando usuários adversariais começarem a sondar os TBV na mainnet é a parte que apenas a pesquisa não consegue responder.
@BabylonLabs_io $BABY #baby
$BLESS
A Babylon parece um alvo fácil para essa suposição no papel. O cofundador David Tse passou 18 anos lecionando na UC Berkeley antes de, por mais de uma década, atuar na Stanford, onde ainda dirige um laboratório de pesquisa, e a Babylon nem sequer tem um CEO: Tse atua como cientista de pesquisa enquanto o cofundador Fisher Yu lidera a engenharia como CTO. Essa é uma estrutura acadêmica, não a de uma startup típica.
O cronograma diz o contrário. BABE, o protocolo de verificação de prova Groth16 de Tse para o Bitcoin, chegou à testnet alfa da Babylon em fevereiro de 2026, alegando uma redução de cerca de 1.000x no custo de configuração e armazenamento para verificar provas de conhecimento zero no Bitcoin. Em 2 de junho, aproximadamente quatro meses depois, essa mesma pesquisa sustentou a integração pública da Aave v4 dos Trustless Bitcoin Vaults' na testnet, envolvendo a16z crypto, Ledger e GoMining ao mesmo tempo.
A Babylon não é um laboratório de pesquisa que apenas acontece de ter um token; é evidência de que uma estrutura de laboratório ainda pode entregar no ritmo de uma startup quando os incentivos se alinham. Se as economias de custo do BABE se mantêm quando usuários adversariais começarem a sondar os TBV na mainnet é a parte que apenas a pesquisa não consegue responder.
@BabylonLabs_io $BABY #baby
$BLESS
A maioria dos protocolos de empréstimo faz pool de garantias porque a agregação é eficiente. Aave e Compound misturam os depósitos de milhares de usuários em mercados compartilhados, o que aprofunda a liquidez e aperta a precificação; e é exatamente nesse modelo de pool que se baseia a maior parte da eficiência de capital do DeFi. A Babylon analisou esse modelo ao projetar os Trustless Bitcoin Vaults e escolheu de propósito uma estrutura oposta.
Cada vault de TBV mantém um bitcoin de um único usuário, vinculado por meio de transações pré-assinadas a essa posição específica e a um estado específico de contrato inteligente externo. Nada é misturado. A Babylon e analistas externos que cobriram o lançamento descreveram essa segregação como direcionada com precisão ao conforto institucional e regulatório, já que o bitcoin de um vault permanece rastreável ao próprio depósito, em vez de se misturar a um pool compartilhado anônimo, como faria uma reserva fracionária de um banco. Vale notar que a Babylon está optando por acoplar esse design segregado ao Aave — justamente o tipo de protocolo de pool que ela recusou imitar — por meio da integração do Aave v4 esperada para meados de 2026, em vez de construir do zero o seu próprio mercado de lending em pool. O trade-off aparece imediatamente: vaults segregados não conseguem atingir a profundidade nem os spreads mais apertados que um pool compartilhado gera, e cada um carrega seu próprio overhead de configuração e monitoramento sob o BitVM3.
A Babylon não está otimizando o TBV para máxima eficiência de capital; ela está otimizando para auditabilidade e rastreabilidade por posição — uma aposta de que detentores institucionais de bitcoin pagarão um prêmio de liquidez por uma contabilidade mais limpa.
@BabylonLabs_io $BABY #baby
$WMTX
Cada vault de TBV mantém um bitcoin de um único usuário, vinculado por meio de transações pré-assinadas a essa posição específica e a um estado específico de contrato inteligente externo. Nada é misturado. A Babylon e analistas externos que cobriram o lançamento descreveram essa segregação como direcionada com precisão ao conforto institucional e regulatório, já que o bitcoin de um vault permanece rastreável ao próprio depósito, em vez de se misturar a um pool compartilhado anônimo, como faria uma reserva fracionária de um banco. Vale notar que a Babylon está optando por acoplar esse design segregado ao Aave — justamente o tipo de protocolo de pool que ela recusou imitar — por meio da integração do Aave v4 esperada para meados de 2026, em vez de construir do zero o seu próprio mercado de lending em pool. O trade-off aparece imediatamente: vaults segregados não conseguem atingir a profundidade nem os spreads mais apertados que um pool compartilhado gera, e cada um carrega seu próprio overhead de configuração e monitoramento sob o BitVM3.
A Babylon não está otimizando o TBV para máxima eficiência de capital; ela está otimizando para auditabilidade e rastreabilidade por posição — uma aposta de que detentores institucionais de bitcoin pagarão um prêmio de liquidez por uma contabilidade mais limpa.
@BabylonLabs_io $BABY #baby
$WMTX
Wrapped Bitcoin fez algo genuinamente importante para esta indústria: permitiu que a liquidez do Bitcoin aparecesse dentro do DeFi do Ethereum anos antes de qualquer coisa como os Trustless Bitcoin Vaults existir. O pitch da Babylon não funciona se você pular primeiro o crédito dado por esse wrapped BTC.
Mas a estrutura do wrapped BTC carrega um custo estrutural permanente. Um custodiante detém Bitcoins reais e emite um token sintético 1:1 contra isso, e cada unidade desse ativo sintético só é tão confiável quanto a solvência e a honestidade do custodiante. Mesmo em escala relevante, o wrapped BTC ainda representa bem menos de 1% do fornecimento total de Bitcoin: cerca de 150.000 BTC de pouco menos de 20 milhões — o que me diz que a maioria dos detentores de Bitcoin simplesmente recusou, em primeiro lugar, fazer esse tipo de transação com custódia.
A resposta da Babylon é remover o custodiante completamente da equação. BTC nativo faz um lock em um Taproot UTXO diretamente no próprio Bitcoin, e o Aave v4 empresta com base nessa posição bloqueada, de forma direta — então a moeda que dá lastro ao seu empréstimo nunca é cunhada como um IOU em algum outro lugar. Depositantes colocam como colateral Bitcoins reais e tomam emprestados ativos aceitos como USDC ou USDT no Ethereum, sem que esse colateral mude de forma.
A complicação honesta é que isso atualmente é uma public testnet, não comprovada em escala de mainnet, enquanto o wrapped BTC tem anos de histórico de produção por trás dele — incluindo erros. A Babylon está propondo um modelo estruturalmente mais seguro para um problema que o wrapped BTC já resolveu na prática, apenas de maneira imperfeita. Se o modelo estruturalmente mais seguro vence contra anos de infraestrutura já funcionando, esse é o verdadeiro embate aqui.
@BabylonLabs_io $BABY #baby
$GIGGLE
Mas a estrutura do wrapped BTC carrega um custo estrutural permanente. Um custodiante detém Bitcoins reais e emite um token sintético 1:1 contra isso, e cada unidade desse ativo sintético só é tão confiável quanto a solvência e a honestidade do custodiante. Mesmo em escala relevante, o wrapped BTC ainda representa bem menos de 1% do fornecimento total de Bitcoin: cerca de 150.000 BTC de pouco menos de 20 milhões — o que me diz que a maioria dos detentores de Bitcoin simplesmente recusou, em primeiro lugar, fazer esse tipo de transação com custódia.
A resposta da Babylon é remover o custodiante completamente da equação. BTC nativo faz um lock em um Taproot UTXO diretamente no próprio Bitcoin, e o Aave v4 empresta com base nessa posição bloqueada, de forma direta — então a moeda que dá lastro ao seu empréstimo nunca é cunhada como um IOU em algum outro lugar. Depositantes colocam como colateral Bitcoins reais e tomam emprestados ativos aceitos como USDC ou USDT no Ethereum, sem que esse colateral mude de forma.
A complicação honesta é que isso atualmente é uma public testnet, não comprovada em escala de mainnet, enquanto o wrapped BTC tem anos de histórico de produção por trás dele — incluindo erros. A Babylon está propondo um modelo estruturalmente mais seguro para um problema que o wrapped BTC já resolveu na prática, apenas de maneira imperfeita. Se o modelo estruturalmente mais seguro vence contra anos de infraestrutura já funcionando, esse é o verdadeiro embate aqui.
@BabylonLabs_io $BABY #baby
$GIGGLE
Aqui vai um detalhe que acredito que a maioria dos resumos rápidos dos Cofres de Bitcoin sem confiança da Babylon ignora completamente, e vale a pena considerar, porque isso complica a narrativa “sem wrapping, nunca” de forma bem limpa. No Aave v4, se uma posição nativa com colateral em Bitcoin for liquidada, o Spoke de Troca do BTC Vault permite que os liquidantes façam a troca dessa posição de BTC apreendida por WBTC, para que a liquidação aconteça rapidamente, com o Bitcoin nativo real sendo resgatado depois na rede Bitcoin por meio do sistema de provas da Babylon.
Então o Bitcoin “wrapped” aparece aqui, só não exatamente onde os usuários normalmente esperam. Depositantes fazem o aporte com BTC genuinamente nativo como colateral, e essa parte da reivindicação é totalmente verdadeira: seu Bitcoin fica na rede Bitcoin o tempo todo enquanto você toma empréstimos usando esse colateral. Mas a infraestrutura de liquidação no backend usa uma representação “wrapped” especificamente para resolver uma incompatibilidade real de timing: o Bitcoin liquida mais devagar que o Ethereum, e os liquidantes precisam agir rápido quando uma posição fica em situação não saudável.
Não vejo isso como uma contradição, mas como uma troca honesta de engenharia que a linguagem de marketing tende a suavizar. A Babylon está trazendo liquidez em Bitcoin nativo para o Ethereum com esse desenho, e usar um ativo “wrapped” por alguns segundos rápidos durante a liquidação é algo muito diferente de exigir que os usuários façam wrapping do próprio Bitcoin apenas para conseguir participar.
Ainda assim, eu preferiria que as pessoas entendessem essa nuance já no testnet público, em vez de descobrir isso depois e se sentir enganadas. “Trustless” descreve a camada de custódia e verificação do colateral aqui. Isso não significa que o Bitcoin “wrapped” tenha desaparecido completamente do sistema; apenas foi empurrado para um canto mais específico e de movimentação mais rápida dele.
@BabylonLabs_io $BABY #baby
$COTI
Então o Bitcoin “wrapped” aparece aqui, só não exatamente onde os usuários normalmente esperam. Depositantes fazem o aporte com BTC genuinamente nativo como colateral, e essa parte da reivindicação é totalmente verdadeira: seu Bitcoin fica na rede Bitcoin o tempo todo enquanto você toma empréstimos usando esse colateral. Mas a infraestrutura de liquidação no backend usa uma representação “wrapped” especificamente para resolver uma incompatibilidade real de timing: o Bitcoin liquida mais devagar que o Ethereum, e os liquidantes precisam agir rápido quando uma posição fica em situação não saudável.
Não vejo isso como uma contradição, mas como uma troca honesta de engenharia que a linguagem de marketing tende a suavizar. A Babylon está trazendo liquidez em Bitcoin nativo para o Ethereum com esse desenho, e usar um ativo “wrapped” por alguns segundos rápidos durante a liquidação é algo muito diferente de exigir que os usuários façam wrapping do próprio Bitcoin apenas para conseguir participar.
Ainda assim, eu preferiria que as pessoas entendessem essa nuance já no testnet público, em vez de descobrir isso depois e se sentir enganadas. “Trustless” descreve a camada de custódia e verificação do colateral aqui. Isso não significa que o Bitcoin “wrapped” tenha desaparecido completamente do sistema; apenas foi empurrado para um canto mais específico e de movimentação mais rápida dele.
@BabylonLabs_io $BABY #baby
$COTI
Mencione empréstimos com lastro em Bitcoin para qualquer pessoa que estivesse prestando atenção em 2022 e você provavelmente terá a mesma reação: foi assim que as pessoas perderam tudo. Celsius, BlockFi, Genesis e Hodlnaut congelaram saques e entraram com pedido de falência em cerca de seis meses entre si, e o setor perdeu mais de 10 bilhões de dólares em ativos dos clientes naquele único ano. Esse histórico é real, não exagerado, e é um estereótipo totalmente razoável levar adiante em qualquer novo produto de empréstimo com BTC.
O estereótipo se mantém porque o padrão de falha continuou o mesmo em todos eles. Investigações posteriores apontaram para rehypothecation, plataformas reutilizando silenciosamente o colateral do cliente para suas próprias operações e apostas, além de descompassos de maturidade e exposição concentrada a um punhado de contrapartes que acabaram quebrando no mesmo período. Os clientes não tinham uma forma real de ver qualquer coisa disso acontecendo de fora até que fosse tarde demais.
Trustless Bitcoin Vaults são construídos para tornar esse modo específico de falha estruturalmente impossível, em vez de apenas prometer um comportamento melhor desta vez. Não há um custodiante mantendo o BTC do cliente para rehypothecá-lo em primeiro lugar, não existe um consórcio de signatários fazendo chamadas discricionárias, e as moedas de cada vault permanecem bloqueadas em um único relacionamento específico e isolado com um contrato inteligente, em vez de serem reunidas em um balanço geral que uma empresa pode emprestar silenciosamente.
Babylon não é uma versão melhor gerida da Celsius; é um animal estruturalmente diferente. As quedas de 2022 aconteceram porque as moedas dos clientes ficavam em contas que empresas podiam acessar. Em TBV, não há conta e nem uma empresa entre o vault e o código que o governa.
@BabylonLabs_io $BABY #baby
$BANK
O estereótipo se mantém porque o padrão de falha continuou o mesmo em todos eles. Investigações posteriores apontaram para rehypothecation, plataformas reutilizando silenciosamente o colateral do cliente para suas próprias operações e apostas, além de descompassos de maturidade e exposição concentrada a um punhado de contrapartes que acabaram quebrando no mesmo período. Os clientes não tinham uma forma real de ver qualquer coisa disso acontecendo de fora até que fosse tarde demais.
Trustless Bitcoin Vaults são construídos para tornar esse modo específico de falha estruturalmente impossível, em vez de apenas prometer um comportamento melhor desta vez. Não há um custodiante mantendo o BTC do cliente para rehypothecá-lo em primeiro lugar, não existe um consórcio de signatários fazendo chamadas discricionárias, e as moedas de cada vault permanecem bloqueadas em um único relacionamento específico e isolado com um contrato inteligente, em vez de serem reunidas em um balanço geral que uma empresa pode emprestar silenciosamente.
Babylon não é uma versão melhor gerida da Celsius; é um animal estruturalmente diferente. As quedas de 2022 aconteceram porque as moedas dos clientes ficavam em contas que empresas podiam acessar. Em TBV, não há conta e nem uma empresa entre o vault e o código que o governa.
@BabylonLabs_io $BABY #baby
$BANK
Os Cofres de Bitcoin Sem Confiança nunca foram projetados para fazer apenas uma coisa. O material da própria roadmap da Babylon descreve a mesma primitiva de cofre alimentando negociações de perp com garantia em BTC e também a emissão de stablecoins atreladas ao dólar, lastreadas estritamente em Bitcoin nativo, além de empréstimos (lending). Três primeiros produtos plausíveis, uma única peça de tecnologia subjacente.
A Babylon escolheu lending e escolheu especificamente a Aave para começar. Essa é uma decisão com lógica real por trás. Perps precisam de uma liquidez profunda e de derivativos que se movimentam rapidamente, além de market makers dispostos a cotar contra um tipo de garantia totalmente novo. A emissão de stablecoin precisa de sua própria campanha de credibilidade para mais um token de dólar em um mercado que já está lotado deles. Emprestar contra o maior protocolo DeFi em liquidez contorna ambos os problemas: a Aave já tem tomadores (borrowers), depositantes (depositors) e uma infraestrutura de liquidação que funciona há anos; assim, a tecnologia do cofre recebe um canal de distribuição comprovado em vez de ter de construir demanda do zero.
O custo-benefício é que lending também é a categoria mais disputada e a mais observada para lançar, competindo diretamente com todas as outras formas de garantia em BTC que a Aave já lista. A Babylon escolheu a sala mais difícil para entrar primeiro porque era também a que já estava construída e cheia de liquidez.
A Babylon não está escolhendo lending porque é a aplicação mais fácil do TBV; perps e emissão de stablecoins estão na mesma roadmap. A Babylon está escolhendo lending porque a Aave já fornece liquidez e usuários que um novo ambiente de perps ou stablecoin teria que construir do zero.
@BabylonLabs_io $BABY #baby
$DEXE $BANK
A Babylon escolheu lending e escolheu especificamente a Aave para começar. Essa é uma decisão com lógica real por trás. Perps precisam de uma liquidez profunda e de derivativos que se movimentam rapidamente, além de market makers dispostos a cotar contra um tipo de garantia totalmente novo. A emissão de stablecoin precisa de sua própria campanha de credibilidade para mais um token de dólar em um mercado que já está lotado deles. Emprestar contra o maior protocolo DeFi em liquidez contorna ambos os problemas: a Aave já tem tomadores (borrowers), depositantes (depositors) e uma infraestrutura de liquidação que funciona há anos; assim, a tecnologia do cofre recebe um canal de distribuição comprovado em vez de ter de construir demanda do zero.
O custo-benefício é que lending também é a categoria mais disputada e a mais observada para lançar, competindo diretamente com todas as outras formas de garantia em BTC que a Aave já lista. A Babylon escolheu a sala mais difícil para entrar primeiro porque era também a que já estava construída e cheia de liquidez.
A Babylon não está escolhendo lending porque é a aplicação mais fácil do TBV; perps e emissão de stablecoins estão na mesma roadmap. A Babylon está escolhendo lending porque a Aave já fornece liquidez e usuários que um novo ambiente de perps ou stablecoin teria que construir do zero.
@BabylonLabs_io $BABY #baby
$DEXE $BANK
No script de staking de “Babylon’s”, há uma pequena escolha criptográfica que diz muito sobre as prioridades da equipe. A saída de des-vinculação (unbonding) em cada UTXO apostado é uma saída do tipo Taproot, e saídas Taproot normalmente suportam duas formas de gasto: um caminho de chave rápido (key path) ou um caminho de script mais lento, com condições explícitas escritas nele. Babylon desabilita completamente o caminho de chave, usando o que é chamado de ponto NUMS, como se não houvesse nada “na manga”, como a chave interna — um valor construído de modo que ninguém possa ter uma chave privada para ele nem sequer em teoria.
Essa única escolha força que cada transação de unbonding passe pelo caminho de script, aquele que exige um quórum de assinaturas do comitê de covenant definida por um limiar específico configurado nos parâmetros da cadeia. Um atalho via caminho de chave teria sido mais simples de implementar e mais barato para gastar. Além disso, teria criado uma saída sem auditoria (unauditable) que contornaria toda a lógica de slashing e unbonding em torno da qual o protocolo foi construído. Babylon escolheu de propósito a rota mais lenta e totalmente condicionada.
Babylon não está escolhendo conveniência aqui; está escolhendo restrição verificável, fechando um atalho que a maioria dos usuários jamais notaria. Essa única decisão de script revela um hábito: quando eficiência e auditabilidade entram em conflito na camada base, esta equipe escolhe auditabilidade. Isso só aparece quando você lê o script, não o deck de apresentação.
@BabylonLabs_io $BABY #baby
$LAB
Essa única escolha força que cada transação de unbonding passe pelo caminho de script, aquele que exige um quórum de assinaturas do comitê de covenant definida por um limiar específico configurado nos parâmetros da cadeia. Um atalho via caminho de chave teria sido mais simples de implementar e mais barato para gastar. Além disso, teria criado uma saída sem auditoria (unauditable) que contornaria toda a lógica de slashing e unbonding em torno da qual o protocolo foi construído. Babylon escolheu de propósito a rota mais lenta e totalmente condicionada.
Babylon não está escolhendo conveniência aqui; está escolhendo restrição verificável, fechando um atalho que a maioria dos usuários jamais notaria. Essa única decisão de script revela um hábito: quando eficiência e auditabilidade entram em conflito na camada base, esta equipe escolhe auditabilidade. Isso só aparece quando você lê o script, não o deck de apresentação.
@BabylonLabs_io $BABY #baby
$LAB
Certa vez, um empreiteiro me disse que a forma mais rápida de estourar um orçamento de reforma é gastar igualmente com o que as pessoas veem e com o que elas não veem. Renovadores inteligentes colocam dinheiro no que é visível e aceitam a complexidade oculta por trás das paredes. Os engenheiros da Babylon fizeram um cálculo semelhante com o BitVM3.
A pesquisa do BitVM3 por trás dos cofres da Babylon relata uma redução de cerca de 1000x nos custos de disputas on-chain em comparação com o design anterior do BitVM2, com uma transação de assert custando aproximadamente US$ 5 e uma transação de disprove por menos de US$ 0,20. Essa é a vitória visível: uma economia on-chain barata, utilizável, para algo que antes era proibitivamente caro de contestar.
O custo-benefício fica por trás das paredes. Obter essa redução de custo significa mover a maior parte da computação para fora do Bitcoin, inteiramente, para circuitos embaralhados que um desafiante avalia fora da cadeia, em vez de postar na blockchain pedaço por pedaço. Uma revisão técnica independente observa que esses circuitos chegam a dezenas de gigabytes de tamanho e dependem de infraestrutura comum de servidor para armazenar e transmitir, infraestrutura que fica totalmente fora das garantias de segurança do Bitcoin — um fato que raramente aparece na chamada principal.
Assim, o design não eliminou complexidade: apenas a realocou de uma forma on-chain cara para uma forma barata, porém fora da cadeia. Esse é um trade-off de engenharia defendível para uma camada base tão limitada quanto a do Bitcoin: computação on-chain cara jamais seria capaz de escalar para o volume real de DeFi, independentemente de como as taxas fossem estruturadas. Esse único número — cinco dólares versus uma fração de centavo — está fazendo muito trabalho para tornar todo o modelo de cofres comercialmente viável em escala no Bitcoin.
A equipe da Babylon escolheu acessibilidade em vez de minimizar a superfície de confiança off-chain e, dado os limites de scripting do Bitcoin, isso parece ser o único trade-off que permite que cofres funcionem a um custo utilizável.
@BabylonLabs_io $BABY #baby
$DEXE
A pesquisa do BitVM3 por trás dos cofres da Babylon relata uma redução de cerca de 1000x nos custos de disputas on-chain em comparação com o design anterior do BitVM2, com uma transação de assert custando aproximadamente US$ 5 e uma transação de disprove por menos de US$ 0,20. Essa é a vitória visível: uma economia on-chain barata, utilizável, para algo que antes era proibitivamente caro de contestar.
O custo-benefício fica por trás das paredes. Obter essa redução de custo significa mover a maior parte da computação para fora do Bitcoin, inteiramente, para circuitos embaralhados que um desafiante avalia fora da cadeia, em vez de postar na blockchain pedaço por pedaço. Uma revisão técnica independente observa que esses circuitos chegam a dezenas de gigabytes de tamanho e dependem de infraestrutura comum de servidor para armazenar e transmitir, infraestrutura que fica totalmente fora das garantias de segurança do Bitcoin — um fato que raramente aparece na chamada principal.
Assim, o design não eliminou complexidade: apenas a realocou de uma forma on-chain cara para uma forma barata, porém fora da cadeia. Esse é um trade-off de engenharia defendível para uma camada base tão limitada quanto a do Bitcoin: computação on-chain cara jamais seria capaz de escalar para o volume real de DeFi, independentemente de como as taxas fossem estruturadas. Esse único número — cinco dólares versus uma fração de centavo — está fazendo muito trabalho para tornar todo o modelo de cofres comercialmente viável em escala no Bitcoin.
A equipe da Babylon escolheu acessibilidade em vez de minimizar a superfície de confiança off-chain e, dado os limites de scripting do Bitcoin, isso parece ser o único trade-off que permite que cofres funcionem a um custo utilizável.
@BabylonLabs_io $BABY #baby
$DEXE
Um colega de turma entrou em uma universidade de alto nível por admissão de legado, e todo mundo presumiu que o diploma, sozinho, garantiria a carreira. Três anos depois de se formar, ele ainda estava tentando se firmar, assim como o resto de nós. A carta provou acesso, não resultado.
A lista de apoiadores da Babylon parece uma checklist de fundos de venture capital cripto de primeira linha: uma rodada seed de US$ 8 milhões em janeiro de 2022 liderada pela IDG Capital e pela Breyer Capital, uma Série A de US$ 18 milhões em dezembro de 2023 vinda da Polychain Capital, Hack VC, Castle Island Ventures e Symbolic Capital, e uma rodada de US$ 70 milhões em maio de 2024 liderada pela Paradigm, com Hashkey Capital e Polychain retornando. O total arrecadado fica em torno de US$ 96 milhões de investidores que também incluem Binance Labs, Galaxy Digital e Amber Group. Esse capital e reputação realmente reduziram o atrito de distribuição: a Babylon se integrou ao Bitget Wallet, OKX Wallet e Binance Earn bem antes de muitos outros projetos concorrentes de BTCFi, e os próprios anúncios das rodadas de financiamento geraram atenção real do mercado a cada vez. Mas capital e integrações são entradas, não resultados. A divulgação de uma vulnerabilidade em extensão de voto do BLS em janeiro de 2026 aconteceu em uma empresa apoiada por todos os nomes acima. Preocupações com tokenomics sobre uma concentração interna de cerca de 66% surgiram dos membros da comunidade, apesar de, e não por causa, do elenco de investidores. Um forte apoio de VC prevê com mais confiabilidade uma pista mais longa e melhor acesso à distribuição do que prevê execução impecável, e o histórico de um ano de operação da própria Babylon mostra tanto pontos fortes quanto tropeços acontecendo sob o mesmo guarda-chuva de financiamento.
A lista de investidores da Babylon não é uma garantia de resultados técnicos ou de tokenomics. Ela comprou fôlego, credibilidade e distribuição — nenhum desses fatores impediu as vulnerabilidades nem as preocupações com concentração que acabaram surgindo mesmo assim.
@BabylonLabs_io $BABY #baby
$DEXE
A lista de apoiadores da Babylon parece uma checklist de fundos de venture capital cripto de primeira linha: uma rodada seed de US$ 8 milhões em janeiro de 2022 liderada pela IDG Capital e pela Breyer Capital, uma Série A de US$ 18 milhões em dezembro de 2023 vinda da Polychain Capital, Hack VC, Castle Island Ventures e Symbolic Capital, e uma rodada de US$ 70 milhões em maio de 2024 liderada pela Paradigm, com Hashkey Capital e Polychain retornando. O total arrecadado fica em torno de US$ 96 milhões de investidores que também incluem Binance Labs, Galaxy Digital e Amber Group. Esse capital e reputação realmente reduziram o atrito de distribuição: a Babylon se integrou ao Bitget Wallet, OKX Wallet e Binance Earn bem antes de muitos outros projetos concorrentes de BTCFi, e os próprios anúncios das rodadas de financiamento geraram atenção real do mercado a cada vez. Mas capital e integrações são entradas, não resultados. A divulgação de uma vulnerabilidade em extensão de voto do BLS em janeiro de 2026 aconteceu em uma empresa apoiada por todos os nomes acima. Preocupações com tokenomics sobre uma concentração interna de cerca de 66% surgiram dos membros da comunidade, apesar de, e não por causa, do elenco de investidores. Um forte apoio de VC prevê com mais confiabilidade uma pista mais longa e melhor acesso à distribuição do que prevê execução impecável, e o histórico de um ano de operação da própria Babylon mostra tanto pontos fortes quanto tropeços acontecendo sob o mesmo guarda-chuva de financiamento.
A lista de investidores da Babylon não é uma garantia de resultados técnicos ou de tokenomics. Ela comprou fôlego, credibilidade e distribuição — nenhum desses fatores impediu as vulnerabilidades nem as preocupações com concentração que acabaram surgindo mesmo assim.
@BabylonLabs_io $BABY #baby
$DEXE
Uma companhia aérea de baixo custo perto de mim foi lançada com outdoors dizendo "voamos para todo lugar". O mapa de rotas real no lançamento cobria seis cidades, sem rotas internacionais, e metade do mapa doméstico tinha a indicação "em breve". Ainda penso em como "todo lugar" foi impresso com tanta confiança antes de o cronograma confirmar.
O lançamento do app mobile da GRVT seguiu uma linguagem parecida. Quando o app Android chegou à Google Play Store em 29 de maio de 2025, o comunicado à imprensa descreveu que ele traria "toda a potência da plataforma de negociação da GRVT para usuários no mundo todo, na ponta dos dedos", e a fala do CEO mencionou tornar a GRVT "o principal marketplace financeiro onchain, em que todos possam acessar com facilidade ferramentas poderosas". O desdobramento real naquele momento foi apenas Android, disponível em 50 países específicos citados no anúncio — lugares como Argentina, Japão, Coreia do Sul e Vietnã, entre outros — não um lançamento global em massa. A versão para iOS não fazia parte daquele lançamento; a nota disse que chegaria "em momento oportuno", sem data comprometida. Qualquer pessoa que lesse "no mundo todo" e "todos" no dia do lançamento e depois verificasse a App Store do iPhone não encontraria nada para baixar. As duas plataformas estão no ar agora, cerca de um ano depois, e a lista de 50 países provavelmente cresceu, mas a lacuna no próprio dia do lançamento era real: um título de "no mundo todo, todos" sustentado por um lançamento de plataforma única, com uma lista fixa de países e um app-irmão sem agendamento. Isso não é incomum para uma startup que entrega em etapas: a maioria das empresas faz uma fase do rollout enquanto promove o destino, em vez do passo atual. A discrepância importa porque "no mundo todo" e "todos" são palavras absolutas, e palavras absolutas convidam alguém a compará-las com a lista real, do mesmo jeito que eu comparei o mapa daquele avião com o outdoor.
A linguagem de lançamento mobile da GRVT de "no mundo todo, todos" não correspondia ao que existia no primeiro dia: um lançamento apenas para Android em 50 países nomeados, com o iOS sem data agendada — uma lacuna que vale notar em qualquer alegação de lançamento.
@grvt_io #grvt
$LAB $VELVET
O lançamento do app mobile da GRVT seguiu uma linguagem parecida. Quando o app Android chegou à Google Play Store em 29 de maio de 2025, o comunicado à imprensa descreveu que ele traria "toda a potência da plataforma de negociação da GRVT para usuários no mundo todo, na ponta dos dedos", e a fala do CEO mencionou tornar a GRVT "o principal marketplace financeiro onchain, em que todos possam acessar com facilidade ferramentas poderosas". O desdobramento real naquele momento foi apenas Android, disponível em 50 países específicos citados no anúncio — lugares como Argentina, Japão, Coreia do Sul e Vietnã, entre outros — não um lançamento global em massa. A versão para iOS não fazia parte daquele lançamento; a nota disse que chegaria "em momento oportuno", sem data comprometida. Qualquer pessoa que lesse "no mundo todo" e "todos" no dia do lançamento e depois verificasse a App Store do iPhone não encontraria nada para baixar. As duas plataformas estão no ar agora, cerca de um ano depois, e a lista de 50 países provavelmente cresceu, mas a lacuna no próprio dia do lançamento era real: um título de "no mundo todo, todos" sustentado por um lançamento de plataforma única, com uma lista fixa de países e um app-irmão sem agendamento. Isso não é incomum para uma startup que entrega em etapas: a maioria das empresas faz uma fase do rollout enquanto promove o destino, em vez do passo atual. A discrepância importa porque "no mundo todo" e "todos" são palavras absolutas, e palavras absolutas convidam alguém a compará-las com a lista real, do mesmo jeito que eu comparei o mapa daquele avião com o outdoor.
A linguagem de lançamento mobile da GRVT de "no mundo todo, todos" não correspondia ao que existia no primeiro dia: um lançamento apenas para Android em 50 países nomeados, com o iOS sem data agendada — uma lacuna que vale notar em qualquer alegação de lançamento.
@grvt_io #grvt
$LAB $VELVET
Eu já havia baixado a versão mobile de um aplicativo de trading que eu já usava no desktop, esperando o mesmo kit de ferramentas no bolso. Metade dos tipos de ordens que eu usava diariamente simplesmente não estavam disponíveis na tela do celular, e eu tinha que voltar ao laptop sempre que quisesse fazer algo além de uma ordem básica de mercado.
A GRVT lançou seus apps para Android e iOS, financiados em parte pelos US$ 14,3 milhões que a empresa havia captado até janeiro de 2025 — uma rodada que incluiu um aporte estratégico de US$ 5 milhões da Further Ventures, uma empresa apoiada pelo fundo soberano de Abu Dhabi, a ADQ. No lançamento, os apps móveis ofereciam suporte a mais de 40 pares de trading perpétuos, uma fatia relevante dos cerca de 168 mercados disponíveis na plataforma completa, mas ainda distante do catálogo inteiro. A diferença entre "a GRVT é uma plataforma completa e de custódia própria" e "o app móvel da GRVT cobre um subconjunto do que a plataforma realmente lista" importa para qualquer pessoa que suponha equivalência na App Store com a experiência do desktop, por padrão. Um trader que gerencia posições em pares mais nichados fora daqueles primeiros 40 pode acabar precisando de um navegador mesmo depois de baixar o app especificamente para operar em movimento. A cobertura móvel provavelmente se expandiu desde aquela contagem inicial, dado o ritmo de crescimento da lista geral de mercados em toda a plataforma, mas a lacuna de “completude divulgada” versus “completude entregue” vale a pena ser observada antes de assumir que qualquer recurso exista em todas as telas que a marca toca. A mesma rodada de financiamento que pagou pelos apps também apoiou o trabalho central de infraestrutura; isso significa que o desenvolvimento mobile competiu por recursos com o back end da exchange, em vez de rodar, desde o primeiro dia, como uma trilha independente totalmente equipada.
Os apps móveis da GRVT não são apenas uma janela menor para a mesma plataforma completa: eles foram entregues com menos recursos do que a experiência do desktop — vale verificar antes de depender de um telefone para qualquer coisa além dos pares mais comuns.
@grvt_io #grvt
$LAB
A GRVT lançou seus apps para Android e iOS, financiados em parte pelos US$ 14,3 milhões que a empresa havia captado até janeiro de 2025 — uma rodada que incluiu um aporte estratégico de US$ 5 milhões da Further Ventures, uma empresa apoiada pelo fundo soberano de Abu Dhabi, a ADQ. No lançamento, os apps móveis ofereciam suporte a mais de 40 pares de trading perpétuos, uma fatia relevante dos cerca de 168 mercados disponíveis na plataforma completa, mas ainda distante do catálogo inteiro. A diferença entre "a GRVT é uma plataforma completa e de custódia própria" e "o app móvel da GRVT cobre um subconjunto do que a plataforma realmente lista" importa para qualquer pessoa que suponha equivalência na App Store com a experiência do desktop, por padrão. Um trader que gerencia posições em pares mais nichados fora daqueles primeiros 40 pode acabar precisando de um navegador mesmo depois de baixar o app especificamente para operar em movimento. A cobertura móvel provavelmente se expandiu desde aquela contagem inicial, dado o ritmo de crescimento da lista geral de mercados em toda a plataforma, mas a lacuna de “completude divulgada” versus “completude entregue” vale a pena ser observada antes de assumir que qualquer recurso exista em todas as telas que a marca toca. A mesma rodada de financiamento que pagou pelos apps também apoiou o trabalho central de infraestrutura; isso significa que o desenvolvimento mobile competiu por recursos com o back end da exchange, em vez de rodar, desde o primeiro dia, como uma trilha independente totalmente equipada.
Os apps móveis da GRVT não são apenas uma janela menor para a mesma plataforma completa: eles foram entregues com menos recursos do que a experiência do desktop — vale verificar antes de depender de um telefone para qualquer coisa além dos pares mais comuns.
@grvt_io #grvt
$LAB
O prédio de escritórios em que eu costumava trabalhar tinha um processo normal para qualquer reforma: enviar um pedido, aguardar uma comissão de avaliação, obter uma licença e, então, aguardar um período de notificação obrigatório antes que as equipes pudessem mexer em qualquer coisa estrutural. Havia exatamente uma exceção para todo esse processo: um painel de segurança contra incêndios que um pequeno grupo de funcionários sêniores podia acionar imediatamente durante uma emergência ativa, sem período de espera, sem comitê, com ação em questão de minutos.
A estrutura de governança do ZKsync, em cuja cadeia está inserida a do GRVT, tem uma análogo a essa exceção. As atualizações de protocolo comuns seguem um atraso obrigatório de aproximadamente 4 dias e 3 horas até 8 dias e 3 horas antes que possam ser executadas, dando tempo à comunidade para notar e reagir a qualquer coisa suspeita em uma mudança de código proposta. Mas existe um caminho contornando todo esse período de espera: o Emergency Upgrade Board (Conselho de Atualização de Emergência), formado pelo Security Council, pelos Guardians e pelo ZK Foundation Multisig atuando em conjunto, pode fazer uma atualização passar imediatamente, sem qualquer atraso. Esse mecanismo existe por um motivo real: uma vulnerabilidade crítica descoberta no meio de um ataque não pode esperar 4 dias por uma janela de revisão comunitária antes de ser corrigida. Porém, a mesma rota rápida que permite ao time interromper um exploit ativo em minutos também é, por design, uma forma de um pequeno grupo coordenado aprovar uma mudança de contrato com nenhuma divulgação pública, caso eles optem por isso. Nada no próprio mecanismo informa a observadores externos qual cenário está, de fato, acontecendo em qualquer momento em que ele é acionado.
Se o Emergency Upgrade Board é uma válvula de segurança necessária ou um risco de centralização depende inteiramente da situação em que ele é usado, e os usuários do GRVT não têm como distinguir um patch de emergência de um patch apressado até depois do fato. Nenhuma das interpretações está totalmente errada, e a posição honesta é que o dilema ainda não foi resolvido — apenas aceito como o custo de agir rápido quando importa.
@grvt_io #grvt
$LAB
A estrutura de governança do ZKsync, em cuja cadeia está inserida a do GRVT, tem uma análogo a essa exceção. As atualizações de protocolo comuns seguem um atraso obrigatório de aproximadamente 4 dias e 3 horas até 8 dias e 3 horas antes que possam ser executadas, dando tempo à comunidade para notar e reagir a qualquer coisa suspeita em uma mudança de código proposta. Mas existe um caminho contornando todo esse período de espera: o Emergency Upgrade Board (Conselho de Atualização de Emergência), formado pelo Security Council, pelos Guardians e pelo ZK Foundation Multisig atuando em conjunto, pode fazer uma atualização passar imediatamente, sem qualquer atraso. Esse mecanismo existe por um motivo real: uma vulnerabilidade crítica descoberta no meio de um ataque não pode esperar 4 dias por uma janela de revisão comunitária antes de ser corrigida. Porém, a mesma rota rápida que permite ao time interromper um exploit ativo em minutos também é, por design, uma forma de um pequeno grupo coordenado aprovar uma mudança de contrato com nenhuma divulgação pública, caso eles optem por isso. Nada no próprio mecanismo informa a observadores externos qual cenário está, de fato, acontecendo em qualquer momento em que ele é acionado.
Se o Emergency Upgrade Board é uma válvula de segurança necessária ou um risco de centralização depende inteiramente da situação em que ele é usado, e os usuários do GRVT não têm como distinguir um patch de emergência de um patch apressado até depois do fato. Nenhuma das interpretações está totalmente errada, e a posição honesta é que o dilema ainda não foi resolvido — apenas aceito como o custo de agir rápido quando importa.
@grvt_io #grvt
$LAB
A GRVT se promove em torno de auto custódia, fundos que nunca são mantidos por um terceiro, com o controle em poder do trader. Seu fundo de seguro, silenciosamente, complica essa proposta. Quando uma posição liquidada é encerrada a um preço pior do que seu preço de falência, a diferença precisa vir de algum lugar; e, na GRVT, assim como em quase toda exchange alavancada, esse “algum lugar” é um pool compartilhado de capital, financiado por taxas de liquidação arrecadadas de todos os traders na plataforma.
Esse pool, na prática, é um risco de contraparte compartilhado. Se o fundo de seguro secar durante um evento extremo, o “respaldo” muda para auto deleveraging (auto desestabilização), em que traders lucrativos podem ter suas posições vencedoras fechadas à força para cobrir a falta de outra pessoa. Nem um nem outro mecanismo tem qualquer relação com quem mantém as chaves privadas da sua garantia. A auto custódia protege seus ativos contra a empresa GRVT; ela não faz nada para proteger seu PnL aberto da realidade matemática de que derivativos alavancados exigem alguma forma de socialização de perdas quando uma posição vai à falência mais rápido do que pode ser encerrada.
Isso não é uma falha exclusiva da GRVT; todo venue sério de futuros perpétuos funciona dessa forma. Mas isso significa que a proposta de auto custódia e a proposta do fundo de seguro respondem a duas perguntas diferentes. Uma é sobre a custódia do seu capital. A outra é sobre quem absorve a perda quando o mercado se move mais rápido do que o motor de liquidação consegue reagir, e a auto custódia nunca iria responder sozinho à segunda pergunta. Eu penso nisso toda vez que um projeto se posiciona puramente pelo ângulo da auto custódia sem mencionar o fundo de seguro na mesma conversa, porque os dois mecanismos estão respondendo a questões de risco completamente diferentes, e misturá-las deixa o trader com uma falsa sensação de quão protegidos realmente estão seus lucros não realizados durante um evento de cauda genuíno em qualquer venue alavancado, incluindo a GRVT.
@grvt_io #grvt
$LAB
Esse pool, na prática, é um risco de contraparte compartilhado. Se o fundo de seguro secar durante um evento extremo, o “respaldo” muda para auto deleveraging (auto desestabilização), em que traders lucrativos podem ter suas posições vencedoras fechadas à força para cobrir a falta de outra pessoa. Nem um nem outro mecanismo tem qualquer relação com quem mantém as chaves privadas da sua garantia. A auto custódia protege seus ativos contra a empresa GRVT; ela não faz nada para proteger seu PnL aberto da realidade matemática de que derivativos alavancados exigem alguma forma de socialização de perdas quando uma posição vai à falência mais rápido do que pode ser encerrada.
Isso não é uma falha exclusiva da GRVT; todo venue sério de futuros perpétuos funciona dessa forma. Mas isso significa que a proposta de auto custódia e a proposta do fundo de seguro respondem a duas perguntas diferentes. Uma é sobre a custódia do seu capital. A outra é sobre quem absorve a perda quando o mercado se move mais rápido do que o motor de liquidação consegue reagir, e a auto custódia nunca iria responder sozinho à segunda pergunta. Eu penso nisso toda vez que um projeto se posiciona puramente pelo ângulo da auto custódia sem mencionar o fundo de seguro na mesma conversa, porque os dois mecanismos estão respondendo a questões de risco completamente diferentes, e misturá-las deixa o trader com uma falsa sensação de quão protegidos realmente estão seus lucros não realizados durante um evento de cauda genuíno em qualquer venue alavancado, incluindo a GRVT.
@grvt_io #grvt
$LAB
Inicia sessão para explorar mais conteúdos