Binance Square
Lào Thoại Ngân
269 Publicações

Lào Thoại Ngân

278 A seguir
70 Seguidores
132 Gostaram
Publicações
·
--
Eu precisava converter uma quantidade relativamente grande para USDT no mês passado — mais do que eu normalmente opero em uma única ordem — então fiz algo que eu normalmente não faço: abri quatro perfis diferentes de comerciantes lado a lado no Binance P2P antes de escolher um. Os números contaram uma história mais clara do que qualquer descrição de anúncio isolada. Um comerciante tinha uma taxa de conclusão de 98% em mais de 3000 transações. Outro tinha um preço parecido, mas apenas 60 negociações no total e uma taxa de conclusão em 91%. Um terceiro parecia atraente só pelo preço até eu perceber que o tempo médio de liberação deles era bem mais lento do que o dos demais. O Binance P2P mostra esses dados por um motivo, e comparar isso antes de uma negociação é uma das formas mais simples de verificação de contraparte disponíveis — ao lado de conferir o status do KYC e ler comentários recentes das ordens. Cada parte da transação, da mensagem inicial até a confirmação final, precisa ficar dentro do aplicativo também; como mover comunicação ou pagamento para fora da plataforma por uma taxa um pouco melhor remove a proteção que o Binance P2P oferece, incluindo o bloqueio do escrow e o caminho de apelação da disputa caso algo dê errado. Para uma ordem grande especificamente, minha lista de verificação mudou um pouco. Eu parei de selecionar automaticamente o preço mais alto. Li a última página de comentários no perfil de um comerciante, não apenas a avaliação por estrelas. Eu tratei um tempo de liberação incomumente lento ou uma conta recém-criada oferecendo limites incomumente altos como um sinal de alerta que valia evitar, em vez de uma “pechincha” para correr atrás. Eu dividi o total em duas negociações menores com dois comerciantes verificados diferentes, em vez de fazer uma grande transferência para uma única contraparte — principalmente para limitar a exposição enquanto eu ainda estava aprendendo em quem confiava. Eu confirmei que o pagamento tinha sido compensado na minha própria conta antes de considerar qualquer uma das negociações como concluída, e guardei todas as capturas de tela e números de pedido depois, caso eu precisasse deles para o suporte. O tamanho altera o nível de risco de uma negociação, então ele também deve mudar o quanto você olha com cuidado antes de começar uma. @Binance_Vietnam #BinanceP2PAnToan $BTW $BLESS $TUT Como você negocia ordens P2P grandes?
Eu precisava converter uma quantidade relativamente grande para USDT no mês passado — mais do que eu normalmente opero em uma única ordem — então fiz algo que eu normalmente não faço: abri quatro perfis diferentes de comerciantes lado a lado no Binance P2P antes de escolher um.

Os números contaram uma história mais clara do que qualquer descrição de anúncio isolada. Um comerciante tinha uma taxa de conclusão de 98% em mais de 3000 transações. Outro tinha um preço parecido, mas apenas 60 negociações no total e uma taxa de conclusão em 91%. Um terceiro parecia atraente só pelo preço até eu perceber que o tempo médio de liberação deles era bem mais lento do que o dos demais. O Binance P2P mostra esses dados por um motivo, e comparar isso antes de uma negociação é uma das formas mais simples de verificação de contraparte disponíveis — ao lado de conferir o status do KYC e ler comentários recentes das ordens. Cada parte da transação, da mensagem inicial até a confirmação final, precisa ficar dentro do aplicativo também; como mover comunicação ou pagamento para fora da plataforma por uma taxa um pouco melhor remove a proteção que o Binance P2P oferece, incluindo o bloqueio do escrow e o caminho de apelação da disputa caso algo dê errado.

Para uma ordem grande especificamente, minha lista de verificação mudou um pouco. Eu parei de selecionar automaticamente o preço mais alto. Li a última página de comentários no perfil de um comerciante, não apenas a avaliação por estrelas. Eu tratei um tempo de liberação incomumente lento ou uma conta recém-criada oferecendo limites incomumente altos como um sinal de alerta que valia evitar, em vez de uma “pechincha” para correr atrás. Eu dividi o total em duas negociações menores com dois comerciantes verificados diferentes, em vez de fazer uma grande transferência para uma única contraparte — principalmente para limitar a exposição enquanto eu ainda estava aprendendo em quem confiava. Eu confirmei que o pagamento tinha sido compensado na minha própria conta antes de considerar qualquer uma das negociações como concluída, e guardei todas as capturas de tela e números de pedido depois, caso eu precisasse deles para o suporte.

O tamanho altera o nível de risco de uma negociação, então ele também deve mudar o quanto você olha com cuidado antes de começar uma.

@Binance Vietnam #BinanceP2PAnToan $BTW $BLESS $TUT

Como você negocia ordens P2P grandes?
Compare merchant history
Check reviews first
Split into smaller trades
Prioritize the best price
9 hora(s) restante(s)
Um perfil com zero pedidos concluídos me chamou querendo comprar US$ 4000 em cripto na Binance P2P em uma única negociação. Sem histórico, sem avaliações, conta criada na mesma semana. Eu não recusei automaticamente, já que todo mundo começa em algum lugar, mas desacelerei todo o processo e tratei como um estudo de caso do que a verificação realmente é para fazer. A Binance P2P exige que cada usuário passe pela verificação de identidade antes de negociar, o que já filtra uma grande parcela de golpistas casuais que dependem do anonimato. Além disso, com base nesse ponto de partida, eu analiso três coisas antes de aceitar qualquer contraparte: sua taxa de conclusão, há quanto tempo a conta existe e o padrão dos tamanhos das negociações anteriores. Alguém que vai direto de nenhum histórico para um pedido grande não é prova de má intenção, mas aumenta o nível de cuidado que eu uso para confirmar o pagamento. Para essa negociação em particular, pedi para dividi-la em duas ordens menores em vez de uma grande. Ele concordou sem resistência, o que me disse mais do que qualquer insígnia poderia. No meio do caminho, conferi diretamente no meu aplicativo bancário, em vez de confiar na notificação de pagamento que ele enviou no chat, confirmei que o valor exato havia caído e só então liberei a cripto de cada parte. Sinais de alerta que eu observo além da idade da conta: pedidos para sair do chat oficial da Binance P2P, linguagem de urgência me empurrando a pular etapas e comprovantes de pagamento que chegam suspeitosamente rápido sem um número de referência do banco anexado. Nada disso apareceu aqui, então a negociação foi encerrada sem problemas. Dividir o pedido também me deu um ponto de checagem natural. Se a primeira parte tivesse dado errado de qualquer forma, eu teria parado antes mesmo de a segunda movimentação de pagamento acontecer, em vez de comprometer o valor total adiantado com alguém com quem eu não tinha nenhum histórico. Eu ainda salvei o número do pedido e a confirmação bancária das duas partes, porque manter registros não custa nada e o suporte da Binance P2P vai sempre pedir isso caso algo seja contestado mais tarde. Novos traders merecem uma chance justa, mas uma chance justa não é a mesma coisa que pular a verificação. @Binance_Vietnam #BinanceP2PAnToan $BTW $BLESS
Um perfil com zero pedidos concluídos me chamou querendo comprar US$ 4000 em cripto na Binance P2P em uma única negociação. Sem histórico, sem avaliações, conta criada na mesma semana. Eu não recusei automaticamente, já que todo mundo começa em algum lugar, mas desacelerei todo o processo e tratei como um estudo de caso do que a verificação realmente é para fazer.

A Binance P2P exige que cada usuário passe pela verificação de identidade antes de negociar, o que já filtra uma grande parcela de golpistas casuais que dependem do anonimato. Além disso, com base nesse ponto de partida, eu analiso três coisas antes de aceitar qualquer contraparte: sua taxa de conclusão, há quanto tempo a conta existe e o padrão dos tamanhos das negociações anteriores. Alguém que vai direto de nenhum histórico para um pedido grande não é prova de má intenção, mas aumenta o nível de cuidado que eu uso para confirmar o pagamento.

Para essa negociação em particular, pedi para dividi-la em duas ordens menores em vez de uma grande. Ele concordou sem resistência, o que me disse mais do que qualquer insígnia poderia. No meio do caminho, conferi diretamente no meu aplicativo bancário, em vez de confiar na notificação de pagamento que ele enviou no chat, confirmei que o valor exato havia caído e só então liberei a cripto de cada parte.

Sinais de alerta que eu observo além da idade da conta: pedidos para sair do chat oficial da Binance P2P, linguagem de urgência me empurrando a pular etapas e comprovantes de pagamento que chegam suspeitosamente rápido sem um número de referência do banco anexado. Nada disso apareceu aqui, então a negociação foi encerrada sem problemas.

Dividir o pedido também me deu um ponto de checagem natural. Se a primeira parte tivesse dado errado de qualquer forma, eu teria parado antes mesmo de a segunda movimentação de pagamento acontecer, em vez de comprometer o valor total adiantado com alguém com quem eu não tinha nenhum histórico.

Eu ainda salvei o número do pedido e a confirmação bancária das duas partes, porque manter registros não custa nada e o suporte da Binance P2P vai sempre pedir isso caso algo seja contestado mais tarde. Novos traders merecem uma chance justa, mas uma chance justa não é a mesma coisa que pular a verificação.

