Binance Square
NewbieToNode
4.3k Publicações

NewbieToNode

Square verificado+
Planting tokens 🌱 Waiting for sun 🌞 Watering with hope 💧 Soft degen vibes only
Traders League Badge Expert
Traders League Badge Expert
Trader Frequente
4.4 ano(s)
183 A seguir
33.0K+ Seguidores
27.8K+ Gostaram
1 Emblemas
Publicações
·
--
Verificado
então, as solicitações de auxílio-desemprego vieram em 206 mil hoje, abaixo das 212 mil da semana passada. os manchetes vão chamar isso de "mercado de trabalho forte", mas se você olhar além da linha principal... a média móvel de 4 semanas SUBIU para 204 mil e as solicitações contínuas (continuing claims) subiram para 1,8 milhão. as pessoas estão tendo mais dificuldade para encontrar novos empregos, mesmo que, neste momento, menos gente esteja sendo demitida. e tem mais — um economista literalmente disse que o mercado de trabalho "não mostrou nenhum desgaste" por causa do aumento do preço do petróleo ligado à escalada da guerra entre o Irã. essa é a história de verdade, que ninguém está colocando nas manchetes. os mercados provavelmente vão interpretar isso como um cenário de "dourados" (nem quente demais, nem frio demais), o que mantém o Fed no caminho para cortes. isso é uma notícia até boa para ativos de risco — expectativas menores de juros costumam ser um vento a favor para o BTC e para as principais criptos. vamos observar se teremos uma reação positiva (verde) até o fechamento, ou se os indicadores mistos (subida das solicitações contínuas) vão assustar as coisas. não é aconselhamento de investimento, é só pensando em voz alta 🤔 #USJoblessClaimsFallTo206000
então, as solicitações de auxílio-desemprego vieram em 206 mil hoje, abaixo das 212 mil da semana passada. os manchetes vão chamar isso de "mercado de trabalho forte", mas se você olhar além da linha principal... a média móvel de 4 semanas SUBIU para 204 mil e as solicitações contínuas (continuing claims) subiram para 1,8 milhão. as pessoas estão tendo mais dificuldade para encontrar novos empregos, mesmo que, neste momento, menos gente esteja sendo demitida.
e tem mais — um economista literalmente disse que o mercado de trabalho "não mostrou nenhum desgaste" por causa do aumento do preço do petróleo ligado à escalada da guerra entre o Irã. essa é a história de verdade, que ninguém está colocando nas manchetes.

os mercados provavelmente vão interpretar isso como um cenário de "dourados" (nem quente demais, nem frio demais), o que mantém o Fed no caminho para cortes. isso é uma notícia até boa para ativos de risco — expectativas menores de juros costumam ser um vento a favor para o BTC e para as principais criptos. vamos observar se teremos uma reação positiva (verde) até o fechamento, ou se os indicadores mistos (subida das solicitações contínuas) vão assustar as coisas.
não é aconselhamento de investimento, é só pensando em voz alta 🤔

#USJoblessClaimsFallTo206000
Verificado
@Dusk_Foundation 16 iterações falhas consecutivas é o suficiente para fazer o Dusk parar de se comportar normalmente. Eu li esse número algumas vezes antes dele se confirmar. Em condições normais, as etapas de consenso são executadas com um limite de tempo. Se uma etapa não produzir um resultado a tempo, ela não retorna nada e a rodada tenta novamente. Tente. Timeout. Tente novamente. Eu assumi que esse caminho de falha permanecia no lugar não importa o quão ruim as coisas ficassem. Não fica. Após 16 falhas consecutivas, o Dusk desabilita esses timeouts. As etapas não podem mais retornar NoCandidate ou NoQuorum. As iterações continuam rodando até que um candidato de fato alcance o quorum para validação e ratificação. Isso cria um segundo modo de falha que eu não tinha separado antes. A falha normal é limitada pelo relógio. O modo de emergência remove essa fronteira. E isso introduz outro problema: múltiplas iterações sem fim podem rodar ao mesmo tempo, criando a possibilidade de candidatos concorrentes alcançarem quorum na mesma rodada. O Dusk já tem uma regra para esse caso: o candidato que alcança quorum na menor iteração vence. O que eu ainda não sei é como são exatamente essas 16 falhas consecutivas em uma rede real. Que tipo de condição de rede sustentada te leva até aí, e com que frequência a regra de resolução de fork seria realmente aplicada em vez de permanecer como um caminho teórico? $DUSK becomes more interesting to me if this emergency path proves reliable when the network actually needs it. #dusk {spot}(DUSKUSDT)
@Dusk

16 iterações falhas consecutivas é o suficiente para fazer o Dusk parar de se comportar normalmente.

Eu li esse número algumas vezes antes dele se confirmar.

Em condições normais, as etapas de consenso são executadas com um limite de tempo. Se uma etapa não produzir um resultado a tempo, ela não retorna nada e a rodada tenta novamente.

Tente. Timeout. Tente novamente.

Eu assumi que esse caminho de falha permanecia no lugar não importa o quão ruim as coisas ficassem.

Não fica.

Após 16 falhas consecutivas, o Dusk desabilita esses timeouts. As etapas não podem mais retornar NoCandidate ou NoQuorum. As iterações continuam rodando até que um candidato de fato alcance o quorum para validação e ratificação.

Isso cria um segundo modo de falha que eu não tinha separado antes.

A falha normal é limitada pelo relógio. O modo de emergência remove essa fronteira.

E isso introduz outro problema: múltiplas iterações sem fim podem rodar ao mesmo tempo, criando a possibilidade de candidatos concorrentes alcançarem quorum na mesma rodada.

O Dusk já tem uma regra para esse caso: o candidato que alcança quorum na menor iteração vence.

O que eu ainda não sei é como são exatamente essas 16 falhas consecutivas em uma rede real.

Que tipo de condição de rede sustentada te leva até aí, e com que frequência a regra de resolução de fork seria realmente aplicada em vez de permanecer como um caminho teórico?

$DUSK becomes more interesting to me if this emergency path proves reliable when the network actually needs it.

