Pham Kim 26

“Escrow” (depósito em garantia) parecia para mim, por muito tempo, uma palavra vaga de segurança — algo que a Binance P2P mencionava, sem que eu realmente entendesse o que fazia de forma mecânica. Quando eu finalmente negociei o suficiente para ver isso em ação, passou a ser a parte do sistema em que eu mais confio.

Quando um vendedor cria ou aceita um pedido na Binance P2P, o ativo cripto que está sendo vendido não fica livre na carteira dele durante a negociação; ele é bloqueado no escrow assim que o pedido é aberto. Nenhuma das partes consegue acessá-lo nesse intervalo. O comprador não consegue recebê-lo até que o vendedor o libere manualmente, e o vendedor não consegue retirar aquilo nem gastar em outro lugar enquanto estiver bloqueado. Esse único mecanismo é o que faz o resto do sistema funcionar: o comprador pode enviar o pagamento com segurança sabendo que o vendedor, fisicamente, não consegue sumir com os dois — o pagamento e o ativo cripto — e o vendedor pode aguardar com segurança a confirmação do pagamento sem se preocupar de que o ativo vá se mover sozinho. Combinado com verificação de KYC, chat no aplicativo e a opção de apelar uma disputa, o escrow forma o núcleo estrutural de por que a negociação na Binance P2P funciona com tanta segurança quanto funciona, desde que a negociação aconteça totalmente dentro da plataforma.

Entender isso mudou a forma como eu negocio de algumas maneiras bem concretas. Eu parei de me preocupar com a possibilidade de um vendedor fugir com meu pagamento, já que o ativo cripto fica bloqueado, independentemente. Em vez disso, direciono minha atenção para as partes que o escrow não cobre: verificar o perfil da contraparte antes de começar, confirmar que o pagamento realmente foi compensado antes de esperar a liberação e observar sinais de alerta como urgência incomum. Também mantenho uma anotação simples do número do pedido e do horário (timestamp) de cada negociação que eu concluo, só para o caso de eu precisar consultar os detalhes depois. Se alguma liberação alguma vez parecer atrasada além de uma janela normal, eu entro em contato com o suporte da Binance em vez de presumir o pior, já que eles conseguem ver o status do escrow diretamente.

@Binance Vietnam #BinanceP2PAnToan
$TUT $BLUAI

"Eu acabei enviando a você a mais, você pode reembolsar a diferença agora mesmo?" Essa mensagem chegou quatro minutos após eu iniciar uma negociação no Binance P2P, e é uma das tentativas de golpe mais inteligentes que já encontrei.

O esquema funciona assim: um comprador envia uma notificação de pagamento afirmando um valor maior do que o que o pedido realmente exigia e, em seguida, pede ao vendedor que devolva diretamente a parte excedente por meio de uma transferência separada, colocando isso como algo urgente e constrangedor para ele. A pegadinha é que o pagamento original ou nem chega a acontecer ou chega depois, usando um método reversível, enquanto o “reembolso” do vendedor sai imediatamente a partir de fundos reais. Se o vendedor se apressar para ser educado com o suposto erro, ele acaba enviando dinheiro de verdade e não recebe nada ou recebe um pagamento que depois é estornado.

O Binance P2P, na verdade, tem um canal adequado para exatamente esse tipo de situação. Se um comprador realmente pagar a mais, o correto é discutir isso pelo chat oficial e resolver qualquer valor extra por meio de uma apelação, se necessário—nunca por um reembolso privado enviado fora do próprio pedido. Eu disse isso ao comprador de forma bem direta, verifiquei meu aplicativo bancário e confirmei que nenhum pagamento havia caído ainda e recusei devolver qualquer coisa. Ele ficou impaciente, depois ficou quieto e, por fim, o pedido simplesmente expirou.

O que torna esse golpe específico tão eficaz é o quão plausível ele parece. Ninguém quer parecer difícil por algo que parece um engano honesto, e os golpistas contam com essa tendência à educação mais do que com qualquer truque técnico.

Minha regra desde aquele dia: qualquer solicitação envolvendo reembolso, um segundo pagamento, ou mover dinheiro fora do próprio pedido é tratada automaticamente como um sinal vermelho, sem exceções para o quão educada ou desculpável a mensagem pareça. O sistema de custódia (escrow) e de apelação do Binance P2P existe justamente para que os vendedores não tenham de tomar essa decisão sozinhos sob pressão, e usá-lo é melhor do que tentar ser “um cara legal” com uma solicitação suspeita.

