Binance Square
CryptoDeon
14.7k Publicações

CryptoDeon

Exploring and sharing new insights Daily | Investor and Trader | X (Twitter): @CryptoDeonX
Trade aberto
Holder de BNB
Holder de BNB
Trader de alta frequência
1.9 anos
317 Seguindo
3.7K+ Seguidores
17.8K+ Curtiu
Publicações
Portfólio
·
--
Hoje olhei para a divisão de volume da Babylon de forma diferente — não apenas a proporção, mas o que acontece quando uma nova oferta se encontra com ela. No momento, $BABY runs está por volta de US$ 11,45M em volume centralizado contra US$ 2,95M nos DEXs, colocando a execução descentralizada em aproximadamente 21% do volume total. Essa diferença não é novidade. O que é novo é o timing. Em 10 de agosto, a Babylon desbloqueia 136,11M de tokens BABY no valor de cerca de US$ 1,43M, representando 1,2% da oferta total. Em termos percentuais, é pouco. Mas, medido pela liquidez on-chain real, é outra história — US$ 1,43M é perto de metade do que negocia via DEXs em um único dia agora. Um contexto rápido para quem é mais novo nisso: o volume de CEX é negociado em plataformas como Binance ou OKX, onde a exchange mantém a custódia e casa as ordens internamente. O volume de DEX é negociado e liquidado on-chain via contratos inteligentes, sem custodiante. Quando o volume em DEX é baixo em comparação ao de CEX, a maior parte da formação de preços ainda depende de venues centralizadas — não das “rails” sem confiança nas quais a tese do token foi construída. Então o verdadeiro teste não é se a Babylon consegue absorver 1,2% da oferta. É se os pools descentralizados conseguem absorver isso por conta própria, ou se precisam dos books de ordens do CEX para manter os preços alinhados. Se os pools de DEX dependerem da arbitragem do CEX para permanecerem equilibrados, o desbloqueio ainda passa pela camada centralizada — só que de forma indireta. Estou acompanhando a profundidade dos DEX nos dias após 10 de agosto, não a vela do preço. #baby $BABY @babylonlabs_io
Hoje olhei para a divisão de volume da Babylon de forma diferente — não apenas a proporção, mas o que acontece quando uma nova oferta se encontra com ela.

No momento, $BABY runs está por volta de US$ 11,45M em volume centralizado contra US$ 2,95M nos DEXs, colocando a execução descentralizada em aproximadamente 21% do volume total. Essa diferença não é novidade. O que é novo é o timing.

Em 10 de agosto, a Babylon desbloqueia 136,11M de tokens BABY no valor de cerca de US$ 1,43M, representando 1,2% da oferta total. Em termos percentuais, é pouco. Mas, medido pela liquidez on-chain real, é outra história — US$ 1,43M é perto de metade do que negocia via DEXs em um único dia agora.

Um contexto rápido para quem é mais novo nisso: o volume de CEX é negociado em plataformas como Binance ou OKX, onde a exchange mantém a custódia e casa as ordens internamente. O volume de DEX é negociado e liquidado on-chain via contratos inteligentes, sem custodiante. Quando o volume em DEX é baixo em comparação ao de CEX, a maior parte da formação de preços ainda depende de venues centralizadas — não das “rails” sem confiança nas quais a tese do token foi construída.

Então o verdadeiro teste não é se a Babylon consegue absorver 1,2% da oferta. É se os pools descentralizados conseguem absorver isso por conta própria, ou se precisam dos books de ordens do CEX para manter os preços alinhados. Se os pools de DEX dependerem da arbitragem do CEX para permanecerem equilibrados, o desbloqueio ainda passa pela camada centralizada — só que de forma indireta.

Estou acompanhando a profundidade dos DEX nos dias após 10 de agosto, não a vela do preço.

#baby $BABY @BabylonLabs_io
Verificado
Tirei os números reais de governança em vez de falar em generalidades — aqui vai um recorte novo, um ponto de entrada diferente do “depósitos como barreira”: A parte de $BABY governança que realmente precisa de explicação não é o depósito, é o que acontece quando você não faz nada. O depósito padrão de proposta é 50.000 BABY; o caminho acelerado precisa de 200.000 BABY para uma votação tipo “no mesmo dia” em vez da janela usual de três dias. Pelo preço de hoje, ~$0.01269, isso dá aproximadamente US$ 635 para o padrão e US$ 2.540 para o acelerado — não é o muro plutocrático que soa no papel; é mais como uma taxa moderada de cadastro que encolheu bastante conforme o token esfrio­u em relação às máximas. Quórum fica em 33,4% da oferta bloqueada; limiar de aprovação em 50%. Mas aqui está a mecânica que de fato decide a maioria dos resultados: se você mantém BABY e não vota, o voto do seu validador é herdado automaticamente em seu nome. Vote primeiro e ele é seu. Fique em silêncio e sua voz vira apenas o que seu validador já decidiu. O guia oficial de governança da Babylon aponta isso diretamente, instruindo os stakers a votarem em tudo especificamente para não ficarem apenas “caronando” na opinião do validador por padrão. Então a pergunta real não é “pequenos detentores conseguem arcar com propostas?” É quantos deles percebem que o silêncio deles já é um voto — dado por outra pessoa — no momento em que eles não aparecem. A proposta de deflação/queima que passou no ano passado é um bom caso de teste: vale voltar e conferir como foi de fato a participação dos stakers (turnout) versus votos herdados do validador, em vez de só perguntar ao mesmo tempo para a conta diretamente. Você tem números de participação separados por “staker votou diretamente” versus “herdado do validador” para propostas passadas, ou essa divisão não é algo que o explorador mostre de jeito nenhum agora? #baby $BABY @babylonlabs_io
Tirei os números reais de governança em vez de falar em generalidades — aqui vai um recorte novo, um ponto de entrada diferente do “depósitos como barreira”:

A parte de $BABY governança que realmente precisa de explicação não é o depósito, é o que acontece quando você não faz nada.

O depósito padrão de proposta é 50.000 BABY; o caminho acelerado precisa de 200.000 BABY para uma votação tipo “no mesmo dia” em vez da janela usual de três dias. Pelo preço de hoje, ~$0.01269, isso dá aproximadamente US$ 635 para o padrão e US$ 2.540 para o acelerado — não é o muro plutocrático que soa no papel; é mais como uma taxa moderada de cadastro que encolheu bastante conforme o token esfrio­u em relação às máximas. Quórum fica em 33,4% da oferta bloqueada; limiar de aprovação em 50%.

Mas aqui está a mecânica que de fato decide a maioria dos resultados: se você mantém BABY e não vota, o voto do seu validador é herdado automaticamente em seu nome. Vote primeiro e ele é seu. Fique em silêncio e sua voz vira apenas o que seu validador já decidiu. O guia oficial de governança da Babylon aponta isso diretamente, instruindo os stakers a votarem em tudo especificamente para não ficarem apenas “caronando” na opinião do validador por padrão.

Então a pergunta real não é “pequenos detentores conseguem arcar com propostas?” É quantos deles percebem que o silêncio deles já é um voto — dado por outra pessoa — no momento em que eles não aparecem. A proposta de deflação/queima que passou no ano passado é um bom caso de teste: vale voltar e conferir como foi de fato a participação dos stakers (turnout) versus votos herdados do validador, em vez de só perguntar ao mesmo tempo para a conta diretamente.

Você tem números de participação separados por “staker votou diretamente” versus “herdado do validador” para propostas passadas, ou essa divisão não é algo que o explorador mostre de jeito nenhum agora?

#baby $BABY @BabylonLabs_io
Verificado
O mempool do Bitcoin neste momento fica em torno de 179 MB, com taxas pairando em cerca de 1 sat por vByte — tão silencioso quanto a rede chega a ficar. Eu conferi esse número esperando que fosse irrelevante para o $BABY. Não é. Cada checkpoint que a Babylon publica para ancorar o estado de uma cadeia PoS no Bitcoin passa por uma transação real no Bitcoin: uma gravação OP_RETURN enviada por um Vigilante Submitter, pagando a taxa vigente no momento. O espaço de blocos do Bitcoin não sabe nem se importa se a transação veio da Babylon em vez de um lote de saque de uma exchange ou de um mint de Ordinals. É um único leilão compartilhado por cerca de 4 milhões de unidades de peso a cada dez minutos, e todo mundo dá lances na mesma fila. Esse é o ponto fácil de perder ao ler os documentos da Babylon isoladamente. Em 2023, quando a onda de Ordinals e inscrições BRC-20 atingiu o pico, as taxas medianas saíram de cerca de 5 sat/vB para 100 e depois 300 sat/vB por meses, puramente por causa de uma atividade NFT-style não relacionada competindo pelo mesmo espaço. Runes fez algo semelhante em 2024, empurrando as taxas para além de 1.000 sat/vB no pico. Nada disso teve a ver com cadeias PoS precisando de segurança do Bitcoin. Ainda teria atingido os custos de checkpoints da Babylon tão forte quanto aconteceria com todo mundo. Então, a despesa operacional da Babylon para aquilo que ela realmente está vendendo — a segurança ancorada no Bitcoin — não é definida pelo uso próprio da Babylon. Ela é definida por tudo o que mais está competindo por espaço em blocos do Bitcoin naquela semana: mints de memecoin, consolidações de exchanges, congestionamento impulsionado pelo halving; nada disso a Babylon consegue prever ou controlar. Vale lembrar na próxima vez que os custos de checkpoint forem enquadrados como um indicador da Babylon. Metade daquele número nunca foi da Babylon para começar. $BABY #baby @babylonlabs_io
O mempool do Bitcoin neste momento fica em torno de 179 MB, com taxas pairando em cerca de 1 sat por vByte — tão silencioso quanto a rede chega a ficar. Eu conferi esse número esperando que fosse irrelevante para o $BABY . Não é.

