Marquitta Ullum lyUI

Meu pai, sessenta e dois anos, tinha um pouco de BTC na mão — foi eu que o convenci a comprar há alguns anos. No mês passado, levei-o comigo por todo o caminho do TBV. O processo foi mais trabalhoso do que eu imaginava, mas a colheita foi diferente.
No começo eu achava que o problema estava na parte técnica, mas não era nada disso. Ele já estava acostumado com conceitos como chaves privadas e endereços. O ponto que ele demorou a aceitar foi a frase: “Minhas moedas estão aqui comigo, mas por enquanto não consigo sacar.” Eu expliquei isso três vezes até ele aceitar. Em essência, as palavras dele foram: “Então, isso é realmente meu ou não?” No fim, eu decidi dar um exemplo com depósito a prazo — o dinheiro é seu, o banco não fica com ele, mas se você sacar antes do prazo tem que seguir as regras. Foi assim que ele entendeu, e aceitou mais rápido do que eu esperava.
O verdadeiro nível de dificuldade está em dois lugares. Um é o período de espera para sair: ele precisa saber com antecedência que durante essa fase ele não consegue mexer, senão, na hora, com certeza vai entrar em pânico e vai começar a suspeitar se foi golpeado; o outro é escolher o provedor de serviços. Ele não tem nenhuma capacidade de julgar, então eu só consegui escolher por ele — e ainda tive que deixar bem claro o que pode acontecer se essa etapa for escolhida errado. Essas duas coisas, nas interfaces atuais, não ficam particularmente visíveis. Para nós, que precisamos levar familiares para operar, vira um peso bem real.
O ponto que mais o tranquilizou também foi bem claro. Eu mostrei os endereços: as moedas realmente estavam na rede principal do Bitcoin, sem virar outra coisa; as condições de saída estão escritas no script, então qualquer pessoa pode verificar. Depois de ver isso, ele disse uma frase bastante interessante: “Então ninguém pode decidir por mim.” Eu sinto que essa frase foi mais do que qualquer explicação de rendimento. Ele pegou exatamente o ponto mais central dessa arquitetura.
Minha conclusão é: para quem já tem algum nível de entendimento, isso alivia; para quem é totalmente iniciante, isso pesa. Ele troca o custo de confiar por um custo de compreender, e esse custo de compreender não dá para terceirizar.
A seguir, pretendo transformar todo o processo em uma folha para ele, e também registrar o tempo de resgate dessa rodada dele, para ver se bate com o da minha própria vez.
@BabylonLabs_io $BABY #baby

Não completei a média do custo desta perda com novas compras. Colocar posições numa operação em prejuízo é o caminho mais rápido para transformar um pequeno erro num grande. A diluição reduz o custo, mas amplia o risco — esta conta nunca vale a pena. Se estiver errado, reconheça; na próxima, recomece. #TradFi晒单

Mesmo que o TBV funcione perfeitamente, a maioria dos BTC ainda não vai ser utilizada como garantia
Discussões técnicas costumam partir de um pressuposto: se o risco de custódia desaparecer, os BTC ociosos certamente entrarão em larga escala no mercado de collateral. Porém, na prática, as pessoas que detêm esses ativos tendem a não serem impedidas principalmente por falta de confiança, e sim por falta de motivação.
A necessidade central dos detentores de longo prazo é não fazer nada. Qualquer utilização como garantia introduz risco de liquidação, eventos tributários e ônus operacional. E, muitas vezes, a rentabilidade obtida com esses custos fica abaixo do nível de retorno que eles exigem com base na certeza sobre o principal.
O perfil de capital que realmente virá é bem específico: há necessidade estável de financiamento via stablecoin, aceitação das regras de liquidação, necessidade de conseguir explicar em auditoria o controle dos ativos, e incapacidade de aceitar risco de contraparte concentrado em um único emissor. Esse grupo existe, mas as fronteiras são bem claras.
Isso também significa que o alvo competitivo razoável do TBV não é todo o BTC, e sim aquela parcela de capital que, por questões de compliance ou controles de risco, não consegue usar ativos tokenizados/“wrapped”. Ao estimar o mercado potencial com base na capitalização total, tende-se a superestimar a demanda de forma sistemática.
Do lado da demanda, existe ainda um requisito implícito: as instituições precisam de que o custodiante, as ferramentas de auditoria e os sistemas de controle de risco deem suporte a essa estrutura de cofre. O ciclo de integração dessa natureza é medido em trimestres, e não termina automaticamente apenas com o lançamento do produto.
Assim, o progresso de @BabylonLabs_io não deve ser avaliado apenas pelos marcos técnicos; é preciso ver quantos custodiantes, quantos mercados de empréstimo e quantos provedores de controle de risco realmente concluíram a integração e colocaram em produção.
Vou acompanhar o volume real de BTC caucionado, o grau de concentração das fontes e a duração média de manutenção das posições. $BABY depende de quanto capital real entrou nesse sistema, e não de quantas pessoas concordam com a lógica de design.
@BabylonLabs_io $BABY #baby