@Binance Vietnam #BinanceP2PAnToan
$ACE

Considero que uma ordem da Binance P2P expirada ou cancelada é um limite rígido. Se o dinheiro se mover depois desse limite, eu não recrio o antigo acordo por meio de negociação particular. O preço cotado pode ter mudado, o escrow talvez já não proteja a transferência pretendida e o prazo da ordem pode não suportar a ação que a outra parte agora quer.

Como comprador, eu verifico a contagem regressiva do pagamento antes de enviar. Uso apenas o beneficiário exibido na ordem ativa, pago a partir de uma conta que corresponda ao meu nome verificado e marco o pagamento somente depois de eu realmente enviar o valor exato. Se a ordem for encerrada primeiro, eu não faço a transferência e peço ao vendedor que libere manualmente. Eu entro em contato com o Suporte da Binance se um pagamento atrasado ou duplicado já tiver ocorrido.

Como vendedor, eu verifico o status da ordem antes de liberar o cripto. O comprador dizer “pago” não revive uma negociação cancelada. Eu abro meu banco ou aplicativo de pagamento, identifico o remetente, confiro o valor e confirmo se os recursos foram liquidados. Eu deixo o cripto intocado enquanto descrevo o problema de timing no chat da ordem da Binance ou no Suporte oficial. Eu nunca reembolso para uma nova conta informada em uma mensagem apressada, porque isso pode separar a devolução do pagador original.

Minha lista de sinais vermelhos inclui solicitações para continuar em outro lugar, abrir uma ordem nova mas contar um pagamento antigo, aceitar um remetente de terceiros ou liberar no preço expirado. Eu salvo o número da ordem antiga, carimbos de data/hora, o chat, o ID da transação do pagamento e qualquer novo número de ordem. Esses links importam se for necessário um recurso ou uma análise do Suporte.

KYC, escrow, chat e Recurso protegem uma transação definida na plataforma. Eles não são uma garantia ampla para acordos paralelos montados depois que uma ordem termina. Eu respeito o estado da ordem tanto quanto respeito o valor do pagamento. Minha sequência é: ordem ativa, correspondência de identidade, conta especificada, recursos liquidados, liberação confirmada. Se o relógio quebrar essa sequência, eu pauso e deixo o Suporte da Binance orientar o próximo passo.

@Binance Vietnam #BinanceP2PAnToan
$BLESS

Diga que o modelo de governança de Babylon é justo e razoável; pessoas razoáveis concordam com isso; diga também que é um desajuste estrutural e pessoas razoáveis concordam com isso também. Ambas as reações estão respondendo à mesma escolha real de design.

Os detentores de tokens BABY são os que votam nas propostas do Babylon Genesis, a configuração padrão para uma cadeia Cosmos SDK em que o token nativo carrega direitos de governança, consistente com como essencialmente toda cadeia comparável nesse ecossistema opera. Os stakers de BTC, as pessoas que de fato estão bloqueando bilhões de dólares em Bitcoin para fornecer a segurança que a Babylon vende para redes externas, não têm uma votação on-chain paralela por meio dessa própria posição em BTC. Do ponto de vista puramente arquitetural, isso faz sentido: os stakers de BTC interagem com a própria cadeia do Bitcoin, e não com o Babylon Genesis, então encaminhar a governança pelo token nativo é o desenho convencional. Do ponto de vista de incentivos, parece mais estranho: o grupo que assume o risco real de slashing e o bloqueio de capital tem menos poder formal do que o grupo que detém um token que, em meados de 2026, é negociado por uma fração pequena do valor que os stakers de BTC, coletivamente, fornecem.

A comunidade Babylon claramente notou essa tensão. Uma proposta de co-staking BTC-BABY foi levantada especificamente para alinhar incentivos entre os dois grupos de stakers e reduzir a inflação, algo que só acontece quando já existe uma discordância real e em curso sobre a divisão atual.

O design de governança da Babylon é defensável, não obviamente correto. Encaminhar as votações via BABY corresponde à prática padrão do Cosmos SDK, mas deixa os stakers de BTC — que fornecem o capital real de segurança que chega a vários bilhões de dólares — sem poder formal direto, uma tensão que a própria proposta de co-staking do projeto sugere que também não está totalmente resolvida internamente.

@BabylonLabs_io $BABY #baby
$BLESS