#dusk
#termmax @termmax Hoje eu estava verificando o TVL da TermMax e um número me levou de volta aos documentos de liquidação. US$ 31,22M, queda de 7,2% nos últimos 30 dias, de acordo com a DeFiLlama. Não foi um colapso. Mas me fez olhar com mais atenção para o que acontece quando uma liquidação não sai perfeitamente. Quando um empréstimo atinge o limite de LLTV, ou quando o tomador perde o vencimento, a posição recebe uma janela de liquidação de 2 horas. Os liquidadores ganham uma recompensa de 5% a partir da garantia. O protocolo cobra uma penalidade de 5%. Normalmente, essa é toda a história. Mas o que acontece quando 2 horas não é suficiente? Os próprios documentos de risco da TermMax descrevem a alternativa. Se a liquidação não conseguir ser executada completamente por causa de um movimento brusco de preço ou de liquidez baixa, os credores recebem uma parcela proporcional da garantia do tomador em vez do ativo que eles originalmente emprestaram. Entrega Física. Automática. Sem opt-in do credor. Essa foi a parte que eu tive que pensar duas vezes. A taxa é fixa. O vencimento é fixo. O caminho de recuperação não é. E eu não acho necessariamente que isso seja uma falha. Se a alternativa for uma liquidação malsucedida e uma perda pior, receber a garantia subjacente pode ser o resultado melhor. Mas isso muda o que “certeza” significa para o credor. Você conhece a taxa. Você conhece o prazo. Você não sabe necessariamente qual ativo estará na sua carteira se o caminho normal de liquidação falhar. Uma queda de 7,2% no TVL não me diz que a Entrega Física está perto de ser acionada em qualquer lugar. Eu não tenho esses dados. Mas me faz querer ver outro número junto com o TVL: quanto de garantia de fato pode ser liquidado dentro dessa janela de 2 horas? Porque é esse o limite que eu gostaria de entender antes de considerar o mecanismo de liquidação resiliente sob estresse. Se a TermMax algum dia tornar esse número visível, é ele que eu estarei observando.
#termmax @TermMax

Hoje eu estava verificando o TVL da TermMax e um número me levou de volta aos documentos de liquidação.

US$ 31,22M, queda de 7,2% nos últimos 30 dias, de acordo com a DeFiLlama.

Não foi um colapso. Mas me fez olhar com mais atenção para o que acontece quando uma liquidação não sai perfeitamente.

Quando um empréstimo atinge o limite de LLTV, ou quando o tomador perde o vencimento, a posição recebe uma janela de liquidação de 2 horas.

Os liquidadores ganham uma recompensa de 5% a partir da garantia. O protocolo cobra uma penalidade de 5%.

Normalmente, essa é toda a história.

Mas o que acontece quando 2 horas não é suficiente?

Os próprios documentos de risco da TermMax descrevem a alternativa. Se a liquidação não conseguir ser executada completamente por causa de um movimento brusco de preço ou de liquidez baixa, os credores recebem uma parcela proporcional da garantia do tomador em vez do ativo que eles originalmente emprestaram.

Entrega Física.

Automática. Sem opt-in do credor.

Essa foi a parte que eu tive que pensar duas vezes.

A taxa é fixa.
O vencimento é fixo.
O caminho de recuperação não é.

E eu não acho necessariamente que isso seja uma falha. Se a alternativa for uma liquidação malsucedida e uma perda pior, receber a garantia subjacente pode ser o resultado melhor.

Mas isso muda o que “certeza” significa para o credor.

Você conhece a taxa.
Você conhece o prazo.
Você não sabe necessariamente qual ativo estará na sua carteira se o caminho normal de liquidação falhar.

Uma queda de 7,2% no TVL não me diz que a Entrega Física está perto de ser acionada em qualquer lugar. Eu não tenho esses dados.

Mas me faz querer ver outro número junto com o TVL: quanto de garantia de fato pode ser liquidado dentro dessa janela de 2 horas?

Porque é esse o limite que eu gostaria de entender antes de considerar o mecanismo de liquidação resiliente sob estresse.

Se a TermMax algum dia tornar esse número visível, é ele que eu estarei observando.
#dusk $DUSK @Dusk_Foundation Comecei com a exigência de 1.000 DUSK e depois fiquei preso na configuração da carteira. Um stake pode usar duas chaves diferentes. A chave de consenso opera o nó. Ela vota e assina blocos. A chave do proprietário controla o outro lado: desbloqueio (unstaking) e retirada. A Dusk recomenda mantê-las separadas. Isso mudou a forma como eu estava vendo a exigência de 1.000 DUSK. Não é apenas capital parado em uma carteira. É uma posição operacional vinculada a uma máquina que precisa ficar online 24/7 e participar do consenso. A Dusk está separando a autoridade para operar o consenso da autoridade para controlar o stake. Comprometer o lado do consenso não dá automaticamente controle do stake. O trade-off é interessante. O limite de segurança fica melhor. O caminho de recuperação fica mais difícil. Se um provedor (provisioner) tiver que ser migrado ou recuperado sob pressão de tempo, como os operadores mantêm essa separação intacta sem perder o papel deles no consenso? {spot}(DUSKUSDT)
#dusk $DUSK @Dusk

Comecei com a exigência de 1.000 DUSK e depois fiquei preso na configuração da carteira.

Um stake pode usar duas chaves diferentes.

A chave de consenso opera o nó. Ela vota e assina blocos.

A chave do proprietário controla o outro lado: desbloqueio (unstaking) e retirada.

A Dusk recomenda mantê-las separadas.

Isso mudou a forma como eu estava vendo a exigência de 1.000 DUSK.

Não é apenas capital parado em uma carteira. É uma posição operacional vinculada a uma máquina que precisa ficar online 24/7 e participar do consenso.

A Dusk está separando a autoridade para operar o consenso da autoridade para controlar o stake.

Comprometer o lado do consenso não dá automaticamente controle do stake.

O trade-off é interessante.

O limite de segurança fica melhor. O caminho de recuperação fica mais difícil.

Se um provedor (provisioner) tiver que ser migrado ou recuperado sob pressão de tempo, como os operadores mantêm essa separação intacta sem perder o papel deles no consenso?
Verificado
#termmax @termmax O exemplo de 45 dias na integração de Morpho da TermMax me pegou de surpresa. Um tomador tem 50.000 USDC contra wstETH, alocados em uma posição da TermMax com uma data de vencimento. Taxa fixa. Prazo conhecido. Bastante simples. Então eu percebi a rota de saída. Fazer Roll para a Morpho permite que o mesmo tomador feche a posição da TermMax antes do vencimento e mova o mesmo colateral para um empréstimo de taxa flutuante na Morpho, de forma atômica. Sem interrupção na cobertura. Sem necessidade de conseguir recursos para quitação antes. O próprio exemplo deles deixa isso claro: se um tomador espera que as taxas flutuantes caiam, ele pode sair da posição fixa mais cedo e refinanciar via Morpho. Então a parte interessante não é a taxa. É o compromisso. A TermMax criou um produto de taxa fixa e, depois, construiu uma forma deliberadamente de baixa fricção de sair da parte fixa. O que significa que a data de vencimento não é, de fato, uma barreira. É mais como uma configuração padrão que o tomador pode substituir quando muda a visão sobre a taxa. Aqui está o que eu não consigo responder apenas lendo o mecanismo: Quando as taxas se movem o bastante para tornar o Roll para Morpho atrativo, essa saída protege a liquidez da TermMax ou drena o lado fixo exatamente quando o protocolo precisa do compromisso para sustentar? Esse é o comportamento que eu gostaria de ver quando volume real, e não um exemplo limpo de 50.000 USDC, começar a passar por cima. O $TMX ainda não está no ar, então estou menos interessado em o que o token faz hoje. Estou mais interessado em saber se essa arquitetura consegue se sustentar em escala antes de o token fazer parte da equação.
#termmax @TermMax

