#dusk $DUSK @Dusk
Continuei voltando a um detalhe do padrão XSC que parecia pequeno até eu verificar o que ele realmente significava na prática. $DUSK and #DuskNetwork geralmente são apresentados como oferecendo "conformidade programável", como se fosse um único sistema compartilhado que se ajusta conforme as regulamentações mudam, mas as regras não são regidas pelo nível de protocolo de forma alguma. Elas são definidas pelo emissor individual no momento em que um token de segurança é criado. O emissor controla a lista de permissões (whitelist), pode forçar a transferência de ativos para cumprir uma ordem legal e pode recuperar uma carteira perdida — tudo isso são funções do lado do emissor, não do nível da rede. Enquanto isso, a governança real do protocolo da Dusk, a equipe de Core R&D e o Conselho de Governança, lida com atualizações da própria rede de referência, e não com a lógica de conformidade embutida em qualquer ativo específico. Portanto, essas duas camadas de governança não se sobrepõem da forma que eu havia presumido. Isso significa que "conformidade programável" aqui fica mais perto de "conformidade definida pelo emissor, programada uma vez e controlada por esse emissor daqui em diante" do que de um sistema em toda a rede que se adapta automaticamente conforme as leis mudam. É uma boa estrutura para dar aos emissores controle legal sobre ativos regulamentados, mas isso também coloca o ônus de manter tudo atualizado em cada emissor individualmente. Ainda estou trabalhando para entender o que isso significa em escala, quando houver dezenas de emissores na Dusk em vez de um ou dois.
Continuei voltando a um detalhe do padrão XSC que parecia pequeno até eu verificar o que ele realmente significava na prática. $DUSK and #DuskNetwork geralmente são apresentados como oferecendo "conformidade programável", como se fosse um único sistema compartilhado que se ajusta conforme as regulamentações mudam, mas as regras não são regidas pelo nível de protocolo de forma alguma. Elas são definidas pelo emissor individual no momento em que um token de segurança é criado. O emissor controla a lista de permissões (whitelist), pode forçar a transferência de ativos para cumprir uma ordem legal e pode recuperar uma carteira perdida — tudo isso são funções do lado do emissor, não do nível da rede. Enquanto isso, a governança real do protocolo da Dusk, a equipe de Core R&D e o Conselho de Governança, lida com atualizações da própria rede de referência, e não com a lógica de conformidade embutida em qualquer ativo específico. Portanto, essas duas camadas de governança não se sobrepõem da forma que eu havia presumido. Isso significa que "conformidade programável" aqui fica mais perto de "conformidade definida pelo emissor, programada uma vez e controlada por esse emissor daqui em diante" do que de um sistema em toda a rede que se adapta automaticamente conforme as leis mudam. É uma boa estrutura para dar aos emissores controle legal sobre ativos regulamentados, mas isso também coloca o ônus de manter tudo atualizado em cada emissor individualmente. Ainda estou trabalhando para entender o que isso significa em escala, quando houver dezenas de emissores na Dusk em vez de um ou dois.