Pontes que conectam o Bitcoin a outra cadeia normalmente se apoiam em um grupo permissionado para detectar fraudes: um conjunto pago de observadores, destinado a notar se alguém tenta reivindicar BTC que não lhe é devido. Esse grupo, por si só, é uma suposição de confiança, e o próprio paper do cofre do Babylon, lançado em agosto de 2025, aponta que não existe, até hoje, uma forma conhecida de construir uma ponte de Bitcoin totalmente sem confiança (trustless) com a linguagem de scripts do Bitcoin como ela existe atualmente, já que o Bitcoin ainda não tem opcodes de covenant como o OP-CAT.

Cofres de Bitcoin sem confiança contornam essa lacuna de maneira diferente. Reivindicações de resgate e de liquidação em TBV são verificadas por meio de provas de conhecimento zero do que aconteceu na cadeia hospedeira, vinculadas a dois spokes dedicados do Aave v4: o Babylon Core Lending Spoke e o BTC Vault Swap Spoke. Qualquer reivindicação que não tenha uma prova válida pode ser contestada durante uma janela de fraud proof antes de se concretizar. O design do Babylon vai além da maioria ao garantir que o depositante esteja sempre habilitado a agir como seu próprio contestador; assim, defender BTC nunca depende estritamente de um observador separado e pago que apareça a tempo.

Essa escolha tem um custo real. Permitir que depositantes sejam sua própria última linha de defesa significa que a segurança depende, em parte, de os usuários realmente acompanharem posições abertas, em um sistema que só existe na testnet pública desde 2 de junho de 2026 — um esforço maior do que apenas clicar em aprovar uma vez e seguir em frente.

O Babylon não apenas removeu um comitê de signatários do TBV: ele empurrou a tarefa de detectar fraudes para a pessoa com o maior risco, o depositante. Trata-se de um trade deliberado de conveniência por pureza arquitetural, e só compensa para usuários que entendem o que estão defendendo.

@BabylonLabs_io $BABY #baby
$BLESS

Alpha season rồi các con vk ơi, Top gain toàn coin alpha thế này 🤣🤣🤣
$BLESS $memes

Eu vi pessoas usarem LBTC, SolvBTC e Babylon de forma intercambiável na mesma frase, como se fossem 3 nomes para um único produto. É uma confusão compreensível. Os 3 aparecem nas mesmas conversas de BTCFi, os 3 remontam a bitcoin apostado (staked) por meio do protocolo da Babylon, e os 3 são apresentados como formas de tornar bitcoin ocioso produtivo.

Eles não são a mesma coisa, e a diferença importa se você se importa com o que está realmente confiando. O LBTC da Lombard é cunhado e resgatado por um Security Consortium que inclui nós institucionais como Galaxy e Wintermute, um grupo de partes que você está confiando para executar esse processo com honestidade. O Solv da SolvBTC é roteado por meio da sua própria Staking Abstraction Layer, e o stBTC do Lorenzo é emitido por Agentes de Staking designados, responsáveis por fazer o staking dos fundos dos usuários e reportar as provas de volta. Cada um deles é uma empresa separada que adiciona suas próprias suposições de confiança em cima do protocolo base de staking da Babylon. As próprias Trustless Bitcoin Vaults (TBV) da Babylon são outra categoria totalmente diferente: um primitivo de primeira parte em que o BTC fica em um cofre de autocustódia, pré-assinado, com acesso controlado por provas de zero conhecimento, sem consórcio nem agente de staking cunhando qualquer coisa em seu nome.

A Babylon é a camada de liquidação e segurança por baixo de LBTC, SolvBTC e stBTC — não é um rebrand de nenhum deles, e o TBV é o produto próprio da Babylon, ficando ao lado desses “wrappers”, em vez de estar dentro deles.

@BabylonLabs_io $BABY #baby
$WMTX

Os anúncios de financiamento são as notícias cripto mais fáceis de superestimar, então tento lê-los pelo que eles sinalizam sobre convicção, e não como evidência de sucesso do produto por conta própria. A tabela de capital da Babylon me dá muita coisa para analisar.

A lista inclui Polychain Capital, Hack VC, Paradigm, Galaxy Digital e um investimento de US$ 15 milhões da a16z crypto especificamente, entre vários outros fundos. Esse é um grupo de investidores realmente profundo, que entende bem a infraestrutura cripto o suficiente para ter dito não a várias propostas concorrentes de Bitcoin DeFi. Apostar em garantias nativas de BTC, entregues por meio de Trustless Bitcoin Vaults e Aave v4 em vez de um modelo com token envolvido (wrapped) ou ponte (bridged), foi uma escolha de tese concreta entre várias alternativas.

