Minh Nhat Builder

Quanto mais eu procuro entender o Dusk e o staking, mais percebo que esta parte é ainda mais digna de atenção do que a própria história de privacidade. Atualmente, para fazer stake é necessário no mínimo 1.000 DUSK, levando cerca de 1-2 epochs para ativar. O protocolo prevê emitir 500M DUSK em 36 anos, com redução de emissão de 50% a cada 4 anos
No começo, eu quase não prestei atenção a esses números. Mas quanto mais eu observo como tudo foi organizado, mais interessante isso fica. @Dusk não só protege o consenso como também aparece no staking, no gas e no settlement quando o ecossistema $DUSK se expande
Comparado com a atualização do whitepaper de novembro de 2024, a arquitetura atual do Dusk mudou significativamente. Naquela época, Moonlight e Phoenix ainda ficavam responsáveis por transações públicas e privacidade em finanças reguladas.Até junho de 2025, o Dusk passou a ser dividido em três partes: DuskDS para settlement e data availability, DuskEVM para apps de EVM, e DuskVM para aplicações que precisam de privacidade
Eu vejo que o staking pode ter um significado diferente quando o Dusk entra em uma fase com mais atividades práticas. Quando EVM e VM começarem a ter usuários, um token pode ser usado em várias camadas da rede ao mesmo tempo.
Claro, por enquanto eu só estou colocando essa hipótese na mesa
Eu também prestei bastante atenção no Stake Abstraction porque ele abre a possibilidade de contratos tratarem automaticamente o stake; assim, pode dar suporte a modelos como staking pool ou estratégias de operação automática diretamente na rede
Ainda assim, eu não sei em que medida a atividade atual de #dusk reflete de fato a necessidade de uso real. Parte é aplicação, parte é apenas staking e infraestrutura — ainda não há dados suficientes para separar claramente
Se você tiver dados on-chain mais detalhados, eu adoraria dar uma olhada para confrontar com o que estou observando e entender melhor o que a atividade prática na rede está realmente refletindo

Passei algum tempo analisando a Seção 6 da documentação técnica de @Dusk e saí com mais perguntas do que respostas.

Estranhamente, acho que isso é um bom sinal.

O que chamou minha atenção não foi apenas a PVM ou o modelo de execução baseado em WASM. Foi o quanto do comportamento central da rede do Dusk parece estar sendo empurrado para contratos.

Transfer lida com $DUSK transfers, taxas de validação e de execução. Stake gerencia DUSK bloqueado, o estado de staking e os saques. Peças futuras como Zedger e Clock empurram ainda mais lógica para contratos.

Isso me fez repensar uma suposição.

Eu inicialmente olhei para a PVM principalmente como uma forma leve e modular de executar contratos inteligentes. Mas a pergunta mais profunda talvez não seja o quão limpo o VM os executa.

É quem controla os contratos dos quais a rede cada vez mais depende.

Se um contrato importante virar um gargalo de segurança, como ele é atualizado ou substituído?

Quem realmente tem autoridade para mudá-lo?

E o quão descentralizado é esse controle, na prática?

Essas perguntas importam mais para mim agora do que simplesmente saber que #Dusk tem uma VM baseada em WASM.

A parte interessante da arquitetura pode ser menos sobre o que os contratos podem fazer e mais sobre o que acontece quando a rede começa a depender deles para um comportamento crítico.

Meu próximo passo é aprofundar como esses contratos do sistema — tanto os de gênesis quanto os futuros — são governados, atualizados e protegidos.

Tenho a sensação de que é aí que meu entendimento atual de Dusk vai ou se sustentar — ou mudar bastante.
$TMX $XRP #KazakhstanCutsOilOutputForecastTo96MTons #JapanNoAdditionalOilReserveReleaseInSepOct #SamsungSKHynixLeveragedETFsPostFirstMonthlyOutflow #ThailandToExpandSECDigitalAssetProbePowers

Ontem de manhã, eu basicamente passei quase todo o tempo “brincando” com o novo testnet DuskEVM da @Dusk , em vez de fazer algo mais útil.

O testnet subiu em 10/8, e o que mais se fala até agora é “já ter suporte a Solidity e Hardhat”. Ok, isso é bem legal, mas, sendo bem sincero, não é exatamente isso que me faz parar e ficar de olhos fixos quando estou rolando o feed.

