Coloque o Moonlight e o Phoenix de @Dusk lado a lado e fica mais parecido com um arranjo de liquidação em duas camadas: uma camada de contas públicas na lista, outra de um sistema de notas verificável porém sem identificação, compartilhando a mesma disciplina de compensação. Depois de revisar as permissões do contrato e as rotas de migração de fundos, a conclusão é direta — a estrutura risco-retorno é assimétrica desde a origem. Os usuários acham que estão ganhando conveniência em privacidade e conformidade, mas essa conveniência é separada em dois pools de fundos; entre os dois pools, os limites de divulgação são determinados de forma centralizada pelo protocolo.
As contas do Moonlight se baseiam em nonce e saldo público para construir uma conta de liquidação auditável e resistente a replay, bem próxima de reconciliação transacional de uma corretora tradicional. O Phoenix, por sua vez, utiliza notes, nullifier e endereços furtivos para formar notas sem identificação; o número de cancelamento apenas prova que o ticket foi descartado, sem expor o detentor. Aquela frase do whitepaper do Dusk, “duas modelagens são indispensáveis”, quando aterrissa nas cláusulas financeiras vira divulgação em níveis: a camada transparente assume a conformidade e o custo de rastreabilidade; a camada de confusão assume o risco de concentração de anonimato. A profundidade de liquidez e as regras de divulgação de ambos são decididas pelos parâmetros do contrato, e não pelo acordo do usuário. Na prática, o usuário consegue alternar livremente entre privacidade e transparência? Provavelmente é mais como ser empurrado entre dois “tanques” com exposições a risco diferentes, realizando uma configuração passiva.
De onde surgiria o risco de $DUSK ? Provavelmente não viria da validação de assinatura, mas de instabilidades na fronteira entre as duas camadas. Se o conjunto de anonimato encolher, a intensidade de privacidade do Phoenix cai junto; se as movimentações entre a camada transparente e a camada de confusão forem sistematicamente marcadas, a chamada divulgação seletiva logo se degrada em rastreamento efetivo e completo. Some-se a isso a entrada de novos recursos que derruba o fluxo abaixo do limiar de manutenção, ou transferências de grande porte de endereços concentradas entre os dois pools — e o destino desse arranjo de liquidação em duas camadas muito provavelmente será um evento de crédito de um produto estruturado. A única diferença é: aqui o crédito é endossado por um algoritmo, mas o algoritmo nunca assume obrigação de liquidação.
No meu estágio atual, não assumo posição direcional para #dusk ; mantenho apenas um pequeno orçamento de risco. Controlar a exposição única dentro do limite de perdas que dá para suportar; qualquer anomalia no tamanho do conjunto de anonimato ou na migração entre os dois pools leva a uma saída prioritária, em vez de esperar uma reversão de narrativa. Os indicadores on-chain que preciso acompanhar no dia a dia não são muitos: tendência do volume total travado, mudanças de posição de endereços de grande porte, e registros de alterações de permissões do administrador do contrato. Sobre este projeto eu não tomo posição — o que consigo oferecer é apenas um número de retorno esperado ajustado ao risco.
As contas do Moonlight se baseiam em nonce e saldo público para construir uma conta de liquidação auditável e resistente a replay, bem próxima de reconciliação transacional de uma corretora tradicional. O Phoenix, por sua vez, utiliza notes, nullifier e endereços furtivos para formar notas sem identificação; o número de cancelamento apenas prova que o ticket foi descartado, sem expor o detentor. Aquela frase do whitepaper do Dusk, “duas modelagens são indispensáveis”, quando aterrissa nas cláusulas financeiras vira divulgação em níveis: a camada transparente assume a conformidade e o custo de rastreabilidade; a camada de confusão assume o risco de concentração de anonimato. A profundidade de liquidez e as regras de divulgação de ambos são decididas pelos parâmetros do contrato, e não pelo acordo do usuário. Na prática, o usuário consegue alternar livremente entre privacidade e transparência? Provavelmente é mais como ser empurrado entre dois “tanques” com exposições a risco diferentes, realizando uma configuração passiva.
De onde surgiria o risco de $DUSK ? Provavelmente não viria da validação de assinatura, mas de instabilidades na fronteira entre as duas camadas. Se o conjunto de anonimato encolher, a intensidade de privacidade do Phoenix cai junto; se as movimentações entre a camada transparente e a camada de confusão forem sistematicamente marcadas, a chamada divulgação seletiva logo se degrada em rastreamento efetivo e completo. Some-se a isso a entrada de novos recursos que derruba o fluxo abaixo do limiar de manutenção, ou transferências de grande porte de endereços concentradas entre os dois pools — e o destino desse arranjo de liquidação em duas camadas muito provavelmente será um evento de crédito de um produto estruturado. A única diferença é: aqui o crédito é endossado por um algoritmo, mas o algoritmo nunca assume obrigação de liquidação.
No meu estágio atual, não assumo posição direcional para #dusk ; mantenho apenas um pequeno orçamento de risco. Controlar a exposição única dentro do limite de perdas que dá para suportar; qualquer anomalia no tamanho do conjunto de anonimato ou na migração entre os dois pools leva a uma saída prioritária, em vez de esperar uma reversão de narrativa. Os indicadores on-chain que preciso acompanhar no dia a dia não são muitos: tendência do volume total travado, mudanças de posição de endereços de grande porte, e registros de alterações de permissões do administrador do contrato. Sobre este projeto eu não tomo posição — o que consigo oferecer é apenas um número de retorno esperado ajustado ao risco.