O exemplo de 45 dias na integração de Morpho da TermMax me pegou de surpresa.

Um tomador tem 50.000 USDC contra wstETH, alocados em uma posição da TermMax com uma data de vencimento.

Taxa fixa. Prazo conhecido.

Bastante simples.

Então eu percebi a rota de saída.

Fazer Roll para a Morpho permite que o mesmo tomador feche a posição da TermMax antes do vencimento e mova o mesmo colateral para um empréstimo de taxa flutuante na Morpho, de forma atômica.

Sem interrupção na cobertura. Sem necessidade de conseguir recursos para quitação antes.

O próprio exemplo deles deixa isso claro: se um tomador espera que as taxas flutuantes caiam, ele pode sair da posição fixa mais cedo e refinanciar via Morpho.

Então a parte interessante não é a taxa.

É o compromisso.

A TermMax criou um produto de taxa fixa e, depois, construiu uma forma deliberadamente de baixa fricção de sair da parte fixa.

O que significa que a data de vencimento não é, de fato, uma barreira.

É mais como uma configuração padrão que o tomador pode substituir quando muda a visão sobre a taxa.

Aqui está o que eu não consigo responder apenas lendo o mecanismo:

Quando as taxas se movem o bastante para tornar o Roll para Morpho atrativo, essa saída protege a liquidez da TermMax ou drena o lado fixo exatamente quando o protocolo precisa do compromisso para sustentar?

Esse é o comportamento que eu gostaria de ver quando volume real, e não um exemplo limpo de 50.000 USDC, começar a passar por cima.

O $TMX ainda não está no ar, então estou menos interessado em o que o token faz hoje. Estou mais interessado em saber se essa arquitetura consegue se sustentar em escala antes de o token fazer parte da equação.
Verificado
#dusk $DUSK @Dusk_Foundation Eu parei no prêmio do gerador de 80% quando li pela primeira vez a divisão do bloco de Dusk. Então notei que os 80% não são, na verdade, fixos. O prêmio é dividido em 80% para o gerador, 10% para o comitê de votação e 10% para a Dusk. Apenas 70% da parcela do gerador é fixa. Os 10% restantes dependem de quantos votos do comitê entram no certificado do bloco, ponderados pelos créditos dos eleitores. Inclua todos os votos, e o gerador recebe os 80% completos. Então vencer o bloco e maximizar seu prêmio são duas coisas diferentes. O gerador precisa fazer mais do que produzir o bloco; ele também precisa incorporar o trabalho do comitê no certificado. Isso cria um incentivo simples, mas interessante: parte da economia do gerador depende de o certificado estar completo. O que eu não consigo ver na documentação é o quanto isso importa na prática. Quando os votos chegam tarde, com que frequência essa variável de 10% realmente é capturada?
#dusk $DUSK @Dusk

Eu parei no prêmio do gerador de 80% quando li pela primeira vez a divisão do bloco de Dusk.

Então notei que os 80% não são, na verdade, fixos.

O prêmio é dividido em 80% para o gerador, 10% para o comitê de votação e 10% para a Dusk.

Apenas 70% da parcela do gerador é fixa. Os 10% restantes dependem de quantos votos do comitê entram no certificado do bloco, ponderados pelos créditos dos eleitores. Inclua todos os votos, e o gerador recebe os 80% completos.

Então vencer o bloco e maximizar seu prêmio são duas coisas diferentes.

O gerador precisa fazer mais do que produzir o bloco; ele também precisa incorporar o trabalho do comitê no certificado.

Isso cria um incentivo simples, mas interessante: parte da economia do gerador depende de o certificado estar completo.

O que eu não consigo ver na documentação é o quanto isso importa na prática. Quando os votos chegam tarde, com que frequência essa variável de 10% realmente é capturada?
#termmax @termmax 2M $TMX. Esse é o número para o qual eu continuava voltando depois de analisar a campanha do Booster da TermMax... 1,7M vai para o sorteio. 300K vai para criadores do Binance Square. E o maior pool de recompensas é bem pouco “friction”. As tarefas do sorteio listadas são basicamente seguir, repostar, quiz, Discord e conectar sua carteira — não é necessário depósito nem atividade de empréstimo, concessão de crédito ou opções para esse caminho. Aí, espera... A história completa da TermMax é sobre empréstimo, concessão de crédito e opções com taxa fixa, capital com a taxa e o vencimento definidos com antecedência. Mas a maior “rail” de recompensas na verdade não exige que os usuários usem esses produtos. O pool menor de 300K TMX é do lado do Binance Square, onde os criadores realmente precisam competir em qualidade do conteúdo e no ranking. Então talvez eu estivesse encarando o Booster pelo ângulo errado. Parece que o pool de 1,7M TMX foi construído para alcance com pouca fricção e conexões de carteira... enquanto o pool menor do Square recompensa visibilidade e ranking do criador. Talvez isso faça sentido para uma campanha de TGE. Mas o que acontece depois que o TMX cai? Esses participantes de 1,7M-TMX viram usuários da TermMax... ou a campanha termina quando as recompensas acabam?
#termmax @TermMax

2M $TMX.

Esse é o número para o qual eu continuava voltando depois de analisar a campanha do Booster da TermMax...

1,7M vai para o sorteio. 300K vai para criadores do Binance Square.

E o maior pool de recompensas é bem pouco “friction”. As tarefas do sorteio listadas são basicamente seguir, repostar, quiz, Discord e conectar sua carteira — não é necessário depósito nem atividade de empréstimo, concessão de crédito ou opções para esse caminho.

Aí, espera...

A história completa da TermMax é sobre empréstimo, concessão de crédito e opções com taxa fixa, capital com a taxa e o vencimento definidos com antecedência.

Mas a maior “rail” de recompensas na verdade não exige que os usuários usem esses produtos.

O pool menor de 300K TMX é do lado do Binance Square, onde os criadores realmente precisam competir em qualidade do conteúdo e no ranking.

Então talvez eu estivesse encarando o Booster pelo ângulo errado.

Parece que o pool de 1,7M TMX foi construído para alcance com pouca fricção e conexões de carteira... enquanto o pool menor do Square recompensa visibilidade e ranking do criador.

Talvez isso faça sentido para uma campanha de TGE.

Mas o que acontece depois que o TMX cai?