O que mais me chamou atenção foi como a #dusk lida com settlement. O contract roda no DuskEVM, e o sequencer fica encarregado da execução; mas o batcher manda os dados das transações para o DuskDS na forma de blobs. Depois, é o proposer que grava o state commitment por cima disso. Em termos simples: a execução acontece no DuskEVM, enquanto a finalidade fica “ancorada” na base layer. O gas é pago com $DUSK , mas antes é preciso fazer bridge do DUSK do DuskDS para conseguir fazer o deploy.

Isso ficou girando na minha cabeça. Para começar a escrever Solidity no DuskEVM, o dev teve que trazer DUSK de verdade via bridge antes. Para mim, esse detalhe torna a experiência da rede mais real e palpável — em vez de ficar só no campo teórico.

Acabei de dar uma olhada rápida no explorer do testnet e vi que o contrato já apareceu lá há alguns dias. Uma rede nova funcionando por apenas seis dias e já tendo tanta atividade, na minha opinião, não é pouca coisa.

Eu ainda não parei de aprofundar se esse modelo de settlement-anchoring vai ter um papel grande na forma como ativos como NPEX vão operar no EVM no futuro, ou se eu só estou olhando um padrão familiar do OP Stack e atribuindo a ele um significado demais.

Por enquanto, eu estou mais inclinado para a primeira hipótese, mas ainda não estou seguro o bastante para concluir.

Será que alguém já colocou contract no DuskEVM, ou todo mundo ainda está travado na etapa de ler docs como eu?
$UAI $MarsCoin #BitcoinRises23.6%Weekly #TinFed #TheoDõiFOMC

@Dusk @Dusk $DUSK #dusk
Eu costumava pensar que privacidade em uma blockchain significava aceitar menos transparência.

Se você quisesse privacidade, tinha que abrir mão da visibilidade.
Se você quisesse conformidade, tinha que aceitar que tudo se tornaria público.

Então eu me aprofundei no modelo de transações de @Dusk e um detalhe me fez parar.

O que chamou minha atenção não foi a narrativa de privacidade em si, mas como Moonlight e Phoenix trabalham juntas.

Moonlight pode fornecer transparência para conformidade, enquanto Phoenix usa ZK para proteger dados sensíveis como saldos e valores de transações.

No começo, vi isso como mais um mecanismo de privacidade.

Mas quanto mais eu olhava, mais eu percebia que a ideia real é separar verificabilidade de visibilidade.

Uma instituição pode provar o que os reguladores precisam verificar sem expor toda a sua posição financeira ou estratégia de negociação ao mercado.

Isso me faz repensar a abordagem de #Dusk .

Talvez o futuro da blockchain institucional não seja uma transparência total ou uma anonimidade total, mas uma privacidade controlada.

Ainda estou pensando:

Se a privacidade se tornar verificável sem estar totalmente visível, essa é a ponte que traz instituições para o cripto — ou uma concessão da visão original do cripto, que era sem permissão?

$DUSK

Ao novo aprender sobre DeFi de taxa fixa, eu achei o rendimento bastante simples: se for alto, chama atenção; se for baixo, quase não importa. Mas quando o RWA começou a aparecer com o papel de colateral, meu olhar mudou. Nesse momento, a taxa de juros também passa a refletir, em certa medida, como o mercado precifica os ativos por trás do empréstimo.

O que mais me prendeu em @TermMax foi o jeito como cada mercado pode formar seu próprio “piso” de empréstimo. Quando o RWA é usado como colateral e atrelado a um prazo fixo, liquidez, qualidade do ativo e até a volatilidade podem gerar diferenças. Se esses dados forem suficientemente densos no tempo, @TermMax pode construir uma base de medição de crédito onchain — em vez de apenas virar um lugar que gera APY adicional.

Eu também quero ver mais uma coisa: os usuários realmente ficam ou não. Uma recompensa alta não necessariamente significa demanda sustentável. Vou observar se os lenders continuam a fornecer capital, se as taxas se ajustam quando os incentivos diminuem e se os tomadores voltam em vários prazos. Liquidez baixa também deixa a taxa parecer atraente — especialmente quando a maior parte das negociações vem de um grupo pequeno.

Eu teria uma visão melhor de @TermMax se a atividade de empréstimo mantiver um ritmo consistente, se a taxa de juros refletir de forma adequada as características de cada tipo de colateral e se a liquidez estiver bem distribuída entre diferentes termos. Caso contrário, se o que está sendo “contado” for mais do que o que está realmente acontecendo, eu vou manter a cautela.

Para mim, uma curva de juros bonita não é suficiente. Eu quero rastrear de onde o dinheiro de verdade está vindo.
#termmax $XRP $BLESS $BTW #SamsungToAnnounceNewShareholderReturnPlanFriday #BitcoinBestWeekSinceMarch2023 #TinFed #SpotGoldHitsHighestSinceMay15