Ainda assim, eu não vou deixar isso substituir a evidência de que o produto funciona para pessoas que não estão sendo pagas para usá-lo. A atividade no testnet ligada a campanhas de incentivos diz quase nada sobre demanda orgânica, e todo protocolo que eu acompanhei ao longo dos anos teve que provar que essa lacuna se fecha depois do mainnet, quando as recompensas acabam e só o próprio mecanismo sobra para justificar o uso.

Convicção de capital de investidores sérios é um sinal real sobre a equipe e a tese. Não é um sinal sobre se um detentor de Bitcoin, sem incentivo de campanha, escolhe a Babylon em vez de simplesmente manter BTC e não fazer nada com ele. Esse segundo ponto de prova ainda não aconteceu.

@BabylonLabs_io $BABY #baby
$GIGGLE

Os detentores de Bitcoin no varejo não foram a única audiência que a Babylon tinha em mente ao projetar seus Cofres de Bitcoin sem Confiança (Trustless). E eu acho que essa é uma parte subestimada desta história. A Babylon está fazendo parceria com a Utila, uma plataforma institucional de carteira MPC confiável por mais de 300 instituições — incluindo exchanges, custodians, fundos de hedge e bancos — para oferecer empréstimos com garantia em Bitcoin nativo, com Aave v4 diretamente para os clientes institucionais da Utila.

Esse detalhe muda a forma como penso sobre quem realmente avança primeiro nessa tecnologia. Indivíduos valorizam a autocustódia por razões filosóficas e práticas, mas as instituições têm um conjunto completamente diferente (e muitas vezes mais rigoroso) de exigências em relação a risco de contraparte, atestações de custódia e controles operacionais. Uma instituição que se encontra com uma grande posição de Bitcoin nativa historicamente teve uma escolha ruim: deixá-la ociosa e improdutiva, ou entregá-la a um custodiante e aceitar exposição à contraparte apenas para acessar mercados de empréstimo. A proposta da Babylon para plataformas como a Utila é que o empréstimo com BTC nativo como garantia remove essa troca (trade-off) sem que as instituições abram mão do modelo de custódia operacional que elas já confiam.

O empréstimo com Bitcoin nativo como garantia via os Cofres de Bitcoin sem Confiança da Babylon já está ativo na testnet pública com Aave v4 hoje, e integrações institucionais como essa ainda são descritas como chegando nos próximos meses, em vez de estarem ativas agora. Essa lacuna entre o anúncio e o fluxo institucional ao vivo é algo que vale a pena observar de perto.

Eu fico me perguntando se as instituições realmente vão implementar uma escala significativa em um sistema que ainda está na fase de testnet e ainda aguarda a aprovação da governança do Aave sobre os parâmetros finais de risco, ou se isso vira volume real apenas quando a mainnet for ativada. Anúncios são baratos. Capital institucional aparecendo é o sinal de verdade.

@BabylonLabs_io $BABY #baby
$COTI

Uma liquidação em Bitcoin tem um problema de timing que liquidações em Ethereum não têm. O resgate nativo de BTC de um vault segue o ritmo de liquidação próprio do Bitcoin, e não há como forçar isso mais rápido sem entregar a alguém controle custodial sobre as moedas, o que destruiria o propósito inteiro do design desde o início.

Babylon e a resposta da Aave é desacoplar os dois eventos. Quando um vault é liquidado, ele é imediatamente convertido em WBTC, então a posição do credor é liquidada na hora de acordo com o cronograma do Ethereum. O resgate real do BTC nativo então acontece separadamente, no próprio cronograma do Bitcoin, sem segurar a resolução do empréstimo para mais ninguém no mercado. Há também um segundo benefício embutido nisso. A Aave atualmente detém perto de 5 bilhões de dólares em oferta de WBTC que a Babylon descreveu como subutilizada no lado de empréstimos; então, direcionar o acerto de liquidação por ela também devolve parte desse WBTC ocioso ao trabalho.

A alternativa seria obrigar toda liquidação a esperar por confirmação do Bitcoin nativo e pela lógica de resgate do vault antes que qualquer credor veja qualquer resolução. Isso é mais puro filosoficamente, sem tocar em ativos wrapped em nenhum momento, mas significa que as liquidações se movem no ritmo do Bitcoin exatamente no momento em que a velocidade é o que protege o credor de perdas adicionais.

Babylon não é wrap-free de ponta a ponta; é wrap-free para o caminho que a maioria dos usuários realmente vai seguir. Especificamente na fase de liquidação, a Babylon escolheu velocidade para o credor em vez de pureza para a saída do tomador — um trade defensável, mas ainda assim um trade.