Esses participantes de 1,7M-TMX viram usuários da TermMax... ou a campanha termina quando as recompensas acabam?
Verificado
#termmax @termmax Estava vendo a última atualização da TermMax esta manhã... comecei pelos detalhes do TGE de 25 de agosto e, de alguma forma, acabei cavando pelos números. US$ 90M+ de TVL. 1,5M+ carteiras registradas. 90K+ usuários ativos diários. 10 cadeias EVM. Ok... isso é uma pegada bem grande. Mas então reparei em onde a mesma ideia de taxa fixa está aparecendo agora. Empréstimos, opções, equities tokenizadas... e até financiamento institucional em Canton. Isso me fez parar por um segundo. Porque não é só @termmax pegar um produto de crédito e colocá-lo em mais cadeias. Eles estão levando a mesma ideia de “taxa conhecida, prazo conhecido” para tipos de capital bem diferentes. Hmm... não tenho certeza se é tão simples quanto parece. Se o capital aumenta e as pessoas que o usam precisam planejar fluxos de caixa, a certeza provavelmente se torna mais valiosa. Mas o DeFi também foi construído, por anos, em cima da flexibilidade. Então quem vence quando os dois começam a puxar em direções opostas? O $TMX vai ao ar em 25 de agosto. Acho que é essa a parte que estou observando agora.
#termmax @TermMax

Estava vendo a última atualização da TermMax esta manhã... comecei pelos detalhes do TGE de 25 de agosto e, de alguma forma, acabei cavando pelos números.

US$ 90M+ de TVL. 1,5M+ carteiras registradas. 90K+ usuários ativos diários. 10 cadeias EVM.

Ok... isso é uma pegada bem grande.

Mas então reparei em onde a mesma ideia de taxa fixa está aparecendo agora.

Empréstimos, opções, equities tokenizadas... e até financiamento institucional em Canton.

Isso me fez parar por um segundo.

Porque não é só @TermMax pegar um produto de crédito e colocá-lo em mais cadeias. Eles estão levando a mesma ideia de “taxa conhecida, prazo conhecido” para tipos de capital bem diferentes.

Hmm... não tenho certeza se é tão simples quanto parece.

Se o capital aumenta e as pessoas que o usam precisam planejar fluxos de caixa, a certeza provavelmente se torna mais valiosa.

Mas o DeFi também foi construído, por anos, em cima da flexibilidade.

Então quem vence quando os dois começam a puxar em direções opostas?

O $TMX vai ao ar em 25 de agosto.

Acho que é essa a parte que estou observando agora.
#dusk $DUSK @Dusk_Foundation Eu costumava pensar que o lado regulatório dos ativos on-chain se resumia, na maior parte, ao próprio ativo. Esse token pode existir? Ele pode ser negociado? Mas, ao ver como as licenças da NPEX se dividem, pensei que isso provavelmente era simples demais. MTF, Broker, ECSP e DLT-TSS não parecem realmente ser apenas um rótulo de conformidade ligado a um ativo. Elas parecem mais permissões diferentes relacionadas a coisas distintas que você pode fazer com esse ativo. É essa parte que mudou a forma como eu estava pensando. O mesmo ativo pode estar dentro de emissão, distribuição ou negociação secundária, mas isso não é o mesmo ato regulado. Então, de fora, “finanças reguladas na Dusk” pode soar como uma única capacidade. Quanto mais eu observo, menos isso parece ser uma coisa só. Parece mais um conjunto de funções separadas que apenas coincidem em tocar o mesmo ativo em pontos diferentes. Talvez essa separação permaneça principalmente na camada de licenciamento. O que eu fico curioso agora é se ela também aparece na arquitetura real do produto. {spot}(DUSKUSDT)
#dusk $DUSK @Dusk

Eu costumava pensar que o lado regulatório dos ativos on-chain se resumia, na maior parte, ao próprio ativo.

Esse token pode existir? Ele pode ser negociado?

Mas, ao ver como as licenças da NPEX se dividem, pensei que isso provavelmente era simples demais.

MTF, Broker, ECSP e DLT-TSS não parecem realmente ser apenas um rótulo de conformidade ligado a um ativo.

Elas parecem mais permissões diferentes relacionadas a coisas distintas que você pode fazer com esse ativo.

É essa parte que mudou a forma como eu estava pensando.

O mesmo ativo pode estar dentro de emissão, distribuição ou negociação secundária, mas isso não é o mesmo ato regulado.

Então, de fora, “finanças reguladas na Dusk” pode soar como uma única capacidade.

Quanto mais eu observo, menos isso parece ser uma coisa só.

Parece mais um conjunto de funções separadas que apenas coincidem em tocar o mesmo ativo em pontos diferentes.

Talvez essa separação permaneça principalmente na camada de licenciamento.

O que eu fico curioso agora é se ela também aparece na arquitetura real do produto.
#dusk $DUSK @Dusk_Foundation E se o token disser que você é o proprietário da segurança, mas a lei disser que o registro real está em outro lugar? Eu me deparei com essa questão enquanto lia o artigo mais recente da Dusk sobre tokenização de SME. O artigo traz um exemplo concreto na Holanda: transferências de ações de BV exigem um ato notarial. Isso levanta uma questão que eu realmente não tinha considerado. Se a segurança é representada on-chain, mas um processo legalmente exigido ainda fica fora da cadeia, o que exatamente o token está representando? Eu vinha pensando em propriedade tokenizada principalmente como uma questão de colocar o ativo on-chain. Mas a parte mais difícil pode ser manter esse estado de propriedade digital alinhado com qualquer registro que a jurisdição realmente reconhece. Se esses dois estados alguma vez puderem discordar, a tokenização não eliminou completamente a necessidade de conciliação. Ela criou um novo problema de coordenação entre os lados digital e legal. Então, quando o estado de propriedade on-chain e o registro legalmente definitivo discordam, qual deles a Dusk trata como fonte da verdade? {spot}(DUSKUSDT) $HEMI {spot}(HEMIUSDT) $ACE {spot}(ACEUSDT)
#dusk $DUSK @Dusk

E se o token disser que você é o proprietário da segurança, mas a lei disser que o registro real está em outro lugar?

Eu me deparei com essa questão enquanto lia o artigo mais recente da Dusk sobre tokenização de SME.

O artigo traz um exemplo concreto na Holanda: transferências de ações de BV exigem um ato notarial.

Isso levanta uma questão que eu realmente não tinha considerado. Se a segurança é representada on-chain, mas um processo legalmente exigido ainda fica fora da cadeia, o que exatamente o token está representando?

Eu vinha pensando em propriedade tokenizada principalmente como uma questão de colocar o ativo on-chain. Mas a parte mais difícil pode ser manter esse estado de propriedade digital alinhado com qualquer registro que a jurisdição realmente reconhece.

Se esses dois estados alguma vez puderem discordar, a tokenização não eliminou completamente a necessidade de conciliação. Ela criou um novo problema de coordenação entre os lados digital e legal.