Cada checkpoint que a Babylon publica para ancorar o estado de uma cadeia PoS no Bitcoin passa por uma transação real no Bitcoin: uma gravação OP_RETURN enviada por um Vigilante Submitter, pagando a taxa vigente no momento. O espaço de blocos do Bitcoin não sabe nem se importa se a transação veio da Babylon em vez de um lote de saque de uma exchange ou de um mint de Ordinals. É um único leilão compartilhado por cerca de 4 milhões de unidades de peso a cada dez minutos, e todo mundo dá lances na mesma fila.

Esse é o ponto fácil de perder ao ler os documentos da Babylon isoladamente. Em 2023, quando a onda de Ordinals e inscrições BRC-20 atingiu o pico, as taxas medianas saíram de cerca de 5 sat/vB para 100 e depois 300 sat/vB por meses, puramente por causa de uma atividade NFT-style não relacionada competindo pelo mesmo espaço. Runes fez algo semelhante em 2024, empurrando as taxas para além de 1.000 sat/vB no pico. Nada disso teve a ver com cadeias PoS precisando de segurança do Bitcoin. Ainda teria atingido os custos de checkpoints da Babylon tão forte quanto aconteceria com todo mundo.

Então, a despesa operacional da Babylon para aquilo que ela realmente está vendendo — a segurança ancorada no Bitcoin — não é definida pelo uso próprio da Babylon. Ela é definida por tudo o que mais está competindo por espaço em blocos do Bitcoin naquela semana: mints de memecoin, consolidações de exchanges, congestionamento impulsionado pelo halving; nada disso a Babylon consegue prever ou controlar.

Vale lembrar na próxima vez que os custos de checkpoint forem enquadrados como um indicador da Babylon. Metade daquele número nunca foi da Babylon para começar.

$BABY #baby @BabylonLabs_io
Parcialmente verdadeiro
Eu assumi que cada transação em uma cadeia protegida pela Babylon herdava automaticamente a finalidade final do Bitcoin no momento em que era confirmada. Ao ler o design de verdade, não é assim que funciona, e a diferença entre a finalidade rápida e a lenta é justamente a parte que a maioria dos explicadores deixa passar. A Babylon roda em dois ritmos lado a lado. As transações normais recebem finalidade rápida, confirmada instantaneamente pelo próprio consenso PoS da cadeia, o mesmo modelo de consenso social que toda cadeia Cosmos já usa. A segurança no nível do Bitcoin só entra em ação para a finalidade lenta, quando um cliente espera até que o checkpoint da transação esteja enterrado em blocos suficientes no Bitcoin — aproximadamente algumas horas, às vezes mais perto de um ciclo completo de epoch — antes de tratá-lo como realmente irreversível. Versão simples: esperar horas por confirmação do Bitcoin elimina o sentido de uma cadeia rápida, então quase ninguém faz isso para atividade cotidiana. O que significa que o volume de transações que é divulgado como "protegido por Bitcoin" roda, na maior parte, no mesmo consenso rápido e socialmente confiável do qual a Babylon foi construída para se afastar. O timestamp do Bitcoin existe, ali, como uma opção, mas é algo opt-in; e precisa ter valor o bastante para uma pessoa escolher esperar por isso. Então a melhoria real de segurança não é universal: é seletiva por design. Transferências de alto valor, disputas de checkpoint, qualquer coisa que valha a espera — tudo isso recebe a garantia real do Bitcoin. Atividades rotineiras não recebem, porque na prática ninguém está disposto a trocar velocidade por isso. Vale saber em qual camada suas próprias transações realmente estão caindo, antes de assumir que o rótulo cobre tudo. $BABY #baby @babylonlabs_io
Eu assumi que cada transação em uma cadeia protegida pela Babylon herdava automaticamente a finalidade final do Bitcoin no momento em que era confirmada. Ao ler o design de verdade, não é assim que funciona, e a diferença entre a finalidade rápida e a lenta é justamente a parte que a maioria dos explicadores deixa passar.

A Babylon roda em dois ritmos lado a lado. As transações normais recebem finalidade rápida, confirmada instantaneamente pelo próprio consenso PoS da cadeia, o mesmo modelo de consenso social que toda cadeia Cosmos já usa. A segurança no nível do Bitcoin só entra em ação para a finalidade lenta, quando um cliente espera até que o checkpoint da transação esteja enterrado em blocos suficientes no Bitcoin — aproximadamente algumas horas, às vezes mais perto de um ciclo completo de epoch — antes de tratá-lo como realmente irreversível.

Versão simples: esperar horas por confirmação do Bitcoin elimina o sentido de uma cadeia rápida, então quase ninguém faz isso para atividade cotidiana. O que significa que o volume de transações que é divulgado como "protegido por Bitcoin" roda, na maior parte, no mesmo consenso rápido e socialmente confiável do qual a Babylon foi construída para se afastar. O timestamp do Bitcoin existe, ali, como uma opção, mas é algo opt-in; e precisa ter valor o bastante para uma pessoa escolher esperar por isso.

Então a melhoria real de segurança não é universal: é seletiva por design. Transferências de alto valor, disputas de checkpoint, qualquer coisa que valha a espera — tudo isso recebe a garantia real do Bitcoin. Atividades rotineiras não recebem, porque na prática ninguém está disposto a trocar velocidade por isso.

Vale saber em qual camada suas próprias transações realmente estão caindo, antes de assumir que o rótulo cobre tudo.

$BABY #baby @BabylonLabs_io
A Babylon se vende com uma frase: sem encapsulamento, sem bridging, custódia própria total. Eu acreditava nisso totalmente até verificar por onde passa a maior parte do volume real de BTC apostado. Uma parcela grande disso nem chega a apostar nativamente. Ela passa pelo LBTC da Lombard, um token de staking líquido, um ERC-20 que é negociado entre Ethereum, Solana e outras redes, lastreado 1:1 por BTC que a Lombard aposta na Babylon em nome do usuário. Em termos simples: você deposita Bitcoin, a Lombard faz o staking, e você recebe um token de IOU negociável em vez de manter diretamente o BTC apostado. Esse IOU é exatamente o tipo de wrapper que a proposta da Babylon dizia que queria evitar. Veja por que, ainda assim, as pessoas escolhem isso — e é um motivo completamente razoável. O destravamento (unstaking) nativo via Babylon leva cerca de um período de unbonding de 7 dias. Converter LBTC de volta para BTC nativo pode levar até 10 dias, considerando também o ciclo próprio de rebalanceamento da Lombard. Então o LBTC existe especificamente para dar liquidez e acesso a DeFi, negociável em mais de 70 plataformas, enquanto o BTC subjacente fica travado durante exatamente esse mesmo período de unbonding. A custódia do BTC que dá lastro ao token fica com o que a Lombard chama de Security Consortium — nós institucionais como Galaxy, Wintermute e OKX cunhando e resgatando o token em conjunto. Assim, agora existem dois modelos de confiança diferentes empilhados um sobre o outro usando o mesmo rótulo de "staking de Bitcoin". O staking nativo via Babylon diretamente é a versão sem confiança e com custódia própria (self-custodial) para a qual o protocolo foi desenhado. Ter exposição via LBTC significa confiar que um consórcio de instituições nomeadas gerencie custódia e resgate corretamente — um risco de forma significativamente diferente daquele que a arquitetura da Babylon diz que remove. O que eu estou de olho, na prática, é se exposições encapsuladas como o LBTC continuam ganhando espaço em relação ao staking nativo e direto, pois isso significaria que a base real de segurança está silenciosamente se concentrando em torno de um pequeno grupo de membros do consórcio, mesmo enquanto o protocolo base em si permanece exatamente como foi anunciado: sem confiança. $BABY #baby @babylonlabs_io
A Babylon se vende com uma frase: sem encapsulamento, sem bridging, custódia própria total. Eu acreditava nisso totalmente até verificar por onde passa a maior parte do volume real de BTC apostado.