Faz muito tempo que não escrevo sobre macroeconomia, mas o TBV me fez lembrar um velho problema: de que modo a “verba de segurança” do Bitcoin se sustenta a longo prazo.
As recompensas em bloco estão diminuindo; isso está previsto no protocolo, sem margem para negociação e sem mudar quando o preço sobe. No longo prazo, a segurança desse sistema tende a depender cada vez mais de outras fontes. As taxas fazem parte disso, e outra parte muito provavelmente virá de saber se o próprio BTC consegue gerar um efeito econômico real sem sair da rede principal. Isso não é uma questão de emoção, nem de narrativa — é uma questão de matemática. Quando o tempo chegar, é inevitável encarar.
Acredito que o significado do TBV está exatamente aqui. Em vez de “embrulhar” o BTC para colocá-lo em outro lugar, ele permite que quem o mantém, mantendo a custódia própria, use o capital para prover segurança às redes que precisam dela — e, ao mesmo tempo, receba recompensas. Essa trajetória é totalmente diferente das abordagens passadas de “entregar moedas e receber juros”: no primeiro caso, não se adiciona nenhum custodiante, nem se empilha risco; no segundo, cada camada extra introduz mais um elo possível de dar errado, e nestes anos foram exatamente esses elos que falharam — nenhum escapou.
Minhas dúvidas também são bem concretas. Do lado da demanda, quão grande ela realmente é? Quanta rede estará disposta a pagar por segurança a longo prazo? A que nível de preço unitário isso aguenta? Esse mercado consegue crescer até uma escala relevante? Ainda não há dados suficientemente longos para responder. Qualquer argumento que fale apenas de visão sem entrar na demanda, eu desconto. É justamente isso que eu mais me preocupo ao analisar ativos como $BABY : o valor final precisa ser sustentado por uma demanda real e paga; não é algo que se sustente por narrativa, porque histórias duram pouco.
Mas pelo menos a direção está certa. O maior desperdício do Bitcoin não é a volatilidade de preço, e sim o fato de que trilhões ficam ociosos por muito tempo — ao mesmo tempo em que não se pode simplesmente entregar a custódia para fazê-los se moverem. Por mais de uma década, quase ninguém conseguiu resolver bem esse problema. O TBV tenta abordar as duas coisas ao mesmo tempo, e essa linha de pensamento merece ser analisada com seriedade por um tempo.
A seguir, planejo registrar trimestralmente as mudanças do lado da demanda; só olhando dados, sem ouvir histórias.
@BabylonLabs_io $BABY #baby

Compreender o valor do TBV exige primeiro enxergar o que ele substitui.
O custódio de bitcoin cross-chain tradicional geralmente é um multisig com limiar: entre n signatários, basta juntar t para movimentar os fundos. Por isso, a segurança se resume a uma frase: "pelo menos n-t+1 pessoas não conspirem". O problema dessa suposição é que ela falha conforme o tamanho do conluio aumenta; e como o conluio é uma ação off-chain, ele não pode ser visto nem prevenido antecipadamente on-chain. Historicamente, a maioria das pontes que deram errado caiu justamente aqui.
O que o TBV quer fazer é virar a direção da suposição: sair de "a maioria é honesta" e ir para "pelo menos uma pessoa é honesta". O caminho de gasto do dinheiro é fixado previamente por pré-assinatura; se será possível recuperar os fundos depende de as alegações do operador estarem corretas, e qualquer participante honestidade individual tem capacidade para submeter uma prova de fraude para derrubá-las. O comportamento malicioso exige que todos permaneçam em silêncio ao mesmo tempo, e não mais apenas reunir um limiar.
As diferenças nesse sentido são substanciais. No primeiro caso, a segurança se dilui conforme aumenta o número de participantes; no segundo, ela melhora com mais participantes, porque, enquanto houver mais uma pessoa, aumenta a chance de haver uma denúncia.
O custo também é bem claro: os desafios mencionados nas primeiras partes — janela de desafios, liquidez adiantada, a suposição de chaves para o ritual de pré-assinatura, e a ativação das taxas — tudo isso é a complexidade paga para trocar essa suposição. Se essa complexidade compensa, depende de conseguir operar de forma estável em um ambiente real. Eu entendi a concepção do mecanismo; o que resta é ver os dados na implantação prática.
@BabylonLabs_io $BABY #baby