@BabylonLabs_io $BABY #baby
$BANK

Diga "Bitcoin plus DeFi" para a maioria dos nativos do cripto e o cérebro deles pula direto para uma ponte ou sidechain. Embrulhe sua moeda, envie-a, confie em um conjunto de validadores ou em um multisig do outro lado e torça para que a ponte em si nunca vire manchete pelo motivo errado. Anos de exploits em pontes treinaram esse reflexo por um bom motivo.

Trustless Bitcoin Vaults (Cofres de Bitcoin sem confiança) são constantemente colocados nessa mesma categoria mental, e é o balde errado. O design da Babylon nunca remove BTC da rede do Bitcoin. A moeda é bloqueada em um UTXO do Taproot sob condições impostas por script e permanece ali durante todo o ciclo de empréstimos, enquanto o Ethereum só vê uma prova criptográfica desse estado bloqueado por meio de um light client, em vez de custodiar o ativo em si. Não existe uma cadeia de execução separada mantendo um pool de BTC “bridged” do jeito que um modelo de sidechain exigiria. A arquitetura de spoke do Aave v4 então direciona empréstimos contra essa prova, e não contra um token ponteado guardado no reserve de alguém.

Chamar isso de "apenas mais uma ponte" ignora a diferença real de engenharia e, honestamente, subestima o problema mais difícil que a Babylon escolheu resolver. Pontes movem valor. Isso move a prova de valor enquanto a moeda permanece exatamente onde começou.

A Babylon não é uma ponte de Bitcoin nem uma sidechain vestindo uma nova identidade. Com esse design, a moeda nunca deixa a rede do Bitcoin. O que atravessa para o Ethereum é uma prova de estado bloqueado, não o próprio ativo, e essa distinção é a razão inteira de que o risco de custódia no estilo “ponte” não se aplica aqui como se aplica em outros lugares.

@BabylonLabs_io $BABY #baby
$DEXE $BANK

A Babylon vende seu protocolo de staking pela ausência de custódia por terceiros: nenhuma empresa que detenha o seu BTC, nenhum operador de ponte que possa desaparecer com os fundos. O comitê de covenant fica um pouco desconfortável ao lado desse discurso. Trata-se de um grupo de múltiplas assinaturas de partes externas cujas assinaturas são legalmente exigidas antes que uma transação de desaccounting ou de slashing se torne válida — uma estrutura M-de-N imposta diretamente dentro do script do Bitcoin. Na documentação do próprio testnet da rede, esse comitê tinha 9 membros no total, e 3 desses 9 assentos, um terço completo, eram operados pela própria Babylon Foundation.

Uma parte que você não escolheu, detendo uma parcela relevante do poder de assinatura necessário para mover seus fundos por um caminho aprovado, é uma forma de exposição a contraparte, mesmo que mais restrita do que uma custódia em que alguém guarda suas chaves de forma direta. O próprio blog da fundação da Babylon reconhece isso de maneira explícita, descrevendo a premissa de confiança por trás desse tipo de comitê como reduzida à honestidade existencial — ou seja, basta que exista um signatário honesto, em vez de eliminar totalmente a possibilidade de má conduta — e propõe covenants criptoeconômicos que podem ser “slashados” como correção eventual.

A Babylon ainda não alcançou a confiança zero de terceiros que sua estrutura de “sem custódia” sugere, pelo menos não ainda: o comitê de covenant é uma dependência real, e a Foundation está dentro dele. O que ela construiu é uma dependência mais estreita do que a de uma custódia, com um plano próprio para estreitá-la ainda mais. São duas alegações diferentes, e apenas uma delas é totalmente verdadeira hoje.

@BabylonLabs_io $BABY #baby
$LAB

A maioria das cadeias de prova de participação (proof of stake) ancoram a segurança em um único ativo. Os validadores colocam em garantia o token nativo; má conduta é punida com slashing desse mesmo token; e o peso econômico do sistema se apoia em um único número: quanto desse token está bloqueado.

O Babylon Genesis executa, ao mesmo tempo, dois trilhos separados de segurança. Validadores do CometBFT protegem a cadeia por meio de delegação em BABY, enquanto um conjunto completamente diferente de participantes, os provedores de finalização (finality providers), a protege por meio de delegação em Bitcoin — e ambos os trilhos podem ser punidos por slashing de forma independente, caso seus participantes ajam mal. A cadeia financia os dois lados na mesma fonte: BABY carrega 8% de inflação anual, dividida exatamente ao meio: 4% para os stakers de BABY e os outros 4% para os stakers de Bitcoin. É uma divisão paritária, em vez de um lado subsidiar o outro. Até o registro de uma stake passa por uma transação do Cosmos SDK que consome BABY apenas como gás, já que o BABY em si nunca foi emitido como um token ERC-20.