Uma parcela grande disso nem chega a apostar nativamente. Ela passa pelo LBTC da Lombard, um token de staking líquido, um ERC-20 que é negociado entre Ethereum, Solana e outras redes, lastreado 1:1 por BTC que a Lombard aposta na Babylon em nome do usuário. Em termos simples: você deposita Bitcoin, a Lombard faz o staking, e você recebe um token de IOU negociável em vez de manter diretamente o BTC apostado. Esse IOU é exatamente o tipo de wrapper que a proposta da Babylon dizia que queria evitar.

Veja por que, ainda assim, as pessoas escolhem isso — e é um motivo completamente razoável. O destravamento (unstaking) nativo via Babylon leva cerca de um período de unbonding de 7 dias. Converter LBTC de volta para BTC nativo pode levar até 10 dias, considerando também o ciclo próprio de rebalanceamento da Lombard. Então o LBTC existe especificamente para dar liquidez e acesso a DeFi, negociável em mais de 70 plataformas, enquanto o BTC subjacente fica travado durante exatamente esse mesmo período de unbonding. A custódia do BTC que dá lastro ao token fica com o que a Lombard chama de Security Consortium — nós institucionais como Galaxy, Wintermute e OKX cunhando e resgatando o token em conjunto.

Assim, agora existem dois modelos de confiança diferentes empilhados um sobre o outro usando o mesmo rótulo de "staking de Bitcoin". O staking nativo via Babylon diretamente é a versão sem confiança e com custódia própria (self-custodial) para a qual o protocolo foi desenhado. Ter exposição via LBTC significa confiar que um consórcio de instituições nomeadas gerencie custódia e resgate corretamente — um risco de forma significativamente diferente daquele que a arquitetura da Babylon diz que remove.

O que eu estou de olho, na prática, é se exposições encapsuladas como o LBTC continuam ganhando espaço em relação ao staking nativo e direto, pois isso significaria que a base real de segurança está silenciosamente se concentrando em torno de um pequeno grupo de membros do consórcio, mesmo enquanto o protocolo base em si permanece exatamente como foi anunciado: sem confiança.

$BABY #baby @BabylonLabs_io
Verificado
O número de rendimento que aparece nos painéis de staking para BABY fica em torno de 15 a 20 por cento ao ano. Quase interpretei isso como prova de que Bitcoin Secured Networks estava pagando dinheiro de verdade pela segurança do Bitcoin. Depois, rastreei de onde esse rendimento realmente vem, e não é isso. A BABY tem uma taxa de inflação anual de 8 por cento, dividida igualmente: 4 por cento é cunhado para stakers de BTC e 4 por cento para stakers de BABY. Esse é o financiamento da camada base que sustenta quase todo o rendimento anunciado hoje. Separadamente, existe um leilão de recompensas em que BSNs que de fato se integram podem direcionar uma parcela de suas próprias recompensas para a rede, e é nessa BABY que acontece o lance e a queima. Mas esse fluxo do leilão ainda é pequeno em comparação com a linha de inflação, porque a maior parte do ecossistema ainda é o próprio Babylon Genesis — um único BSN —, e não ainda um mercado de redes pagantes. Aqui vai a versão direta de por que essa distinção importa. Rendimento financiado por inflação não é prova de que alguém valoriza a segurança que está sendo vendida. É apenas a criação de novos tokens e o repasse para quem bloqueou BTC ou BABY primeiro. A demanda real só aparece nesse mecanismo separado de leilão e queima, quando cadeias externas realmente colocam valor na mesa pela segurança lastreada em Bitcoin, em vez de Babylon pagar seus próprios stakers para estarem presentes. Neste momento, a Babylon mantém perto de 57.000 BTC em staking, que já valeu mais de US$ 5,6 bilhões no pico do TVL — o que soa como uma validação esmagadora. Mas TVL mede quanto BTC foi bloqueado, não quanto qualquer cadeia PoS está disposta a pagar para alugar essa segurança. São perguntas diferentes, com respostas diferentes. O que eu estou considerando de verdade é se esse lado de leilão e queima alguma vez começa a pesar de forma real contra a subvenção de 8 por cento conforme mais redes entram em funcionamento, ou se o rendimento apenas continua sendo algo que a Babylon financia para si mesma. #baby $BABY @babylonlabs_io
O número de rendimento que aparece nos painéis de staking para BABY fica em torno de 15 a 20 por cento ao ano. Quase interpretei isso como prova de que Bitcoin Secured Networks estava pagando dinheiro de verdade pela segurança do Bitcoin. Depois, rastreei de onde esse rendimento realmente vem, e não é isso.

A BABY tem uma taxa de inflação anual de 8 por cento, dividida igualmente: 4 por cento é cunhado para stakers de BTC e 4 por cento para stakers de BABY. Esse é o financiamento da camada base que sustenta quase todo o rendimento anunciado hoje. Separadamente, existe um leilão de recompensas em que BSNs que de fato se integram podem direcionar uma parcela de suas próprias recompensas para a rede, e é nessa BABY que acontece o lance e a queima. Mas esse fluxo do leilão ainda é pequeno em comparação com a linha de inflação, porque a maior parte do ecossistema ainda é o próprio Babylon Genesis — um único BSN —, e não ainda um mercado de redes pagantes.

Aqui vai a versão direta de por que essa distinção importa. Rendimento financiado por inflação não é prova de que alguém valoriza a segurança que está sendo vendida. É apenas a criação de novos tokens e o repasse para quem bloqueou BTC ou BABY primeiro. A demanda real só aparece nesse mecanismo separado de leilão e queima, quando cadeias externas realmente colocam valor na mesa pela segurança lastreada em Bitcoin, em vez de Babylon pagar seus próprios stakers para estarem presentes.

Neste momento, a Babylon mantém perto de 57.000 BTC em staking, que já valeu mais de US$ 5,6 bilhões no pico do TVL — o que soa como uma validação esmagadora. Mas TVL mede quanto BTC foi bloqueado, não quanto qualquer cadeia PoS está disposta a pagar para alugar essa segurança. São perguntas diferentes, com respostas diferentes.

O que eu estou considerando de verdade é se esse lado de leilão e queima alguma vez começa a pesar de forma real contra a subvenção de 8 por cento conforme mais redes entram em funcionamento, ou se o rendimento apenas continua sendo algo que a Babylon financia para si mesma.

#baby $BABY @BabylonLabs_io
Verificado
A penalidade de corte (slashing) por dupla assinatura (double-signing) na Babylon é de 0,1% do BTC apostado (staked). Quando li esse número pela primeira vez, senti um certo alívio, pequeno, contido, administrável. Depois li como o multi-staking realmente funciona, e o número deixou de contar toda a história. A Fase 3 da Babylon permite que um depósito de 1 BTC garanta múltiplas Redes Bitcoin Secured (BSNs) ao mesmo tempo, não apenas a Babylon Genesis. Um único provedor de finalidade (finality provider) mantém um pool de chaves de assinatura pré-registradas e pode assinar checkpoints em várias BSNs usando o mesmo stake subjacente. Essa é a proposta inteira: um único bloqueio (lock), muitas redes, mais fontes de rendimento (yield) a partir de um único depósito, em vez de dividir o BTC em posições separadas. Veja o que esse número de 0,1% não captura. Ele é por evento de corte, não por stake. Se um provedor de finalidade se comportar mal e for pego em uma rede, isso é um corte de 0,1%. Mas se o mesmo provedor, usando o mesmo stake compartilhado, também estiver garantindo outras três ou quatro BSNs ao mesmo tempo, a honestidade e o uptime desse único operador passam a ser determinantes para tudo ao mesmo tempo. A pergunta estrutural é exatamente a mesma que o modelo de restaking da EigenLayer teve de enfrentar no Ethereum: colateral reutilizado significa que a linha de falha de um serviço pode se estender além do serviço onde a falha ocorreu. Assim, o risco não é realmente a porcentagem de slashing. É a correlação. Um apostador (staker) de BTC não está mais apenas apostando na honestidade de um único provedor de finalidade; agora ele está apostando que esse provedor continue honesto e online em todas as redes que a chave dele toca, tudo ao mesmo tempo, dentro de um universo de aproximadamente 250 provedores de finalidade competindo por essa confiança. Condição que estou observando: se as BSNs que fazem onboarding via multi-staking começam a divulgar a sobreposição de provedores de finalidade compartilhados do mesmo modo que protocolos de empréstimo (lending) divulgam o risco de colateral compartilhado, ou se essa correlação permanece invisível até que um operador ruim a torne óbvia do jeito mais difícil. $BABY #baby @babylonlabs_io
A penalidade de corte (slashing) por dupla assinatura (double-signing) na Babylon é de 0,1% do BTC apostado (staked). Quando li esse número pela primeira vez, senti um certo alívio, pequeno, contido, administrável. Depois li como o multi-staking realmente funciona, e o número deixou de contar toda a história.