@Binance Vietnam #BinanceP2PAnToan $BTW $BLESS
Uso o nome em um pagamento P2P da Binance como um sinal de segurança, não como mera formalidade. Um perigo comum começa quando o comprador diz que um cônjuge, cliente, colega ou empresa enviará o dinheiro. O depósito pode ser real, mas a pessoa cujos fundos foram movimentados pode não ser a contraparte verificada. Isso pode indicar um golpe em forma de triângulo, uma transferência contestada ou uma conta sendo usada sem autorização clara. Minha lista de verificação começa pelo pedido, não pelo alerta do banco. Eu analiso o perfil da contraparte, a atividade concluída, os termos e o método de pagamento. O KYC ajuda a estabelecer a identidade do usuário da Binance, enquanto o escrow reserva a criptomoeda durante a negociação. Em seguida, eu comparo esse nome verificado com o nome do pagador que aparece na minha conta de pagamento. Se não forem iguais, eu não libero, não negocio uma solução alternativa e não devolvo fundos para uma nova conta fornecida no chat. Eu mantenho a conversa no chat do pedido e descrevo a divergência de forma clara. Isso importa porque o Suporte da Binance pode inspecionar a linha do tempo na plataforma se houver necessidade de apelação. Um pedido para discutir em outro lugar, dividir o pagamento entre vários remetentes, ocultar uma observação relacionada a cripto ou solicitar reembolso para um beneficiário diferente aumenta ainda mais o risco. Eu tiro capturas de tela ou registro do pedido, dos dados do pagador, do ID da transação, do valor e do chat, sem expor isso publicamente. A verificação do pagamento ainda vem em seguida. Mesmo com um nome compatível, eu abro o aplicativo oficial do banco ou da carteira, confirmo se o valor exato foi creditado e pode ser usado, e ignoro capturas de tela ou mensagens de “pagamento bem-sucedido” do comprador. Alinhamento de identidade não substitui confirmação de recebimento, e confirmação de recebimento não desculpa uma divergência de identidade. Quando os fatos não batem, eu deixo o ativo em escrow e seleciono Apelação ou entro em contato com o Suporte da Binance pela plataforma oficial. Prefiro explicar uma liberação atrasada com evidências do que transformar um pagamento suspeito em uma perda irreversível. Minha regra tem 3 linhas que precisam bater: identidade na Binance, nome da conta de pagamento e detalhes do pedido. Se uma linha falhar, a negociação pausa. @Binance_Vietnam #BinanceP2PAnToan $BTW $ON $HFT
Uso o nome em um pagamento P2P da Binance como um sinal de segurança, não como mera formalidade. Um perigo comum começa quando o comprador diz que um cônjuge, cliente, colega ou empresa enviará o dinheiro. O depósito pode ser real, mas a pessoa cujos fundos foram movimentados pode não ser a contraparte verificada. Isso pode indicar um golpe em forma de triângulo, uma transferência contestada ou uma conta sendo usada sem autorização clara.

Minha lista de verificação começa pelo pedido, não pelo alerta do banco. Eu analiso o perfil da contraparte, a atividade concluída, os termos e o método de pagamento. O KYC ajuda a estabelecer a identidade do usuário da Binance, enquanto o escrow reserva a criptomoeda durante a negociação. Em seguida, eu comparo esse nome verificado com o nome do pagador que aparece na minha conta de pagamento. Se não forem iguais, eu não libero, não negocio uma solução alternativa e não devolvo fundos para uma nova conta fornecida no chat.

Eu mantenho a conversa no chat do pedido e descrevo a divergência de forma clara. Isso importa porque o Suporte da Binance pode inspecionar a linha do tempo na plataforma se houver necessidade de apelação. Um pedido para discutir em outro lugar, dividir o pagamento entre vários remetentes, ocultar uma observação relacionada a cripto ou solicitar reembolso para um beneficiário diferente aumenta ainda mais o risco. Eu tiro capturas de tela ou registro do pedido, dos dados do pagador, do ID da transação, do valor e do chat, sem expor isso publicamente.

A verificação do pagamento ainda vem em seguida. Mesmo com um nome compatível, eu abro o aplicativo oficial do banco ou da carteira, confirmo se o valor exato foi creditado e pode ser usado, e ignoro capturas de tela ou mensagens de “pagamento bem-sucedido” do comprador. Alinhamento de identidade não substitui confirmação de recebimento, e confirmação de recebimento não desculpa uma divergência de identidade.

Quando os fatos não batem, eu deixo o ativo em escrow e seleciono Apelação ou entro em contato com o Suporte da Binance pela plataforma oficial. Prefiro explicar uma liberação atrasada com evidências do que transformar um pagamento suspeito em uma perda irreversível. Minha regra tem 3 linhas que precisam bater: identidade na Binance, nome da conta de pagamento e detalhes do pedido. Se uma linha falhar, a negociação pausa.

@Binance Vietnam #BinanceP2PAnToan $BTW $ON $HFT
""Não são as suas chaves, não são as suas moedas" tem sido o mais antigo aviso do mundo cripto, e na maior parte das vezes foi direcionado a exchanges. Babylon aplica a mesma lógica em algum lugar onde as pessoas raramente pensam em pedir: o próprio empréstimo em DeFi. Depositantes que usam Trustless Bitcoin Vaults mantêm o controle do seu Bitcoin durante todo o empréstimo; ele fica bloqueado na rede Bitcoin em uma saída Taproot, em vez de ser movido para a custódia de uma mesa de empréstimos ou para a carteira-reserva de uma ponte. Quero ser preciso sobre o que, de fato, a autogestão (self-custodial) cobre aqui, porque acho que a frase é usada de forma um pouco limpa demais no marketing cripto em geral. As chaves privadas que controlam o resgate ficam com o endereço designado pelo depositante. Mas o sistema como um todo ainda depende de outros participantes se comportarem corretamente: Provedores de Vaults que gerenciam as reivindicações do cofre, Arbitrageurs que compram a garantia apreendida durante liquidações e Universal Challengers que monitoram tentativas inválidas de resgate. Nenhum deles consegue mover seu BTC sem uma prova válida, e qualquer um deles, incluindo você, pode contestar uma reivindicação ruim. Isso é significativamente diferente de risco de custódia, mas não é ausência completa de dependência de outras pessoas. O que o Babylon realmente removeu é o ponto único de falha: nenhum custodiante consegue congelar fundos, nenhum operador de ponte pode desaparecer com a reserva, nenhum quórum de signatários pode se combinar para mover moedas fora das regras escritas no próprio script Taproot. Ter ativos suportados por empréstimo, como USDC ou USDT, contra BTC nativo por meio do Aave v4, enquanto seu Bitcoin permanece exatamente onde você o travou, é uma mudança estrutural real em relação a como o lending lastreado em BTC tem funcionado até agora, mesmo que "trustless" descreva a matemática em vez de um mundo sem atores restantes. @babylonlabs_io $BTW $GRVT #baby $BABY {spot}(BABYUSDT)
""Não são as suas chaves, não são as suas moedas" tem sido o mais antigo aviso do mundo cripto, e na maior parte das vezes foi direcionado a exchanges. Babylon aplica a mesma lógica em algum lugar onde as pessoas raramente pensam em pedir: o próprio empréstimo em DeFi. Depositantes que usam Trustless Bitcoin Vaults mantêm o controle do seu Bitcoin durante todo o empréstimo; ele fica bloqueado na rede Bitcoin em uma saída Taproot, em vez de ser movido para a custódia de uma mesa de empréstimos ou para a carteira-reserva de uma ponte.

Quero ser preciso sobre o que, de fato, a autogestão (self-custodial) cobre aqui, porque acho que a frase é usada de forma um pouco limpa demais no marketing cripto em geral. As chaves privadas que controlam o resgate ficam com o endereço designado pelo depositante. Mas o sistema como um todo ainda depende de outros participantes se comportarem corretamente: Provedores de Vaults que gerenciam as reivindicações do cofre, Arbitrageurs que compram a garantia apreendida durante liquidações e Universal Challengers que monitoram tentativas inválidas de resgate. Nenhum deles consegue mover seu BTC sem uma prova válida, e qualquer um deles, incluindo você, pode contestar uma reivindicação ruim. Isso é significativamente diferente de risco de custódia, mas não é ausência completa de dependência de outras pessoas.

O que o Babylon realmente removeu é o ponto único de falha: nenhum custodiante consegue congelar fundos, nenhum operador de ponte pode desaparecer com a reserva, nenhum quórum de signatários pode se combinar para mover moedas fora das regras escritas no próprio script Taproot. Ter ativos suportados por empréstimo, como USDC ou USDT, contra BTC nativo por meio do Aave v4, enquanto seu Bitcoin permanece exatamente onde você o travou, é uma mudança estrutural real em relação a como o lending lastreado em BTC tem funcionado até agora, mesmo que "trustless" descreva a matemática em vez de um mundo sem atores restantes.