A decisão de rodar dois trilhos em vez de um é uma aposta de que o peso econômico do Bitcoin e o peso econômico do BABY são ambos necessários e que nenhum deles, sozinho, é suficiente. Ancorar apenas no BABY deixaria a segurança criptoeconômica ligada a um token jovem, pouco negociado; ancorar apenas na delegação do Bitcoin deixaria o consenso sem um token cujos detentores estejam incentivados a governar a própria cadeia.

O Babylon não escolhe entre a segurança do Bitcoin ou o alinhamento de incentivos do BABY: ele financia os dois ao mesmo tempo com uma recompensa de inflação dividida igualmente. Isso revela uma equipe que não está disposta a apostar o orçamento inteiro de segurança da cadeia em um único ativo, mesmo quando um desses dois ativos vale muito mais do que o outro.

@BabylonLabs_io $BABY #baby
$PIEVERSE

Presumi que meu avô jamais conseguiria gerenciar um aplicativo de banco no celular; ele passou sessenta anos escrevendo cheques à mão. Depois, eu o vi verificar o saldo no meio de uma conversa, sem olhar para baixo. Eu havia subestimado o quanto um sistema antigo consegue se adaptar, e o Bitcoin é subestimado da mesma forma.

A suposição comum é que, como o Bitcoin não tem contratos inteligentes no estilo do Ethereum, simplesmente não consegue servir como garantia nativa de DeFi sem antes ser envolto em um token em outra cadeia. Esse contorno já gerou bilhões em explorações ao longo dos anos, porque normalmente significa confiar em um custodiante em algum lugar.

Os cofres da Babylon foram construídos especificamente para desafiar essa suposição. O BTC é travado em um UTXO regido por regras criptográficas predefinidas e transações pré-assinadas; para desbloqueá-lo, é preciso enviar uma prova de conhecimento zero em vez da assinatura de um custodiante. Aquele Bitcoin nativo e travado então funciona como garantia para empréstimos ou emissão de stablecoins em cadeias externas, incluindo Ethereum e Cosmos, sem que um token envolto seja cunhado. Todo o mecanismo roda no Bitcoin como ele existe agora, sem novos opcodes e sem necessidade de soft fork para tornar tudo isso possível.

A linguagem de scripting do Bitcoin, de fato, é mais limitada do que a do Ethereum. Essa limitação moldou como a Babylon teve de construir isso, favorecendo caminhos de transações pré-assinadas e verificação de provas fora da cadeia em vez da lógica flexível, sempre ativa na cadeia que o Ethereum permite. “Limitado” não é o mesmo que “incapaz”, e o projeto dos cofres é evidência de que a restrição pode ser contornada via engenharia, em vez de apenas ser contornada com um wrapper.

O Bitcoin não precisa se tornar Ethereum para participar como garantia em DeFi; só precisava de uma arquitetura diferente, e os cofres da Babylon mostram como isso fica.

@BabylonLabs_io $BABY #baby
$DEXE

Um senhorio de quem eu alugava certa vez ficava aumentando continuamente o número total de unidades do prédio convertendo salas de depósito em estúdios: tecnicamente mais oferta, tecnicamente mais receita e, tecnicamente, diluindo o quão especial qualquer unidade parecia ser para se viver. Crescimento e diluição apareciam na mesma reforma.

A BABY não tem uma oferta máxima fixa; rastreadores de tokenomics descrevem o cronograma de liberação como se estendendo indefinidamente, em vez de ser limitada a um número final como os 21 milhões do Bitcoin. A alocação inicial planejada cobre 10 bilhões de tokens nas categorias de investidores, equipe, ecossistema, P&D e comunidade, mas a emissão contínua além desse patamar não fica limitada pelo design do protocolo do mesmo jeito rígido. Os defensores interpretam isso como necessário: um conjunto de validadores em crescimento e provedores de finalidade, além de incentivos de comunidade de longo prazo, precisa de um fluxo sustentado de tokens em vez de uma alocação única que acaba. Os críticos apontam o mesmo mecanismo como uma pressão estrutural de venda; cerca de 3,99 bilhões de BABY já circulam e mais entra via vesting e emissões futuras a cada mês, diluindo a participação dos detentores atuais na rede, independentemente do crescimento do uso. As duas leituras partem do mesmo fato: uma oferta sem limite, continuamente expansiva, alimentando um token de governança e de gás cujo valor depende em parte da escassez e em parte da demanda por utilidade acompanhando as novas emissões. O histórico de preço da BABY adiciona contexto: uma alta em abril de 2025 perto de US$ 0,1661, seguida de uma queda de aproximadamente 93% para US$ 0,0107 em março de 2026, mostra que o mercado já precifica alguma versão desse debate sobre diluição.