Antes, eu imaginava a conversão de FT de um jeito bem direto: um empréstimo sendo liquidado, o detentor de FT recebe um token de dívida (debt token) e então a negociação é encerrada. Eu achava que seria uma etapa de pagamento simples quando chegasse o vencimento.

Mas a documentação de @TermMax já traz uma solução para quando o empréstimo não é liquidado como previsto. Se, ao final do liquidation window, a dívida ainda existir ou tiver sido apenas parcialmente processada, a entrega física (physical delivery) acontecerá automaticamente. Essa parte dos ativos é tratada imediatamente dentro do mecanismo de conversão, sem que o usuário precise fazer qualquer etapa adicional.

O ponto que vale destacar é que o detentor de FT pode receber outros tipos de ativos diferentes do caso em que o empréstimo é liquidado integralmente. Nesse momento, o pool pode incluir tanto o debt token quanto o(s) token(s) de ativos dados em garantia (collateral) que ainda restaram. A parcela desses ativos que a @TermMax distribui é feita na proporção de FT que cada pessoa possui em relação à oferta total de FT.

Em outras palavras, a taxa de conversão 1:1 entre FT e debt token só reflete o cenário em que tudo ocorre conforme o planejado. Quando há problemas no processo de liquidação do empréstimo, o detentor de FT recebe a parte correspondente do valor a partir do pool, e a quantidade desses ativos pode mudar de acordo com o resultado do processamento antes da data de vencimento.

Isso me deixa curioso sobre um detalhe diferente: antes do vencimento, o detentor de FT consegue saber, com uma certa clareza, qual parte do valor dele está vinculada ao debt token e qual parte vem do token de collateral? 🧐
#termmax $XRP $COLLECT $ON
#GrayscaleFilesToListZcashTrustOnNYSEArca #TinFed #USJoblessClaimsFallTo206000 #WalmartFalls7%

#binancep2pantoan @Binance Vietnam
Antes eu só ficava alerta com ordens que pareciam estar atrasadas ou que não concluíam o pagamento. Depois de algum tempo observando, percebi que existe outro cenário que também pode fazer o usuário perder a cautela: no meio do processo, a outra parte de repente fornece uma informação nova para receber o dinheiro, ou seja, mudar a conta de pagamento. O motivo que eles dão muitas vezes não parece nada de estranho, como “a conta anterior deu problema”. Mas o ponto que me chamou atenção é que os dados da ordem deixaram de ser os mesmos. Eu consultei a Ordem original para confirmar: quem é o parceiro, qual é o valor da transação e para onde o dinheiro seria enviado

À primeira vista, isso parece bastante plausível, mas apenas uma mensagem solicitando a troca da conta já torna tudo mais difícil de verificar. Para mim, o aspecto importante está justamente nisso: faz com que eu precise parar e revisar do zero quem é o destinatário, o valor e a forma de pagamento

Na minha opinião, uma abordagem melhor não é desconfiar imediatamente da outra parte, e sim verificar as informações que foram alteradas antes de prosseguir. A Binance também orienta os usuários a escolherem métodos de pagamento aceitos e conferirem para garantir que as informações da conta correspondam ao que a transação exige. Mas isso só faz sentido quando os dados novos ainda são compatíveis com a ordem original e eu consigo validar. Se eu não tiver certeza, eu prefiro interromper a transação e usar o Appeal, caso a situação precise de tratamento adicional

Ainda fico pensando em quando uma mudança é apenas algo inconveniente e em quando ela se torna um sinal de alerta. Talvez esse seja um ponto que eu deva continuar observando em transações futuras
$XRP $COLLECT $ON #TinFed #GrayscaleFilesToListZcashTrustOnNYSEArca #WalmartFalls7%

$DUSK @Dusk
Certa vez, ouvi uma colega contar sobre o procedimento de transferir dinheiro entre duas contas abertas em lugares diferentes. Ela achava que bastaria fazer uma operação nesta conta para que a outra recebesse algo equivalente. Quando chegou a hora de devolver o dinheiro, o processo voltou a exigir mais uma etapa de verificação no local da transação original.

Essa história me fez pensar em como o @Dusk € é transferido de um lado para o outro entre a Dusk L1 e a DuskEVM Testnet.