Ao estudar o TBV @BabylonLabs_io , eu prestei atenção especial ao seu processo de peg-out. O desenho do período de desafio (challenge period) nessa etapa é o “esqueleto” de todo o modelo de segurança do TBV, mas também é o ponto de custo mais fácil de ser ignorado pelos usuários.
Primeiro, vamos ao mecanismo. Quando o usuário precisa resgatar os ativos e convertê-los em BTC, a contraparte inicia uma transação de peg-out. Essa transação não é efetivada imediatamente; ela entra em um período de desafio. Durante esse intervalo, qualquer observador (watcher) pode enviar uma prova de fraude. Se a contraparte tentar roubar BTC ou submeter um estado incorreto, a prova será verificada e a transação será bloqueada. Depois que o período de desafio termina, sem objeções, o peg-out só então é confirmado.
Esse desenho, na essência, une “segurança” com “tempo”. Quanto mais longo o período de desafio, maior a chance de os observadores descobrirem problemas, mas por outro lado os fundos dos usuários ficam travados por mais tempo. Quanto mais curto o período de desafio, melhor a experiência, mas também mais estreita é a janela em que a fraude pode ser descoberta. É um problema clássico de trade-off, e o Optimistic Rollup segue a mesma lógica.
Eu acho que há dois detalhes que valem ser observados: primeiro, o papel do observador é sem permissão? Se qualquer pessoa puder observar, e qualquer pessoa puder enviar o desafio, com incentivos econômicos para isso (por exemplo, confiscar a garantia do agente mal-intencionado como recompensa), então o modelo de segurança tende a ser mais robusto. Se os observadores forem baseados em whitelist ou exigirem qualificações especiais, o risco se concentra. Segundo, qual é a duração exata do período de desafio? Sete dias? Quatorze dias? Isso afeta diretamente a experiência do usuário e a eficiência do capital, além de determinar se o TBV consegue atender estratégias DeFi de curto ciclo.
O TBV leva a suposição de confiança de nível de segurança do BTC para uma ponte cross-chain, mas o custo é que os usuários precisam aceitar esse custo de tempo. Ao avaliar a aderência de produto ao mercado do $BABY , se o período de desafio pode ser aceito por usuários do DeFi é o primeiro obstáculo prático; não é um problema apenas técnico.
@BabylonLabs_io $BABY #baby

Fiz por alguns anos coisas relacionadas a BTCFi, revirei todas as propostas do mercado que “tiravam” Bitcoin, esbarrei em wBTC, tBTC, renBTC e em várias pontes de LP. Ontem, depois de ler o whitepaper do TBV com seriedade, fiquei meio abalado.
Vamos começar pelo wBTC: o BitGo faz o custódio. O usuário envia BTC ao custodiante e, na cadeia, cunha um ERC-20 1:1. O modelo de risco é simples e bruto — confiar totalmente no BitGo para não fugir com os fundos, não se aproveitar indevidamente e não ser congelado por autoridades/regulação. Isso é custódia totalmente centralizada.
tBTC v2 é um pouco melhor. Ele usa um conjunto de signers com um esquema de assinatura limite (tECDSA) para gerenciar o BTC; os signers precisam depositar tokens T como garantia econômica, e teoricamente, se maldarem, são penalizados. Porém, o pool é centralizado: uma vez que o limiar é comprometido, todo o lote de BTC fica em risco. Além disso, os usuários dependem da atividade do conjunto de signers para fazer saques.
O caminho do TBV é totalmente diferente: ele nem “leva” o BTC embora. O BTC fica o tempo todo dentro do seu próprio Taproot UTXO na mainnet. O usuário continua sendo um dos signatários conjuntos do UTXO. O Covenant Committee só tem autoridade para aprovar caminhos pré-assinados; ele não consegue mover as moedas sozinho. Mesmo que todo o ecossistema Babylon desapareça amanhã, depois de o usuário superar o timelock de unbonding ele consegue retirar de forma independente.
Resumindo em uma frase a diferença: wBTC é “o custodiante tem BTC, você tem uma nota promissória”; tBTC é “a ponte de limiar tem BTC, você tem um token wrapped”; TBV é “você sempre tem BTC, apenas recebeu uma promessa de cessão de uso”.
Essa diferença é crucial para a entrada de instituições. Para fundos de conformidade comprarem BTC, a parte mais difícil é a auditoria — quando os recursos saem de uma carteira sob controle do próprio fundo, é preciso seguir uma tonelada de processos. No modelo TBV, ferramentas de auditoria na cadeia conseguem varrer diretamente os UTXOs para provar que as moedas existem; não envolve nenhuma ponte interchain nem custódia.
Como vocês veem esse “staking no mesmo lugar” competindo com pontes cross-chain tradicionais? A longo prazo, isso vai apertar a participação de wrapped BTC?
@BabylonLabs_io $BABY #baby