Nenhum dos dois argumentos — o do crescimento ou o da diluição — vence totalmente aqui. Uma oferta infinita pode financiar um ecossistema amadurecendo ou, silenciosamente, corroer o valor do detentor, e qual desses desfechos acontece depende do crescimento da demanda que a Babylon não consegue garantir sozinha.

@BabylonLabs_io $BABY #baby
$DEXE

Uma amiga minha é uma médica licenciada no país onde mora, mas o hospital onde ela trabalha agora publica um aviso dizendo que a licença dela no domicílio não tem validade legal localmente. A mesma pessoa, o mesmo diploma, e ainda assim, aqui, se ela é "uma médica licenciada" depende inteiramente de qual manual de regras do país você consulta.

A GRVT está em uma situação semelhante. Em dezembro de 2024, ela obteve uma Licença de Negócios de Ativos Digitais Modificada da Classe M junto à Autoridade Monetária das Bermudas, que a empresa e a maior parte da cobertura descrevem como a que a tornaria a primeira bolsa de derivativos onchain regulada do mundo. Essa credencial é repetida constantemente em marketing e avaliações. Enquanto isso, a entidade operacional por trás do aplicativo, a GRVT Technologies Pte Ltd, fica em Singapura, e a própria listagem da loja de aplicativos da plataforma traz um aviso direto para aquele mercado: a GRVT não é licenciada, aprovada, autorizada, designada, reconhecida, registrada, ou de qualquer outra forma regulada sob qualquer legislação administrada pela Autoridade Monetária de Singapura, e os usuários de lá não têm nenhum dos salvaguardas regulatórias que a supervisão da MAS normalmente forneceria. Assim, a resposta honesta para "a GRVT é regulada" se divide por jurisdição, em vez de se resumir a uma única palavra. Bermudas, sim, sob uma categoria de licença modificada. Singapura, explicitamente não, nas próprias palavras da empresa. A plataforma também busca uma licença mais completa nas Bermudas, juntamente com engajamento com reguladores da União Europeia e do Oriente Médio, nenhum dos quais está concluído ainda. Um usuário que leia isoladamente a manchete de "a primeira DEX regulada do mundo" poderia razoavelmente supor uma cobertura mais ampla do que, na prática, uma única licença modificada em uma jurisdição pequena realmente oferece. Já um usuário baseado em Singapura, ao ler a ressalva detalhada na loja de aplicativos, tem exatamente a impressão oposta.

Se a GRVT é ou não regulada depende de qual jurisdição é perguntada: real em Bermudas sob uma licença modificada, explicitamente ausente em Singapura de acordo com o próprio aviso da empresa, e nenhum lado, sozinho, conta toda a história.

@grvt_io #grvt
$LAB $VELVET

Um amigo que construía um food truck insistiu em operá-lo em um estacionamento fechado por dois fins de semana antes de estacionar de verdade numa esquina de rua. A parceira dele queria lançar imediatamente no centro. Ele disse que o equipamento precisava falhar primeiro em algum lugar pequeno, não durante o almoço de um cliente que paga.

A GRVT colocou seu mercado spot no ar na testnet em 29 de abril de 2026, meses antes de qualquer declaração pública sobre uma data de lançamento do mainnet. Isso aconteceu depois de a exchange já ter construído sua reputação quase inteiramente em futuros perpétuos, abrangendo cerca de 168 mercados; por isso, o spot representou uma lógica genuinamente nova de pareamento e liquidação, e não um simples recurso acoplado. Executá-lo primeiro na testnet significou que usuários reais e integradores puderam rotear pedidos, testar casos-limite e identificar bugs contra um tipo de mercado que a plataforma nunca havia operado ao vivo antes, sem colocar em risco um único dólar de volume real de spot caso algo quebrasse. Exchanges concorrentes frequentemente lançam novos produtos diretamente no mainnet sob pressão de tempo vinda de lançamentos de tokens ou calendários de marketing, aceitando o risco de que bugs iniciais sejam descobertos por usuários pagantes em vez de testadores. O rollout do spot da GRVT fez parte de um roteiro mais amplo de 2026, sob a pressão real de prazos próprios; após uma sequência de anúncios vinculados a meses específicos, ainda assim a equipe inseriu uma etapa na testnet antes de permitir que pedidos de spot tocassem fundos reais. Essa escolha de sequenciamento troca velocidade para o mercado por uma chance menor de uma falha embaraçosa ou custosa quando o capital real começa a fluir por um tipo de pedido que a plataforma nunca havia executado ao vivo antes.