@BabylonLabs_io $BTW $GRVT #baby $BABY
A maioria das pessoas que conhece Babylon a conhece primeiro como uma camada de segurança, um protocolo que permite que o peso econômico do Bitcoin sustente a finalização das cadeias de prova de participação (proof of stake). Isso não é pouca coisa. Estender a segurança do Bitcoin para blockchains PoS resolve um problema real: cadeias jovens ou menores não têm décadas de poder de hash acumulado ou participação econômica por trás delas, então a Babylon empresta a elas a credibilidade do Bitcoin. Tenho pensado nessa missão original enquanto lia o recente anúncio do Trustless Bitcoin Vaults, porque a linha que conecta tudo é mais consistente do que eu esperava. Trustless Bitcoin Vaults segue o mesmo instinto: usa a confiança e a segurança do Bitcoin sem enfraquecê-las e aplica isso a empréstimos. O primeiro caso de uso, empréstimo nativo com lastro em Bitcoin usando Aave v4, já está ativo em testnet pública, com várias marcas importantes já testando. Os depositantes colocam BTC nativo como garantia e tomam ativos como USDC ou USDT na Ethereum, e nada disso exige wrapping (empacotamento) ou bridging da garantia subjacente. O que eu quero entender melhor é se as garantias de segurança do lado do staking realmente se traduzem para as mecânicas do cofre (vault), ou se são 2 modelos de confiança separados rodando sob uma mesma marca. A Babylon ainda não respondeu totalmente isso na documentação pública, pelo menos até onde encontrei, e é um detalhe técnico que define se é uma arquitetura coerente ou 2 boas ideias simplesmente acopladas. De todo modo, a ambição é consistente: tornar o Bitcoin útil sem pedir que qualquer pessoa confie em um terceiro com ele. @babylonlabs_io $BTW $GRVT $BABY #baby {spot}(BABYUSDT)
A maioria das pessoas que conhece Babylon a conhece primeiro como uma camada de segurança, um protocolo que permite que o peso econômico do Bitcoin sustente a finalização das cadeias de prova de participação (proof of stake). Isso não é pouca coisa. Estender a segurança do Bitcoin para blockchains PoS resolve um problema real: cadeias jovens ou menores não têm décadas de poder de hash acumulado ou participação econômica por trás delas, então a Babylon empresta a elas a credibilidade do Bitcoin. Tenho pensado nessa missão original enquanto lia o recente anúncio do Trustless Bitcoin Vaults, porque a linha que conecta tudo é mais consistente do que eu esperava.

Trustless Bitcoin Vaults segue o mesmo instinto: usa a confiança e a segurança do Bitcoin sem enfraquecê-las e aplica isso a empréstimos. O primeiro caso de uso, empréstimo nativo com lastro em Bitcoin usando Aave v4, já está ativo em testnet pública, com várias marcas importantes já testando. Os depositantes colocam BTC nativo como garantia e tomam ativos como USDC ou USDT na Ethereum, e nada disso exige wrapping (empacotamento) ou bridging da garantia subjacente.

O que eu quero entender melhor é se as garantias de segurança do lado do staking realmente se traduzem para as mecânicas do cofre (vault), ou se são 2 modelos de confiança separados rodando sob uma mesma marca. A Babylon ainda não respondeu totalmente isso na documentação pública, pelo menos até onde encontrei, e é um detalhe técnico que define se é uma arquitetura coerente ou 2 boas ideias simplesmente acopladas. De todo modo, a ambição é consistente: tornar o Bitcoin útil sem pedir que qualquer pessoa confie em um terceiro com ele.

@BabylonLabs_io $BTW $GRVT $BABY #baby
Mostre a maioria das pessoas um título sobre o Bitcoin se tornando garantia em DeFi e elas assumem que é o mesmo truque de novo: cunhar um token em algum lugar, chamá-lo de Bitcoin e seguir em frente. Essa reação não é “estúpida”. Menos de 1% de todo o bitcoin está hoje em plataformas de contratos inteligentes, e quase toda rota que o leva até lá envolve um wrapper ou um custodiante que guarda as moedas reais enquanto uma versão sintética circula. Os Babylon Trustless Bitcoin Vaults foram construídos justamente contra esse padrão. Quando o empréstimo nativo com Bitcoin como garantia entrou no ar na rede de testes pública do Aave v4 em 2 de junho de 2026, o BTC envolvido nunca deixou a cadeia do Bitcoin. Ele fica trancado em um Taproot UTXO, e o Aave reconhece a posição por meio de um token com transferência restrita chamado vaultBTC, que representa o vault em vez de substituir a moeda. Compare isso com como o Bitcoin “wrapado” funciona há anos: em que um emissor centralizado mantém BTC em reserva e cunha um ativo separado em outro lugar — uma estrutura para a qual o próprio paper de vault da Babylon aponta diretamente ao argumentar que a adoção de Bitcoin wrapado e custodial permaneceu limitada em relação ao suprimento total do Bitcoin. O sinal de que este é um modelo diferente, não apenas uma embalagem mais “caprichada” em cima de um antigo, apareceu novamente em março de 2026, quando a Babylon fez parceria com a Ledger para que seus 8 milhões de usuários de carteira de hardware pudessem aprovar ações do vault via Clear Signing, lendo a transação real na própria tela do dispositivo, em vez de confiar em um pop-up do navegador ou na palavra de um emissor. A Babylon não está rebatizando o Bitcoin wrapado com um marketing melhor; ela está recusando o movimento central desse modelo, a parte em que a custódia silenciosamente muda de mãos. TBV ainda carrega seus próprios riscos, principalmente ligados aos liquidadores e oráculos do Aave, mas “outro coin wrapado” não é um deles. @babylonlabs_io $AKE $BTW $BABY #baby
Mostre a maioria das pessoas um título sobre o Bitcoin se tornando garantia em DeFi e elas assumem que é o mesmo truque de novo: cunhar um token em algum lugar, chamá-lo de Bitcoin e seguir em frente. Essa reação não é “estúpida”. Menos de 1% de todo o bitcoin está hoje em plataformas de contratos inteligentes, e quase toda rota que o leva até lá envolve um wrapper ou um custodiante que guarda as moedas reais enquanto uma versão sintética circula.

Os Babylon Trustless Bitcoin Vaults foram construídos justamente contra esse padrão. Quando o empréstimo nativo com Bitcoin como garantia entrou no ar na rede de testes pública do Aave v4 em 2 de junho de 2026, o BTC envolvido nunca deixou a cadeia do Bitcoin. Ele fica trancado em um Taproot UTXO, e o Aave reconhece a posição por meio de um token com transferência restrita chamado vaultBTC, que representa o vault em vez de substituir a moeda. Compare isso com como o Bitcoin “wrapado” funciona há anos: em que um emissor centralizado mantém BTC em reserva e cunha um ativo separado em outro lugar — uma estrutura para a qual o próprio paper de vault da Babylon aponta diretamente ao argumentar que a adoção de Bitcoin wrapado e custodial permaneceu limitada em relação ao suprimento total do Bitcoin.

O sinal de que este é um modelo diferente, não apenas uma embalagem mais “caprichada” em cima de um antigo, apareceu novamente em março de 2026, quando a Babylon fez parceria com a Ledger para que seus 8 milhões de usuários de carteira de hardware pudessem aprovar ações do vault via Clear Signing, lendo a transação real na própria tela do dispositivo, em vez de confiar em um pop-up do navegador ou na palavra de um emissor.

A Babylon não está rebatizando o Bitcoin wrapado com um marketing melhor; ela está recusando o movimento central desse modelo, a parte em que a custódia silenciosamente muda de mãos. TBV ainda carrega seus próprios riscos, principalmente ligados aos liquidadores e oráculos do Aave, mas “outro coin wrapado” não é um deles.

@BabylonLabs_io $AKE $BTW $BABY #baby
Toda vez que eu menciono os Cofres de Bitcoin Sem Custódia (Trustless) da Babylon para alguém novo, a primeira pergunta é alguma versão disso: então basicamente é WBTC com etapas extras. Eu entendo o reflexo. Os detentores de Bitcoin observaram anos de falhas em bridges e problemas de custódia, e o atalho mental de que um novo produto de Bitcoin equivale a um novo token “wrapped” (empacotado) equivale a um novo risco de contraparte não é uma hipótese sem fundamento antes de sair carregando isso. Aqui, porém, está errado, e os mecanismos mostram por quê. Produtos de Wrapped BTC como o WBTC funcionam ao entregar moedas a um custodiante que cunha um token correspondente em outro lugar: assim, os usuários confiam que uma única entidade mantenha as reservas com honestidade e continue solvente. Bridges movem BTC ao roteá-lo por meio de uma federação de signatários que, em conjunto, controlam os fundos. A TBV não faz isso. O bitcoin permanece em um cofre de auto-custódia, pré-assinado, na própria blockchain do Bitcoin, e ele nunca é representado como um IOU (título) livremente negociável em outra rede. O acesso é condicionado por uma prova de conhecimento zero vinculada a um estado específico de um contrato inteligente externo, e não pela promessa de uma entidade de resgatar um token 1:1. Uma figura amplamente citada resume o problema que a TBV busca enfrentar: mais de 99% do bitcoin fica ocioso, com cerca de 1% tocando DeFi o tempo todo, majoritariamente por meio de produtos wrapped custodiados. A Babylon não está operando um negócio de “wrapping” e a TBV não é uma bridge, apesar de como a proposta possa soar familiar na primeira menção. O design foi construído para remover duas coisas — o custodiante e a federação —, não para embalá-las novamente. @babylonlabs_io $BTW $AKE $BABY #baby
Toda vez que eu menciono os Cofres de Bitcoin Sem Custódia (Trustless) da Babylon para alguém novo, a primeira pergunta é alguma versão disso: então basicamente é WBTC com etapas extras. Eu entendo o reflexo. Os detentores de Bitcoin observaram anos de falhas em bridges e problemas de custódia, e o atalho mental de que um novo produto de Bitcoin equivale a um novo token “wrapped” (empacotado) equivale a um novo risco de contraparte não é uma hipótese sem fundamento antes de sair carregando isso.