Então, quando o estado de propriedade on-chain e o registro legalmente definitivo discordam, qual deles a Dusk trata como fonte da verdade?

$HEMI
$ACE
Verificado
#dusk $DUSK @Dusk_Foundation Eu costumava achar que “ativos regulamentados on-chain” era basicamente um único obstáculo regulatório. Ao analisar a parceria da Dusk com a NPEX, percebi que é mais complexo do que isso. Os próprios materiais da Dusk citam quatro licenças: uma licença MTF para um mercado secundário regulamentado, uma licença Broker para captar ativos como MMFs e títulos, uma licença ECSP para instrumentos de investimento financiados pelo varejo e uma licença DLT-TSS ligada à emissão nativa e à tokenização de ativos regulamentados on-chain. A parte interessante não é apenas que a NPEX tem quatro licenças. É que elas correspondem a coisas diferentes que uma instituição pode realmente fazer com um ativo. Negociar um ativo regulamentado já existente e criar esse ativo nativamente on-chain são dois fluxos de trabalho diferentes, com requisitos regulatórios distintos por trás de cada um. Eu não tinha separado isso antes. “Finanças regulamentadas na Dusk” parece, de fora, uma única capacidade, mas a infraestrutura por trás é muito mais granular. O que eu estou observando agora é se essa separação regulatória também aparece na arquitetura real do produto. A emissão nativa na Dusk exige, fundamentalmente, um fluxo de trabalho diferente para levar um ativo regulamentado já existente para a rede?
#dusk $DUSK @Dusk

Eu costumava achar que “ativos regulamentados on-chain” era basicamente um único obstáculo regulatório.

Ao analisar a parceria da Dusk com a NPEX, percebi que é mais complexo do que isso.

Os próprios materiais da Dusk citam quatro licenças: uma licença MTF para um mercado secundário regulamentado, uma licença Broker para captar ativos como MMFs e títulos, uma licença ECSP para instrumentos de investimento financiados pelo varejo e uma licença DLT-TSS ligada à emissão nativa e à tokenização de ativos regulamentados on-chain.

A parte interessante não é apenas que a NPEX tem quatro licenças. É que elas correspondem a coisas diferentes que uma instituição pode realmente fazer com um ativo.

Negociar um ativo regulamentado já existente e criar esse ativo nativamente on-chain são dois fluxos de trabalho diferentes, com requisitos regulatórios distintos por trás de cada um.

Eu não tinha separado isso antes. “Finanças regulamentadas na Dusk” parece, de fora, uma única capacidade, mas a infraestrutura por trás é muito mais granular.

O que eu estou observando agora é se essa separação regulatória também aparece na arquitetura real do produto.

A emissão nativa na Dusk exige, fundamentalmente, um fluxo de trabalho diferente para levar um ativo regulamentado já existente para a rede?
Verificado
A deter $DUSK9.7 USDT
@Dusk_Foundation Após o aviso, um provedor Dusk pode mover 10% do seu stake para Rewards, mas os tokens não são queimados. Essa foi a parte que eu não esperava. O mecanismo de soft-slashing (punição suave) do Dusk finalizado é incrementado com falhas consecutivas. N falhas significa que N × 10% do stake é movido para o saldo de Rewards do mesmo nó, enquanto o provedor é excluído do consenso por N epochs. Então a penalidade não é simplesmente “seus tokens desaparecem”. O stake permanece com o mesmo provedor. O que muda é quanto dele continua ativo para o consenso. Há outro detalhe que achei ainda mais interessante. A contagem de falhas não é reiniciada apenas porque a suspensão termina. A Dusk diz que o aviso e a contagem de falhas são redefinidos quando o provedor realmente obtém um reward ao produzir um bloco ou votar com sucesso. Então não é esperar que restaura o registro. É participar com sucesso. A redução do stake ativo também pode continuar em direção ao mínimo de 1.000 DUSK da rede. Comecei a pensar sobre soft slashing de forma diferente depois de ler isso. É menos sobre tirar os tokens de alguém e mais sobre reduzir progressivamente o peso ativo e a elegibilidade de um provedor que continua falhando. Isso torna a recuperação de falhas repetidas intencionalmente mais difícil do que simplesmente esperar o fim de uma suspensão? @Dusk_Foundation #dusk $DUSK {spot}(DUSKUSDT)
@Dusk

Após o aviso, um provedor Dusk pode mover 10% do seu stake para Rewards, mas os tokens não são queimados.

Essa foi a parte que eu não esperava.

O mecanismo de soft-slashing (punição suave) do Dusk finalizado é incrementado com falhas consecutivas. N falhas significa que N × 10% do stake é movido para o saldo de Rewards do mesmo nó, enquanto o provedor é excluído do consenso por N epochs.

Então a penalidade não é simplesmente “seus tokens desaparecem”.

O stake permanece com o mesmo provedor. O que muda é quanto dele continua ativo para o consenso.

Há outro detalhe que achei ainda mais interessante. A contagem de falhas não é reiniciada apenas porque a suspensão termina. A Dusk diz que o aviso e a contagem de falhas são redefinidos quando o provedor realmente obtém um reward ao produzir um bloco ou votar com sucesso.

Então não é esperar que restaura o registro. É participar com sucesso.

A redução do stake ativo também pode continuar em direção ao mínimo de 1.000 DUSK da rede.

Comecei a pensar sobre soft slashing de forma diferente depois de ler isso. É menos sobre tirar os tokens de alguém e mais sobre reduzir progressivamente o peso ativo e a elegibilidade de um provedor que continua falhando.

Isso torna a recuperação de falhas repetidas intencionalmente mais difícil do que simplesmente esperar o fim de uma suspensão?

@Dusk #dusk $DUSK
Verificado
#dusk $DUSK Achei que uma transação rápida do DuskEVM fosse basicamente uma transação já liquidada. Então encontrei um aviso na documentação do Dusk que me fez repensar essa suposição. O DuskEVM separa a inclusão da transação da liquidação. Uma transação pode ser incluída rapidamente em um bloco de L2, mas isso não significa que o estado resultante já tenha sido liquidado de volta na Dusk L1. Essas duas etapas se conectam por meio de batching, compromissos de estado e provas de falha. {future}(DUSKUSDT) O detalhe que achei mais interessante é que o @Dusk_Foundation explicitamente diz às aplicações que movem valor entre o DuskEVM e a Dusk L1 que NÃO devem inferir finalidade apenas a partir do tempo decorrido. Isso parece óbvio depois de ler, mas na verdade é uma distinção de design importante. “Confirmada rapidamente” e “segura para tratar como liquidada” não são necessariamente a mesma coisa. Para uma aplicação que movimenta valor real, usar um temporizador como atalho poderia significar agir na inclusão enquanto o processo de liquidação entre camadas ainda não está completo. Então fico com uma pergunta: Qual status exato de protocolo uma aplicação deve tratar como autoritativo antes de liberar valor através do limite DuskEVM ↔ Dusk L1?
#dusk $DUSK