Ao estudar o modelo de tokens da Babylon, notei uma estrutura em camadas: existem, em paralelo, o staking de BABY e o staking de BTC. Ambos participam da segurança do protocolo, mas com papéis diferentes.
Os stakers de BABY são principalmente responsáveis pelo próprio consenso PoS do protocolo, validando transações e transições de estado na chain da Babylon. Já os stakers de BTC, por meio do bloqueio com time-lock, comprometem BTC ao protocolo, oferecendo segurança econômica adicional para a validação cross-chain e para a finalidade (finalidade) do TBV. Essas duas partes recebem incentivos em BABY, mas os limites de responsabilidade são bem definidos.
O interessante é a proporção de alocação da inflação. Na inflação do token BABY, uma parte é destinada aos stakers de BABY, outra parte aos stakers de BTC e uma terceira parte é destinada ao desenvolvimento do protocolo e à construção do ecossistema. Esse modelo de alocação reconhece uma realidade: os detentores de BTC são o maior grupo de usuários do sistema de TBV da Babylon; sua participação determina diretamente o teto do TVL do protocolo. Incentivá-los com “dinheiro de verdade” é muito mais útil do que apenas fazer narrativas.
Do ponto de vista da teoria dos jogos, esse desenho de dupla garantia (duplo staking) na prática cria um vínculo de interesses entre detentores de dois tipos de ativos. Os stakers de BTC querem que o TBV seja seguro, utilizável e tenha mais integrações com cenários de DeFi, pois assim os seus ganhos conseguem continuar. Já os stakers de BABY querem que o uso do protocolo cresça, porque isso faz com que as receitas de taxas e a demanda por tokens aumentem. As metas dos dois grupos ficam altamente alinhadas, formando um ciclo virtuoso.
Em comparação com outros projetos de BTCFi, muitos dependem totalmente de endosso de marca do BTC, mas sem vínculo econômico real; ou então usam uma lógica de token independente sem relação com o BTC. A Babylon, ao fazer a acoplagem funcional entre as propriedades dos ativos BTC e as propriedades de governança do BABY via TBV, apresenta uma diferença arquitetural que tende a se tornar mais evidente ao longo do tempo.
Eu não prevejo o preço de curto prazo do BABY, mas posso dizer isto: se a curva de adoção do TBV realmente acontecer, o modelo de captura de valor do BABY é claro e sustentável — não é baseado em emoções, e sim no fluxo de caixa do protocolo e no uso real.
@BabylonLabs_io $BABY #baby

EOTS é uma das partes mais “hardcore” do stack técnico da Babylon. Eu levei três noites em claro para entender o suficiente para acompanhar. Sua sigla completa é Extractable One-Time Signature (assinatura extraível de uso único), ou seja, uma assinatura que pode ser extraída apenas uma vez. Para o TBV implementar slashing na cadeia BTC, é necessário contar com isso.
Em termos bem gerais: o signatário só consegue assinar uma vez a mesma mensagem. Se ele assinar duas vezes conteúdos diferentes, as relações matemáticas entre as duas assinaturas automaticamente revelarão a chave privada. O processo inteiro acontece no nível criptográfico, sem necessidade de um terceiro mediador. Parece conversa de outro mundo, mas a academia estuda isso há muitos anos, e a Babylon conseguiu “industrializar” a ideia no formato que pode ser verificado por scripts do BTC.
O que isso significa para o TBV? Se um finality provider assinar em dois blocos conflitantes, as assinaturas EOTS dele para o pool de colateral do BTC vão expor a chave privada ao mesmo tempo. Qualquer pessoa que encontrar essa chave privada consegue executar uma transação de slashing em seu lugar, removendo o BTC dele. A punição não depende de decisão de comitê nem de votação de governança; é pura ativação criptográfica.
Vamos a uma analogia: punição padrão por quebra de contrato é “assina contrato → dá calote → tribunal julga → execução forçada”. O EOTS é mais como “ao assinar o contrato, a chave já fica largada no chão na porta; no instante em que você viola, a chave voa automaticamente—quem vê, consegue abrir a porta”. A execução imediata e a impossibilidade de evitar são garantidas pela matemática.
Mas há limites na implementação. A seção 14 do whitepaper admite: o EOTS assume que a proteção da chave privada do signatário é de uma entidade única. Se usar MPC com fatiamento, a detecção de dupla assinatura precisa de mecanismos adicionais. E em ambiente de produção, finality providers geralmente usam MPC para aumentar a disponibilidade, o que abre uma nova superfície de ataque.
Um dos problemas que a camada de governança $BABY terá de tratar no futuro é como coordenar a teoria pura do EOTS com a realidade de engenharia do MPC. Isso não é um problema de criptografia, é um problema de engenharia de sistemas.
Minha opinião: o EOTS é a mais bonita conquista criptográfica do TBV—permite que o BTC também suporte slashing, uma punição ativa. Mas quando uma teoria bonita cai na engenharia, sempre há concessões; não transporte diretamente a segurança de artigos acadêmicos para o ambiente operacional.
Como de costume, DYOR. O EOTS é o fosso defensivo da Babylon—ou ainda é uma ponte de vidro entre teoria acadêmica e prática de engenharia? Desmontem no campo de comentários.
@BabylonLabs_io $BABY #baby