Aqui, porém, está errado, e os mecanismos mostram por quê. Produtos de Wrapped BTC como o WBTC funcionam ao entregar moedas a um custodiante que cunha um token correspondente em outro lugar: assim, os usuários confiam que uma única entidade mantenha as reservas com honestidade e continue solvente. Bridges movem BTC ao roteá-lo por meio de uma federação de signatários que, em conjunto, controlam os fundos. A TBV não faz isso. O bitcoin permanece em um cofre de auto-custódia, pré-assinado, na própria blockchain do Bitcoin, e ele nunca é representado como um IOU (título) livremente negociável em outra rede. O acesso é condicionado por uma prova de conhecimento zero vinculada a um estado específico de um contrato inteligente externo, e não pela promessa de uma entidade de resgatar um token 1:1. Uma figura amplamente citada resume o problema que a TBV busca enfrentar: mais de 99% do bitcoin fica ocioso, com cerca de 1% tocando DeFi o tempo todo, majoritariamente por meio de produtos wrapped custodiados.

A Babylon não está operando um negócio de “wrapping” e a TBV não é uma bridge, apesar de como a proposta possa soar familiar na primeira menção. O design foi construído para remover duas coisas — o custodiante e a federação —, não para embalá-las novamente.

@BabylonLabs_io $BTW $AKE $BABY #baby
Suas chaves, seu Bitcoin — parece simples até você ler as entrelinhas de como um cofre de custódia própria realmente cumpre essa promessa quando algo dá errado. Eu li especificamente a documentação da testnet da Babylon para encontrar essas entrelinhas, porque slogans não sobrevivem ao contato com casos-limite. Cofres de Bitcoin sem confiança (trustless) depositam BTC em um cofre onde, em condições normais, um Provedor de Cofre faz a redenção do lado do Bitcoin quando um empréstimo é quitado. Mas o design da Babylon não para por aí. A cada usuário baixa um arquivo de par de chaves WOTS e artefatos do claimer no momento em que o cofre é criado — existentes justamente para que o depositante consiga resgatar seu próprio Bitcoin sem precisar do Provedor de Cofre, caso esse provedor fique offline. Isso é uma garantia real de auto custódia, não uma frase de marketing. Nenhuma terceira parte, custodiante ou consórcio de signatários detém poder discricionário sobre o BTC subjacente. Mas isso vem com uma responsabilidade que eu não acho que usuários casuais ainda entendam plenamente: o par de chaves WOTS não pode ser regenerado se for perdido, e a própria orientação da Babylon diz para tratar perdê-lo com a mesma seriedade de perder uma frase-semente de carteira. Gosto de existir esse plano de contingência. Estou menos certo de que o depositante médio, ao fazer backup de mais um arquivo secreto irrepetível, além da frase-semente, tenha sido resolvido em termos de UX pela Babylon ainda. Trustlessness genuíno tem um custo, e aqui o custo é a responsabilidade pessoal. @babylonlabs_io $1000RATS $GRVT $BABY #baby
Suas chaves, seu Bitcoin — parece simples até você ler as entrelinhas de como um cofre de custódia própria realmente cumpre essa promessa quando algo dá errado. Eu li especificamente a documentação da testnet da Babylon para encontrar essas entrelinhas, porque slogans não sobrevivem ao contato com casos-limite.

Cofres de Bitcoin sem confiança (trustless) depositam BTC em um cofre onde, em condições normais, um Provedor de Cofre faz a redenção do lado do Bitcoin quando um empréstimo é quitado. Mas o design da Babylon não para por aí. A cada usuário baixa um arquivo de par de chaves WOTS e artefatos do claimer no momento em que o cofre é criado — existentes justamente para que o depositante consiga resgatar seu próprio Bitcoin sem precisar do Provedor de Cofre, caso esse provedor fique offline.

Isso é uma garantia real de auto custódia, não uma frase de marketing. Nenhuma terceira parte, custodiante ou consórcio de signatários detém poder discricionário sobre o BTC subjacente. Mas isso vem com uma responsabilidade que eu não acho que usuários casuais ainda entendam plenamente: o par de chaves WOTS não pode ser regenerado se for perdido, e a própria orientação da Babylon diz para tratar perdê-lo com a mesma seriedade de perder uma frase-semente de carteira.

Gosto de existir esse plano de contingência. Estou menos certo de que o depositante médio, ao fazer backup de mais um arquivo secreto irrepetível, além da frase-semente, tenha sido resolvido em termos de UX pela Babylon ainda. Trustlessness genuíno tem um custo, e aqui o custo é a responsabilidade pessoal.

@BabylonLabs_io $1000RATS $GRVT $BABY #baby
A cada poucos meses surge mais um produto de DeFi de Bitcoin prometendo acesso nativo e sem confiança, e a cada poucos meses acaba ficando claro que significa exatamente o mesmo token cunhado por um custodiante, apenas com um novo nome anexado. WBTC existe desde 2019, cbBTC desde o fim de 2024, e, juntos, ainda representam menos de 1% da capitalização total de mercado do Bitcoin. Isso não é um erro de arredondamento: é um sinal de que a maior parte dos detentores de BTC nunca confiou o suficiente no modelo de “wrap” para usá-lo em escala. Então, quando li pela primeira vez que Trustless Bitcoin Vaults também cunha algo chamado vaultBTC no Ethereum, minha reação imediata foi ceticismo, porque, no papel, isso soa exatamente como WBTC com uma rebrand. Um token que representa Bitcoin bloqueado, cunhado no Ethereum, usado como garantia. Mesma forma, mesmo pitch, eu presumi. A diferença aparece quando você olha para quem consegue mover esse token e por quê. WBTC e cbBTC são cunhados e queimados a critério de um custodiante. As transferências de vaultBTC são restritas ao Aave V4 Hub, ao Babylon Core Spoke e ao contrato de adapter, e o resgate de volta para Bitcoin nativo passa por uma prova de conhecimento zero de um evento no Ethereum, em vez de uma assinatura de um custodiante. Não existe um consórcio de signatários e nem uma terceira parte com controle discricionário sobre o BTC subjacente. De longe, parece um token “wrapped”. De perto, a autoridade de mintagem é criptografia, não uma empresa. Babylon não está rodando um wrapper custodial com copy de marketing melhor. vaultBTC só existe como um recibo restrito para BTC que criptografia, não um custodiante, concordou em liberar — e essa distinção é o cerne do design. @babylonlabs_io $BANK $ON $BABY #baby
A cada poucos meses surge mais um produto de DeFi de Bitcoin prometendo acesso nativo e sem confiança, e a cada poucos meses acaba ficando claro que significa exatamente o mesmo token cunhado por um custodiante, apenas com um novo nome anexado. WBTC existe desde 2019, cbBTC desde o fim de 2024, e, juntos, ainda representam menos de 1% da capitalização total de mercado do Bitcoin. Isso não é um erro de arredondamento: é um sinal de que a maior parte dos detentores de BTC nunca confiou o suficiente no modelo de “wrap” para usá-lo em escala.

Então, quando li pela primeira vez que Trustless Bitcoin Vaults também cunha algo chamado vaultBTC no Ethereum, minha reação imediata foi ceticismo, porque, no papel, isso soa exatamente como WBTC com uma rebrand. Um token que representa Bitcoin bloqueado, cunhado no Ethereum, usado como garantia. Mesma forma, mesmo pitch, eu presumi.

A diferença aparece quando você olha para quem consegue mover esse token e por quê. WBTC e cbBTC são cunhados e queimados a critério de um custodiante. As transferências de vaultBTC são restritas ao Aave V4 Hub, ao Babylon Core Spoke e ao contrato de adapter, e o resgate de volta para Bitcoin nativo passa por uma prova de conhecimento zero de um evento no Ethereum, em vez de uma assinatura de um custodiante. Não existe um consórcio de signatários e nem uma terceira parte com controle discricionário sobre o BTC subjacente. De longe, parece um token “wrapped”. De perto, a autoridade de mintagem é criptografia, não uma empresa.

Babylon não está rodando um wrapper custodial com copy de marketing melhor. vaultBTC só existe como um recibo restrito para BTC que criptografia, não um custodiante, concordou em liberar — e essa distinção é o cerne do design.