Achei que uma transação rápida do DuskEVM fosse basicamente uma transação já liquidada.

Então encontrei um aviso na documentação do Dusk que me fez repensar essa suposição.

O DuskEVM separa a inclusão da transação da liquidação.

Uma transação pode ser incluída rapidamente em um bloco de L2, mas isso não significa que o estado resultante já tenha sido liquidado de volta na Dusk L1. Essas duas etapas se conectam por meio de batching, compromissos de estado e provas de falha.


O detalhe que achei mais interessante é que o @Dusk explicitamente diz às aplicações que movem valor entre o DuskEVM e a Dusk L1 que NÃO devem inferir finalidade apenas a partir do tempo decorrido.

Isso parece óbvio depois de ler, mas na verdade é uma distinção de design importante.

“Confirmada rapidamente” e “segura para tratar como liquidada” não são necessariamente a mesma coisa.

Para uma aplicação que movimenta valor real, usar um temporizador como atalho poderia significar agir na inclusão enquanto o processo de liquidação entre camadas ainda não está completo.

Então fico com uma pergunta:

Qual status exato de protocolo uma aplicação deve tratar como autoritativo antes de liberar valor através do limite DuskEVM ↔ Dusk L1?
Protocol / wallet status
67%
Elapsed time
0%
L2 confirmation
33%
Not sure
0%
3 Votos • Votação encerrada
$BMT acabei de passar por um reset brutal. De ~$0.013 → $0.0436, a BMT entregou uma grande ruptura. Então veio o outro lado da operação: ~50% de queda a partir do topo. Agora começa a parte interessante. No gráfico de 1H, $0.0208–$0.0220 é a zona-chave. Se essa área se mantiver e a BMT recuperar: → $0.025 → $0.027–0.028 → $0.030 então a correção pode estar formando uma base em vez de encerrar a tendência. Mas se $0.0208 romper com volume, eu ficaria de olho em $0.018–$0.019 em seguida. O volume também conta uma história interessante: após a ruptura explosiva, o volume vem esfriando de forma bem significativa. Então eu não estou perguntando: “Será que a BMT vai a $0.10?” A melhor pergunta é: “A BMT consegue construir uma mínima mais alta?” Essa resposta vem primeiro. #BMT #Bubblemaps
$BMT acabei de passar por um reset brutal.

De ~$0.013 → $0.0436, a BMT entregou uma grande ruptura.

Então veio o outro lado da operação:

~50% de queda a partir do topo.

Agora começa a parte interessante.

No gráfico de 1H, $0.0208–$0.0220 é a zona-chave.

Se essa área se mantiver e a BMT recuperar:

→ $0.025
→ $0.027–0.028
→ $0.030

então a correção pode estar formando uma base em vez de encerrar a tendência.

Mas se $0.0208 romper com volume, eu ficaria de olho em $0.018–$0.019 em seguida.

O volume também conta uma história interessante: após a ruptura explosiva, o volume vem esfriando de forma bem significativa.

Então eu não estou perguntando:

“Será que a BMT vai a $0.10?”

A melhor pergunta é:

“A BMT consegue construir uma mínima mais alta?”

Essa resposta vem primeiro.

#BMT #Bubblemaps
Esta pode ser uma SEMANa MUITO importante para o cripto. 👀 Não por causa de um único evento. Mas porque inflação + petróleo + geopolítica estão atingindo o mercado ao mesmo tempo. 🇺🇸 Terça-feira Vendas de Casas Existentes 🔥 Quarta-feira EUA CPI + Relatório do Mercado de Petróleo da AIE ⚠️ Quinta-feira EUA PPI 🇺🇸 Sexta-feira Confiança do Consumidor de Michigan A parte interessante? O CPI → PPI vêm um em sequência ao outro. Se a inflação vier mais quente do que o esperado, as expectativas de corte de juros podem voltar a ser empurradas novamente. E, com a situação EUA–Irã ainda influenciando o petróleo e o Estreito de Ormuz, o mercado tem mais uma variável de inflação para acompanhar. Para o cripto, isso importa. Inflação mais quente + petróleo mais alto = potencialmente condições de liquidez mais difíceis. Inflação mais amena + menor pressão = um cenário muito mais amigável para ativos de risco. Então eu estou observando uma coisa acima de tudo: O que acontece com as expectativas de inflação após o CPI de quarta-feira? Porque esta semana pode nos dizer muito sobre o próximo grande movimento em $BTC 👀 Qual é o seu palpite? CPI quente ou CPI frio?
Esta pode ser uma SEMANa MUITO importante para o cripto. 👀

Não por causa de um único evento.

Mas porque inflação + petróleo + geopolítica estão atingindo o mercado ao mesmo tempo.

🇺🇸 Terça-feira Vendas de Casas Existentes

🔥 Quarta-feira EUA CPI + Relatório do Mercado de Petróleo da AIE

⚠️ Quinta-feira EUA PPI

🇺🇸 Sexta-feira Confiança do Consumidor de Michigan

A parte interessante?

O CPI → PPI vêm um em sequência ao outro.

Se a inflação vier mais quente do que o esperado, as expectativas de corte de juros podem voltar a ser empurradas novamente.

E, com a situação EUA–Irã ainda influenciando o petróleo e o Estreito de Ormuz, o mercado tem mais uma variável de inflação para acompanhar.

Para o cripto, isso importa.

Inflação mais quente + petróleo mais alto = potencialmente condições de liquidez mais difíceis.

Inflação mais amena + menor pressão = um cenário muito mais amigável para ativos de risco.

Então eu estou observando uma coisa acima de tudo:

O que acontece com as expectativas de inflação após o CPI de quarta-feira?

Porque esta semana pode nos dizer muito sobre o próximo grande movimento em $BTC 👀

Qual é o seu palpite?

CPI quente ou CPI frio?
🚀 $HEI JUST WENT PARABOLIC 🚀 0.1362 → 0.4906 em horas. Energia de principal valorização certificada. 📍 Agora: $0.4327 🟢 Suporte: $0.3524 (última base de consolidação) 🔴 Resistência: $0.4906 (ATH local, acabou de tocar) 🎯 Alvo se romper: $0.55–$0.60 Esse é o tipo de movimento que faz ou quebra uma carteira. Estou de olho na região de $0.3524 como um falcão; se perder isso, esfria rápido. NFA, DYOR. 👀 {spot}(HEIUSDT)
🚀 $HEI JUST WENT PARABOLIC 🚀

0.1362 → 0.4906 em horas. Energia de principal valorização certificada.

📍 Agora: $0.4327

🟢 Suporte: $0.3524 (última base de consolidação)
🔴 Resistência: $0.4906 (ATH local, acabou de tocar)
🎯 Alvo se romper: $0.55–$0.60