Eu costumava imaginar que as duas direções funcionariam de forma semelhante: enviar da Dusk L1 faria o DUSK aparecer na carteira DuskEVM que foi vinculada. Mas a direção de saque é totalmente diferente. O comando começa na DuskEVM; depois, é preciso voltar para @Dusk L1 para provar o withdrawal e finalizar. Assim, além das taxas do local de origem, o usuário ainda gera mais duas cobranças na L1.

O que achei particularmente relevante não é o número de etapas, e sim a lógica por trás. Um withdrawal só pode continuar quando o status da rede foi atualizado, o proof atingiu as condições necessárias e as etapas de verificação relacionadas foram concluídas. Por isso, a orientação do #dusk sugere que o usuário verifique diretamente o status na Web Wallet, em vez de depender apenas do tempo de espera.

Ainda quero saber se esses dois passos realmente reforçam a segurança do fechamento da transação ou se, sem querer, acabam deixando o usuário ainda mais dependente de verificar o progresso e tratar cada etapa por conta própria.
$XRP $ON #GrayscaleFilesToListZcashTrustOnNYSEArca #TinFed #USJoblessClaimsFallTo206000 #WalmartFalls7%

#termmax @TermMax
Fico pensando o tempo todo se alavancagem precisa necessariamente caminhar junto com liquidação e, com o TermMax Alpha Options, a resposta parece ser diferente em relação à maioria das abordagens.

Isso não é uma redução de alavancagem para evitar liquidação. É uma oportunidade para verificar se o prêmio fixo realmente consegue transformar o downside em uma perda definida com antecedência.

O que eu consigo realmente verificar é o valor do prêmio a pagar, o payoff na posição long/short e o prejuízo máximo da posição. Também posso analisar o mecanismo pelo qual o depositante recebe o prêmio para fornecer liquidez, porque isso é, na prática, um teste para ver se este modelo consegue alocar risco entre os dois lados — e não apenas fazer a alavancagem parecer mais “segura”.

O que eu ainda não sei é como o sistema funcionará sob volatilidade forte e liquidez real, em vez de em um ambiente controlado. A pergunta é: se o downside é limitado teoricamente, isso de fato gera uma melhor experiência de gestão de risco quando o mercado fica volátil?

Estou acompanhando se os usuários realmente optam por pagar um prêmio em troca de uma perda máxima claramente definida.
$DOS $ACE $HEMI
#CryptoRally #FOMCWatch

#binancep2pantoan @Binance Vietnam
Quando uma transação P2P dura tempo suficiente com uma mesma pessoa, a familiaridade às vezes nos faz perder a atenção.

No começo eram apenas alguns Orders; depois, 5 Orders, 10 Orders… Tudo parecia dar certo: pagamento rápido, troca sem obstáculos e nunca aconteceu nenhum problema. Aos poucos… a cautela inicial foi dando lugar a um sentimento de segurança. Então, num dia, o Merchant sugeriu: “Da próxima vez a gente conversa pelo Telegram ou Zalo, lá eu consigo te dar um preço bem melhor”.

Sinceramente, eu entendo por que tanta gente facilmente acena com a cabeça. Já negociei bastante, e nas vezes anteriores deu tudo certo; além disso, desta vez o preço parece vantajoso. Mas eu sempre me lembro: confiar em alguém é uma coisa; garantir a segurança da transação atual é outra.

Cada Order P2P da Binance tem as informações da Order, método de pagamento, Order ID, Order Chat, histórico, Appeal e Escrow. Quando a transação é levada para fora, aquela camada de proteção que vem com a Order deixa de existir. A intimidade, às vezes, nos faz negligenciar a regra: mudar para Zalo, Telegram, pular a etapa de verificação, até mesmo fazer Release mais cedo só porque nas vezes anteriores não deu problema. Por isso, mesmo que o Merchant já tenha negociado comigo várias vezes, eu mantenho a regra: a transação deve sempre ficar dentro da Order, e cada pagamento precisa ser verificado novamente.

Um bom histórico não significa que a transação atual não precise ser verificada.

E quando eu vendo, eu só confio no saldo real exibido no app do banco antes de fazer Release. Sem Zalo, Telegram ou prints.

Eu confio no histórico, mas não descuido da transação atual. Porque no P2P, às vezes o problema não vem da desconfiança, e sim do momento em que perdemos a cautela.
$DOS $ACE #TheoDõiFOMC

Eu normalmente quero entender como uma rede é construída antes de me preocupar com tokens ou ecossistemas. Na Dusk Network, a primeira coisa que chamou minha atenção foi a arquitetura, que é bem claramente orientada para privacidade em aplicações financeiras.