Qualquer sistema chamado, por assim dizer, de “retirar a necessidade de confiar”, no fim precisa responder uma questão: quem opera, na prática, a infraestrutura, e por que não faria o mal. TBV também é assim.
Em termos de arquitetura, o TBV envolve algumas categorias-chave de participantes. O Vault Operator coordena os depósitos e retiradas dos usuários, além das atualizações de status; os Universal Challengers monitoram atividades fraudulentas e, quando necessário, enviam provas de contestação; os geradores de provas são responsáveis por produzir as provas zk necessárias para desbloqueio e liquidação. Se essas três categorias falharem, ou forem controladas pela mesma parte, “descentralizar a confiança” vira um compromisso apenas no papel.
O que mais me preocupa é o desenho de incentivos do contestador. No modelo otimista de Rollup, os incentivos dos contestadores sempre foram um problema: em condições normais, a maioria das transações é honesta, então as oportunidades de um contestador agir são poucas; uma vez que, de fato, se capture uma fraude, a recompensa consegue compensar o custo de ficar “de plantão” a longo prazo? Se não conseguir, contestadores racionais sairão, deixando apenas algumas poucas instituições profissionais, e o risco de centralização volta silenciosamente.
A função do Vault Operator também precisa ser cuidadosamente destrinchada. A operadora consegue recusar serviços? Consegue desaparecer em um momento crucial, forçando os usuários a seguirem caminhos de saída de emergência complexos? No design do TBV, deve haver um mecanismo de saída forçada, para que o usuário recupere o BTC mesmo quando a operadora falhar; mas esse conjunto de processos não é amigável para usuários comuns — é uma questão de outro nível.
A segurança econômica do TBV não é um problema único de criptografia; é uma engenharia sistêmica de jogo entre múltiplos participantes. Parâmetros do protocolo, regras de penalidades e critérios de admissão — se qualquer item for configurado de forma inadequada, pode desequilibrar todo o sistema. Espero ver a divulgação de um modelo de segurança econômica mais detalhado, incluindo cálculos de custo-benefício sob diferentes cenários de ataque e resultados de testes de estresse em condições extremas de mercado.
Ser viável do ponto de vista técnico não significa que a direção econômica seja coerente. Essas duas linhas precisam andar juntas.
@BabylonLabs_io $BABY #baby

As stablecoins agora são a vertente mais lucrativa do mundo cripto. O valor de mercado combinado de USDT e USDC já ultrapassa US$ 200 bilhões, e os lucros anuais da Circle e da Tether ficam na casa de dezenas de bilhões de dólares. Em termos de estrutura de colateral, ambas dependem principalmente de Treasuries dos EUA e dinheiro em caixa; os substitutos descentralizados como DAI/USDS também vêm migrando para a tendência de RWA. Como o BTC é o ativo cripto com maior valor de mercado, ele nunca conseguiu uma fatia condizente no mercado de colateral para stablecoins—e a raiz disso está no risco de custódia. O TBV de @BabylonLabs_io tem esperança de mudar esse cenário.

TBV é a sigla para Trustless Bitcoin Vault. O BTC é bloqueado em um contrato do cofre na mainnet que não se desloca. Com base na proposta do BitVM3, os cálculos complexos são feitos fora da cadeia usando circuitos embaralhados; na cadeia, ficam apenas provas de fraude simplificadas. Do lado do Ethereum, são geradas credenciais de estado de colateral sustentadas por criptografia, para chamadas de contratos inteligentes. Para desbloquear, é preciso fornecer uma prova ZK que corresponda ao estado do contrato correspondente; para a liquidação, também é necessário fornecer uma prova ZK. Não há multisig, custodiante nem oráculo.

Para protocolos de stablecoin, o TBV oferece um tipo de colateral com “liquidez no nível de BTC + custódia sem centralização”, o que praticamente não existia no passado. O whitepaper afirma de forma explícita que a cunhagem de stablecoins é um dos principais cenários de uso do TBV. Isso sugere que, no futuro, pode surgir uma stablecoin descentralizada com lastro em BTC: o colateral seria um BTC auto-custodiado, e a cunhagem e a liquidação seriam totalmente impulsionadas por provas ZK. Se esse produto conseguir funcionar, o espaço de mercado não é pequeno.

A base é o protocolo de staking de Bitcoin da Babylon: TVL acima de US$ 5 bilhões e mais de 50.000 BTC bloqueados. A primeira integração é com o Aave v4: bloqueia BTC → cria credencial de colateral → toma stablecoin → quita o empréstimo para desbloquear. Em maio, a parceria de Gomining introduziu pela primeira vez 1000 BTC em testes com “ouro de verdade”.

Pensando com calma: a volatilidade do BTC é significativamente maior do que a dos Treasuries; para usar BTC como colateral de stablecoins, é necessária uma taxa de colateral mais conservadora, o que reduz a eficiência de capital. Além disso, o risco de atraso na liquidação em condições extremas, proporcionado pelo mecanismo de “período de desafio”, também precisa ser validado por modelos. Ainda assim, a direção faz sentido e vale a pena acompanhar.
@BabylonLabs_io $BABY #baby

A entrada do BTC na DeFi hoje tem principalmente três caminhos. O primeiro é WBTC: custódia pela BitGo, maior valor de mercado e a melhor liquidez. Porém você precisa confiar na empresa BitGo; depois das controvérsias sobre a mudança de controle em 2024, essa confiança se fragmentou bastante. O segundo é tBTC: uma solução de multisig da Threshold Network; é mais descentralizada, mas a liquidez é mais fina. O terceiro é o TBV <c-1/> apresentado agora por @BabylonLabs_io — um caminho completamente diferente: o BTC nem sai da rede principal do Bitcoin.