Esse é o tipo de movimento que faz ou quebra uma carteira. Estou de olho na região de $0.3524 como um falcão; se perder isso, esfria rápido.

NFA, DYOR. 👀
@babylonlabs_io Uma frase na documentação dos Trustless Bitcoin Vaults (TBV) mudou completamente a forma como eu pensei sobre liquidação entre múltiplos vaults. Eu estava procurando entender o que acontece quando uma única posição de empréstimo é garantida por múltiplos vaults. Eu esperava que a liquidação fosse proporcional. Se três vaults garantissem uma mesma posição de empréstimo, eu assumiria que cada vault contribuiria com sua parte do colateral que está sendo confiscado. Em vez disso, a documentação descreve algo muito mais específico. Quando múltiplos vaults dão suporte a uma única posição de empréstimo, a TBV confisca um prefixo da lista de vaults ordenada, parando assim que houver colateral suficiente tomado para satisfazer a meta de confisco. Eu realmente pausar e reli essa frase novamente. O mecanismo não é “retirar um pouco de cada vault”. É “retirar vaults da frente de uma lista ordenada até que a meta seja atingida”. Isso imediatamente me fez pensar como essa lista ordenada é construída. A documentação explica a regra do confisco, mas nesta página não explica o que determina a ordem. A ordem é baseada em quando os vaults são criados? Existe alguma outra regra de protocolo envolvida? Os tomadores conseguem influenciá-la antes de abrir uma posição? O mecanismo de liquidação está documentado. A construção da lista ordenada é a parte que eu ainda estou tentando entender, porque parece fundamental para como posições com múltiplos vaults se comportam na prática. @babylonlabs_io #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io

Uma frase na documentação dos Trustless Bitcoin Vaults (TBV) mudou completamente a forma como eu pensei sobre liquidação entre múltiplos vaults.

Eu estava procurando entender o que acontece quando uma única posição de empréstimo é garantida por múltiplos vaults.

Eu esperava que a liquidação fosse proporcional. Se três vaults garantissem uma mesma posição de empréstimo, eu assumiria que cada vault contribuiria com sua parte do colateral que está sendo confiscado.

Em vez disso, a documentação descreve algo muito mais específico.

Quando múltiplos vaults dão suporte a uma única posição de empréstimo, a TBV confisca um prefixo da lista de vaults ordenada, parando assim que houver colateral suficiente tomado para satisfazer a meta de confisco.

Eu realmente pausar e reli essa frase novamente.

O mecanismo não é “retirar um pouco de cada vault”.

É “retirar vaults da frente de uma lista ordenada até que a meta seja atingida”.

Isso imediatamente me fez pensar como essa lista ordenada é construída. A documentação explica a regra do confisco, mas nesta página não explica o que determina a ordem.

A ordem é baseada em quando os vaults são criados? Existe alguma outra regra de protocolo envolvida? Os tomadores conseguem influenciá-la antes de abrir uma posição?

O mecanismo de liquidação está documentado. A construção da lista ordenada é a parte que eu ainda estou tentando entender, porque parece fundamental para como posições com múltiplos vaults se comportam na prática.

@BabylonLabs_io

#baby $BABY
Verificado
@babylonlabs_io Eu abri a documentação mais recente dos Cofres de Bitcoin sem Confiança (TBV) da Babylon esperando passar mais tempo entendendo o BitVM3. Em vez disso, encontrei o fluxo de resgate sendo explicado através do BABE quase imediatamente. Isso me levou à seção de Pesquisa para entender por quê. O artigo identifica uma das maiores limitações práticas do BitVM3: aproximadamente 42 GiB de armazenamento off-chain por circuito cifrado. O BABE é introduzido para lidar com essa restrição, alegando uma redução de cerca de 1000× nas necessidades de armazenamento, preservando ao mesmo tempo os baixos custos de verificação on-chain do BitVM3. Eu entrei achando que a parte mais difícil do TBV seria a criptografia em si. Saí pensando que o maior desafio talvez seja tornar essa criptografia suficientemente prática para operar. Se esses ganhos de eficiência se mantiverem até a produção, eles podem importar bem além do artigo de pesquisa. Requisitos menores de armazenamento poderiam reduzir um dos custos operacionais por trás do empréstimo nativo garantido por Bitcoin via TBV, tornando o protocolo mais viável para ser executado em escala. Uma frase também me chamou atenção: “preservando as economias on-chain do BitVM3”. Eu não acho que isso seja suficiente para concluir que o BABE substitui completamente o BitVM3. Parece mais uma evolução na mesma direção. O que fica claro, porém, é que alguém que está aprendendo sobre TBV hoje é apresentado ao BABE primeiro. Isso mudou como eu li a documentação. Em vez de perguntar se o Bitcoin consegue verificar essas provas, agora estou mais interessado no que os engenheiros da Babylon veem como o próximo gargalo prático depois que a sobrecarga de armazenamento é reduzida dramaticamente. @babylonlabs_io #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io

Eu abri a documentação mais recente dos Cofres de Bitcoin sem Confiança (TBV) da Babylon esperando passar mais tempo entendendo o BitVM3. Em vez disso, encontrei o fluxo de resgate sendo explicado através do BABE quase imediatamente.

Isso me levou à seção de Pesquisa para entender por quê.

O artigo identifica uma das maiores limitações práticas do BitVM3: aproximadamente 42 GiB de armazenamento off-chain por circuito cifrado. O BABE é introduzido para lidar com essa restrição, alegando uma redução de cerca de 1000× nas necessidades de armazenamento, preservando ao mesmo tempo os baixos custos de verificação on-chain do BitVM3.

Eu entrei achando que a parte mais difícil do TBV seria a criptografia em si. Saí pensando que o maior desafio talvez seja tornar essa criptografia suficientemente prática para operar.

Se esses ganhos de eficiência se mantiverem até a produção, eles podem importar bem além do artigo de pesquisa. Requisitos menores de armazenamento poderiam reduzir um dos custos operacionais por trás do empréstimo nativo garantido por Bitcoin via TBV, tornando o protocolo mais viável para ser executado em escala.

Uma frase também me chamou atenção: “preservando as economias on-chain do BitVM3”. Eu não acho que isso seja suficiente para concluir que o BABE substitui completamente o BitVM3. Parece mais uma evolução na mesma direção. O que fica claro, porém, é que alguém que está aprendendo sobre TBV hoje é apresentado ao BABE primeiro.

Isso mudou como eu li a documentação. Em vez de perguntar se o Bitcoin consegue verificar essas provas, agora estou mais interessado no que os engenheiros da Babylon veem como o próximo gargalo prático depois que a sobrecarga de armazenamento é reduzida dramaticamente.

