AlizehAli
11.2k Publicações
AlizehAli
592 A seguir
24.3K+ Seguidores
8.2K+ Gostaram
Publicações
Tudo
Cotações
Em direto
PINNED
@Dusk A constituição de fundação de um país existe no momento em que o país existe — ninguém a vota para ser criada depois, ela simplesmente já está lá no primeiro dia, e tudo o mais é construído fazendo referência a ela.
Os contratos de gênese do Dusk funcionam da mesma forma. A própria documentação de arquitetura do Dusk descreve dois: o contrato de stake, que acompanha quais provisionadores estão fazendo stake, registra recompensas e habilita ações de stake, unstake e saque de recompensas; e o contrato de transferência, que lida tanto com as transferências Moonlight (públicas) quanto com Phoenix (protegidas/ocultas), paga o gás e atua como o ponto de entrada para a execução das transações diretamente no DuskDS.
Esse papel fundamental se estende além do DuskDS apenas, embora o mecanismo exato varie por camada. O DuskEVM, conforme os próprios documentos do Dusk, move DUSK para gás por meio de sua própria ponte até o L1 do Dusk, e então liquida de volta no DuskDS — um caminho relacionado, mas distinto, do papel direto do contrato de transferência nas transações nativas do DuskDS. As duas rotas levam de volta à mesma camada base; elas não são mecanismos idênticos. #dusk
Autocrítica: a analogia com constituição tem um limite real que vale nomear. A constituição de um país pode ser alterada formalmente por meio de um processo definido. O que eu não encontrei documentado é se os contratos de gênese do Dusk seguem um caminho equivalente, claramente especificado para emendas, ou se "gênese" aqui significa, funcionalmente, algo permanente por design — uma questão real de governança, dado o quanto da pilha multilayer do Dusk em expansão agora depende desses mesmos dois contratos continuarem corretos. $DUSK
DUSK deve ser avaliado com base em se essa ambiguidade é esclarecida antes que esses contratos alguma vez precisem ser atualizados sob pressão real, e não depois.
#dusk $DUSK @Dusk
Os contratos de gênese do Dusk funcionam da mesma forma. A própria documentação de arquitetura do Dusk descreve dois: o contrato de stake, que acompanha quais provisionadores estão fazendo stake, registra recompensas e habilita ações de stake, unstake e saque de recompensas; e o contrato de transferência, que lida tanto com as transferências Moonlight (públicas) quanto com Phoenix (protegidas/ocultas), paga o gás e atua como o ponto de entrada para a execução das transações diretamente no DuskDS.
Esse papel fundamental se estende além do DuskDS apenas, embora o mecanismo exato varie por camada. O DuskEVM, conforme os próprios documentos do Dusk, move DUSK para gás por meio de sua própria ponte até o L1 do Dusk, e então liquida de volta no DuskDS — um caminho relacionado, mas distinto, do papel direto do contrato de transferência nas transações nativas do DuskDS. As duas rotas levam de volta à mesma camada base; elas não são mecanismos idênticos. #dusk
Autocrítica: a analogia com constituição tem um limite real que vale nomear. A constituição de um país pode ser alterada formalmente por meio de um processo definido. O que eu não encontrei documentado é se os contratos de gênese do Dusk seguem um caminho equivalente, claramente especificado para emendas, ou se "gênese" aqui significa, funcionalmente, algo permanente por design — uma questão real de governança, dado o quanto da pilha multilayer do Dusk em expansão agora depende desses mesmos dois contratos continuarem corretos. $DUSK
DUSK deve ser avaliado com base em se essa ambiguidade é esclarecida antes que esses contratos alguma vez precisem ser atualizados sob pressão real, e não depois.
#dusk $DUSK @Dusk
Permanent by design
Should have amendment path
17 hora(s) restante(s)
PINNED
@TermMax Eu assumi que exercitar uma opção lucrativa no TermMax Alpha funcionaria de um jeito fixo — o pagamento cai na sua carteira, pronto, igual a qualquer outra plataforma de opções que eu já tinha usado antes. $BEAT
Essa suposição caiu por terra quando eu li que a TermMax oferece dois caminhos distintos para o exercício. Exercise-Net-Settle fecha a posição e paga o lucro líquido diretamente. Exercise-Delivery, em vez disso, liquida transferindo o ativo subjacente em si, não o dinheiro — no fim, você realmente fica com o token em que sua posição Long ou Short se baseava. #TermMax
Isso muda o que significa “vencer” uma negociação de opções aqui. Na maioria das plataformas, exercer é só realizar um número. No TermMax, exercer pode significar sair com o ativo real, o que importa especificamente para listagens iniciais do Binance Alpha, onde obter exposição real ao token — e não apenas ao movimento do preço — pode ser o objetivo principal da trade. $TUT
O que a documentação não esclarece é se a escolha entre as duas opções está sempre disponível para o trader ou se depende da configuração do mercado específico no momento da liquidação. $ENA
O teste real para o TMX é se os traders de fato entendem que essa escolha existe antes de exercer, ou se simplesmente ficam com a opção que a interface mostra primeiro.
Alguém já usou Exercise-Delivery em vez de Net-Settle, e por quê?
#termmax @TermMax
Essa suposição caiu por terra quando eu li que a TermMax oferece dois caminhos distintos para o exercício. Exercise-Net-Settle fecha a posição e paga o lucro líquido diretamente. Exercise-Delivery, em vez disso, liquida transferindo o ativo subjacente em si, não o dinheiro — no fim, você realmente fica com o token em que sua posição Long ou Short se baseava. #TermMax
Isso muda o que significa “vencer” uma negociação de opções aqui. Na maioria das plataformas, exercer é só realizar um número. No TermMax, exercer pode significar sair com o ativo real, o que importa especificamente para listagens iniciais do Binance Alpha, onde obter exposição real ao token — e não apenas ao movimento do preço — pode ser o objetivo principal da trade. $TUT
O que a documentação não esclarece é se a escolha entre as duas opções está sempre disponível para o trader ou se depende da configuração do mercado específico no momento da liquidação. $ENA
O teste real para o TMX é se os traders de fato entendem que essa escolha existe antes de exercer, ou se simplesmente ficam com a opção que a interface mostra primeiro.
Alguém já usou Exercise-Delivery em vez de Net-Settle, e por quê?
#termmax @TermMax
Verificado
@Dusk Voltei à própria apresentação de arquitetura da Dusk de junho de 2025, e o enquadramento mudou em relação ao posicionamento anterior da Dusk.
Três camadas, segundo a documentação atual da Dusk: DuskDS na base, consenso, settlement, disponibilidade de dados, modelos nativos de transação. DuskEVM por cima, baseado na OP Stack, compatibilidade total com Solidity. DuskVM ao lado, contratos em Rust/WASM executando diretamente na L1 para casos de uso nativos de privacidade. #dusk
O que mudou da evolução anunciada originalmente em 2025 para agora: o DuskVM foi descrito como “em breve” naquele momento. A documentação atual o descreve como infraestrutura em funcionamento, não como item de uma roadmap. Separadamente, as atualizações de 2026 da própria Dusk descrevem que o dApp de securities reguladas da NPEX está sendo implantado ativamente na DuskEVM especificamente — quero ser preciso ao dizer que isso é descrito como um rollout contínuo, e não algo que eu possa confirmar como um lançamento concluído e totalmente operacional ainda. $DUSK
Um detalhe conecta concretamente todas as três camadas, independentemente do status desse rollout: um único token DUSK alimenta todas as camadas, e uma ponte nativa operada por validadores move valor entre elas sem ativos “wrapped” nem custodians.
Ainda é um sistema em evolução, não concluído. A própria documentação da DuskEVM confirma que, no momento, ele roda apenas como sequenciador, sem mempool público ainda — uma limitação específica e datada, situada por baixo de tudo o que está sendo implantado ativamente em cima dele agora.
Se alguém já acompanhou como o rollout da NPEX está, de fato, progredindo em relação a essa arquitetura na prática, eu gostaria de comparar anotações com o que encontrei aqui.
#dusk $DUSK @Dusk
Três camadas, segundo a documentação atual da Dusk: DuskDS na base, consenso, settlement, disponibilidade de dados, modelos nativos de transação. DuskEVM por cima, baseado na OP Stack, compatibilidade total com Solidity. DuskVM ao lado, contratos em Rust/WASM executando diretamente na L1 para casos de uso nativos de privacidade. #dusk
O que mudou da evolução anunciada originalmente em 2025 para agora: o DuskVM foi descrito como “em breve” naquele momento. A documentação atual o descreve como infraestrutura em funcionamento, não como item de uma roadmap. Separadamente, as atualizações de 2026 da própria Dusk descrevem que o dApp de securities reguladas da NPEX está sendo implantado ativamente na DuskEVM especificamente — quero ser preciso ao dizer que isso é descrito como um rollout contínuo, e não algo que eu possa confirmar como um lançamento concluído e totalmente operacional ainda. $DUSK
Um detalhe conecta concretamente todas as três camadas, independentemente do status desse rollout: um único token DUSK alimenta todas as camadas, e uma ponte nativa operada por validadores move valor entre elas sem ativos “wrapped” nem custodians.
Ainda é um sistema em evolução, não concluído. A própria documentação da DuskEVM confirma que, no momento, ele roda apenas como sequenciador, sem mempool público ainda — uma limitação específica e datada, situada por baixo de tudo o que está sendo implantado ativamente em cima dele agora.
Se alguém já acompanhou como o rollout da NPEX está, de fato, progredindo em relação a essa arquitetura na prática, eu gostaria de comparar anotações com o que encontrei aqui.
#dusk $DUSK @Dusk
Verificado
@TermMax Passei algum tempo mapeando a mecânica das opções do TermMax Alpha, esperando o perfil de risco usual de opções abertas.
Não foi isso que encontrei. “Going Long” significa comprar uma call; “Short” significa comprar uma put — ambas contra uma contraparte que a documentação chama de Dual Investment — o vendedor da opção. O “Max Cost” é definido com precisão como o prêmio pago, principalmente denominado em USDT. A liquidação ocorre via Exercise-Net-Settle ou Exercise-Delivery e, em qualquer caso, a perda máxima possível foi fixada no momento em que a posição foi aberta.
Nenhum desses termos parecia especialmente significativo por si só. Mas o contexto de lançamento me fez parar. O TermMax Alpha foi lançado na mainnet da BNB Chain em 12 de novembro de 2025, construído pela Term Structure Labs, apoiado pela Cumberland DRW — uma empresa real de trading institucional, e não apenas um truque de “listagem de token”.
Esse apoio importa porque é isso que o produto realmente resolve. Quando a Binance Alpha lista um novo token, os traders frequentemente esperam semanas antes que contratos perpétuos apareçam em algum lugar. O TermMax Alpha existe especificamente para preencher essa lacuna — exposição alavancada com custo limitado e conhecido, disponível desde o primeiro dia de uma listagem, em vez de semanas depois. #TermMax
O que chamou minha atenção é que isso torna o TermMax Alpha uma infraestrutura realmente sensível ao tempo — sua relevância está ligada à rapidez com que novas listagens da Binance Alpha continuam acontecendo, e não a um recurso estático que fica parado.
Eu ainda não confirmei quantos mercados Alpha ativos estão atualmente em funcionamento, nem o quão apertados são os spreads nas listagens mais novas.
Long ou Short?
#termmax @TermMax
Não foi isso que encontrei. “Going Long” significa comprar uma call; “Short” significa comprar uma put — ambas contra uma contraparte que a documentação chama de Dual Investment — o vendedor da opção. O “Max Cost” é definido com precisão como o prêmio pago, principalmente denominado em USDT. A liquidação ocorre via Exercise-Net-Settle ou Exercise-Delivery e, em qualquer caso, a perda máxima possível foi fixada no momento em que a posição foi aberta.
Nenhum desses termos parecia especialmente significativo por si só. Mas o contexto de lançamento me fez parar. O TermMax Alpha foi lançado na mainnet da BNB Chain em 12 de novembro de 2025, construído pela Term Structure Labs, apoiado pela Cumberland DRW — uma empresa real de trading institucional, e não apenas um truque de “listagem de token”.
Esse apoio importa porque é isso que o produto realmente resolve. Quando a Binance Alpha lista um novo token, os traders frequentemente esperam semanas antes que contratos perpétuos apareçam em algum lugar. O TermMax Alpha existe especificamente para preencher essa lacuna — exposição alavancada com custo limitado e conhecido, disponível desde o primeiro dia de uma listagem, em vez de semanas depois. #TermMax
O que chamou minha atenção é que isso torna o TermMax Alpha uma infraestrutura realmente sensível ao tempo — sua relevância está ligada à rapidez com que novas listagens da Binance Alpha continuam acontecendo, e não a um recurso estático que fica parado.
Eu ainda não confirmei quantos mercados Alpha ativos estão atualmente em funcionamento, nem o quão apertados são os spreads nas listagens mais novas.
Long ou Short?
#termmax @TermMax
Long (call)
75%
Short (put)
0%
Neither, too risky
25%
4 Votos • Votação encerrada
·
--
🎙️ Agora quem é quem e o que é o quê. O que a Binance realmente quer 😂😂
Encerrado
01 h 56 min. 10 seg.
431
0
Função de hash amigável ao SNARK, projetada pela própria equipe da Dusk especificamente para hashing resistente a colisões dentro de circuitos de zero-conhecimento.
Mohsin_Trader_King
·
--
Fiquei com a questão: a documentação do Dusk não responde diretamente com números exatos — duas anotações diferentes do Phoenix podem produzir o mesmo nullifier?
O que posso confirmar com precisão: o próprio repositório do Dusk sobre Phoenix afirma que o nullifier é computado especificamente para que um observador externo não consiga vinculá-lo à anotação de origem. Cada anotação é convertida em hash e inserida como folhas de uma árvore de Merkle de anotações, e gastar uma produz um valor de nullifier determinístico ligado aos dados daquela anotação específica.
A etapa de hashing por baixo disso — tanto na estrutura da árvore de Merkle do Dusk quanto em operações criptográficas mais amplas — usa Poseidon, uma função hash amigável para SNARK, projetada pela própria equipe do Dusk especificamente para hashing resistente a colisões dentro de circuitos de zero conhecimento. Não é um hash genérico reaproveitado “pronto”; é algo construído para este tipo de trabalho de compromisso nativo de ZK.
Mas “resistente a colisões” não é a mesma coisa que “à prova de colisões”. Qualquer função hash, incluindo o Poseidon, carrega uma chance teórica (astronomicamente pequena) de que duas entradas diferentes produzam a mesma saída — isso faz parte da própria ideia de hashing, e não é uma fraqueza específica do Dusk.
O que eu não encontrei nos materiais do próprio Dusk é qualquer número publicado de probabilidade de colisão específico para os parâmetros exatos do Poseidon, nem documentação de testes de colisão dedicados além das propriedades gerais de segurança que o Poseidon herda por design.
Se alguém já viu um relatório de auditoria cobrindo especificamente essa propriedade para a implementação do Dusk, eu gostaria de compará-lo com o que está documentado publicamente.
#dusk $DUSK @Dusk
O que posso confirmar com precisão: o próprio repositório do Dusk sobre Phoenix afirma que o nullifier é computado especificamente para que um observador externo não consiga vinculá-lo à anotação de origem. Cada anotação é convertida em hash e inserida como folhas de uma árvore de Merkle de anotações, e gastar uma produz um valor de nullifier determinístico ligado aos dados daquela anotação específica.
A etapa de hashing por baixo disso — tanto na estrutura da árvore de Merkle do Dusk quanto em operações criptográficas mais amplas — usa Poseidon, uma função hash amigável para SNARK, projetada pela própria equipe do Dusk especificamente para hashing resistente a colisões dentro de circuitos de zero conhecimento. Não é um hash genérico reaproveitado “pronto”; é algo construído para este tipo de trabalho de compromisso nativo de ZK.
Mas “resistente a colisões” não é a mesma coisa que “à prova de colisões”. Qualquer função hash, incluindo o Poseidon, carrega uma chance teórica (astronomicamente pequena) de que duas entradas diferentes produzam a mesma saída — isso faz parte da própria ideia de hashing, e não é uma fraqueza específica do Dusk.
O que eu não encontrei nos materiais do próprio Dusk é qualquer número publicado de probabilidade de colisão específico para os parâmetros exatos do Poseidon, nem documentação de testes de colisão dedicados além das propriedades gerais de segurança que o Poseidon herda por design.
Se alguém já viu um relatório de auditoria cobrindo especificamente essa propriedade para a implementação do Dusk, eu gostaria de compará-lo com o que está documentado publicamente.
#dusk $DUSK @Dusk
Ver tradução
5% goes to the liquidator as their reward for executing the liquidation
Mohsin_Trader_King
·
--
Voltei às documentações de liquidação da TermMax especificamente para rastrear para onde o dinheiro da penalidade realmente vai.
O número é simples: 10% do valor da dívida liquidada, retirado da própria garantia do tomador sempre que a liquidação é acionada. O que é menos óbvio é a divisão — não é um único valor destinado a uma parte. 5% vai para o liquidante como recompensa por executar a liquidação. Os outros 5% são direcionados diretamente para a reserva própria do protocolo.
O que mudou para mim foi perceber que isso não é apenas uma taxa de punição; é uma estrutura de incentivo em duas partes que as documentações enquadram explicitamente em torno da estabilidade do protocolo — projetada para manter o LTV exigido nos empréstimos enquanto dá aos liquidantes um motivo real para agir rapidamente. A fórmula também confirma a ordem de prioridade: primeiro a garantia liquidada cobre a recompensa do liquidante; depois o restante é aplicado à penalidade do protocolo, tudo explicitamente limitado à posição real do tomador — o que significa que matematicamente a penalidade não pode exceder o quanto a garantia do próprio tomador consegue cobrir, independentemente de como a fórmula seja executada.
Vale destacar: as documentações especificam claramente a divisão e o limite, mas não dizem para que a reserva é usada quando se acumula, nem em quais condições ela é sacada.
Próxima coisa que eu verificaria: o quanto essa reserva realmente cresceu em relação ao volume total de liquidações até agora.
#termmax @TermMax $BTW
$RICE
$GPS
O número é simples: 10% do valor da dívida liquidada, retirado da própria garantia do tomador sempre que a liquidação é acionada. O que é menos óbvio é a divisão — não é um único valor destinado a uma parte. 5% vai para o liquidante como recompensa por executar a liquidação. Os outros 5% são direcionados diretamente para a reserva própria do protocolo.
O que mudou para mim foi perceber que isso não é apenas uma taxa de punição; é uma estrutura de incentivo em duas partes que as documentações enquadram explicitamente em torno da estabilidade do protocolo — projetada para manter o LTV exigido nos empréstimos enquanto dá aos liquidantes um motivo real para agir rapidamente. A fórmula também confirma a ordem de prioridade: primeiro a garantia liquidada cobre a recompensa do liquidante; depois o restante é aplicado à penalidade do protocolo, tudo explicitamente limitado à posição real do tomador — o que significa que matematicamente a penalidade não pode exceder o quanto a garantia do próprio tomador consegue cobrir, independentemente de como a fórmula seja executada.
Vale destacar: as documentações especificam claramente a divisão e o limite, mas não dizem para que a reserva é usada quando se acumula, nem em quais condições ela é sacada.
Próxima coisa que eu verificaria: o quanto essa reserva realmente cresceu em relação ao volume total de liquidações até agora.
#termmax @TermMax $BTW
$RICE
$GPS
Verificado
@Dusk Fui procurar o que realmente acontece quando uma prova de conhecimento zero do Phoenix falha na verificação, já que a maioria das explicações para em "a prova é verificada".
A arquitetura do Dusk confirma que a prova precisa demonstrar propriedades específicas em conjunto — a titularidade do comprovante que está sendo gasto, a integridade do saldo entre entradas e saídas e a ausência de gasto duplo — tudo codificado na mesma prova, e não verificado por meio de checagens laterais separadas. $DUSK
Essa é a parte que vale a pena considerar com calma. Se qualquer uma dessas propriedades não for satisfeita, a prova inteira falha como uma única unidade. Não existe um caminho de crédito parcial em que as checagens de saldo passam, mas a titularidade falha silenciosamente.
Rastreie o que isso significa na prática: uma prova rejeitada significa que a transação nem sequer é incluída. O runtime não tenta consertar ou processar parcialmente. A transação simplesmente não acontece, e nada da tentativa fracassada é registrado como mudança de estado. #dusk
O que eu ainda não confirmei, com base nos próprios materiais do Dusk, é se uma prova falha deixa algum rastro em logs da mempool que um operador de nó poderia inspecionar depois, ou se é descartada sem nenhum registro de diagnóstico.
Próxima coisa que eu verificaria: se as ferramentas atuais da carteira do Dusk exibem um motivo específico para uma prova falha, ou apenas uma rejeição genérica, já que essa distinção importa muito para qualquer pessoa que esteja realmente depurando uma transação que não passou.
#dusk $DUSK @Dusk
A arquitetura do Dusk confirma que a prova precisa demonstrar propriedades específicas em conjunto — a titularidade do comprovante que está sendo gasto, a integridade do saldo entre entradas e saídas e a ausência de gasto duplo — tudo codificado na mesma prova, e não verificado por meio de checagens laterais separadas. $DUSK
Essa é a parte que vale a pena considerar com calma. Se qualquer uma dessas propriedades não for satisfeita, a prova inteira falha como uma única unidade. Não existe um caminho de crédito parcial em que as checagens de saldo passam, mas a titularidade falha silenciosamente.
Rastreie o que isso significa na prática: uma prova rejeitada significa que a transação nem sequer é incluída. O runtime não tenta consertar ou processar parcialmente. A transação simplesmente não acontece, e nada da tentativa fracassada é registrado como mudança de estado. #dusk
O que eu ainda não confirmei, com base nos próprios materiais do Dusk, é se uma prova falha deixa algum rastro em logs da mempool que um operador de nó poderia inspecionar depois, ou se é descartada sem nenhum registro de diagnóstico.
Próxima coisa que eu verificaria: se as ferramentas atuais da carteira do Dusk exibem um motivo específico para uma prova falha, ou apenas uma rejeição genérica, já que essa distinção importa muito para qualquer pessoa que esteja realmente depurando uma transação que não passou.
#dusk $DUSK @Dusk
@TermMax Passei algum tempo mapeando o sistema de três tokens da TermMax, e uma linha na documentação reorientou tudo para mim: o Valor do Colateral é igual ao Valor do GT mais o Valor do próprio Empréstimo, onde o Valor do GT é definido como Colateral menos o Valor da Dívida. Os tokens não são apenas três objetos separados; eles são partes de uma única equação que precisa se equilibrar.
FT é um ERC-20, funcionando como um título de cupom zero — 110 FT-USDC resgatam por 110 USDC no vencimento; então, comprá-lo por 100 USDC trava um retorno de 10% ao longo de um período de um ano. Mas os documentos especificam que esse número escala com o vencimento, não fica constante — um FT de 180 dias com o mesmo desconto anualiza para cerca de 20%, não 10%. XT é definido com mais precisão do que eu esperava: não é apenas “a outra metade”; é especificamente o valor presente dos juros que o tomador deve, separado do principal. GT é o invólucro da posição — ERC-721, acompanhando colateral e dívida como uma unidade, limitado pelo MLTV.
O que chamou minha atenção é que o XT não é mero preenchimento: ele é um instrumento financeiro distinto que representa o risco de juros por si só, precificado separadamente do risco do principal do FT. Separar o principal dos juros no nível do token é o que faz a equação de soma zero de todo o sistema funcionar — nenhum valor aparece ou desaparece em lugar nenhum na cadeia. #TermMax
A peça que faltava para mim é a profundidade real do mercado secundário especificamente para o XT, já que ele está precificando algo tão específico quanto o risco de juros de curto prazo sozinho.
"Qual token importa mais para você?"
#termmax
@TermMax
FT é um ERC-20, funcionando como um título de cupom zero — 110 FT-USDC resgatam por 110 USDC no vencimento; então, comprá-lo por 100 USDC trava um retorno de 10% ao longo de um período de um ano. Mas os documentos especificam que esse número escala com o vencimento, não fica constante — um FT de 180 dias com o mesmo desconto anualiza para cerca de 20%, não 10%. XT é definido com mais precisão do que eu esperava: não é apenas “a outra metade”; é especificamente o valor presente dos juros que o tomador deve, separado do principal. GT é o invólucro da posição — ERC-721, acompanhando colateral e dívida como uma unidade, limitado pelo MLTV.
O que chamou minha atenção é que o XT não é mero preenchimento: ele é um instrumento financeiro distinto que representa o risco de juros por si só, precificado separadamente do risco do principal do FT. Separar o principal dos juros no nível do token é o que faz a equação de soma zero de todo o sistema funcionar — nenhum valor aparece ou desaparece em lugar nenhum na cadeia. #TermMax
A peça que faltava para mim é a profundidade real do mercado secundário especificamente para o XT, já que ele está precificando algo tão específico quanto o risco de juros de curto prazo sozinho.
"Qual token importa mais para você?"
#termmax
@TermMax
FT (fixed yield)
67%
XT (interest pricing)
33%
GT (leverage wrapper)
0%
All three together
0%
6 Votos • Votação encerrada
@TermMax Presumi que a liquidação no TermMax significa a mesma coisa que significa em qualquer outro lugar onde usei — atravesse a linha de perigo, perca toda a posição de uma vez, sem meio-termo.
Essa suposição desmoronou quando li a fórmula real. A liquidação é acionada de duas maneiras: o LTV atinge ou ultrapassa o limite de LLTV do mercado, ou o tomador deixa de pagar a parcela de vencimento fixo, o que abre uma janela de liquidação de duas horas, independentemente do preço. $ACE
Aqui está o número que mudou tudo. Se a dívida em aberto excede US$ 10.000, os liquidantes ficam limitados a 50% do valor total da dívida por evento. O colateral máximo liquidável é calculado como o total do colateral multiplicado pela dívida liquidada, dividido pela dívida total — uma razão criada para que o LTV melhore após cada liquidação, em vez de colapsar para zero. A liquidação total só acontece se a dívida cair exatamente para zero, momento em que o colateral restante é devolvido automaticamente ao tomador.
A penalidade é de 10% do valor da dívida liquidada, dividida exatamente pela metade — 5% para o liquidante como recompensa, 5% para o cofre de reserva do protocolo.
O que a documentação não diz é qual parcela das posições reais de fato ultrapassa US$ 10.000 em dívida versus ficar abaixo dessa linha, onde o limite nem sequer se aplicaria. $CLO
O teste real para o TMX é se esse limite de 50% protege de forma significativa os grandes tomadores ou se apenas transforma uma liquidação em duas menores, uma atrás da outra. $CYS
Alguém já acompanhou as contagens de liquidação parcial versus total no TermMax até agora?
#termmax @TermMax
Essa suposição desmoronou quando li a fórmula real. A liquidação é acionada de duas maneiras: o LTV atinge ou ultrapassa o limite de LLTV do mercado, ou o tomador deixa de pagar a parcela de vencimento fixo, o que abre uma janela de liquidação de duas horas, independentemente do preço. $ACE
Aqui está o número que mudou tudo. Se a dívida em aberto excede US$ 10.000, os liquidantes ficam limitados a 50% do valor total da dívida por evento. O colateral máximo liquidável é calculado como o total do colateral multiplicado pela dívida liquidada, dividido pela dívida total — uma razão criada para que o LTV melhore após cada liquidação, em vez de colapsar para zero. A liquidação total só acontece se a dívida cair exatamente para zero, momento em que o colateral restante é devolvido automaticamente ao tomador.
A penalidade é de 10% do valor da dívida liquidada, dividida exatamente pela metade — 5% para o liquidante como recompensa, 5% para o cofre de reserva do protocolo.
O que a documentação não diz é qual parcela das posições reais de fato ultrapassa US$ 10.000 em dívida versus ficar abaixo dessa linha, onde o limite nem sequer se aplicaria. $CLO
O teste real para o TMX é se esse limite de 50% protege de forma significativa os grandes tomadores ou se apenas transforma uma liquidação em duas menores, uma atrás da outra. $CYS
Alguém já acompanhou as contagens de liquidação parcial versus total no TermMax até agora?
#termmax @TermMax
Verificado
@Dusk Dusk se posiciona diante do Ethereum especificamente, já que a maioria das comparações entre cadeias de privacidade costuma recorrer ao Zcash ou ao Monero.
A homepage atual da Dusk declara o objetivo de forma direta: infraestrutura para ativos digitais regulados, confidencial por padrão, com provas de conhecimento zero e visibilidade controlada para auditoria e divulgação regulada. Isso é um enquadramento notavelmente mais afiado do que a postura pública anterior da Dusk, que se concentrava mais em combinar as transações públicas do Moonlight com o modelo de privacidade do Phoenix para finanças reguladas de forma mais ampla, sem enfatizar tanto um contraste direto com a transparência do Ethereum.
O que mudou entre esses enquadramentos vale uma pausa. O padrão do Ethereum — todo saldo, toda chamada, visível para qualquer pessoa — funciona bem para coordenação pública. O DuskEVM da Dusk executa equivalência total de EVM usando as mesmas ferramentas que os desenvolvedores do Ethereum já conhecem, mantendo, por baixo, a postura de Dusk com blindagem por padrão. O modelo de execução não está sendo rejeitado. O padrão de visibilidade está. $DUSK
O próprio site da Dusk lista agora parceiros específicos regulados na UE que estão ativamente construindo com base nesse posicionamento — um provedor licenciado de infraestrutura de mercado sob o Regime Piloto de DLT, além de uma plataforma europeia regulada explorando emissão on-chain diretamente por meio desse enquadramento.
Isso é um movimento institucional real, não apenas mensagem — mas se isso se traduz em migração significativa de desenvolvedores saindo de stacks que priorizam o Ethereum especificamente por causa da questão da transparência é algo que eu não encontrei números de adoção para confirmar de qualquer forma. #dusk
Se alguém tiver acompanhado dados reais de migração ligados especificamente ao argumento da transparência, e não ao discurso mais amplo de conformidade da Dusk, eu gostaria de comparar isso com o que está publicamente nomeado na lista de parceiros da própria Dusk.
#dusk $DUSK @Dusk
A homepage atual da Dusk declara o objetivo de forma direta: infraestrutura para ativos digitais regulados, confidencial por padrão, com provas de conhecimento zero e visibilidade controlada para auditoria e divulgação regulada. Isso é um enquadramento notavelmente mais afiado do que a postura pública anterior da Dusk, que se concentrava mais em combinar as transações públicas do Moonlight com o modelo de privacidade do Phoenix para finanças reguladas de forma mais ampla, sem enfatizar tanto um contraste direto com a transparência do Ethereum.
O que mudou entre esses enquadramentos vale uma pausa. O padrão do Ethereum — todo saldo, toda chamada, visível para qualquer pessoa — funciona bem para coordenação pública. O DuskEVM da Dusk executa equivalência total de EVM usando as mesmas ferramentas que os desenvolvedores do Ethereum já conhecem, mantendo, por baixo, a postura de Dusk com blindagem por padrão. O modelo de execução não está sendo rejeitado. O padrão de visibilidade está. $DUSK
O próprio site da Dusk lista agora parceiros específicos regulados na UE que estão ativamente construindo com base nesse posicionamento — um provedor licenciado de infraestrutura de mercado sob o Regime Piloto de DLT, além de uma plataforma europeia regulada explorando emissão on-chain diretamente por meio desse enquadramento.
Isso é um movimento institucional real, não apenas mensagem — mas se isso se traduz em migração significativa de desenvolvedores saindo de stacks que priorizam o Ethereum especificamente por causa da questão da transparência é algo que eu não encontrei números de adoção para confirmar de qualquer forma. #dusk
Se alguém tiver acompanhado dados reais de migração ligados especificamente ao argumento da transparência, e não ao discurso mais amplo de conformidade da Dusk, eu gostaria de comparar isso com o que está publicamente nomeado na lista de parceiros da própria Dusk.
#dusk $DUSK @Dusk
@Dusk Eu costumava achar que um verificador em Dusk precisava ver os detalhes de uma transação para confirmar que ela era legítima.
Isso não é o que acontece com o Phoenix.
Eu rastreei o que o verificador realmente recebe, em vez dos dados brutos. Os próprios materiais de arquitetura do Dusk confirmam que o Phoenix usa provas de conhecimento zero especificamente para provar a posse de saídas não gastas e impedir gastos duplos — o verificador verifica a prova, não a transação em si.
Hmm.
Então o que está, na prática, dentro dessa prova?
Fiquei pensando nisso por um tempo. O pagador prova conhecimento do caminho até a raiz da árvore de Merkle e conhecimento da abertura do compromisso — ou seja, a prova demonstra matematicamente que a nota existe na árvore e que o pagador realmente sabe o que está dentro dela, sem expor nem o conteúdo da nota nem sua localização para qualquer pessoa que esteja observando.
O ato de gastar em si exige uma Chave Secreta conhecida exclusivamente pelo dono da nota — então, até mesmo a etapa de geração da prova não consegue acontecer sem a única informação que ninguém mais possui.
Isso é uma garantia mais estranha do que parece à primeira vista. O verificador não está confiando na palavra do remetente. Nem está confiando em um terceiro. Ele está confirmando uma afirmação matemática — que a associação à árvore mais o conhecimento do compromisso — é verdadeira, sem nunca reconstruir o que fez isso ser verdade.
Não estou dizendo que isso é uma verificação mais fraca. Se for o caso, se recusar a olhar talvez seja o ponto — o verificador não pode ser enganado por dados que ele nem recebe em primeiro lugar.
Um sistema construído para verificar a associação à árvore e o conhecimento da chave secreta, sem nunca ver valores, ganha mais confiança do que um que verifica olhando diretamente para os dados?
@Dusk #dusk $DUSK
Isso não é o que acontece com o Phoenix.
Eu rastreei o que o verificador realmente recebe, em vez dos dados brutos. Os próprios materiais de arquitetura do Dusk confirmam que o Phoenix usa provas de conhecimento zero especificamente para provar a posse de saídas não gastas e impedir gastos duplos — o verificador verifica a prova, não a transação em si.
Hmm.
Então o que está, na prática, dentro dessa prova?
Fiquei pensando nisso por um tempo. O pagador prova conhecimento do caminho até a raiz da árvore de Merkle e conhecimento da abertura do compromisso — ou seja, a prova demonstra matematicamente que a nota existe na árvore e que o pagador realmente sabe o que está dentro dela, sem expor nem o conteúdo da nota nem sua localização para qualquer pessoa que esteja observando.
O ato de gastar em si exige uma Chave Secreta conhecida exclusivamente pelo dono da nota — então, até mesmo a etapa de geração da prova não consegue acontecer sem a única informação que ninguém mais possui.
Isso é uma garantia mais estranha do que parece à primeira vista. O verificador não está confiando na palavra do remetente. Nem está confiando em um terceiro. Ele está confirmando uma afirmação matemática — que a associação à árvore mais o conhecimento do compromisso — é verdadeira, sem nunca reconstruir o que fez isso ser verdade.
Não estou dizendo que isso é uma verificação mais fraca. Se for o caso, se recusar a olhar talvez seja o ponto — o verificador não pode ser enganado por dados que ele nem recebe em primeiro lugar.
Um sistema construído para verificar a associação à árvore e o conhecimento da chave secreta, sem nunca ver valores, ganha mais confiança do que um que verifica olhando diretamente para os dados?
@Dusk #dusk $DUSK
@TermMax costumava pensar que um empréstimo apenas aparecia como um número parado em algum saldo da conta.
quanto mais eu olhava para como a TermMax realmente estrutura uma posição, menos isso se sustentava.
um tomador bloqueia uma garantia. A TermMax cunha um Gearing Token contra ela, um ERC-721, não um lançamento em um livro-razão. o token da dívida, o token da garantia e a data de vencimento ficam todos fixos no nível do mercado antes mesmo de existir aquele GT.
o próprio GT registra exatamente duas coisas. quanto de garantia está dentro dele. quantos Fixed-Rate Tokens foram cunhados contra aquela garantia, limitados pelo LTV máximo do mercado. um MLTV de 0,8, por exemplo, transforma 1 ETH em até 800 $USDC de dívida cunhável. #TermMax
sem pool compartilhado, sem compensação (netting), sem número misturado em lugar nenhum no design.
releia essa parte de isolamento duas vezes. A TermMax roda 100+ mercados na atualização de março de 2026, cada um isolado dos outros, então um preço ruim de garantia em um mercado nunca toca os GTs que estão em qualquer outro. não é contabilidade. é uma fronteira.
repague diretamente com tokens de dívida ou compre de volta os FTs no mercado aberto e devolva esses. em qualquer caso, o GT fecha e a garantia é liberada, mas ele nunca foi fundido com os números de ninguém desde o início.
assim, tomar empréstimo na TermMax não é um número que cresce ou diminui. é tantos GTs quanto você abriu, cada um carregando sua própria garantia, sua própria dívida, seu próprio vencimento, cada um por si.
o acompanhamento por empréstimo individual deixa o risco mais claro, ou só mais difícil de gerenciar em escala?
@TermMax #termmax
quanto mais eu olhava para como a TermMax realmente estrutura uma posição, menos isso se sustentava.
um tomador bloqueia uma garantia. A TermMax cunha um Gearing Token contra ela, um ERC-721, não um lançamento em um livro-razão. o token da dívida, o token da garantia e a data de vencimento ficam todos fixos no nível do mercado antes mesmo de existir aquele GT.
o próprio GT registra exatamente duas coisas. quanto de garantia está dentro dele. quantos Fixed-Rate Tokens foram cunhados contra aquela garantia, limitados pelo LTV máximo do mercado. um MLTV de 0,8, por exemplo, transforma 1 ETH em até 800 $USDC de dívida cunhável. #TermMax
sem pool compartilhado, sem compensação (netting), sem número misturado em lugar nenhum no design.
releia essa parte de isolamento duas vezes. A TermMax roda 100+ mercados na atualização de março de 2026, cada um isolado dos outros, então um preço ruim de garantia em um mercado nunca toca os GTs que estão em qualquer outro. não é contabilidade. é uma fronteira.
repague diretamente com tokens de dívida ou compre de volta os FTs no mercado aberto e devolva esses. em qualquer caso, o GT fecha e a garantia é liberada, mas ele nunca foi fundido com os números de ninguém desde o início.
assim, tomar empréstimo na TermMax não é um número que cresce ou diminui. é tantos GTs quanto você abriu, cada um carregando sua própria garantia, sua própria dívida, seu próprio vencimento, cada um por si.
o acompanhamento por empréstimo individual deixa o risco mais claro, ou só mais difícil de gerenciar em escala?
@TermMax #termmax
Verificado
@Dusk costumava achar que "divulgação seletiva" era só uma palavra mais suave para transparência.
Fiquei um tempo analisando o design real da Citadel, e não é.
Transparência total — do tipo que a Dusk cria explicitamente contra — significa que cada observador vê todos os atributos vinculados a uma transação ou identidade, quer precise ou não. A Citadel faz algo mais restrito, e eu rastreei a mecânica real: três partes distintas, não duas. Um Usuário solicita uma licença on-chain a um Provedor de Licenças. Uma vez emitida, essa licença permite que o Usuário estabeleça uma conexão privada, off-chain, com um Provedor de Serviço — que verifica a alegação usando apenas o que está armazenado on-chain, sem jamais conhecer a identidade subjacente do Usuário.
Hmm.
Então o que o Provedor de Serviço realmente aprende quando uma verificação passa?
Apenas que aquela alegação é verdadeira — residência, faixa etária, credenciamento, o que quer que a licença cubra. Não os dados subjacentes por trás disso, não qualquer outro atributo que o Usuário possua, não um identificador persistente que vincule essa verificação a uma futura.
Essa é uma promessa bem mais estreita do que a transparência faz parecer. Um sistema totalmente transparente conta tudo para todos, permanentemente, seja relevante ou não. A estrutura de três partes da Citadel faz com que um Provedor de Serviço receba uma única coisa verdadeira, verificada contra um registro on-chain, sem que esse Provedor toque jamais o perfil completo do Usuário.
Não estou dizendo que transparência esteja errada em todo lugar. Coordenação pública realmente se beneficia de todos verem o mesmo livro-razão. Mas ações condicionadas por identidade — provar elegibilidade sem divulgar um perfil completo — exigiam um protocolo com três funções separadas, não duas, para funcionar de verdade.
Provar uma única coisa verdadeira por meio de três funções separadas é uma garantia de privacidade mais forte do que a transparência de "todos veem tudo, então ninguém está escondendo nada"?
@Dusk #dusk $DUSK
Fiquei um tempo analisando o design real da Citadel, e não é.
Transparência total — do tipo que a Dusk cria explicitamente contra — significa que cada observador vê todos os atributos vinculados a uma transação ou identidade, quer precise ou não. A Citadel faz algo mais restrito, e eu rastreei a mecânica real: três partes distintas, não duas. Um Usuário solicita uma licença on-chain a um Provedor de Licenças. Uma vez emitida, essa licença permite que o Usuário estabeleça uma conexão privada, off-chain, com um Provedor de Serviço — que verifica a alegação usando apenas o que está armazenado on-chain, sem jamais conhecer a identidade subjacente do Usuário.
Hmm.
Então o que o Provedor de Serviço realmente aprende quando uma verificação passa?
Apenas que aquela alegação é verdadeira — residência, faixa etária, credenciamento, o que quer que a licença cubra. Não os dados subjacentes por trás disso, não qualquer outro atributo que o Usuário possua, não um identificador persistente que vincule essa verificação a uma futura.
Essa é uma promessa bem mais estreita do que a transparência faz parecer. Um sistema totalmente transparente conta tudo para todos, permanentemente, seja relevante ou não. A estrutura de três partes da Citadel faz com que um Provedor de Serviço receba uma única coisa verdadeira, verificada contra um registro on-chain, sem que esse Provedor toque jamais o perfil completo do Usuário.
Não estou dizendo que transparência esteja errada em todo lugar. Coordenação pública realmente se beneficia de todos verem o mesmo livro-razão. Mas ações condicionadas por identidade — provar elegibilidade sem divulgar um perfil completo — exigiam um protocolo com três funções separadas, não duas, para funcionar de verdade.
Provar uma única coisa verdadeira por meio de três funções separadas é uma garantia de privacidade mais forte do que a transparência de "todos veem tudo, então ninguém está escondendo nada"?
@Dusk #dusk $DUSK
Stronger guarantee
100%
Transparency is simpler
0%
4 Votos • Votação encerrada
O próprio repositório do Dusk afirma que o anulador é calculado especificamente de modo que um observador externo não consiga vinculá-lo a nenhuma nota em particular.
precious Zarmalaa
·
--
O que um anulador realmente impede que aconteça duas vezes
Eu verifiquei o que especificamente um anulador impede na Dusk, já que “impede gastos duplos” é dito sem muita precisão.
Ele impede que a mesma nota blindada seja gasta mais de uma vez — nada mais amplo do que isso.
Eu rastreei como a Dusk faz isso sem revelar qual nota foi gasta. O próprio repositório da Dusk afirma que o anulador é calculado especificamente para que um observador externo não consiga vinculá-lo a nenhuma nota em particular. A rede não verifica a nota em si contra uma lista; ela verifica se este exato anulador já apareceu.
Eu confirmei que a nota não é removida de lugar nenhum depois de ser gasta. Ela permanece registrada na árvore Merkle de notas da Dusk. Apenas o anulador é adicionado a um registro separado, que cresce.
Essa distinção importa. Se as notas fossem excluídas ao serem gastas, eu esperaria que isso vazasse informações de tempo apenas por observar a estrutura diminuir. Manter toda nota no lugar, gasta ou não, elimina esse sinal.
Eu procurei se isso cria algum risco de colisão — duas notas diferentes produzindo acidentalmente o mesmo anulador. Não encontrei nenhum caso documentado disso nos próprios materiais da Dusk, embora a garantia dependa das mesmas suposições criptográficas subjacentes das quais o restante do sistema depende.
Então um anulador na Dusk não é realmente “marcar” uma nota como gasta de um modo visível. Ele está provando que um gasto aconteceu, sem identificar o que foi gasto.
Impedir gastos duplos dessa forma protege mais privacidade do que vale a pena em um armazenamento permanente que cresce indefinidamente?
@Dusk #dusk $DUSK #dusk
Eu verifiquei o que especificamente um anulador impede na Dusk, já que “impede gastos duplos” é dito sem muita precisão.
Ele impede que a mesma nota blindada seja gasta mais de uma vez — nada mais amplo do que isso.
Eu rastreei como a Dusk faz isso sem revelar qual nota foi gasta. O próprio repositório da Dusk afirma que o anulador é calculado especificamente para que um observador externo não consiga vinculá-lo a nenhuma nota em particular. A rede não verifica a nota em si contra uma lista; ela verifica se este exato anulador já apareceu.
Eu confirmei que a nota não é removida de lugar nenhum depois de ser gasta. Ela permanece registrada na árvore Merkle de notas da Dusk. Apenas o anulador é adicionado a um registro separado, que cresce.
Essa distinção importa. Se as notas fossem excluídas ao serem gastas, eu esperaria que isso vazasse informações de tempo apenas por observar a estrutura diminuir. Manter toda nota no lugar, gasta ou não, elimina esse sinal.
Eu procurei se isso cria algum risco de colisão — duas notas diferentes produzindo acidentalmente o mesmo anulador. Não encontrei nenhum caso documentado disso nos próprios materiais da Dusk, embora a garantia dependa das mesmas suposições criptográficas subjacentes das quais o restante do sistema depende.
Então um anulador na Dusk não é realmente “marcar” uma nota como gasta de um modo visível. Ele está provando que um gasto aconteceu, sem identificar o que foi gasto.
Impedir gastos duplos dessa forma protege mais privacidade do que vale a pena em um armazenamento permanente que cresce indefinidamente?
@Dusk #dusk $DUSK #dusk
Verificado
@Dusk foi mantido assumindo elegibilidade em Dusk era algo que você ganhava uma vez e mantinha, como uma insígnia que ficava presa.
na verdade, são três mecanismos separados trabalhando juntos, e qualquer um deles pode tirá-lo.
primeiro: o valor mínimo de aposta. eu confirmei que um provisionador de Dusk precisa ter 1000 DUSK bloqueados; abaixo desse limite, nada mais sobre a aposta importa.
segundo: a maturidade. mesmo uma aposta acima do mínimo precisa ficar por um número fixo de epochs antes que a sortição do Dusk a considere. $DUSK
terceiro, e este é o que eu quase perdi: a penalização. descobri que faltas repetidas não apenas tiram recompensas — cada suspensão consecutiva move um percentual crescente da aposta para o pool de recompensas reivindicáveis, começando em 10% e subindo 10% a cada violação subsequente.
eu rastreei o que acontece quando essa penalização empurra uma aposta para baixo do piso de 1000 DUSK. ela não apenas perde peso na sortição. eu descobri que ela é congelada de forma definitiva — a única maneira de voltar ao Dusk é fazer o unstakes do restante congelado e restake de novo, fresco.
então a elegibilidade não é uma única porta pela qual um provisionador passa uma vez. são três mecanismos separados — um piso, um relógio e uma programação de penalidades — qualquer um deles pode, silenciosamente, desqualificar um provisionador de Dusk que achava que ainda estava ativo. #dusk
colocar elegibilidade em camadas sobre três mecanismos independentes torna o Dusk mais resistente a fraudes, ou apenas torna mais fácil para um provisionador honesto perder o status sem perceber imediatamente por quê?
#dusk $DUSK @Dusk
na verdade, são três mecanismos separados trabalhando juntos, e qualquer um deles pode tirá-lo.
primeiro: o valor mínimo de aposta. eu confirmei que um provisionador de Dusk precisa ter 1000 DUSK bloqueados; abaixo desse limite, nada mais sobre a aposta importa.
segundo: a maturidade. mesmo uma aposta acima do mínimo precisa ficar por um número fixo de epochs antes que a sortição do Dusk a considere. $DUSK
terceiro, e este é o que eu quase perdi: a penalização. descobri que faltas repetidas não apenas tiram recompensas — cada suspensão consecutiva move um percentual crescente da aposta para o pool de recompensas reivindicáveis, começando em 10% e subindo 10% a cada violação subsequente.
eu rastreei o que acontece quando essa penalização empurra uma aposta para baixo do piso de 1000 DUSK. ela não apenas perde peso na sortição. eu descobri que ela é congelada de forma definitiva — a única maneira de voltar ao Dusk é fazer o unstakes do restante congelado e restake de novo, fresco.
então a elegibilidade não é uma única porta pela qual um provisionador passa uma vez. são três mecanismos separados — um piso, um relógio e uma programação de penalidades — qualquer um deles pode, silenciosamente, desqualificar um provisionador de Dusk que achava que ainda estava ativo. #dusk
colocar elegibilidade em camadas sobre três mecanismos independentes torna o Dusk mais resistente a fraudes, ou apenas torna mais fácil para um provisionador honesto perder o status sem perceber imediatamente por quê?
#dusk $DUSK @Dusk
More resistant
100%
Easy to lose status
0%
3 Votos • Votação encerrada
O crepúsculo está construindo em torno de um problema que blockchains transparentes nem sempre conseguem resolver com eficiência.
precious Zarmalaa
·
--
Os Dois Modelos de Transação da DUSK, Luz do Crepúsculo (Moonlight) e Fênix (Phoenix)
Esta noite eu estava verificando um fluxo de transferência simples na testnet da Dusk, alternando entre uma visualização de carteira pública e uma protegida para a mesma quantia de teste. No lado público, tudo apareceu imediatamente: remetente, destinatário e valor. No lado protegido, quase nada foi exibido.
Presumi que eram apenas dois modos de exibição para a mesma transação subjacente. Isso parecia razoável no começo.
Eu estava errado. Moonlight é baseado em contas. Saldos ficam à vista, e uma transferência expõe, por padrão, remetente, destinatário e valor. Phoenix funciona de forma diferente. Os fundos ficam como notas criptografadas. Há uma prova de conhecimento zero por trás disso que apenas confirma que a transação está correta — nada sobre o valor, o remetente ou quais notas foram gastas realmente aparece.
Dois modelos de transação diferentes, não duas visões de um único modelo — e essa distinção é justamente o motivo de compará-los.
O que eu continuei pensando, depois de fechar o laptop e voltar, é que ambos ainda são liquidados pelo mesmo local na Dusk. A DuskDS lida com ambos. O Contrato de Transferência aceita qualquer tipo de payload e o encaminha pela lógica de verificação correspondente, mantendo o estado global da rede consistente de qualquer forma.
A escolha entre Moonlight e Phoenix não é sobre qual cadeia usar. É uma decisão feita por transação, dentro de uma única camada de liquidação, sobre quanto do resto da rede fica com acesso a essas informações.
Eu ainda não sei com que frequência os desenvolvedores optam por um modelo em vez do outro quando um fluxo não exige privacidade estritamente.
Se uma carteira permitir que você escolha por transação, qual modelo você usaria por padrão?
@Dusk #dusk $DUSK #dusk
Esta noite eu estava verificando um fluxo de transferência simples na testnet da Dusk, alternando entre uma visualização de carteira pública e uma protegida para a mesma quantia de teste. No lado público, tudo apareceu imediatamente: remetente, destinatário e valor. No lado protegido, quase nada foi exibido.
Presumi que eram apenas dois modos de exibição para a mesma transação subjacente. Isso parecia razoável no começo.
Eu estava errado. Moonlight é baseado em contas. Saldos ficam à vista, e uma transferência expõe, por padrão, remetente, destinatário e valor. Phoenix funciona de forma diferente. Os fundos ficam como notas criptografadas. Há uma prova de conhecimento zero por trás disso que apenas confirma que a transação está correta — nada sobre o valor, o remetente ou quais notas foram gastas realmente aparece.
Dois modelos de transação diferentes, não duas visões de um único modelo — e essa distinção é justamente o motivo de compará-los.
O que eu continuei pensando, depois de fechar o laptop e voltar, é que ambos ainda são liquidados pelo mesmo local na Dusk. A DuskDS lida com ambos. O Contrato de Transferência aceita qualquer tipo de payload e o encaminha pela lógica de verificação correspondente, mantendo o estado global da rede consistente de qualquer forma.
A escolha entre Moonlight e Phoenix não é sobre qual cadeia usar. É uma decisão feita por transação, dentro de uma única camada de liquidação, sobre quanto do resto da rede fica com acesso a essas informações.
Eu ainda não sei com que frequência os desenvolvedores optam por um modelo em vez do outro quando um fluxo não exige privacidade estritamente.
Se uma carteira permitir que você escolha por transação, qual modelo você usaria por padrão?
@Dusk #dusk $DUSK #dusk
Verificado
#dusk $DUSK
DuskVM em comparação com DuskEVM na Rede DUSK
@Dusk No começo, achei que escolher entre DuskVM e DuskEVM se resumia a linguagem, Rust e WASM versus Solidity com as ferramentas da EVM que todo mundo já usa. Passei mais tempo analisando isso esta noite do que eu esperava, e, em algum momento, deixou de parecer uma escolha de linguagem.
O DuskVM fica bem na base da rede, então ele tem acesso direto às questões de privacidade e às coisas de zero conhecimento nas quais o Dusk é realmente construído. O DuskEVM executa contratos Solidity por meio das ferramentas padrão da EVM, mas ainda assim ele liquida e publica seus dados de volta através da mesma camada DuskDS, pagando gás com o mesmo token DUSK de qualquer forma. Existe uma simetria estranha nisso que eu continuo retomando: caminhos de execução diferentes, mesma liquidação, o mesmo token por baixo dos dois.
Escolher DuskVM não é apenas escolher uma linguagem; é escolher proximidade com as primitivas de privacidade em si. Escolher DuskEVM não é apenas familiaridade; é distância dessas primitivas para ferramentas com as quais a maioria dos desenvolvedores já sabe trabalhar. Essa é uma fricção sutil que a maioria das comparações não passa. #dusk
Há uma terceira camada por baixo de ambas em que eu sempre volto. A documentação do Dusk confirma que o DuskEVM permite que carteiras, bridges e exchanges existentes baseados em EVM se conectem com mudanças mínimas no código, mais rápido do que uma integração nativa exigiria. O DuskVM não oferece um atalho equivalente. As ferramentas precisam ser construídas para ele, do zero, toda vez. $DUSK
Paridade de recursos entre os dois não é garantida apenas porque ambos liquidam pela mesma camada e compartilham um token de gás. O que parece ser opcionalidade na superfície, na verdade, são duas apostas diferentes sobre onde o custo real é pago: adiantado, nas ferramentas, ou mais tarde, no que o ambiente não consegue fazer.
O Dusk está realmente oferecendo uma escolha aos construtores aqui, ou apenas decidindo por eles onde a fricção vai aparecer? @Dusk
DuskVM em comparação com DuskEVM na Rede DUSK
@Dusk No começo, achei que escolher entre DuskVM e DuskEVM se resumia a linguagem, Rust e WASM versus Solidity com as ferramentas da EVM que todo mundo já usa. Passei mais tempo analisando isso esta noite do que eu esperava, e, em algum momento, deixou de parecer uma escolha de linguagem.
O DuskVM fica bem na base da rede, então ele tem acesso direto às questões de privacidade e às coisas de zero conhecimento nas quais o Dusk é realmente construído. O DuskEVM executa contratos Solidity por meio das ferramentas padrão da EVM, mas ainda assim ele liquida e publica seus dados de volta através da mesma camada DuskDS, pagando gás com o mesmo token DUSK de qualquer forma. Existe uma simetria estranha nisso que eu continuo retomando: caminhos de execução diferentes, mesma liquidação, o mesmo token por baixo dos dois.
Escolher DuskVM não é apenas escolher uma linguagem; é escolher proximidade com as primitivas de privacidade em si. Escolher DuskEVM não é apenas familiaridade; é distância dessas primitivas para ferramentas com as quais a maioria dos desenvolvedores já sabe trabalhar. Essa é uma fricção sutil que a maioria das comparações não passa. #dusk
Há uma terceira camada por baixo de ambas em que eu sempre volto. A documentação do Dusk confirma que o DuskEVM permite que carteiras, bridges e exchanges existentes baseados em EVM se conectem com mudanças mínimas no código, mais rápido do que uma integração nativa exigiria. O DuskVM não oferece um atalho equivalente. As ferramentas precisam ser construídas para ele, do zero, toda vez. $DUSK
Paridade de recursos entre os dois não é garantida apenas porque ambos liquidam pela mesma camada e compartilham um token de gás. O que parece ser opcionalidade na superfície, na verdade, são duas apostas diferentes sobre onde o custo real é pago: adiantado, nas ferramentas, ou mais tarde, no que o ambiente não consegue fazer.
O Dusk está realmente oferecendo uma escolha aos construtores aqui, ou apenas decidindo por eles onde a fricção vai aparecer? @Dusk
#dusk $DUSK
@Dusk eu costumava assumir que uma cadeia de privacidade significava que cada transação era protegida por padrão, sem exceções.
então eu li o que o Moonlight realmente faz na Dusk.
Dusk executa dois modelos nativos de transação na mesma camada de liquidação. Moonlight é baseado em conta, público; remetente, destinatário e valor ficam todos visíveis. Phoenix é baseado em notas, protegido; os fundos ficam como notas criptografadas em vez de um saldo em execução, mais próximo de unidades gastáveis do que um total de conta. #dusk
isso é o “por padrão” que mudou a forma como eu li isso, e eu voltei para reler essa seção duas vezes só para ter certeza.
uma única transferência escolhe um modelo ou o outro, nunca uma mistura. enviar DUSK através do Moonlight e ela fica totalmente transparente, feito para fluxos que precisam permanecer observáveis; um cenário de tesouraria ou relatório é o tipo de exemplo para o qual os documentos apontam. enviar por Phoenix e o valor, o remetente e quais notas específicas foram movidas permanecem ocultos, comprovados por provas de conhecimento zero em vez de serem exibidos diretamente, embora uma chave de visualização possa revelar esses mesmos dados ocultos para quem o staker escolher mostrar. $DUSK
um único Contract de Transferência lida com ambos, roteando cada payload para a lógica de verificação correta, mantendo o estado global consistente de qualquer maneira.
então a privacidade aqui não é binária no nível do protocolo também; é uma escolha por transferência, e mesmo a opção protegida tem um caminho documentado para voltar a ficar visível mediante solicitação.
essa escolha fica com o remetente, não com o protocolo.
dar aos usuários uma opção pública enfraquece o argumento de privacidade, ou privacidade opcional e revogável é na verdade um design mais honesto para mercados regulados?
privacidade opcional ainda é privacidade?
@Dusk eu costumava assumir que uma cadeia de privacidade significava que cada transação era protegida por padrão, sem exceções.
então eu li o que o Moonlight realmente faz na Dusk.
Dusk executa dois modelos nativos de transação na mesma camada de liquidação. Moonlight é baseado em conta, público; remetente, destinatário e valor ficam todos visíveis. Phoenix é baseado em notas, protegido; os fundos ficam como notas criptografadas em vez de um saldo em execução, mais próximo de unidades gastáveis do que um total de conta. #dusk
isso é o “por padrão” que mudou a forma como eu li isso, e eu voltei para reler essa seção duas vezes só para ter certeza.
uma única transferência escolhe um modelo ou o outro, nunca uma mistura. enviar DUSK através do Moonlight e ela fica totalmente transparente, feito para fluxos que precisam permanecer observáveis; um cenário de tesouraria ou relatório é o tipo de exemplo para o qual os documentos apontam. enviar por Phoenix e o valor, o remetente e quais notas específicas foram movidas permanecem ocultos, comprovados por provas de conhecimento zero em vez de serem exibidos diretamente, embora uma chave de visualização possa revelar esses mesmos dados ocultos para quem o staker escolher mostrar. $DUSK
um único Contract de Transferência lida com ambos, roteando cada payload para a lógica de verificação correta, mantendo o estado global consistente de qualquer maneira.
então a privacidade aqui não é binária no nível do protocolo também; é uma escolha por transferência, e mesmo a opção protegida tem um caminho documentado para voltar a ficar visível mediante solicitação.
essa escolha fica com o remetente, não com o protocolo.
dar aos usuários uma opção pública enfraquece o argumento de privacidade, ou privacidade opcional e revogável é na verdade um design mais honesto para mercados regulados?
privacidade opcional ainda é privacidade?
Inicia sessão para explorar mais conteúdos