A Fase 3 da Babylon permite que um depósito de 1 BTC garanta múltiplas Redes Bitcoin Secured (BSNs) ao mesmo tempo, não apenas a Babylon Genesis. Um único provedor de finalidade (finality provider) mantém um pool de chaves de assinatura pré-registradas e pode assinar checkpoints em várias BSNs usando o mesmo stake subjacente. Essa é a proposta inteira: um único bloqueio (lock), muitas redes, mais fontes de rendimento (yield) a partir de um único depósito, em vez de dividir o BTC em posições separadas.

Veja o que esse número de 0,1% não captura. Ele é por evento de corte, não por stake. Se um provedor de finalidade se comportar mal e for pego em uma rede, isso é um corte de 0,1%. Mas se o mesmo provedor, usando o mesmo stake compartilhado, também estiver garantindo outras três ou quatro BSNs ao mesmo tempo, a honestidade e o uptime desse único operador passam a ser determinantes para tudo ao mesmo tempo. A pergunta estrutural é exatamente a mesma que o modelo de restaking da EigenLayer teve de enfrentar no Ethereum: colateral reutilizado significa que a linha de falha de um serviço pode se estender além do serviço onde a falha ocorreu.

Assim, o risco não é realmente a porcentagem de slashing. É a correlação. Um apostador (staker) de BTC não está mais apenas apostando na honestidade de um único provedor de finalidade; agora ele está apostando que esse provedor continue honesto e online em todas as redes que a chave dele toca, tudo ao mesmo tempo, dentro de um universo de aproximadamente 250 provedores de finalidade competindo por essa confiança.

Condição que estou observando: se as BSNs que fazem onboarding via multi-staking começam a divulgar a sobreposição de provedores de finalidade compartilhados do mesmo modo que protocolos de empréstimo (lending) divulgam o risco de colateral compartilhado, ou se essa correlação permanece invisível até que um operador ruim a torne óbvia do jeito mais difícil.

$BABY #baby @BabylonLabs_io
Na documentação de Babylon existe uma frase que, silenciosamente, desfaz a palavra que todo mundo usa para o “seu corte”: “trustless”. Eu tinha assumido que o EOTS fazia todo o trabalho sozinho—a matemática detecta um dupla-assinatura, a punição acontece, não é necessário comitê. Ler as condições reais de gasto mudou isso. Bitcoin Script não consegue expressar nativamente “se este provedor de finalidade dupla-assinar, corte o valor apostado dele”. Então Babylon constrói o caminho de punição de forma diferente. No momento do staking, seus fundos travam em um UTXO que exige assinaturas suas e de um quórum do comitê do pacto, coletadas com antecedência. Se o provedor de finalidade mais tarde dupla-assinar, a matemática do EOTS vaza a chave privada deles, e essa chave vazada fornece a assinatura final que o multisig pré-construído já estava aguardando. Assim, a parte elegante — a matemática pegando automaticamente maus atores — é real, mas é a última peça de uma estrutura, não a estrutura inteira. As assinaturas do comitê precisam existir antes de qualquer má conduta acontecer, ou não há caminho punível de jeito nenhum. A ausência de confiança aparece no fim. Tudo antes disso depende de o comitê estar presente, honesto e online no momento do staking. Isso também redefine o que, de fato, vale a pena observar. Não se a criptografia funciona — essa parte está sólida. Mas se o comitê do pacto continua descentralizado e disponível conforme Babylon escala em mais Bitcoin Secured Networks, porque se essa camada afinar, o caminho de slashing não falha ruidosamente: ele simplesmente deixa de existir para um novo stake antes que ninguém verifique. se a composição do comitê e o uptime começam a receber a mesma atenção que TVL e números de staking, ou se continuam sendo a pré-condição invisível da qual ninguém se preocupa até ser tarde demais. $BABY #baby @babylonlabs_io
Na documentação de Babylon existe uma frase que, silenciosamente, desfaz a palavra que todo mundo usa para o “seu corte”: “trustless”. Eu tinha assumido que o EOTS fazia todo o trabalho sozinho—a matemática detecta um dupla-assinatura, a punição acontece, não é necessário comitê. Ler as condições reais de gasto mudou isso.

Bitcoin Script não consegue expressar nativamente “se este provedor de finalidade dupla-assinar, corte o valor apostado dele”. Então Babylon constrói o caminho de punição de forma diferente. No momento do staking, seus fundos travam em um UTXO que exige assinaturas suas e de um quórum do comitê do pacto, coletadas com antecedência. Se o provedor de finalidade mais tarde dupla-assinar, a matemática do EOTS vaza a chave privada deles, e essa chave vazada fornece a assinatura final que o multisig pré-construído já estava aguardando.

Assim, a parte elegante — a matemática pegando automaticamente maus atores — é real, mas é a última peça de uma estrutura, não a estrutura inteira. As assinaturas do comitê precisam existir antes de qualquer má conduta acontecer, ou não há caminho punível de jeito nenhum. A ausência de confiança aparece no fim. Tudo antes disso depende de o comitê estar presente, honesto e online no momento do staking.

Isso também redefine o que, de fato, vale a pena observar. Não se a criptografia funciona — essa parte está sólida. Mas se o comitê do pacto continua descentralizado e disponível conforme Babylon escala em mais Bitcoin Secured Networks, porque se essa camada afinar, o caminho de slashing não falha ruidosamente: ele simplesmente deixa de existir para um novo stake antes que ninguém verifique.

se a composição do comitê e o uptime começam a receber a mesma atenção que TVL e números de staking, ou se continuam sendo a pré-condição invisível da qual ninguém se preocupa até ser tarde demais.

$BABY #baby @BabylonLabs_io
Algo sobre o desbloqueio de 10 de julho não bateu quando eu sentei com os números de verdade, então parei de presumir e fui conferir. BABY não faz desbloqueios do tipo “cliff-and-dump” como muitos tokens. A equipe, os assessores e os investidores iniciais desbloqueiam 1/36 da alocação deles todos os meses até abril de 2029 — um gotejamento linear lento, em vez de uma única data assustadora no calendário. 10 de julho não foi algum evento especial; foi apenas mais um daqueles trinta e seis meses idênticos. De cerca de 3,99 bilhões de tokens já em circulação, esse release adicionou uma fatia previsível e conhecida — nada que qualquer pessoa com um gráfico de vesting não conseguisse enxergar chegando um ano atrás. Aqui está a parte que realmente importa, e é fácil se confundir no sentido. Um desbloqueio linear e programado não é um choque de oferta: ele já está precificado por qualquer um que esteja prestando atenção, porque o mercado já conhecia a conta exata desde que o cronograma foi publicado. O que mexe no preço não é o desbloqueio em si — é se a nova demanda, mais BTC entrando em staking e TBV, mais integrações como o recente acordo com a Gomining, cresce mais rápido do que esse gotejamento constante mensal de nova liquidez chegando às exchanges. Então a pergunta real nunca foi “quanto vai desbloquear este mês”. Foi se o lado do protocolo — BTC garantido, cofres abertos, uso real — está capitalizando rápido o suficiente para absorver mais trinta e seis meses do mesmo gotejamento, sem que ninguém perceba que isso vira pressão de jeito nenhum. Condição que estou acompanhando: se o crescimento de BTC nos cofres/vaults fica à frente do ritmo mensal de desbloqueio pelos próximos alguns “cliffs”, ou se o gotejamento começa a superar a demanda em silêncio, como vazamentos lentos normalmente fazem. $BABY #baby #BinanceSquareFamily @babylonlabs_io
Algo sobre o desbloqueio de 10 de julho não bateu quando eu sentei com os números de verdade, então parei de presumir e fui conferir.

BABY não faz desbloqueios do tipo “cliff-and-dump” como muitos tokens. A equipe, os assessores e os investidores iniciais desbloqueiam 1/36 da alocação deles todos os meses até abril de 2029 — um gotejamento linear lento, em vez de uma única data assustadora no calendário. 10 de julho não foi algum evento especial; foi apenas mais um daqueles trinta e seis meses idênticos. De cerca de 3,99 bilhões de tokens já em circulação, esse release adicionou uma fatia previsível e conhecida — nada que qualquer pessoa com um gráfico de vesting não conseguisse enxergar chegando um ano atrás.