No começo, eu via o “blockchain de privacidade” da Dusk de forma bem simples. Eu achava que o foco era apenas não revelar dados das transações, mas, quanto mais eu lia a documentação, mais eu percebia que o escopo era muito mais amplo — indo de smart contracts confidenciais até o padrão Confidential Security Contract (XSC).

Perceber isso me fez enxergar a Dusk de outra forma.

Para mim, a pergunta que vale a pena está menos em “até que ponto o blockchain pode proteger dados?” e mais em como criar aplicações financeiras que consigam manter em sigilo parte das informações, mas com o sistema por trás ainda executando as regras necessárias.

Eu acho que este é o problema central para o qual a Dusk está se direcionando, desempenhando o papel de uma Layer-1.

Eu quero entender mais a fundo como o XSC lida com problemas financeiros em múltiplas camadas. Quais dados só serão permitidos para alguns participantes verem, quais dados ainda precisam ser provados para todo mundo e como o limite entre esses dois lados será tratado?

Eu ainda não acho que tenha visto o quadro completo dessa arquitetura. Então, em vez de concluir cedo, eu quero continuar lendo e verificando mais. @Dusk #dusk $DUSK $ACE $DOS #CryptoRally #FOMCWatch #UAESaysItDetectedTwoIranianBallisticMissiles #ToyotaFinanceLaunchesTokenizedBondForRetail

#termmax @TermMax
Voltei aos docs do TermMax mais uma vez, desta vez com foco em entender como o “fixed-rate” realmente muda o modo como empréstimos e lending funcionam no DeFi.

No começo, o que me chamou a atenção foi apenas a possibilidade de tomar ou emprestar com uma taxa que já fica definida. Mas, quanto mais eu fui investigando a fundo, mais fui me envolvendo com o que acontece por trás desse mecanismo.

Passei a me perguntar como o TermMax mantém a taxa estável o bastante quando o mercado muda continuamente. Se a liquidez for fragmentada de forma abrupta, como isso afeta as posições? E quando as options também ficam dentro do sistema, como o protocolo evita que os riscos fiquem sobrepostos?

Depois disso, fui olhar para o governance por outro ângulo.

Um protocolo pode ser descentralizado em nível de tecnologia, mas o poder de decisão real ainda pode se concentrar em um grupo bem pequeno. Eu ainda não tenho dados suficientes para determinar como o TermMax está distribuindo o poder, então essa parte continua sendo uma grande incógnita para mim.

Também quero analisar com mais cuidado a camada de segurança. O smart contract pode ter bugs, mas isso não é o fim da história. As pressões vindas do mercado, oracle, liquidez e liquidação — cada uma delas pode gerar um tipo diferente de risco.

Quanto mais leio, mais eu deixo de ver o TermMax apenas pelo prisma de “fixed-rate DeFi”. Comecei a me interessar mais por até que ponto uma blockchain consegue fornecer estabilidade e previsibilidade para produtos financeiros.

Na sua opinião, qual é a peça mais importante na infraestrutura do TermMax?
$EDEN $ACE $DOS #CryptoRally #FOMCWatch #UAESaysItDetectedTwoIranianBallisticMissiles #ToyotaFinanceLaunchesTokenizedBondForRetail

#binancep2pantoan @Binance Vietnam
O comprador que eu costumava conhecer agora se tornou um estranho.

As vezes anteriores que negociei com esse comprador não tiveram nenhum problema, então hoje de manhã eu fiquei mais descuidado do que o normal. Até eu verificar o valor recebido, e vi que ele vinha de um banco completamente diferente dos anteriores. A conta nova tinha o mesmo nome do remetente, mas eles não tinham avisado nada antes.

Eu parei e perguntei diretamente no chat antes de continuar. No fim, era algo bem simples: eles tinham adicionado outra conta bancária e às vezes usavam aquela. Mas, se eu não tivesse perguntado, eu teria ignorado esse detalhe com muita facilidade, só porque já estava acostumado a negociar com eles.

Foi aí que eu percebi: reconhecer o rosto não significa que já foi verificado.

Como sempre, eu abri o aplicativo do banco para confirmar o recebimento em vez de confiar em um print de tela, mesmo sendo alguém que já tinha negociado comigo muitas vezes. Talvez eles nunca falsificassem provas. Mas, para mim, negociação não pode se basear apenas nas duas palavras: “talvez”.

Um histórico de transações tranquilas deixa a gente relaxar; enquanto as etapas de verificação no começo, na verdade, não têm a intenção de gerar uma sensação de confiança, e sim de manter um rastro das transações caso seja necessário. Então, após cada negociação — como de costume — eu ainda guardo o Order ID e todo o trecho do chat.
$EDEN $ACE $KII #VIXFallsTo2026Low #DollarHits3MonthLow