@BabylonLabs_io $BANK $ON $BABY #baby
Trustless é usado como uma descrição da criptografia nos Trustless Bitcoin Vaults e, nessa camada, ele ganha a palavra: as condições de gasto do cofre são impostas por script do Bitcoin e provas, não por uma empresa. Eu quis verificar se essa mesma palavra se aplica um nível acima — se o cofre consegue, de fato, se conectar ao Aave sem a permissão de ninguém. Não consegue, ainda. O Aave v4 organiza a liquidez por meio de um Hub que concede linhas de crédito para Spokes individuais, e Stani Kulechov afirmou de forma bem direta que novos spokes não são permissionless enquanto a arquitetura ainda é jovem; ele chamou de rodar "de um jeito bem controlado, como com rodinhas" (training wheels), com a governança via DAO decidindo o que se conecta. Os próprios spokes de BTC da Babylon passaram por uma proposta formal de Temperature Check no fórum de governança do Aave antes de qualquer coisa ser enviada para o testnet. Entrar na lista exigiu votação, não apenas uma assinatura. Então o próprio cofre — a parte que bloqueia seu Bitcoin — realmente funciona sem um intermediário confiável. A parte que permite que esse cofre tome empréstimo contra a liquidez do Aave passa por um DAO que pode dizer não. Ambas as coisas são verdade ao mesmo tempo, e apenas uma delas é o que "trustless" normalmente implica para alguém que só lê um título. A Babylon é trustless quando se trata de custódia; condições criptográficas substituem qualquer custodiante. A Babylon não é permissionless quando se trata de acesso: a governança do Aave ainda decide quais spokes recebem liquidez. TBV é trust minimizado ponta a ponta, não permissionless ponta a ponta. @babylonlabs_io $ON $BTW $BABY #baby {spot}(BABYUSDT)
Trustless é usado como uma descrição da criptografia nos Trustless Bitcoin Vaults e, nessa camada, ele ganha a palavra: as condições de gasto do cofre são impostas por script do Bitcoin e provas, não por uma empresa. Eu quis verificar se essa mesma palavra se aplica um nível acima — se o cofre consegue, de fato, se conectar ao Aave sem a permissão de ninguém.

Não consegue, ainda. O Aave v4 organiza a liquidez por meio de um Hub que concede linhas de crédito para Spokes individuais, e Stani Kulechov afirmou de forma bem direta que novos spokes não são permissionless enquanto a arquitetura ainda é jovem; ele chamou de rodar "de um jeito bem controlado, como com rodinhas" (training wheels), com a governança via DAO decidindo o que se conecta. Os próprios spokes de BTC da Babylon passaram por uma proposta formal de Temperature Check no fórum de governança do Aave antes de qualquer coisa ser enviada para o testnet. Entrar na lista exigiu votação, não apenas uma assinatura.

Então o próprio cofre — a parte que bloqueia seu Bitcoin — realmente funciona sem um intermediário confiável. A parte que permite que esse cofre tome empréstimo contra a liquidez do Aave passa por um DAO que pode dizer não. Ambas as coisas são verdade ao mesmo tempo, e apenas uma delas é o que "trustless" normalmente implica para alguém que só lê um título.

A Babylon é trustless quando se trata de custódia; condições criptográficas substituem qualquer custodiante. A Babylon não é permissionless quando se trata de acesso: a governança do Aave ainda decide quais spokes recebem liquidez. TBV é trust minimizado ponta a ponta, não permissionless ponta a ponta.

@BabylonLabs_io $ON $BTW $BABY #baby
Antes do BitVM3, a equipe da Babylon realizou experimentos reais com o BitVM2 para o tipo de verificação de provas de que seus cofres precisam, e os custos de transação on-chain retornaram acima de US$ 16.000 por operação — um número que destrói qualquer esperança de uso por consumidores. A resposta da equipe foi reconstruir a verificação usando circuitos embaralhados, em vez do método de prova em blocos que o BitVM2 usava: mover quase todo o processamento para fora da cadeia e deixar o Bitcoin com um pequeno compromisso para checar. Pesquisas independentes sobre o design colocam o ganho de eficiência em mais de 1000 vezes em comparação com o BitVM2; uma transação de asserção com cerca de 56 kilobytes e uma transação de refutação com cerca de 200 bytes, abaixo de transações que antes rodavam de 2 a 4 megabytes. Isso é uma vitória real de engenharia, e não foi de graça. A abordagem antiga em blocos mantinha mais da lógica de verificação legível diretamente no próprio Bitcoin, ainda que fosse cara. Circuitos embaralhados compactam essa lógica em um blob opaco que só faz sentido durante uma cerimônia específica e fora da cadeia entre partes específicas — exatamente por isso os críticos apontam a honestidade na configuração como uma nova suposição. A Babylon escolheu custo primeiro. A Babylon não está otimizando por pureza criptográfica aqui; ela otimizou por custo. Incapaz de manter a verificação tanto barata quanto totalmente legível no Bitcoin, a equipe transformou um problema de US$ 16.000 em algo em torno de US$ 9 e aceitou uma nova classe de confiança fora da cadeia em troca. Isso é uma troca deliberada, não uma falha. @babylonlabs_io $BANK $BTW $BABY #baby {spot}(BABYUSDT)
Antes do BitVM3, a equipe da Babylon realizou experimentos reais com o BitVM2 para o tipo de verificação de provas de que seus cofres precisam, e os custos de transação on-chain retornaram acima de US$ 16.000 por operação — um número que destrói qualquer esperança de uso por consumidores. A resposta da equipe foi reconstruir a verificação usando circuitos embaralhados, em vez do método de prova em blocos que o BitVM2 usava: mover quase todo o processamento para fora da cadeia e deixar o Bitcoin com um pequeno compromisso para checar. Pesquisas independentes sobre o design colocam o ganho de eficiência em mais de 1000 vezes em comparação com o BitVM2; uma transação de asserção com cerca de 56 kilobytes e uma transação de refutação com cerca de 200 bytes, abaixo de transações que antes rodavam de 2 a 4 megabytes.

Isso é uma vitória real de engenharia, e não foi de graça. A abordagem antiga em blocos mantinha mais da lógica de verificação legível diretamente no próprio Bitcoin, ainda que fosse cara. Circuitos embaralhados compactam essa lógica em um blob opaco que só faz sentido durante uma cerimônia específica e fora da cadeia entre partes específicas — exatamente por isso os críticos apontam a honestidade na configuração como uma nova suposição. A Babylon escolheu custo primeiro.

A Babylon não está otimizando por pureza criptográfica aqui; ela otimizou por custo. Incapaz de manter a verificação tanto barata quanto totalmente legível no Bitcoin, a equipe transformou um problema de US$ 16.000 em algo em torno de US$ 9 e aceitou uma nova classe de confiança fora da cadeia em troca. Isso é uma troca deliberada, não uma falha.

@BabylonLabs_io $BANK $BTW $BABY #baby
Ver tradução
Ask anyone who has watched a DeFi position get margin called what a liquidation looks like and you will hear the same story: a price feed ticks past a threshold, a bot notices before you do, and your collateral gets seized in the time it takes to refresh a browser tab. It is reasonable to assume Bitcoin collateral through Babylon's vaults would work the identical way once it lands on a lending market. It does not, at least not by that mechanism. A Babylon vault only releases locked BTC to a liquidator when that liquidator submits a valid zero knowledge proof confirming the loan terms were actually broken, not when an oracle price crosses a line on a dashboard. The proof has to verify against the smart contract state before Bitcoin script will let funds move, and Babylon's design layers in a challenge period so a contested claim can be disputed before it settles for good. The assumption that liquidation always means an automated price race misses what actually gates the outcome here. Price movement can still trigger eligibility on the lending market's side, but the Bitcoin side will not hand collateral to anyone who cannot produce cryptographic proof the breach genuinely happened, and a contested claim gets a window to be challenged rather than settling instantly, a slower and more dispute resistant process than the bot races most DeFi users expect. Babylon's vaults don't liquidate the way most DeFi collateral does, racing a price oracle the instant a threshold breaks. They gate every seizure behind a verified proof and a challenge window, trading the speed of an automated bot for a process that a false claim cannot simply outrun. @babylonlabs_io $AKE $BABY #baby {spot}(BABYUSDT)
Ask anyone who has watched a DeFi position get margin called what a liquidation looks like and you will hear the same story: a price feed ticks past a threshold, a bot notices before you do, and your collateral gets seized in the time it takes to refresh a browser tab. It is reasonable to assume Bitcoin collateral through Babylon's vaults would work the identical way once it lands on a lending market.

It does not, at least not by that mechanism. A Babylon vault only releases locked BTC to a liquidator when that liquidator submits a valid zero knowledge proof confirming the loan terms were actually broken, not when an oracle price crosses a line on a dashboard. The proof has to verify against the smart contract state before Bitcoin script will let funds move, and Babylon's design layers in a challenge period so a contested claim can be disputed before it settles for good.

The assumption that liquidation always means an automated price race misses what actually gates the outcome here. Price movement can still trigger eligibility on the lending market's side, but the Bitcoin side will not hand collateral to anyone who cannot produce cryptographic proof the breach genuinely happened, and a contested claim gets a window to be challenged rather than settling instantly, a slower and more dispute resistant process than the bot races most DeFi users expect.

Babylon's vaults don't liquidate the way most DeFi collateral does, racing a price oracle the instant a threshold breaks. They gate every seizure behind a verified proof and a challenge window, trading the speed of an automated bot for a process that a false claim cannot simply outrun.