Aqui está a parte que realmente importa, e é fácil se confundir no sentido. Um desbloqueio linear e programado não é um choque de oferta: ele já está precificado por qualquer um que esteja prestando atenção, porque o mercado já conhecia a conta exata desde que o cronograma foi publicado. O que mexe no preço não é o desbloqueio em si — é se a nova demanda, mais BTC entrando em staking e TBV, mais integrações como o recente acordo com a Gomining, cresce mais rápido do que esse gotejamento constante mensal de nova liquidez chegando às exchanges.

Então a pergunta real nunca foi “quanto vai desbloquear este mês”. Foi se o lado do protocolo — BTC garantido, cofres abertos, uso real — está capitalizando rápido o suficiente para absorver mais trinta e seis meses do mesmo gotejamento, sem que ninguém perceba que isso vira pressão de jeito nenhum.

Condição que estou acompanhando: se o crescimento de BTC nos cofres/vaults fica à frente do ritmo mensal de desbloqueio pelos próximos alguns “cliffs”, ou se o gotejamento começa a superar a demanda em silêncio, como vazamentos lentos normalmente fazem.

$BABY #baby #BinanceSquareFamily @BabylonLabs_io
Parcialmente verdadeiro
Eu estava brincando com a ideia de desbloquear só parte do meu BTC de um Cofre Bitcoin Sem Confiança (Trustless Bitcoin Vault), do jeito que você sacaria parcialmente de uma conta poupança, e bati numa barreira que eu não esperava. O TBV não faz saques parciais. É cofre inteiro para dentro, cofre inteiro para fora. Uma peça, não várias. No começo, pareceu uma limitação de UX, quase um design preguiçoso. Mas, pensando melhor, acho que é o contrário. Provar um resgate parcial para Bitcoin, sem um fork e sem novos opcodes, significa provar uma fração de um evento usando lógica de script que nunca foi feita para expressar frações com clareza. O resgate de cofre inteiro evita totalmente esse problema. Um depósito, um estado, uma prova limpa. A simplicidade não é um recurso ausente — é o que mantém a verificação honesta em uma blockchain que se recusa a dobrar as regras por você. Aqui vai a parte que é fácil de perder se você é novo nisso: todo design de DeFi nativo do BTC precisa escolher entre flexibilidade e verificabilidade, e normalmente não dá para ter as duas coisas. A Babylon escolheu a verificabilidade. Esse tradeoff é a razão, em silêncio, de estarem com mais de 56.000 BTC em cofres de staking e terem captado um apoio novo da a16z este ano. Instituições não correm atrás do flexível; elas correm atrás do verificável. O que eu continuo retomando é se esse tradeoff escala. O resgate de cofre inteiro é limpo quando os cofres são pequenos e pessoais. Fica menos limpo quando integrações como o acordo recente da Gomining começam a encaminhar mil BTC de uma vez pela mesma porta de saída de “tudo ou nada”. Condição que estou observando: se integrações em grande escala se adaptam ao resgate de cofre inteiro como está, ou se elas silenciosamente se fragmentam em muitos cofres menores só para voltar a obter o comportamento de saque parcial pela porta dos fundos. $BABY #baby @babylonlabs_io
Eu estava brincando com a ideia de desbloquear só parte do meu BTC de um Cofre Bitcoin Sem Confiança (Trustless Bitcoin Vault), do jeito que você sacaria parcialmente de uma conta poupança, e bati numa barreira que eu não esperava. O TBV não faz saques parciais. É cofre inteiro para dentro, cofre inteiro para fora. Uma peça, não várias.

No começo, pareceu uma limitação de UX, quase um design preguiçoso. Mas, pensando melhor, acho que é o contrário. Provar um resgate parcial para Bitcoin, sem um fork e sem novos opcodes, significa provar uma fração de um evento usando lógica de script que nunca foi feita para expressar frações com clareza. O resgate de cofre inteiro evita totalmente esse problema. Um depósito, um estado, uma prova limpa. A simplicidade não é um recurso ausente — é o que mantém a verificação honesta em uma blockchain que se recusa a dobrar as regras por você.

Aqui vai a parte que é fácil de perder se você é novo nisso: todo design de DeFi nativo do BTC precisa escolher entre flexibilidade e verificabilidade, e normalmente não dá para ter as duas coisas. A Babylon escolheu a verificabilidade. Esse tradeoff é a razão, em silêncio, de estarem com mais de 56.000 BTC em cofres de staking e terem captado um apoio novo da a16z este ano. Instituições não correm atrás do flexível; elas correm atrás do verificável.

O que eu continuo retomando é se esse tradeoff escala. O resgate de cofre inteiro é limpo quando os cofres são pequenos e pessoais. Fica menos limpo quando integrações como o acordo recente da Gomining começam a encaminhar mil BTC de uma vez pela mesma porta de saída de “tudo ou nada”.

Condição que estou observando: se integrações em grande escala se adaptam ao resgate de cofre inteiro como está, ou se elas silenciosamente se fragmentam em muitos cofres menores só para voltar a obter o comportamento de saque parcial pela porta dos fundos.

$BABY #baby @BabylonLabs_io
Foi a primeira vez que percebi algo estranho enquanto assistia a uma guild grind — dezenas de jogadores farmando recursos por horas, criando itens sem parar, e $BABY mal tinha avançado em nada. Só quando alguém realmente cunhou ou liquidou um item on-chain é que o token reagiu. Foi aí que entendi: $BABY não precifica atividade. Ele precifica o momento em que o esforço deixa de ser invisível e passa a ser permanente. Farming, criação, grind — tudo isso existe off-chain, não precificado, não registrado pelo mercado. A demanda só aparece na conversão, o passo único em que o tempo do jogador é carimbado em algo que a cadeia precisa reconhecer. Isso significa que um jogo pode parecer totalmente vivo — servidores cheios, criação constante, guildas movimentadas — enquanto a demanda do token esvazia silenciosamente, porque os jogadores aprenderam a adiar ou evitar esse passo final. A atividade continua aparecendo na superfície muito tempo depois de a coisa que $BABY realmente precifica ter parado de acontecer por baixo. Vale observar: se a frequência de conversão mantém o ritmo conforme a base de jogadores cresce, ou se o crescimento de jogadores deixa de se traduzir em crescimento naquele único momento. #baby #BinanceSquare @babylonlabs_io
Foi a primeira vez que percebi algo estranho enquanto assistia a uma guild grind — dezenas de jogadores farmando recursos por horas, criando itens sem parar, e $BABY mal tinha avançado em nada. Só quando alguém realmente cunhou ou liquidou um item on-chain é que o token reagiu.

Foi aí que entendi: $BABY não precifica atividade. Ele precifica o momento em que o esforço deixa de ser invisível e passa a ser permanente. Farming, criação, grind — tudo isso existe off-chain, não precificado, não registrado pelo mercado. A demanda só aparece na conversão, o passo único em que o tempo do jogador é carimbado em algo que a cadeia precisa reconhecer.

Isso significa que um jogo pode parecer totalmente vivo — servidores cheios, criação constante, guildas movimentadas — enquanto a demanda do token esvazia silenciosamente, porque os jogadores aprenderam a adiar ou evitar esse passo final. A atividade continua aparecendo na superfície muito tempo depois de a coisa que $BABY realmente precifica ter parado de acontecer por baixo.

Vale observar: se a frequência de conversão mantém o ritmo conforme a base de jogadores cresce, ou se o crescimento de jogadores deixa de se traduzir em crescimento naquele único momento.

#baby #BinanceSquare @BabylonLabs_io
Fiquei olhando novamente para a tela do Plano do Multiplicador esta manhã, mas desta vez eu não estava olhando para os retornos. Eu estava observando o que o adiamento realmente faz com o próprio token — não apenas com a minha alocação. Aqui está a parte que mais me chamou atenção. Qualquer pessoa que escolher o adiamento de 4 ou 8 meses não está apenas trancando os próprios tokens para obter um multiplicador maior depois. Ela também está removendo essa oferta de circulação diretamente no TGE, quando a GRVT estreia no mercado à vista e busca listagens em CEX Tier-1. Menos oferta circulando no lançamento normalmente significa menor pressão inicial de venda e uma janela de descoberta de preço mais limpa. Então o multiplicador não é apenas uma recompensa pela paciência. É também uma compensação por assumir uma tarefa da qual a própria bolsa se beneficia — manter a oferta fora do mercado durante o período mais frágil da descoberta de preço, logo após o lançamento. Isso muda um pouco a forma de ver a decisão. Não é só “certeza agora”, como eu costumava pensar. Também é aumentar exatamente a pressão de venda à qual a ação inicial do preço no TGE é mais sensível. Adiar não é apenas “talvez um número maior mais tarde”; é sustentar silenciosamente as condições que podem tornar possível, em primeiro lugar, que esse número maior aconteça. O registro está aberto até 27 de julho de 2026, 00:00 UTC, as escolhas são finais, e o pool de adiamento fica dentro dos 18% fixos da parcela da Season 2 da oferta total de 1B. Se isso realmente vai acontecer do jeito que foi desenhado depende de quanto dessa oferta registrada acaba optando por adiamento em vez de uma reivindicação imediata, já que uma taxa de adiamento baixa não mudaria muito o panorama da pressão de venda. #grvt #BinanceSquare @grvt_io
Fiquei olhando novamente para a tela do Plano do Multiplicador esta manhã, mas desta vez eu não estava olhando para os retornos. Eu estava observando o que o adiamento realmente faz com o próprio token — não apenas com a minha alocação.