@Dusk $DUSK #dusk
O dia todo eu só encontrei o STOX quando fui olhar novamente para @Dusk ; agora ele já tem um nome novo: @Dusk Trade. Há um ponto neste projeto que me faz ficar por aqui: o Dusk Trade anunciou um plano para aproximar o mercado privado das PME em 15/8

Staking: Mais de 30% do total de tokens está atualmente em staking, enquanto o APR gira em torno de 27%.

Acesso: O mecanismo de selective disclosure permite verificar endereço ou elegibilidade sem revelar a identidade. A abordagem de privacidade é bem interessante, mas o escopo de participação ainda está limitado a alguns parceiros e grupos de ativos específicos.

#dusk Trade: No momento, os usuários só podem se inscrever na lista de espera; a plataforma ainda não está aberta para todo mundo.

Esse ponto me deixou bastante curioso.

A parte da privacidade talvez não precise de um intermediário, mas participar do mercado ainda precisa passar por uma etapa de avaliação.

Eu já tentei fazer um pouco de stake para testar. Mas fazer stake de tokens não significa que você já pode negociar (trade). Um lado está relacionado à privacidade; o outro está relacionado à elegibilidade. Não me preocupo muito em enfatizar ZK aqui. O que eu quero saber é quem terá vagas na fase inicial e quais requisitos eles precisam cumprir.

Alguém já conseguiu acesso depois de ficar na waitlist?

Se só puder escolher um, na sua opinião, em que ponto o $DUSK Trade precisa se destacar primeiro: cobertura de usuários, nível de segurança, quantidade de ativos ou barreiras para participar?
#CryptoRally #FOMCWatch

#termmax @TermMax Antes de analisar profundamente esta questão, eu sempre pensei que o TGE era o momento mais importante para avaliar um token.

Naquela época, eu nunca tinha realmente verificado se o protocolo já tinha um produto e atividade real antes do token aparecer.

Portanto, decidi voltar e pesquisar o $TMX com cuidado antes da data de TGE em 25/08/2026.

O resultado foi mais nuançado do que eu esperava.

Havia um ponto que correspondia ao que eu pensava: a avaliação inicial do TMX ainda dependeria fortemente do listing e da narrativa no TGE.

Mas o que me surpreendeu foi que a TermMax construiu o protocolo antes do token aparecer. Infraestrutura de taxa fixa, implantação multi-chain e grandes integrações de DeFi já estavam em vigor antes do TGE.

Em vez de o TGE ser o momento em que um projeto começa a criar valor, os dados mostraram que a TermMax já tinha tração: mais de $90M de TVL, segundo os números da equipe, mais de 1,5M de carteiras registradas e mais de 90K de DAU.

O problema real não é o TGE.

É saber se o TMX consegue transformar a atividade real do protocolo em utilidade sustentável e captura de taxas.

Do ponto de vista técnico, o TMX tem uma oferta total fixa de 1 bilhão de tokens, circulação inicial de cerca de 20% e tanto a equipe quanto os investidores têm um cliff de 12 meses. A utilidade está ligada à governança, staking e taxas do protocolo.

Se os usuários só vierem para farmar XP, AP, MP antes do TGE e depois saírem, o TVL e a atividade podem diminuir.

Mas se os usuários continuarem a usar produtos de taxa fixa, a geração de taxas e a retenção poderão se tornar a base para o valor de longo prazo do TMX.

Isso muda completamente a forma como devemos olhar para o TGE da TermMax.

Ao olhar para trás, percebi que abordei essa questão partindo da suposição de que tokenomics e TGE eram o centro, em vez de primeiro verificar os dados.

O processo de pesquisa não me fez pensar que estava tudo bem ou que estava tudo errado

Ele só me fez perceber que o problema era mais nuançado do que eu tinha imaginado

Portanto, a minha perspectiva sobre o TMX também mudou

Eu ainda quero ver a TermMax provar geração de taxas e retenção de usuários após o TGE
$ACE $GPS $PORTAL

#binancep2pantoan Antes de analisar este problema com cuidado, eu sempre achei que, se a contraparte tivesse uma boa taxa de conclusão e um histórico de negociação sólido, eu poderia me sentir mais seguro ao lidar com uma ordem P2P.

Naquela época, eu nunca tinha realmente verificado o valor que eu recebia antes de liberar, quando havia uma pequena discrepância. Então, decidi verificar algo bem básico: se o valor que realmente entrou na conta correspondia ao valor da ordem.