O mecanismo do TBV é travar o BTC em um contrato de cofre na cadeia do Bitcoin; com a solução BitVM3, então são geradas na lateral do Ethereum credenciais verificáveis de estado de garantia. Fora da cadeia, circuitos “embaralhados” lidam com cálculos complexos; na cadeia, ficam apenas provas de fraude simplificadas, mantendo as taxas sob controle. Para o usuário desbloquear o BTC, ele precisa enviar uma prova ZK correspondente ao estado do contrato. Para o liquidante mover a garantia também precisa enviar uma prova ZK. Em todo o processo não há custodiante, não há multisig e não há oráculos.

Comparando fica bem claro: WBTC confia em uma empresa de custódia; tBTC confia em um conjunto de signatários; TBV só confia em criptografia e no período de disputa (challenge period). Os dois primeiros são “problemas de pessoas”; o último é “problema de matemática”. Vulnerabilidades matemáticas podem ser corrigidas; problemas de pessoas são mais difíceis de ajustar.

A solução de staking de Bitcoin da Babylon é a base: seu protocolo de BTC com TVL acima de US$ 5 bilhões, com mais de 50.000 BTC travados, fornece uma rede madura de validadores e uma base sólida de liquidez para o TBV. O primeiro cenário integrado é o Aave v4: travar BTC → credenciais → tomar empréstimo em stablecoin → pagar para desbloquear. O whitepaper também traça ramificações como emissão de stablecoin, margens perpétuas e algumas linhas de staking de liquidez. A parceria de Gomining em maio foi um teste “no mundo real” com escala de 1000 BTC.

Sem enfeitar as desvantagens. A experiência do usuário do TBV é mais complexa do que a do WBTC: o período de disputa desacelera o ritmo das operações e a auditabilidade dos circuitos fora da cadeia também é um novo desafio. No curto prazo, a liquidez e a conveniência do WBTC ainda vão levar vantagem. Mas se o TBV conseguir encapsular essa complexidade a ponto de o usuário nem perceber, substituição em longo prazo não é impossível.

@BabylonLabs_io $BABY #baby

Após 2024, a supervisão global sobre derivativos de criptomoedas foi claramente sendo apertada. Nesse contexto, ao reavaliar a proposta do @grvt_io , sinto que a rota escolhida por ele foi bastante visionária.
Primeiro, vamos ao contexto. A SEC e a CFTC dos EUA aumentaram a intensidade de fiscalização contra produtos baseados em contratos. A MiCA da União Europeia passa a valer integralmente. Em Hong Kong, Singapura e no Japão, os sistemas de licenciamento de conformidade vêm se aperfeiçoando gradualmente. O modelo tradicional de “offshore + anonimato” nas negociações cripto está sendo comprimido de forma sistêmica. As escolhas que os usuários terão pela frente são: ou aceitam o KYC em plataformas em conformidade, ou negociam em zonas cinzentas com pouca proteção.
$BTC
A GRVT escolheu um caminho intermediário que é amigável à conformidade, mas sem abrir mão da soberania do usuário. Ela tem licença (segundo informações publicamente disponíveis, registrada nas Bermudas e detentora de permissões relacionadas), faz KYC em nível institucional e, ao mesmo tempo, mantém a característica de não custódia — os fundos ficam nas contas inteligentes do usuário; a exchange não consegue congelar ou desviar. Essa combinação, em um ambiente de supervisão cada vez mais rígida, tem mais espaço de sobrevivência do que um DEX puramente anônimo e, ao mesmo tempo, consegue lidar melhor com o nível de “risco de custódia” do que uma CEX tradicional.
Quais são os impactos práticos para usuários comuns?
Primeiro, no futuro, plataformas que consigam fazer saques e aportes sem problemas quase certamente vão exigir KYC. Resistir ao KYC significa que as plataformas disponíveis vão ficando cada vez menos. O processo de KYC da GRVT é relativamente amigável: para a aprovação, documentos de identidade com comprovante de endereço das regiões principais costumam bastar, sem coleta excessiva de dados.
Segundo, as probabilidades de sobrevivência de plataformas em conformidade são maiores. Nos últimos anos, muitas exchanges que foram encerradas por fiscalização tinham por anos evitado a supervisão. Ao escolher plataformas mais amigáveis à conformidade, a segurança dos fundos tende a ser melhor no longo prazo.
Terceiro, conformidade não é sinônimo de centralização. A conformidade da GRVT se manifesta principalmente no nível da entidade legal; no nível técnico, ainda se trata de não custódia on-chain. Essas duas coisas podem coexistir — não é necessário escolher apenas uma.
Vale lembrar: nenhuma plataforma única deveria carregar toda a posição (exposição). Isso é algo que enfatizo repetidamente em vários textos. Diversificar não é apenas diversificar ativos; também deve significar diversificar plataformas e regiões. Plataformas on-chain não custodiantes, CEX em conformidade e carteiras frias — cada uma tem seu papel.
A intensificação da supervisão não é necessariamente uma coisa ruim: ela vai eliminar maus agentes de forma mais duradoura, e deixar equipes sérias focadas em desenvolver produtos. Esse processo é um benefício líquido para os usuários.
@grvt_io #grvt