Aqui está a parte que mais me chamou atenção. Qualquer pessoa que escolher o adiamento de 4 ou 8 meses não está apenas trancando os próprios tokens para obter um multiplicador maior depois. Ela também está removendo essa oferta de circulação diretamente no TGE, quando a GRVT estreia no mercado à vista e busca listagens em CEX Tier-1. Menos oferta circulando no lançamento normalmente significa menor pressão inicial de venda e uma janela de descoberta de preço mais limpa.

Então o multiplicador não é apenas uma recompensa pela paciência. É também uma compensação por assumir uma tarefa da qual a própria bolsa se beneficia — manter a oferta fora do mercado durante o período mais frágil da descoberta de preço, logo após o lançamento.

Isso muda um pouco a forma de ver a decisão. Não é só “certeza agora”, como eu costumava pensar. Também é aumentar exatamente a pressão de venda à qual a ação inicial do preço no TGE é mais sensível. Adiar não é apenas “talvez um número maior mais tarde”; é sustentar silenciosamente as condições que podem tornar possível, em primeiro lugar, que esse número maior aconteça.

O registro está aberto até 27 de julho de 2026, 00:00 UTC, as escolhas são finais, e o pool de adiamento fica dentro dos 18% fixos da parcela da Season 2 da oferta total de 1B.

Se isso realmente vai acontecer do jeito que foi desenhado depende de quanto dessa oferta registrada acaba optando por adiamento em vez de uma reivindicação imediata, já que uma taxa de adiamento baixa não mudaria muito o panorama da pressão de venda.

#grvt #BinanceSquare @grvt_io
Artigo
O Problema da Autorização Está Resolvido. O Problema do Consentimento Não Está.O que me atraiu inicialmente não foi a tecnologia em si. Foi a promessa subjacente — que você poderia definir suas intenções uma vez, com clareza, com limites reais associados, e então se afastar. Essa automação levaria essas intenções adiante com fidelidade, sem exigir sua presença em cada etapa. Essa promessa é genuinamente convincente. E quanto mais eu olhava para a arquitetura do Newton Protocol, mais eu entendia por que ele estava atraindo a atenção de pessoas que não se empolgam facilmente. A abordagem técnica é rigorosa de maneiras que a maior parte da automação em DeFi não é. Políticas aplicadas no momento da execução, não depois. Prova criptográfica de que o agente permaneceu dentro das permissões definidas. Um registro verificável que qualquer pessoa pode inspecionar. Isso não são alegações de marketing. São decisões reais de design que refletem um nível incomum de cuidado com a lacuna entre o que um sistema deveria fazer e o que ele realmente faz em tempo de execução.

O Problema da Autorização Está Resolvido. O Problema do Consentimento Não Está.

O que me atraiu inicialmente não foi a tecnologia em si. Foi a promessa subjacente — que você poderia definir suas intenções uma vez, com clareza, com limites reais associados, e então se afastar. Essa automação levaria essas intenções adiante com fidelidade, sem exigir sua presença em cada etapa.
Essa promessa é genuinamente convincente. E quanto mais eu olhava para a arquitetura do Newton Protocol, mais eu entendia por que ele estava atraindo a atenção de pessoas que não se empolgam facilmente. A abordagem técnica é rigorosa de maneiras que a maior parte da automação em DeFi não é. Políticas aplicadas no momento da execução, não depois. Prova criptográfica de que o agente permaneceu dentro das permissões definidas. Um registro verificável que qualquer pessoa pode inspecionar. Isso não são alegações de marketing. São decisões reais de design que refletem um nível incomum de cuidado com a lacuna entre o que um sistema deveria fazer e o que ele realmente faz em tempo de execução.
A pergunta com a qual eu continuei sentado não era sobre a tecnologia. Era sobre responsabilidade. @NewtonProtocol pode verificar que um agente seguiu suas regras. A prova criptográfica é real — cada avaliação de política deixa um registro, cada ação dentro das permissões definidas é verificável (atestado). Isso é, genuinamente, mais do que a maior parte da automação em DeFi oferece hoje. Mas aqui está o ponto. Execução verificável e julgamento verificável são problemas diferentes. Newton resolve o primeiro com cuidado. O segundo ainda depende, em grande parte, de quem escreveu as regras. Em termos simples: se um gerente de um cofre define um limite de gastos que acaba sendo frouxo demais, ou define um gatilho de rebalanceamento que fazia sentido em mercados calmos, mas não em mercados voláteis, a Newton aplica essas regras corretamente. A política é executada, a prova é produzida, a transação é liquidada. Tudo funcionou conforme o planejado. O resultado ainda pode ser ruim. Isso não é exatamente uma falha da arquitetura. Nenhuma camada de aplicação pode tornar o julgamento humano melhor. Mas ela levanta uma questão que o protocolo ainda não respondeu completamente — quando uma política está correta, mas as regras por trás dela estavam erradas, onde fica a responsabilidade? Com o operador que a configurou? Com o desenvolvedor que publicou o modelo? Com o usuário que a ativou sem ler completamente o que aprovou? As finanças tradicionais resolvem isso por meio de licenciamento, dever fiduciário e regulação. A cripto resolve por meio de documentação que ninguém lê e termos de serviço que isentam de responsabilidade por tudo. A Newton está no meio desse vazio agora. A camada de aplicação está sendo construída com cuidado. A camada de responsabilidade em torno de quem desenha as regras, quem as audita e quem responde quando elas falham — essa parte ainda é, em grande medida, aspiracional. Se isso será resolvido ao longo do tempo provavelmente importa mais do que qualquer marco técnico no roteiro. $NEWT @NewtonProtocol #Newt
A pergunta com a qual eu continuei sentado não era sobre a tecnologia. Era sobre responsabilidade.

@NewtonProtocol pode verificar que um agente seguiu suas regras. A prova criptográfica é real — cada avaliação de política deixa um registro, cada ação dentro das permissões definidas é verificável (atestado). Isso é, genuinamente, mais do que a maior parte da automação em DeFi oferece hoje.

Mas aqui está o ponto. Execução verificável e julgamento verificável são problemas diferentes. Newton resolve o primeiro com cuidado. O segundo ainda depende, em grande parte, de quem escreveu as regras.

Em termos simples: se um gerente de um cofre define um limite de gastos que acaba sendo frouxo demais, ou define um gatilho de rebalanceamento que fazia sentido em mercados calmos, mas não em mercados voláteis, a Newton aplica essas regras corretamente. A política é executada, a prova é produzida, a transação é liquidada. Tudo funcionou conforme o planejado. O resultado ainda pode ser ruim.

Isso não é exatamente uma falha da arquitetura. Nenhuma camada de aplicação pode tornar o julgamento humano melhor. Mas ela levanta uma questão que o protocolo ainda não respondeu completamente — quando uma política está correta, mas as regras por trás dela estavam erradas, onde fica a responsabilidade? Com o operador que a configurou? Com o desenvolvedor que publicou o modelo? Com o usuário que a ativou sem ler completamente o que aprovou?

As finanças tradicionais resolvem isso por meio de licenciamento, dever fiduciário e regulação. A cripto resolve por meio de documentação que ninguém lê e termos de serviço que isentam de responsabilidade por tudo.

A Newton está no meio desse vazio agora. A camada de aplicação está sendo construída com cuidado. A camada de responsabilidade em torno de quem desenha as regras, quem as audita e quem responde quando elas falham — essa parte ainda é, em grande medida, aspiracional.

Se isso será resolvido ao longo do tempo provavelmente importa mais do que qualquer marco técnico no roteiro.