O resultado acabou sendo mais sutil do que eu esperava.

Havia um ponto que correspondia ao que eu tinha pensado: a taxa de conclusão da contraparte e a quantidade de ordens ainda eram úteis para avaliar um trader.

Mas o que me surpreendeu foi que essa informação não podia substituir a checagem do valor realmente recebido.

O problema real não era saber se o comprador era confiável ou se estava insistindo porque “estava com pressa”.

O ponto era se o dinheiro era realmente suficiente ou não.

Se o valor ainda estivesse faltando, então, não importa o quão confiável fosse a contraparte, eu ainda não deveria liberar até que o valor restante fosse transferido integralmente.

Ao olhar para trás, percebi que abordei esse problema pela reputação da contraparte e pela notificação de pagamento, em vez de verificar primeiro o valor real.

Talvez eu devesse ter verificado meu saldo bancário mais cedo, em vez de assumir que uma notificação de pagamento significava que o dinheiro já era suficiente.

Isso só me fez perceber que o problema real ficava mais claro: se o dinheiro não for suficiente, não libere.

A pressa não significa que esteja errado. Mas vale sempre a pena contar duas vezes.@Binance Vietnam $ACE $GPS $PORTAL
#IsraelStrikesLebanonKillsHezbollahCommander #CardanoSplitsDijkstraUpgradeIntoTwoPhases #SECCancelsCryptoRulemakingMeeting #CMESeptemberHikeOddsFallTo30.6%

Eu revisei a tabela de distribuição de recompensas da Dusk e os termos de queima de tokens me surpreenderam. O gerador de blocos recebe 70% das recompensas de cada bloco diretamente, além de mais até 10% atrelados a algo chamado certificate credits. Qualquer parte desses 10% adicionais que não for exigida será queimada em vez de ser redistribuída.

Os documentos nunca definem realmente o que conta como um credit. Eu conferi várias vezes pensando que estivesse ignorando alguma página vinculada, mas essa seção apenas aponta e segue em frente.

Essa lacuna me fez prestar atenção mais do que provavelmente deveria. Um mecanismo de queima acoplado a um indicador de participação não definido é diferente de mecanismos de queima por cronograma ou ativados por governança, que a maioria dos projetos normalmente menciona. O restante da alocação é relativamente simples. 10% para o fundo de desenvolvimento, 5% para validação, 5% para ratificação.

A emissão funciona de forma programada, decrescendo ao longo de 36 anos, reduzindo pela metade a cada quatro anos, e ficando limitada a 500 milhões de novos DUSK sobre os 500 milhões da oferta inicial já emitida. Comparado a essa curva, qualquer quantidade que seja queimada por bloco parece pequena.

No entanto, após milhares de blocos com níveis de conclusão do certificate inconsistentes, isso já não parece insignificante. Nada aqui muda a forma como eu me posiciono. Só muda o que estou acompanhando nos dados de recompensas atuais.
@Dusk $DUSK #dusk $KII $DOS
#IsraelStrikesLebanonKillsHezbollahCommander #CardanoSplitsDijkstraUpgradeIntoTwoPhases #SECCancelsCryptoRulemakingMeeting #CMESeptemberHikeOddsFallTo30.6%

#binancep2pantoan @Binance Vietnam
Antes de olhar com cuidado, eu sempre achei que o Binance P2P era principalmente protegido por um Escrow — o cripto fica bloqueado, as duas partes negociam e existe uma Apelação quando algo dá errado.

Naquela época, eu nunca tinha realmente verificado o que acontece quando uma negociação entra em disputa. Eu decidi voltar e descobrir o que realmente torna uma transação P2P segura.

O resultado não foi tão simples quanto eu imaginava.

O Escrow é, de fato, uma camada importante de proteção. Mas o que me surpreendeu é que o Escrow não consegue contar a história do que realmente aconteceu entre duas pessoas.

Quando há uma discordância, o problema deixa de ser apenas técnico. Ele se torna uma questão de verdade e evidência.

Em vez de ver o P2P apenas como um mercado com Escrow, comecei a enxergá-lo como um sistema de coordenação.

O Escrow mantém os ativos.
O Chat mantém o contexto.
A Apelação mantém o processo.
A evidência ajuda a determinar a verdade.

O problema não é apenas quantas camadas de proteção o Binance tem, mas se os usuários continuam dentro dessas camadas.

Se eles saem do Chat interno, migram para o Telegram ou Zalo, confiam em um print em vez de checar a conta bancária ou se apressam para liberar, os próprios usuários estão se afastando da infraestrutura criada para protegê-los.