Eu tenho pensado em uma questão: o @NewtonProtocol diz que o que ele faz é uma rede orientada a intenção (intent-centric) — mas em que exatamente isso difere do modelo tradicional de transações.
Revisei a documentação algumas vezes. Intent, em linguagem simples, é a forma como o usuário expressa “qual resultado eu quero”, e não “qual etapa eu devo executar”. Transação tradicional é: quero trocar 100 USDC por ETH e usar a pool de 0,05% do Uniswap V3. Intent é: quero usar 100 USDC para obter o máximo possível de ETH, e o operador calcula o melhor caminho por mim.
Parece que poupa trabalho ao usuário, mas eu acho que não é tão simples assim.
O modelo de intent tem um pré-requisito: é preciso haver uma quantidade de operadores dispostos a ajudar os usuários a resolver o problema, e as respostas que eles encontram precisam ser melhores do que as que o próprio usuário concluiria “no chute”. Aqui existem dois tipos de custo: custo de solução e custo de concorrência. A abordagem da Newton é fazer com que os operadores rodem dentro de um TEE, e ao mesmo tempo usar políticas para restringir os limites de execução; em teoria, isso consegue resolver, ao mesmo tempo, “me ajude a calcular rápido” e “não permita que você faça coisas erradas”.
Mas eu calculei o custo do nível de experiência. Antes do usuário assinar uma intent, ele precisa entender claramente qual é a sua policy. Se a policy for escrita de forma ampla demais, o operador pode acabar agindo numa zona cinzenta; se for estreita demais, a intent não consegue ser executada. Esse ponto de equilíbrio, o usuário comum simplesmente não sabe como definir.
Minha conclusão é: o modelo de intent é amigável para desenvolvedores e para curators, mas não é amigável para pequenos investidores. Para a Newton permitir que os pequenos investidores usem diretamente, precisa existir uma camada de “simplificação” em que o usuário só precisa clicar em alguns botões para gerar uma policy razoável. $BTC
Depois, vou focar especialmente em quando a Newton vai conseguir construir essa camada. Por mais que a arquitetura técnica seja elegante, se o usuário não entende, não adianta nada. Se essa etapa não avançar, a network de intent sempre será um brinquedo para o segmento B. A verdadeira escala não está no protocolo em si, e sim na camada de empacotamento.
$NEWT @NewtonProtocol #Newt

#BinanceTurns9 9周年，币安有你抛开繁杂琐事，给自己留一点独处时光。窝在房间听听歌，整理杂乱桌面，放空胡思乱想。不用时刻迎合所有人的期待，你的感受永远最重要。生活藏着无数温柔，只要愿意抬头，就能看见星光与晚风，认真好好生活，好运自会奔赴而来。

Como alguém que ocasionalmente usa uma estratégia de execução por pontos, quando vou avaliar uma nova plataforma de trading, tenho o hábito de primeiro ler a documentação da API, porque muitos problemas só aparecem quando você realmente integra. Nos últimos dias, estudei com seriedade o design da interface do @grvt_io e percebi que, em alguns detalhes, ele é mais cuidadoso do que eu esperava.
Primeiro, a latência. Quem já trabalhou com estratégias sabe que uma latência de matching instável é ainda mais problemática do que ser globalmente mais lenta, porque backtest e negociação ao vivo acabam não batendo. O GRVT processa o matching em um ambiente de alto desempenho fora da cadeia (off-chain), mantendo, ao mesmo tempo, a determinismo da liquidação on-chain. Essa combinação permite que a resposta ao envio de ordens fique próxima do nível de plataformas tradicionais, sem precisar aguentar confirmações em escala de segundos típicas de um fluxo puramente on-chain.
Depois, a lógica de assinatura. Ele usa autorização por assinatura da carteira, então o usuário não precisa entregar o API Key — e, com isso, o risco de ativos que existe em plataformas centralizadas. Depois que a estratégia começa a rodar, mesmo que uma chave seja vazada acidentalmente, o atacante não consegue mover os ativos diretamente, porque o caminho de saque permanece bloqueado no endereço que é controlado pelo próprio usuário. Esse design é crucial para equipes que rodam múltiplas contas ou fazem serviços de custódia para clientes.
Os tipos de ordem também não deixam a desejar. Limite, mercado, take profit e stop loss, Post Only e Reduce Only — esses tipos comuns estão todos presentes. Para estratégias de grid ou market making, a frequência de ações de colocar e cancelar ordens também dá conta. O que eu mais me importo é a velocidade de cancelamento, e nos testes ficou dentro de uma faixa aceitável.
Indo um pouco mais fundo, ele deixa a engine de liquidação e as lógicas de controle de risco relativamente transparentes: regras de cálculo de margem e o algoritmo de preço de liquidação forçada (strong liquidation) podem ser consultados com explicações claras. Isso é muito importante para modelagem na fase de backtest. Muitas plataformas escondem partes do mecanismo de liquidação forçada, e isso faz com que estratégias falhem de repente em cenários de mercado extremos. $BTC
No geral, o GRVT deixa aos usuários de quant uma margem de manobra maior do que a maioria dos projetos de derivativos on-chain; ele não trata “on-chain” como um rótulo para impressionar, mas sim coloca o foco em “realmente conseguir rodar estratégias”. Acho essa orientação pragmática bem rara.
@grvt_io #grvt