@BabylonLabs_io $AKE $BABY #baby
@babylonlabs_io $BANK $DEXE $BABY #baby Tenho um primo que as pessoas confundem o tempo todo com o irmão mais velho: o mesmo jeito de andar, o mesmo riso à distância. Perto, não há nada em comum entre eles; um coleciona relógios vintage, o outro não se dá ao trabalho de conferir as horas. O Crypto Twitter faz a mesma coisa com as pontes de Bitcoin. Toda vez que um projeto diz que conecta o Bitcoin a outra cadeia, o reflexo é chamar de “ponte”, e pontes têm um histórico ruim: bilhões perdidos para explorações porque um custodiante de multisig ou um token “wrapped” virou o único ponto de falha. Os cofres do Babylon acabam nessa categoria por padrão. A comparação ignora os mecanismos. A linguagem de scripts do Bitcoin não tem “covenants” e não há, nativamente, como restringir de que forma uma transação futura pode gastar fundos — e é exatamente por isso que pontes tradicionais “trustless” têm sido tão difíceis de construir sem um grupo “keeper” em algum lugar. Os cofres do Babylon contornam isso ao travar BTC em um UTXO controlado por transações previamente assinadas e criptograficamente condicionadas, na própria rede do Bitcoin, e não em um ativo tokenizado em outro lugar. Cada cofre é segregado por usuário, em vez de ser colocado em uma reserva de custódia compartilhada, e todo o design roda no Bitcoin como ele existe hoje: sem novos opcodes, sem soft fork, sem mudança de consenso necessária. Isso é o oposto do padrão de “ponte via multisig”. Não há uma reserva agrupada para um atacante drenar em uma única transação, porque os fundos nunca foram agrupados. A superfície de risco que fez pontes antigas virarem manchetes de hacks simplesmente não está presente aqui na mesma forma — mesmo que novos riscos, diferentes, passem a ocupar o lugar. O Babylon não é uma ponte usando um novo nome: é mais parecido com um cofre-que-se-executa sozinho, que apenas lê o estado de outras cadeias. {spot}(BABYUSDT)
@BabylonLabs_io $BANK $DEXE $BABY #baby

Tenho um primo que as pessoas confundem o tempo todo com o irmão mais velho: o mesmo jeito de andar, o mesmo riso à distância. Perto, não há nada em comum entre eles; um coleciona relógios vintage, o outro não se dá ao trabalho de conferir as horas. O Crypto Twitter faz a mesma coisa com as pontes de Bitcoin.

Toda vez que um projeto diz que conecta o Bitcoin a outra cadeia, o reflexo é chamar de “ponte”, e pontes têm um histórico ruim: bilhões perdidos para explorações porque um custodiante de multisig ou um token “wrapped” virou o único ponto de falha. Os cofres do Babylon acabam nessa categoria por padrão.

A comparação ignora os mecanismos. A linguagem de scripts do Bitcoin não tem “covenants” e não há, nativamente, como restringir de que forma uma transação futura pode gastar fundos — e é exatamente por isso que pontes tradicionais “trustless” têm sido tão difíceis de construir sem um grupo “keeper” em algum lugar. Os cofres do Babylon contornam isso ao travar BTC em um UTXO controlado por transações previamente assinadas e criptograficamente condicionadas, na própria rede do Bitcoin, e não em um ativo tokenizado em outro lugar. Cada cofre é segregado por usuário, em vez de ser colocado em uma reserva de custódia compartilhada, e todo o design roda no Bitcoin como ele existe hoje: sem novos opcodes, sem soft fork, sem mudança de consenso necessária.

Isso é o oposto do padrão de “ponte via multisig”. Não há uma reserva agrupada para um atacante drenar em uma única transação, porque os fundos nunca foram agrupados. A superfície de risco que fez pontes antigas virarem manchetes de hacks simplesmente não está presente aqui na mesma forma — mesmo que novos riscos, diferentes, passem a ocupar o lugar.

O Babylon não é uma ponte usando um novo nome: é mais parecido com um cofre-que-se-executa sozinho, que apenas lê o estado de outras cadeias.
#baby @babylonlabs_io $DEXE $BANK $BABY Um jardim comunitário perto do meu antigo apartamento mantinha um galpão de ferramentas compartilhado, destrancado, de primeiro a chegar, primeiro a ser atendido, administrado por um comitê rotativo que decidia quem ganhava as boas pás durante as épocas de seca. Ninguém podia dizer que as ferramentas não eram compartilhadas. Ninguém podia dizer que o comitê não era o verdadeiro guardião. Dos 10 bilhões de tokens BABY planejados, 15% — 1,5 bilhão de tokens — ficam em um “bucket” de incentivos da comunidade gerenciado pela Babylon Foundation. Diferentemente dos 1,5 bilhão de tokens da equipe, que seguem um cronograma de 4 anos com um “cliff” de 1 ano, ou dos 3,05 bilhões alocados a investidores iniciais, que liberam 1/36 por mês em uma programação que vai até abril de 2029, a alocação para a comunidade está majoritariamente já desbloqueada e pode ser distribuída a qualquer momento pela Foundation. Um recorte dentro desse “bucket”, 121,6 milhões de BABY, fica reservado especificamente para campanhas de marketing da Binance, liberadas seis meses após o lançamento do mainnet do Babylon Genesis em abril de 2025. As alocações de construção do ecossistema e de P&D, 18% cada do suprimento total, funcionam de modo semelhante: 25% desbloqueados imediatamente no lançamento, o restante fluindo linearmente ao longo de 3 anos, também sob discrição da Foundation. Somadas, as categorias de ecossistema, P&D e comunidade totalizam 51% de todo o suprimento de 10 bilhões, ficando sob algum tipo de liberação “com timing” definido pela Foundation, em vez de uma fórmula pública fixa. Assim, as maiores alocações não-vestidas não são reivindicadas por usuários sob regras previsíveis: elas são liberadas por decisão da Foundation, com timing em torno de parcerias com exchanges tanto quanto de crescimento orgânico do ecossistema. Isso é propriedade da comunidade — ou gastos direcionados pela foundation usando um rótulo de comunidade? As duas leituras têm algum fundo de verdade. Os tokens de fato chegam a usuários e construtores ao longo do tempo, mas o ritmo e o destino continuam decididos centralmente, e, sem critérios de liberação recorrentes mais claros, chamar isso de “propriedade pura da comunidade” é exagerar. {spot}(BABYUSDT)
#baby @BabylonLabs_io $DEXE $BANK $BABY

Um jardim comunitário perto do meu antigo apartamento mantinha um galpão de ferramentas compartilhado, destrancado, de primeiro a chegar, primeiro a ser atendido, administrado por um comitê rotativo que decidia quem ganhava as boas pás durante as épocas de seca. Ninguém podia dizer que as ferramentas não eram compartilhadas. Ninguém podia dizer que o comitê não era o verdadeiro guardião.

Dos 10 bilhões de tokens BABY planejados, 15% — 1,5 bilhão de tokens — ficam em um “bucket” de incentivos da comunidade gerenciado pela Babylon Foundation. Diferentemente dos 1,5 bilhão de tokens da equipe, que seguem um cronograma de 4 anos com um “cliff” de 1 ano, ou dos 3,05 bilhões alocados a investidores iniciais, que liberam 1/36 por mês em uma programação que vai até abril de 2029, a alocação para a comunidade está majoritariamente já desbloqueada e pode ser distribuída a qualquer momento pela Foundation. Um recorte dentro desse “bucket”, 121,6 milhões de BABY, fica reservado especificamente para campanhas de marketing da Binance, liberadas seis meses após o lançamento do mainnet do Babylon Genesis em abril de 2025. As alocações de construção do ecossistema e de P&D, 18% cada do suprimento total, funcionam de modo semelhante: 25% desbloqueados imediatamente no lançamento, o restante fluindo linearmente ao longo de 3 anos, também sob discrição da Foundation. Somadas, as categorias de ecossistema, P&D e comunidade totalizam 51% de todo o suprimento de 10 bilhões, ficando sob algum tipo de liberação “com timing” definido pela Foundation, em vez de uma fórmula pública fixa. Assim, as maiores alocações não-vestidas não são reivindicadas por usuários sob regras previsíveis: elas são liberadas por decisão da Foundation, com timing em torno de parcerias com exchanges tanto quanto de crescimento orgânico do ecossistema. Isso é propriedade da comunidade — ou gastos direcionados pela foundation usando um rótulo de comunidade?

As duas leituras têm algum fundo de verdade. Os tokens de fato chegam a usuários e construtores ao longo do tempo, mas o ritmo e o destino continuam decididos centralmente, e, sem critérios de liberação recorrentes mais claros, chamar isso de “propriedade pura da comunidade” é exagerar.
A balança da minha feira de produtores tem uma pequena defasagem antes de travar o peso. Meu tio, vendendo tomates raros de herança, calibrou a balança para atrasar mais do que a barraca de milho ao lado. Itens raros atraem mais “gaming” de preço, ele disse, então ele queria mais um tempo antes do número se estabilizar. O mecanismo de matching da GRVT roda com a mesma lógica no nível do livro de ofertas. As principais pares recebem uma “barrera” de 25 milissegundos antes de uma ordem poder executar, enquanto altcoins recebem uma “barrera” de 50 milissegundos, dobrando o atraso — especificamente para reduzir o fluxo tóxico, aquele tipo de “quote sniping” ultrarrápida que pune ordens paradas em livros mais finos. As principais têm profundidade suficiente para absorver fluxos rápidos sem causar muitos danos; as altcoins não, então o motor desacelera mais onde o risco de serem “caçadas” é maior. O programa de market maker aplica uma assimetria semelhante no onboarding, em vez da execução. Um market maker que já está ativo em outra exchange e migra para a GRVT recebe automaticamente a categoria Bronze por quatorze dias; depois disso, os benefícios de rebate são ajustados a partir daí, em vez de começar do zero — como faria um participante recém-chegado, com volume inicial inexistente. Isso remove a penalidade de “cold start” especificamente para a liquidez que a GRVT quer atrair rapidamente. Do lado das taxas, cada tier especial acima do Nível 9 converge para a mesma taxa de taker; assim, a escada recompensa aumento de volume apenas até certo ponto e depois fica horizontal, em vez de escalar para sempre. Nenhuma destas três mecânicas são regras uniformes aplicadas em todo lugar: cada uma é calibrada para um risco específico ou para um tipo específico de participante. A GRVT não aplica uma velocidade uniforme, nem uma regra uniforme de onboarding, em todos os mercados e para todos os traders. Ela ajusta o atraso de matching e o tratamento de rebate de acordo com o risco por par e com base se a liquidez é nova ou se está migrando. @grvt_io #grvt $LAB $VELVET
A balança da minha feira de produtores tem uma pequena defasagem antes de travar o peso. Meu tio, vendendo tomates raros de herança, calibrou a balança para atrasar mais do que a barraca de milho ao lado. Itens raros atraem mais “gaming” de preço, ele disse, então ele queria mais um tempo antes do número se estabilizar.