@BabylonLabs_io #baby $BABY
Verificado
@babylonlabs_io Eu esperava que o modelo de confiança nos Trustless Bitcoin Vaults (TBV) fosse simples. Ao ler a documentação do Babylon, cheguei à seção que lista no que um depositante confia. Ela cita a rede Bitcoin, o script Bitcoin coassinado criado na criação do cofre, a rede Ethereum e a aplicação-alvo. Eu realmente pensei que essa era a visão completa. Então uma frase logo abaixo disso me fez parar e reler a página. A documentação acrescenta que, além das próprias cadeias, a confiança residual ainda reside na governança do protocolo e nos multi-sigs de resposta a emergências, descrevendo-os como redes de segurança transitórias que o protocolo pode aposentar com o tempo. Na mesma página, o Babylon também explica que um depositante não precisa de uma federação de signatários para cooperar ao resgatar BTC pelo caminho de resgate pretendido pelo protocolo. Ler essas duas afirmações em conjunto mudou a forma como eu entendo a palavra “trustless”. Eu não interpreto isso como “todas as suposições de confiança já desapareceram”. Eu entendo como um protocolo que documenta claramente as suposições de confiança que ainda existem hoje, enquanto desenha o sistema para que essas suposições possam se tornar menores com o tempo. Na verdade, aprecio mais essa abordagem do que fingir que a jornada já terminou. Saber onde a confiança restante está localizada é tão importante quanto saber onde ela já foi removida. A parte que mais me deixa curioso agora é qual é o marco que o Babylon considera para aposentar essas redes de segurança transitórias. Isso é impulsionado por governança, maturidade técnica, auditorias de segurança ou alguma combinação dos três? @babylonlabs_io #baby $BABY {future}(BABYUSDT)
@BabylonLabs_io

Eu esperava que o modelo de confiança nos Trustless Bitcoin Vaults (TBV) fosse simples.

Ao ler a documentação do Babylon, cheguei à seção que lista no que um depositante confia. Ela cita a rede Bitcoin, o script Bitcoin coassinado criado na criação do cofre, a rede Ethereum e a aplicação-alvo. Eu realmente pensei que essa era a visão completa.

Então uma frase logo abaixo disso me fez parar e reler a página.

A documentação acrescenta que, além das próprias cadeias, a confiança residual ainda reside na governança do protocolo e nos multi-sigs de resposta a emergências, descrevendo-os como redes de segurança transitórias que o protocolo pode aposentar com o tempo.

Na mesma página, o Babylon também explica que um depositante não precisa de uma federação de signatários para cooperar ao resgatar BTC pelo caminho de resgate pretendido pelo protocolo.

Ler essas duas afirmações em conjunto mudou a forma como eu entendo a palavra “trustless”.

Eu não interpreto isso como “todas as suposições de confiança já desapareceram”. Eu entendo como um protocolo que documenta claramente as suposições de confiança que ainda existem hoje, enquanto desenha o sistema para que essas suposições possam se tornar menores com o tempo.

Na verdade, aprecio mais essa abordagem do que fingir que a jornada já terminou. Saber onde a confiança restante está localizada é tão importante quanto saber onde ela já foi removida.

A parte que mais me deixa curioso agora é qual é o marco que o Babylon considera para aposentar essas redes de segurança transitórias. Isso é impulsionado por governança, maturidade técnica, auditorias de segurança ou alguma combinação dos três?

@BabylonLabs_io #baby $BABY
Verificado
$93 versus mais de $15.000. Essa comparação me fez parar enquanto lia a Seção 3 das Trustless Bitcoin Vaults (TBV), whitepaper da @babylonlabs_io Eu tentava responder a uma pergunta prática: quanto custa, na realidade, contestar uma reivindicação inválida? O artigo compara dois projetos. Na arquitetura atual das TBV, ele estima que uma transação de desafio do Bitcoin mainnet custa cerca de US$ 93. Na abordagem anterior do BitVM2, o custo equivalente era de mais de US$ 15.000. Isso representa uma redução de aproximadamente 170×. A parte interessante não é apenas o número. É o que mudou para tornar isso possível. Em vez de verificar a prova ZK diretamente no Bitcoin, o projeto atual usa um processo de desafio com circuito garbled que revela um segredo apenas quando uma reivindicação inválida é contestada. O artigo afirma que reduzir a quantidade de trabalho on-chain é o que torna taxas de segurança menores viáveis na prática. Isso mudou a forma como eu li o desenho. A grande virada não foi apenas tornar as disputas minimizadas de confiança. Foi torná-las baratas o suficiente para se tornarem práticas para empréstimos lastreados nativamente em Bitcoin. A próxima coisa que estou observando é se esses custos estimados continuam próximos da realidade à medida que as TBV avançam além dos testes. Se as taxas das transações do Bitcoin subirem acentuadamente durante períodos de grande congestionamento da rede, as premissas econômicas por trás do processo de disputa ainda se sustentam? #baby $BABY {future}(BABYUSDT)
$93 versus mais de $15.000.

Essa comparação me fez parar enquanto lia a Seção 3 das Trustless Bitcoin Vaults (TBV), whitepaper da @BabylonLabs_io

Eu tentava responder a uma pergunta prática: quanto custa, na realidade, contestar uma reivindicação inválida?

O artigo compara dois projetos. Na arquitetura atual das TBV, ele estima que uma transação de desafio do Bitcoin mainnet custa cerca de US$ 93. Na abordagem anterior do BitVM2, o custo equivalente era de mais de US$ 15.000. Isso representa uma redução de aproximadamente 170×.

A parte interessante não é apenas o número. É o que mudou para tornar isso possível.

Em vez de verificar a prova ZK diretamente no Bitcoin, o projeto atual usa um processo de desafio com circuito garbled que revela um segredo apenas quando uma reivindicação inválida é contestada. O artigo afirma que reduzir a quantidade de trabalho on-chain é o que torna taxas de segurança menores viáveis na prática.

Isso mudou a forma como eu li o desenho. A grande virada não foi apenas tornar as disputas minimizadas de confiança. Foi torná-las baratas o suficiente para se tornarem práticas para empréstimos lastreados nativamente em Bitcoin.

A próxima coisa que estou observando é se esses custos estimados continuam próximos da realidade à medida que as TBV avançam além dos testes. Se as taxas das transações do Bitcoin subirem acentuadamente durante períodos de grande congestionamento da rede, as premissas econômicas por trás do processo de disputa ainda se sustentam?

#baby $BABY
Inicia sessão para explorar mais conteúdos
Junta-te a utilizadores de criptomoedas de todo o mundo na Binance Square
⚡️ Obtém informações úteis e recentes sobre criptomoedas.
💬 Com a confiança da maior exchange de criptomoedas do mundo.
👍 Descobre perspetivas reais de criadores verificados.
E-mail/Número de telefone
Mapa do sítio
Preferências de cookies
Termos e Condições da Plataforma