Eu revisei alguns registros de attestation no Explorer de @NewtonProtocol na semana passada e calculei a latência média de validação. Os dados não são ruins, mas também não são suficientes para sustentar cenários realmente de alta frequência.
O fluxo de attestation do Newton é, em linhas gerais: o agent envia uma solicitação de transação, a rede do operator valida a policy, alcança o consenso e assina a attestation, e então a transação é registrada on-chain. O principal custo de tempo desse processo está na etapa de consenso na rede do operator. Na beta da mainnet atual, a latência média fica entre alguns segundos e dezenas de segundos, dependendo da velocidade de resposta do operator e das regras de consenso. $NEWT
Para cenários de usuários comuns, essa latência está ok. Mas para agents que fazem arbitragem ou relacionados a MEV, é uma falha fatal. Uma latência de alguns segundos significa que a oportunidade de arbitragem já teria desaparecido. A camada de policy do Newton é adequada para automação de frequência média/baixa, não para trading de alta frequência. Isso é uma decisão de arquitetura, não algo que dá para ajustar com parâmetros. #newt
Mais sutil ainda é a variação de latência após a expansão da rede de operators. Em teoria, quanto mais operators, maior a segurança, mas o custo de comunicação na etapa de consenso também aumenta. Se o número de operators sair de algumas dezenas para algumas centenas, a latência pode subir para a faixa de dezenas de segundos. Isso impacta muito a experiência do usuário, e o Newton precisa encontrar um equilíbrio entre o tamanho da rede de operators e a velocidade de resposta. $SYN
Meu entendimento atual: o posicionamento de desempenho do Newton é como uma camada de execução confiável para automação de frequência média/baixa, não como uma plataforma de alta frequência. Entender esse limite ajuda a compreender os cenários de aplicação do Newton. Passar desse limite esperando demais leva à decepção.
$NEWT @NewtonProtocol #Newt

Uma realidade constrangedora nesse setor de perps perpétuos on-chain é a seguinte: muitas plataformas gritam “descentralização”, mas há muito poucos dados que realmente possam ser auditados. O @grvt_io , nesse ponto, me faz sentir que vale a pena escrever um artigo à parte.
Primeiro, vou falar de uma validação prática que fiz. Na última quarta-feira, eu fiz uma operação em uma posição short de ETH na GRVT, travando pelo preço de execução de 3.428 e pela quantidade de 2,4 ETH. Essa transação aparece no front-end como executada após cerca de 12 segundos. No navegador do explorador de blocos do L2 correspondente, encontrei o registro de liquidação: o resultado do matching foi empacotado em uma transação em lote, contendo o hash da ordem, o preço de execução, a quantidade e os endereços das contas de ambas as partes (taker/maker, com ofuscação), e a seguir a raiz de estado (state root) desse lote é submetida de volta à mainnet da Ethereum.
Ou seja, embora o matching off-chain não possa ser verificado em tempo real, todas as execuções podem ser auditadas completamente depois. Qualquer pessoa, ao acessar um explorador de blocos, consegue checar se suas ordens históricas realmente foram executadas e se o preço de execução é igual ao do front-end. Essa capacidade a maioria das CEX não tem absolutamente, e muitos dos chamados “DEX on-chain” também só fazem de forma parcial.
Fundo de seguro, registros de liquidação, fila ADL e o fluxo de fundos do Yield Layer — tudo isso na GRVT é verificável on-chain. Eu peguei os dados de liquidações dos últimos 30 dias e fiz uma estatística simples: 1.247 disparos de liquidação, 3 eventos de liquidação por margem insuficiente (perda de cobertura/“couro”/penetração), todos cobertos pelo fundo de seguro, sem acionar ADL. Esse nível de saúde é um ponto positivo para uma plataforma que não está no mercado há muito tempo.
Vale ressaltar, porém, que transparência não é sinônimo de ausência de risco. A imparcialidade do matching off-chain ainda depende do comportamento do matching engine; apesar de o resultado poder ser verificado posteriormente, se o engine, em um instante, inserir ordens de forma maliciosa ou atrasar o matching, o usuário talvez não perceba no momento em que acontece. A resposta da GRVT é migrar gradualmente para uma arquitetura de prova ZK, ou seja, permitir que o próprio processo de matching seja provável por criptografia. Com essa rota funcionando, a suposição de confiança cai ainda mais.
Eu avalio a maturidade de um projeto on-chain principalmente pelo quanto ele consegue transformar “verificável” em algo concreto. A GRVT, hoje, tem um nível de conclusão que a coloca na primeira divisão dentro dos Perps on-chain.
@grvt_io #grvt