$NEWT @NewtonProtocol #Newt
Estava relendo hoje cedo, no centro de ajuda da GRVT, as mecânicas reais do Multiplier Plan, além da linguagem de marketing, e algo clicou que eu não tinha considerado antes. A alocação da Temporada 2 é fixa em 18% da oferta de 1 bilhão de GRVT. A alocação total para comunidade e airdrop é limitada em 28%. Esse não é um número que muda; é fixo antes mesmo de qualquer pessoa se registrar. Então, quando o Multiplier Plan oferece até 4x da sua alocação por adiar, de onde vem, na prática, esse tamanho extra? Não pode vir de novos tokens; a oferta é fixa e não há emissão adicional. Tem que vir do mesmo pool do qual todo mundo está tirando. Isso significa que o plano não está realmente recompensando a paciência com um novo valor. Ele está redistribuindo uma torta fixa. Cada pessoa que pega um multiplicador maior ao esperar, na prática, está diminuindo o que sobra para o pool em relação àquelas que reivindicam imediatamente. É uma divisão de soma zero, disfarçada de bônus de fidelidade. O registro está aberto agora até 27 de julho de 2026, 00:00 UTC, e a escolha é definitiva depois que é feita. Ninguém sabe ainda qual fração dos participantes vai escolher o multiplicador em vez da reivindicação imediata, e essa proporção é exatamente o que determina se adiar valeu a pena. Se a maioria correr para reivindicar imediatamente, os poucos que adiaram acabam com uma fatia desproporcional. Se a maioria adiar, o multiplicador se dilui contra si mesmo e o "bônus" encolhe em direção a nada. Curioso para ver para qual lado os números do registro realmente pendem quando a janela fechar. #grvt #BinanceSquare @grvt_io
Estava relendo hoje cedo, no centro de ajuda da GRVT, as mecânicas reais do Multiplier Plan, além da linguagem de marketing, e algo clicou que eu não tinha considerado antes.

A alocação da Temporada 2 é fixa em 18% da oferta de 1 bilhão de GRVT. A alocação total para comunidade e airdrop é limitada em 28%. Esse não é um número que muda; é fixo antes mesmo de qualquer pessoa se registrar.

Então, quando o Multiplier Plan oferece até 4x da sua alocação por adiar, de onde vem, na prática, esse tamanho extra? Não pode vir de novos tokens; a oferta é fixa e não há emissão adicional. Tem que vir do mesmo pool do qual todo mundo está tirando.

Isso significa que o plano não está realmente recompensando a paciência com um novo valor. Ele está redistribuindo uma torta fixa. Cada pessoa que pega um multiplicador maior ao esperar, na prática, está diminuindo o que sobra para o pool em relação àquelas que reivindicam imediatamente. É uma divisão de soma zero, disfarçada de bônus de fidelidade.

O registro está aberto agora até 27 de julho de 2026, 00:00 UTC, e a escolha é definitiva depois que é feita. Ninguém sabe ainda qual fração dos participantes vai escolher o multiplicador em vez da reivindicação imediata, e essa proporção é exatamente o que determina se adiar valeu a pena.

Se a maioria correr para reivindicar imediatamente, os poucos que adiaram acabam com uma fatia desproporcional. Se a maioria adiar, o multiplicador se dilui contra si mesmo e o "bônus" encolhe em direção a nada.

Curioso para ver para qual lado os números do registro realmente pendem quando a janela fechar.

#grvt #BinanceSquare @grvt_io
Artigo
Trustless Sempre Foi Uma Simplificação. Newton Parece Saber Disso.Algo ficou comigo esta semana que eu não consegui articular com clareza até agora. Tem a ver com uma palavra que a cripto tem usado com tanta frequência que ela parou de carregar sentido. Essa palavra é trustless. Tenho pensado nisso de um jeito diferente ultimamente. Não como uma crítica à ideia, mas como uma reavaliação honesta do que realmente construímos. Trustless era sempre o objetivo — eliminar a necessidade de confiar em qualquer instituição, em qualquer pessoa, em qualquer autoridade. Substituir a confiança humana por matemática. Deixar o código decidir. Era uma ambição elegante e, em certos aspectos estreitos, funcionou.

Trustless Sempre Foi Uma Simplificação. Newton Parece Saber Disso.

Algo ficou comigo esta semana que eu não consegui articular com clareza até agora. Tem a ver com uma palavra que a cripto tem usado com tanta frequência que ela parou de carregar sentido. Essa palavra é trustless.
Tenho pensado nisso de um jeito diferente ultimamente. Não como uma crítica à ideia, mas como uma reavaliação honesta do que realmente construímos. Trustless era sempre o objetivo — eliminar a necessidade de confiar em qualquer instituição, em qualquer pessoa, em qualquer autoridade. Substituir a confiança humana por matemática. Deixar o código decidir. Era uma ambição elegante e, em certos aspectos estreitos, funcionou.
Passei parte de hoje tentando quebrar a configuração do agente de linguagem natural da Newton — não de um jeito malicioso, apenas pensando no que acontece quando inglês simples encontra código preciso. A experiência é genuinamente suave. Você digita algo como "rebalancear meu portfólio se qualquer ativo individual exceder 30%" e o sistema transforma isso em uma política executável de verdade, com <zkPermissions> anexado. Sem Solidity. Sem arquivos de configuração. A distância entre intenção e execução parece menor do que tudo o que eu já usei antes em DeFi. Aí comecei a fazer as óbvias perguntas de acompanhamento e a suavidade ficou complicada rapidamente. 30% de quê exatamente? O valor atual do portfólio no momento do gatilho? O valor no momento em que a permissão foi criada? O depósito inicial? Essas três interpretações produzem gatilhos de rebalance diferentes em um mercado volátil, às vezes de forma dramaticamente diferente. "Qualquer ativo individual" — isso inclui posições apostadas? Tokens de pool de liquidez? Versões envolvidas do mesmo ativo mantidas em protocolos diferentes? O protocolo não te interpreta mal. Esse é o problema. Ele te entende com precisão e executa exatamente o que a versão analisada da sua instrução diz, o que pode não ser o que você quis dizer quando digitou aquilo numa frase comum. A Newton torna a aplicação de políticas confiável. Não torna a autoria de políticas confiável. São problemas diferentes, e o segundo não é resolvido com infraestrutura melhor — ele é resolvido com padrões mais adequados, prévias de interpretação mais claras e, provavelmente, alguns casos-limite dolorosos que ensinam ao ecossistema o que "rebalance" precisa especificar antes de poder ser automatizado com segurança. Eu preferiria ver a camada de linguagem natural mostrar a política analisada em termos simples antes de eu confirmar, em vez de descobrir o desencontro de interpretação três semanas depois, quando o agente fez exatamente o que eu disse e nada parecido com o que eu quis dizer $NEWT @NewtonProtocol #Newt
Passei parte de hoje tentando quebrar a configuração do agente de linguagem natural da Newton — não de um jeito malicioso, apenas pensando no que acontece quando inglês simples encontra código preciso.

A experiência é genuinamente suave. Você digita algo como "rebalancear meu portfólio se qualquer ativo individual exceder 30%" e o sistema transforma isso em uma política executável de verdade, com <zkPermissions> anexado. Sem Solidity. Sem arquivos de configuração. A distância entre intenção e execução parece menor do que tudo o que eu já usei antes em DeFi.

Aí comecei a fazer as óbvias perguntas de acompanhamento e a suavidade ficou complicada rapidamente.

30% de quê exatamente? O valor atual do portfólio no momento do gatilho? O valor no momento em que a permissão foi criada? O depósito inicial? Essas três interpretações produzem gatilhos de rebalance diferentes em um mercado volátil, às vezes de forma dramaticamente diferente. "Qualquer ativo individual" — isso inclui posições apostadas? Tokens de pool de liquidez? Versões envolvidas do mesmo ativo mantidas em protocolos diferentes?

O protocolo não te interpreta mal. Esse é o problema. Ele te entende com precisão e executa exatamente o que a versão analisada da sua instrução diz, o que pode não ser o que você quis dizer quando digitou aquilo numa frase comum.

A Newton torna a aplicação de políticas confiável. Não torna a autoria de políticas confiável. São problemas diferentes, e o segundo não é resolvido com infraestrutura melhor — ele é resolvido com padrões mais adequados, prévias de interpretação mais claras e, provavelmente, alguns casos-limite dolorosos que ensinam ao ecossistema o que "rebalance" precisa especificar antes de poder ser automatizado com segurança.

Eu preferiria ver a camada de linguagem natural mostrar a política analisada em termos simples antes de eu confirmar, em vez de descobrir o desencontro de interpretação três semanas depois, quando o agente fez exatamente o que eu disse e nada parecido com o que eu quis dizer