O mecanismo de matching da GRVT roda com a mesma lógica no nível do livro de ofertas. As principais pares recebem uma “barrera” de 25 milissegundos antes de uma ordem poder executar, enquanto altcoins recebem uma “barrera” de 50 milissegundos, dobrando o atraso — especificamente para reduzir o fluxo tóxico, aquele tipo de “quote sniping” ultrarrápida que pune ordens paradas em livros mais finos. As principais têm profundidade suficiente para absorver fluxos rápidos sem causar muitos danos; as altcoins não, então o motor desacelera mais onde o risco de serem “caçadas” é maior. O programa de market maker aplica uma assimetria semelhante no onboarding, em vez da execução. Um market maker que já está ativo em outra exchange e migra para a GRVT recebe automaticamente a categoria Bronze por quatorze dias; depois disso, os benefícios de rebate são ajustados a partir daí, em vez de começar do zero — como faria um participante recém-chegado, com volume inicial inexistente. Isso remove a penalidade de “cold start” especificamente para a liquidez que a GRVT quer atrair rapidamente. Do lado das taxas, cada tier especial acima do Nível 9 converge para a mesma taxa de taker; assim, a escada recompensa aumento de volume apenas até certo ponto e depois fica horizontal, em vez de escalar para sempre. Nenhuma destas três mecânicas são regras uniformes aplicadas em todo lugar: cada uma é calibrada para um risco específico ou para um tipo específico de participante.

A GRVT não aplica uma velocidade uniforme, nem uma regra uniforme de onboarding, em todos os mercados e para todos os traders. Ela ajusta o atraso de matching e o tratamento de rebate de acordo com o risco por par e com base se a liquidez é nova ou se está migrando.

@grvt_io #grvt $LAB $VELVET
Artigo
Para Onde Realmente Vai o Fundo Cortado de NewtonUm senhorio de quem aluguei anos atrás tinha uma política de caução que parecia incomum na época. Se um inquilino danificasse algo, a caução não desaparecia apenas na conta geral dele; ela era destinada especificamente para consertar o que aquele inquilino tinha quebrado, e se sobrasse algum dinheiro, ele devolvia. A maioria dos senhorios com quem eu tinha lidado antes simplesmente ficava com a caução inteira, independentemente do dano real, tratando-a como uma penalidade fixa em vez de um fundo para reparos. A diferença parece pequena até você ser o inquilino que causou vinte dólares de dano e acabaria perdendo a caução de um mês inteiro no sistema antigo. Onde uma penalidade vai muda para o que, de fato, ela está sendo cobrada.

Para Onde Realmente Vai o Fundo Cortado de Newton

Um senhorio de quem aluguei anos atrás tinha uma política de caução que parecia incomum na época. Se um inquilino danificasse algo, a caução não desaparecia apenas na conta geral dele; ela era destinada especificamente para consertar o que aquele inquilino tinha quebrado, e se sobrasse algum dinheiro, ele devolvia. A maioria dos senhorios com quem eu tinha lidado antes simplesmente ficava com a caução inteira, independentemente do dano real, tratando-a como uma penalidade fixa em vez de um fundo para reparos. A diferença parece pequena até você ser o inquilino que causou vinte dólares de dano e acabaria perdendo a caução de um mês inteiro no sistema antigo. Onde uma penalidade vai muda para o que, de fato, ela está sendo cobrada.
Meu proprietário uma vez me deu uma chave reserva que só abria a caixa de correio; nada mais no prédio. Eu lembro de pensar que aquilo era demais para uma caixa de correio. Anos depois entendi o ponto: ele não estava distribuindo confiança, estava distribuindo exatamente a quantidade de acesso que uma tarefa exigia e nada além disso. Essa é a mesma lógica por trás do rollup do Newton's Keystore. Em vez de dar ao seu agente de IA todo o poder de assinatura da sua carteira, o Keystore permite que você delimite permissões para direitos específicos e estreitos: gastar até esse limite, negociar apenas esse par, agir apenas dentro dessa janela de tempo. Esses escopos ficam onchain e são aplicados de forma criptográfica, não por uma promessa que o operador do agente faz e que pode falhar. O rollup também lida com transições de estado entre cadeias, então uma permissão concedida em uma cadeia permanece consistente conforme as ações do agente repercutem em outras. O custo-benefício é real. Escopos com granularidade significam mais configuração e mais decisões que um usuário precisa tomar antes mesmo de um agente começar a trabalhar: limites de gasto, janelas de tempo, listas de ativos, regras de revogação. Um sistema mais simples apenas pediria uma aprovação genérica e avançaria mais rápido para a parte divertida. A Newton escolheu de propósito o caminho de onboarding mais lento, apostando que pessoas que delegam controle financeiro a software autônomo realmente querem a chave da caixa de correio, não a chave-mestra, mesmo que configurar esse escopo leve alguns minutos extras logo no início. Chaves de sessão construídas sobre a mesma lógica de escopo permitem que um usuário revogue ou atualize uma permissão no meio da execução sem mexer no resto da carteira — o que importa quando você tem mais de um agente rodando ao mesmo tempo. A Newton não está otimizando para a configuração mais rápida possível do agente; está otimizando para o menor raio de impacto quando algo dá errado, e isso diz mais sobre para quem o protocolo foi construído do que qualquer lista de recursos. @NewtonProtocol $NEWT #Newt $LAB $VELVET {spot}(NEWTUSDT)
Meu proprietário uma vez me deu uma chave reserva que só abria a caixa de correio; nada mais no prédio. Eu lembro de pensar que aquilo era demais para uma caixa de correio. Anos depois entendi o ponto: ele não estava distribuindo confiança, estava distribuindo exatamente a quantidade de acesso que uma tarefa exigia e nada além disso.

Essa é a mesma lógica por trás do rollup do Newton's Keystore. Em vez de dar ao seu agente de IA todo o poder de assinatura da sua carteira, o Keystore permite que você delimite permissões para direitos específicos e estreitos: gastar até esse limite, negociar apenas esse par, agir apenas dentro dessa janela de tempo. Esses escopos ficam onchain e são aplicados de forma criptográfica, não por uma promessa que o operador do agente faz e que pode falhar. O rollup também lida com transições de estado entre cadeias, então uma permissão concedida em uma cadeia permanece consistente conforme as ações do agente repercutem em outras.

O custo-benefício é real. Escopos com granularidade significam mais configuração e mais decisões que um usuário precisa tomar antes mesmo de um agente começar a trabalhar: limites de gasto, janelas de tempo, listas de ativos, regras de revogação. Um sistema mais simples apenas pediria uma aprovação genérica e avançaria mais rápido para a parte divertida. A Newton escolheu de propósito o caminho de onboarding mais lento, apostando que pessoas que delegam controle financeiro a software autônomo realmente querem a chave da caixa de correio, não a chave-mestra, mesmo que configurar esse escopo leve alguns minutos extras logo no início. Chaves de sessão construídas sobre a mesma lógica de escopo permitem que um usuário revogue ou atualize uma permissão no meio da execução sem mexer no resto da carteira — o que importa quando você tem mais de um agente rodando ao mesmo tempo.

A Newton não está otimizando para a configuração mais rápida possível do agente; está otimizando para o menor raio de impacto quando algo dá errado, e isso diz mais sobre para quem o protocolo foi construído do que qualquer lista de recursos.