Relembrando, eu percebi que eu tinha pensado “Escrow = segurança”, em vez de analisar todo o processo.

A segurança no P2P é uma combinação de tecnologia, evidência, processo e disciplina do usuário.

Uma boa infraestrutura não é algo que torna cada transação simples.

É algo que te ajuda a descobrir o que realmente aconteceu quando a transação deixa de ser simples.
$KII $AIO $MarsCoin
#LMECopperStocksFall42DaysLongestSince2014 #SP500TopsRecord7800 #USToPressNationsToPickUSOrChinaAICoalition #SP500EarningsBeatExpectations

Há uma coisa que sempre volto ao explorar @Dusk : se a conformidade realmente precisa ser negociada em troca de privacidade, e toda a lógica de design está em como o Citadel 2 separa “comprovar que foi verificado” de “revelar a pessoa por trás disso”. O fluxo começa com o License Provider verificando o usuário fora da cadeia e assinando os atributos necessários. A partir daí, o usuário cria uma prova de conhecimento zero para provar que possui uma licença válida que foi assinada e registrada na blockchain; é essa a parte que acho mais interessante.

A prova ocorre por meio da criptografia sem revelar a chave da carteira, os atributos ou a licença específica, e é aí que a questão da privacidade é realmente testada. A política do serviço sempre existe em segundo plano, aguardando que o Service Provider decida quais provedores são confiáveis, quais atributos são aceitos e se a sessão ainda é válida. Por fim, o contrato apenas confirma que a prova é válida e registra uma sessão pública. Na blockchain, tudo o que resta é a evidência de que uma credencial válida foi utilizada.

O que eu ainda não sei é como esse mecanismo funcionará quando a política mudar, quando o provedor emitir uma credencial incorreta ou quando uma sessão antiga ainda estiver válida em vez das condições ideais. A questão é se a criptografia realmente elimina a necessidade de revelar a identidade do controle de acesso ou se apenas desloca a confiança para o emissor e para a interpretação da credencial. Estou acompanhando como #dusk $DUSK
lida com o limite entre prova criptográfica e política de serviço quando as finanças regulamentadas realmente começam a usá-la. $AIO $KII
#LMECopperStocksFall42DaysLongestSince2014 #SP500TopsRecord7800 #USToPressNationsToPickUSOrChinaAICoalition #SP500EarningsBeatExpectations

#binancep2pantoan @Binance Vietnam
Antes de olhar mais a fundo para esta questão, eu sempre pensei que o trading P2P era principalmente sobre encontrar um comerciante confiável, com um selo, uma alta taxa de conclusão e muitas ordens, o que o tornaria relativamente seguro.

Naquela época, eu nunca havia verificado de fato se esses sinais eram suficientes para confirmar que uma transação era segura.

Então, decidi voltar e verificar o que realmente deve ser considerado como evidência segura ao negociar P2P.

O resultado foi mais nuançado do que eu esperava.

Havia um ponto que correspondia ao que eu tinha pensado: o selo, a alta taxa de conclusão e o histórico de negociações ainda são sinais úteis.

Mas o que me surpreendeu foi que eles não podem substituir a verificação pessoal de que o dinheiro de fato chegou na conta.

A questão real não é se o vendedor tem ou não um selo, mas a diferença entre “acreditar que o dinheiro chegou” e quando o dinheiro realmente aparece.

Uma captura de tela é apenas uma imagem que foi enviada. Ela não prova que o dinheiro realmente entrou na conta.

Se o comprador liberar o cripto antes de verificar por conta própria, essa diferença pode se tornar uma lição muito cara.

Voltando no tempo, percebi que abordei esse problema com base na reputação e nas métricas do comerciante, em vez de verificar com evidências reais.

O processo de pesquisa não me fez pensar que todo comerciante é não confiável.

Ele simplesmente me fez perceber uma coisa com mais clareza: não confie em algo que você não verificou pessoalmente.

Portanto, minha visão sobre o P2P também mudou.

Um selo pode ser um sinal. Uma captura de tela pode ser uma informação. Mas somente quando o dinheiro realmente chega na conta é que eu considero isso como evidência.

E se alguém estiver te pressionando para liberar rapidamente, isso é ainda mais motivo para desacelerar.
$KII $AEON $PRL
#BNBChainToActivatePasteurHardFork #SanDiskRises7%OnRevenueGrowthOutlook #USJulyRetailSalesFall0.6% #SaudiPIFDiscloses154.1MSpaceXShares