$NEWT @NewtonProtocol #Newt
Voltei para reler a fórmula exata que o GRVT usa para o haircut, já que percebi que a discussão anterior que eu vi nunca a detalhou de verdade. É o Déficit do Fundo de Seguro dividido pelo Patrimônio Total do Cliente. Esse denominador é a parte que mudou a forma como eu vi isso. Isso significa que o haircut não é uma penalidade fixa atrelada ao tamanho da insuficiência. É uma porcentagem que se move dependendo de quanto capital total do cliente está na exchange naquele momento exato. Mesmo déficit, mais patrimônio total na plataforma, e a taxa de retirada diminui automaticamente. Mesmo déficit, menos patrimônio total, e a cobrança “morde” mais. Assim, o próprio crescimento atua silenciosamente como um amortecedor de impactos. Uma base maior de usuários não só parece mais saudável em um painel, como também dilui matematicamente o ônus que qualquer usuário retirando individualmente assume durante um evento de déficit. O que também significa que o contrário é verdadeiro: um déficit atingindo um período mais tranquilo, com menos recursos estacionados na plataforma, produz um haircut mais severo na mesma insuficiência em dólares. Isso não é exatamente uma falha; é apenas uma característica que ninguém divulga. O tamanho da perda que você pessoalmente absorve depende menos do que causou o déficit e mais de quanto capital não relacionado estava, por acaso, sentado no GRVT no dia em que você precisava sair. Se isso é uma característica estabilizadora ou um risco oculto de timing provavelmente depende de quão rápido o Patrimônio Total do Cliente consegue diminuir durante o mesmo evento de estresse que criou o déficit em primeiro lugar. #grvt #BinanceSquare @grvt_io
Voltei para reler a fórmula exata que o GRVT usa para o haircut, já que percebi que a discussão anterior que eu vi nunca a detalhou de verdade.

É o Déficit do Fundo de Seguro dividido pelo Patrimônio Total do Cliente. Esse denominador é a parte que mudou a forma como eu vi isso.

Isso significa que o haircut não é uma penalidade fixa atrelada ao tamanho da insuficiência. É uma porcentagem que se move dependendo de quanto capital total do cliente está na exchange naquele momento exato. Mesmo déficit, mais patrimônio total na plataforma, e a taxa de retirada diminui automaticamente. Mesmo déficit, menos patrimônio total, e a cobrança “morde” mais.

Assim, o próprio crescimento atua silenciosamente como um amortecedor de impactos. Uma base maior de usuários não só parece mais saudável em um painel, como também dilui matematicamente o ônus que qualquer usuário retirando individualmente assume durante um evento de déficit. O que também significa que o contrário é verdadeiro: um déficit atingindo um período mais tranquilo, com menos recursos estacionados na plataforma, produz um haircut mais severo na mesma insuficiência em dólares.

Isso não é exatamente uma falha; é apenas uma característica que ninguém divulga. O tamanho da perda que você pessoalmente absorve depende menos do que causou o déficit e mais de quanto capital não relacionado estava, por acaso, sentado no GRVT no dia em que você precisava sair.

Se isso é uma característica estabilizadora ou um risco oculto de timing provavelmente depende de quão rápido o Patrimônio Total do Cliente consegue diminuir durante o mesmo evento de estresse que criou o déficit em primeiro lugar.

#grvt #BinanceSquare @grvt_io
Artigo
Por que o Modelo de Autorização em Duas Camadas da Newton Me Faz Pensar Diferente Sobre Aprovações de CarteiraEnquanto lia a documentação técnica do Newton Protocol, eu continuava voltando a uma distinção que a maioria das interações de carteira reduz a uma única etapa. Quanto mais eu olhava para isso, mais eu percebia que separar essa etapa em duas camadas distintas pode ser uma das decisões arquiteturais mais relevantes do projeto — mesmo que a Newton não tenha formalmente nomeado isso como uma funcionalidade unificada. Deixe-me explicar o problema primeiro, porque ele realmente vale a pena ser entendido antes de olhar para a solução.

Por que o Modelo de Autorização em Duas Camadas da Newton Me Faz Pensar Diferente Sobre Aprovações de Carteira

Enquanto lia a documentação técnica do Newton Protocol, eu continuava voltando a uma distinção que a maioria das interações de carteira reduz a uma única etapa. Quanto mais eu olhava para isso, mais eu percebia que separar essa etapa em duas camadas distintas pode ser uma das decisões arquiteturais mais relevantes do projeto — mesmo que a Newton não tenha formalmente nomeado isso como uma funcionalidade unificada.
Deixe-me explicar o problema primeiro, porque ele realmente vale a pena ser entendido antes de olhar para a solução.
Existe uma versão de investimento em cripto que a maioria das pessoas descreve, mas quase ninguém realmente pratica. Ela envolve observar algo sendo construído, entender o que é antes de o mercado fazer isso e, então, esperar tempo suficiente para que o resto do mercado chegue à mesma conclusão. Parece simples. A parte de esperar é onde tudo desanda. A infraestrutura tem um problema específico de timing que outras categorias de cripto não têm. Um novo token pode encontrar uma narrativa em dias. Uma nova cadeia consegue atrair liquidez em semanas. Infraestrutura é usada quando algo mais precisa dela — e esse momento quase nunca é previsível de fora. Ele chega de forma discreta, geralmente porque um desenvolvedor estava construindo algo não relacionado e esbarrou em uma barreira que a infraestrutura foi desenhada para remover. É essa dinâmica que eu continuo pensando ao falar do Newton Protocol. O cenário de demanda não depende de atenção. Depende de necessidade. Se agentes autônomos se proliferarem — o que parece cada vez mais provável — a questão de como autorizar, restringir e verificar o que esses agentes fazem se torna inevitável. Não é interessante. É inevitável. Nesse ponto, os desenvolvedores não avaliam o Newton porque ele tem uma boa narrativa. Eles avaliam porque precisam de algo que ele oferece, e as alternativas são piores. O atual $NEWT price fica em torno de US$ 0,049, com aproximadamente 21,5% da oferta total em circulação e outro desbloqueio chegando em breve. Cronogramas de oferta não pausam para ciclos de adoção de infraestrutura, e esses ciclos são lentos por definição. O que eu acho que vale acompanhar não é o preço. É se a contagem de integrações começa a crescer por conta própria — desenvolvedores encontrando o VaultKit porque outro desenvolvedor mencionou, não porque o time de marketing entrou em contato. Esse tipo de crescimento fica invisível até se tornar impossível negar, que é exatamente quando a maioria das pessoas decide prestar atenção. Os projetos que acabam importando mais raramente são os que tiveram o lançamento mais barulhento. São os que ainda estão sendo integrados silenciosamente dezoito meses depois. $NEWT @NewtonProtocol #Newt
Existe uma versão de investimento em cripto que a maioria das pessoas descreve, mas quase ninguém realmente pratica. Ela envolve observar algo sendo construído, entender o que é antes de o mercado fazer isso e, então, esperar tempo suficiente para que o resto do mercado chegue à mesma conclusão. Parece simples. A parte de esperar é onde tudo desanda.

A infraestrutura tem um problema específico de timing que outras categorias de cripto não têm. Um novo token pode encontrar uma narrativa em dias. Uma nova cadeia consegue atrair liquidez em semanas. Infraestrutura é usada quando algo mais precisa dela — e esse momento quase nunca é previsível de fora. Ele chega de forma discreta, geralmente porque um desenvolvedor estava construindo algo não relacionado e esbarrou em uma barreira que a infraestrutura foi desenhada para remover.

É essa dinâmica que eu continuo pensando ao falar do Newton Protocol. O cenário de demanda não depende de atenção. Depende de necessidade. Se agentes autônomos se proliferarem — o que parece cada vez mais provável — a questão de como autorizar, restringir e verificar o que esses agentes fazem se torna inevitável. Não é interessante. É inevitável. Nesse ponto, os desenvolvedores não avaliam o Newton porque ele tem uma boa narrativa. Eles avaliam porque precisam de algo que ele oferece, e as alternativas são piores.

O atual $NEWT price fica em torno de US$ 0,049, com aproximadamente 21,5% da oferta total em circulação e outro desbloqueio chegando em breve. Cronogramas de oferta não pausam para ciclos de adoção de infraestrutura, e esses ciclos são lentos por definição.

O que eu acho que vale acompanhar não é o preço. É se a contagem de integrações começa a crescer por conta própria — desenvolvedores encontrando o VaultKit porque outro desenvolvedor mencionou, não porque o time de marketing entrou em contato. Esse tipo de crescimento fica invisível até se tornar impossível negar, que é exatamente quando a maioria das pessoas decide prestar atenção.

Os projetos que acabam importando mais raramente são os que tiveram o lançamento mais barulhento. São os que ainda estão sendo integrados silenciosamente dezoito meses depois.

$NEWT @NewtonProtocol #Newt
Faça login para explorar mais conteúdos
Junte-se a usuários de criptomoedas de todo o mundo no Binance Square.
⚡️ Obter informações mais recentes e úteis sobre criptomoeda.
💬 Com a confiança da maior corretora de criptomoedas do mundo.
👍 Descubra insights reais de criadores verificados.
E-mail / número de telefone
Sitemap
Preferências de Cookies
Termos e Condições da Plataforma