@NewtonProtocol $NEWT #Newt $LAB $VELVET
Eu uma vez presumi que a minha conta poupança só pagava juros se eu deixasse o dinheiro completamente intocado por um ano inteiro, então eu nunca movi nem um centavo. Um banqueiro depois me disse que o juro era calculado todos os dias, independentemente disso, e que todo o meu ano de inação paranoica não me rendeu nada a mais. A maioria das pessoas assume que uma troca de perpetuals só te paga se você estiver ativamente abrindo e fechando posições alavancadas; que o saldo parado fica ali como colateral morto, esperando para ser usado. A GRVT executa um programa de Earn on Equity que paga um rendimento anualizado de aproximadamente 10% sobre o próprio patrimônio da conta, e não sobre negociações feitas ou volume gerado. Não há período de lockup associado: os fundos permanecem totalmente disponíveis para margem ou saque a qualquer momento. O rendimento é composto a cada 4 horas, em vez de uma vez por dia ou uma vez por mês; então um saldo em uma subconta continua acumulando em pequenas parcelas o tempo todo, quer ou não uma única ordem seja executada naquele dia. Um trader que deposita colateral e nunca abre uma posição ainda vê esse saldo crescer, simplesmente por estar presente na plataforma como patrimônio registrado, sem limite de volume, sem contagem mínima de negociações, sem “degrau” para liberar primeiro. Isso contraria a suposição comum de que exchanges de derivativos só recompensam atividade; aqui, a recompensa está ligada à presença, não ao movimento. Um trader cauteloso que espera semanas pelo setup certo obtém a mesma taxa subjacente que alguém que abre e fecha posições a cada hora. A maioria dos espaços concorrentes vincula o rendimento ao volume negociado ou a um produto separado de staking que tranca o ativo longe do uso de margem, forçando uma escolha entre ganhar e permanecer pronto para negociar. Aqui essa escolha não existe: o mesmo saldo sustenta posições abertas e acumula rendimento ao mesmo tempo, em um relógio de 4 horas que nunca pausa. A GRVT não exige negociações constantes para gerar retorno; o estereótipo de que saldos ociosos em exchanges não rendem nada é falso aqui. O patrimônio em si é o ativo produtivo, independentemente de quantas vezes o trader realmente clica em comprar ou vender. @grvt_io #grvt $LAB $VELVET
Eu uma vez presumi que a minha conta poupança só pagava juros se eu deixasse o dinheiro completamente intocado por um ano inteiro, então eu nunca movi nem um centavo. Um banqueiro depois me disse que o juro era calculado todos os dias, independentemente disso, e que todo o meu ano de inação paranoica não me rendeu nada a mais.

A maioria das pessoas assume que uma troca de perpetuals só te paga se você estiver ativamente abrindo e fechando posições alavancadas; que o saldo parado fica ali como colateral morto, esperando para ser usado. A GRVT executa um programa de Earn on Equity que paga um rendimento anualizado de aproximadamente 10% sobre o próprio patrimônio da conta, e não sobre negociações feitas ou volume gerado. Não há período de lockup associado: os fundos permanecem totalmente disponíveis para margem ou saque a qualquer momento. O rendimento é composto a cada 4 horas, em vez de uma vez por dia ou uma vez por mês; então um saldo em uma subconta continua acumulando em pequenas parcelas o tempo todo, quer ou não uma única ordem seja executada naquele dia. Um trader que deposita colateral e nunca abre uma posição ainda vê esse saldo crescer, simplesmente por estar presente na plataforma como patrimônio registrado, sem limite de volume, sem contagem mínima de negociações, sem “degrau” para liberar primeiro. Isso contraria a suposição comum de que exchanges de derivativos só recompensam atividade; aqui, a recompensa está ligada à presença, não ao movimento. Um trader cauteloso que espera semanas pelo setup certo obtém a mesma taxa subjacente que alguém que abre e fecha posições a cada hora. A maioria dos espaços concorrentes vincula o rendimento ao volume negociado ou a um produto separado de staking que tranca o ativo longe do uso de margem, forçando uma escolha entre ganhar e permanecer pronto para negociar. Aqui essa escolha não existe: o mesmo saldo sustenta posições abertas e acumula rendimento ao mesmo tempo, em um relógio de 4 horas que nunca pausa.

A GRVT não exige negociações constantes para gerar retorno; o estereótipo de que saldos ociosos em exchanges não rendem nada é falso aqui. O patrimônio em si é o ativo produtivo, independentemente de quantas vezes o trader realmente clica em comprar ou vender.

@grvt_io #grvt $LAB $VELVET
Artigo
A Lacuna dos Recibos Entre Newton e “Agentes de IA Onchain”Uma amiga minha contratou há alguns anos uma contadora freelance que insistia que não precisava enviar recibos; ela apenas diria a ele, no fim de cada mês, o que tinha gasto e como tinha categorizado. Ele confiou nela por quase um ano antes de uma auditoria forçá-lo a verificar de fato os números dela em comparação com os extratos bancários, e os dois não batiam em vários pontos; nada criminoso, apenas uma comunicação/auto-relato desleixado que ninguém havia checado de forma independente. O que o impressionou depois não foi que ela tivesse mentido exatamente, e sim que todo o acordo tinha se baseado em confiar no próprio relato dela sobre o próprio trabalho, sem nenhum registro independente entre a afirmação dela e a crença dele nela.

A Lacuna dos Recibos Entre Newton e “Agentes de IA Onchain”

Uma amiga minha contratou há alguns anos uma contadora freelance que insistia que não precisava enviar recibos; ela apenas diria a ele, no fim de cada mês, o que tinha gasto e como tinha categorizado. Ele confiou nela por quase um ano antes de uma auditoria forçá-lo a verificar de fato os números dela em comparação com os extratos bancários, e os dois não batiam em vários pontos; nada criminoso, apenas uma comunicação/auto-relato desleixado que ninguém havia checado de forma independente. O que o impressionou depois não foi que ela tivesse mentido exatamente, e sim que todo o acordo tinha se baseado em confiar no próprio relato dela sobre o próprio trabalho, sem nenhum registro independente entre a afirmação dela e a crença dele nela.
Um vizinho meu dirige para um app de entregas e jura que o trabalho inteiro é só comprovar que você apareceu no horário. Eu perguntei uma vez se alguém verifica se ele entregou o pedido certo na porta certa, e ele riu e disse que ninguém realmente faz; o sistema só se importa que o app diga que foi entregue. Essa diferença entre provar que algo aconteceu e provar que aconteceu corretamente ficou comigo por mais tempo do que a conversa em si. Redes de keepers como Gelato, Keep3r e Chainlink Automation existem para acionar uma ação predefinida assim que uma condição é atendida: rebalancear um pool, liquidar uma posição, executar uma ordem limite. Elas são genuinamente boas nesse trabalho. O que nenhuma delas faz é provar que a decisão subjacente por trás do gatilho foi ela própria correta; elas confirmam que a função foi executada, não que executá-la foi a escolha certa considerando tudo o que está acontecendo onchain naquele momento. A rede de operadores da Newton, por outro lado, apoia cada decisão de permitir, rejeitar ou limitar com uma prova verificável — em vez disso, uma questão totalmente diferente de saber se uma ação disparou no cronograma. O discurso inteiro da Keep3r sempre foi pagar keepers por execução confiável e eficiente em gás; velocidade e custo são as métricas que importam lá, não julgamento. A rede de operadores da Newton, em contraste, precisa alcançar quórum e produzir uma prova antes de um veredito sequer contar, o que é mais lento por design e tem preço correspondente. Então isso compete? Só em parte. Um cofre poderia usar uma rede de keepers para executar um rebalance e usar a Newton para decidir se esse rebalance deve, de fato, ser permitido, e nenhum dos dois substitui o trabalho do outro. Saber se essa distinção realmente importa para um construtor escolhendo infraestrutura hoje, ou se só importa quando algo dá errado e alguém pergunta por que uma transação tecnicamente bem-sucedida ainda foi a errada, é uma pergunta que o uso da Newton no mundo real ainda não respondeu completamente. Eu me inclino a pensar que importa mais no momento em que há dinheiro real em jogo, mas isso é uma suposição, não um fato estabelecido. @NewtonProtocol $NEWT #Newt $LAB $EVAA {spot}(NEWTUSDT)
Um vizinho meu dirige para um app de entregas e jura que o trabalho inteiro é só comprovar que você apareceu no horário. Eu perguntei uma vez se alguém verifica se ele entregou o pedido certo na porta certa, e ele riu e disse que ninguém realmente faz; o sistema só se importa que o app diga que foi entregue. Essa diferença entre provar que algo aconteceu e provar que aconteceu corretamente ficou comigo por mais tempo do que a conversa em si.

Redes de keepers como Gelato, Keep3r e Chainlink Automation existem para acionar uma ação predefinida assim que uma condição é atendida: rebalancear um pool, liquidar uma posição, executar uma ordem limite. Elas são genuinamente boas nesse trabalho. O que nenhuma delas faz é provar que a decisão subjacente por trás do gatilho foi ela própria correta; elas confirmam que a função foi executada, não que executá-la foi a escolha certa considerando tudo o que está acontecendo onchain naquele momento. A rede de operadores da Newton, por outro lado, apoia cada decisão de permitir, rejeitar ou limitar com uma prova verificável — em vez disso, uma questão totalmente diferente de saber se uma ação disparou no cronograma.

O discurso inteiro da Keep3r sempre foi pagar keepers por execução confiável e eficiente em gás; velocidade e custo são as métricas que importam lá, não julgamento. A rede de operadores da Newton, em contraste, precisa alcançar quórum e produzir uma prova antes de um veredito sequer contar, o que é mais lento por design e tem preço correspondente.

Então isso compete? Só em parte. Um cofre poderia usar uma rede de keepers para executar um rebalance e usar a Newton para decidir se esse rebalance deve, de fato, ser permitido, e nenhum dos dois substitui o trabalho do outro. Saber se essa distinção realmente importa para um construtor escolhendo infraestrutura hoje, ou se só importa quando algo dá errado e alguém pergunta por que uma transação tecnicamente bem-sucedida ainda foi a errada, é uma pergunta que o uso da Newton no mundo real ainda não respondeu completamente. Eu me inclino a pensar que importa mais no momento em que há dinheiro real em jogo, mas isso é uma suposição, não um fato estabelecido.

@NewtonProtocol $NEWT #Newt $LAB $EVAA
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