A GRVT não está correndo para levar todo produto novo direto ao capital real como a pressão do roadmap poderia sugerir; seu lançamento spot mostra uma disposição de desacelerar e fazer testes de estresse primeiro, mesmo enquanto o roadmap ao redor segue um prazo público.

@grvt_io #grvt
$LAB

A city near me installed live traffic cameras on its main bridge a few years ago and advertised them as real time. I checked one during a commute once, watched the same three cars sit frozen in the same spot for what felt like forever, and realized the feed only actually refreshed every 40 minutes or so. Nothing was broken, the label was just doing more work than the technology underneath it could support.

GRVT's chain settles through ZKsync's proof system, and the language around zero knowledge proofs often gets described loosely as real time verification of every transaction as it happens. In practice, independent monitoring from L2BEAT shows ZKsync Era's proof submissions land on Ethereum roughly every 38 minutes on average, with state updates following a similar 29 minute cadence, not on a per transaction basis at all. That is still fast by blockchain standards and it is not a flaw, proofs get batched deliberately to make each one economical to verify on Ethereum's base layer instead of every single trade. But it does mean your trade is proven on Ethereum is closer to your trade is included in a batch proven roughly every half hour than to an instant per trade guarantee. The same monitoring recorded an actual liveness gap in June 2026, where no proof submissions landed for over 10 hours against the typical 38 minute cadence, an anomaly rather than the norm, but a documented one worth knowing about regardless of how rare it was.

GRVT's underlying settlement is not verifying trades to Ethereum instantly the moment they happen, it is bundling roughly half an hour of activity into each proof before that proof lands on Ethereum, with occasional documented gaps stretching well past the average. The security guarantee is real once a proof lands, the timing of when that happens is simply slower and lumpier than real time suggests.

@grvt_io #grvt
$LAB

Muitos novos traders presumem que pagamentos de funding em uma exchange perpétua funcionam como uma taxa de negociação, dinheiro que a plataforma cobra por permitir que você mantenha uma posição alavancada durante a noite. Na GRVT, essa suposição é simplesmente errada. O funding é explicitamente peer to peer entre longos e curtos; a própria documentação da GRVT afirma de forma clara que funding não é uma taxa de exchange, ele não toca a receita da plataforma de maneira alguma.

O mecanismo existe apenas para manter o preço do perpétuo atrelado ao índice à vista. Quando o perpétuo negocia caro em relação ao spot, os longos pagam os curtos para comprimir esse prêmio de volta para perto de zero. Quando negocia barato, os curtos pagam os longos. A GRVT não é uma contraparte que extrai valor de qualquer um dos lados; ela é o ambiente que redistribui pagamentos entre dois grupos de traders que, estruturalmente, estão apostando um contra o outro na direção do preço. A receita da própria GRVT vem de taxas de negociação no lado taker e maker, uma linha totalmente separada do mecanismo de funding.

A diferença entre a suposição e a realidade aqui importa porque muda como um trader deve pensar sobre os custos de funding. Funding persistentemente alto não é a GRVT cobrando mais; é o próprio mercado sinalizando que os longos estão lotados e pagando um prêmio para continuar alavancado na ponta comprada. Entender que funding é um sinal de mercado, e não uma taxa de plataforma, muda como o trader o interpreta antes de abrir uma posição, e não depois de ser cobrado por uma. A primeira vez que vi uma taxa de funding consistentemente positiva em um mercado da GRVT, meu impulso foi checar se a plataforma tinha aumentado silenciosamente alguma taxa em algum lugar, e foi ao ler a documentação com atenção que entendi que aquele impulso estava simplesmente errado: o número estava me dizendo algo sobre o posicionamento de longos lotados naquele mercado específico, e não sobre a receita da GRVT, o que mudou totalmente como eu li cada gráfico de funding depois disso.

@grvt_io #grvt
$LAB

De fato, é sobre o subsolo 😳
$LAB