#dusk $DUSK @Dusk
Tenho pensado um pouco diferente sobre o design pós-negociação da Dusk depois de ler o material sobre o ciclo de vida. Antes eu achava que a conformidade programável era, em grande parte, garantir que uma negociação fosse permitida antes de acontecer. Mas a pergunta mais difícil parece começar depois do negócio, quando a titularidade, os direitos de voto, a elegibilidade para dividendos e o status de conformidade precisam continuar corretos.
Isso torna a ideia de conformidade se tornar programável bem útil, mas também um pouco desconfortável. O código pode impor uma regra de forma consistente. Ele não consegue saber automaticamente o que fazer quando a situação do mundo real por trás dessa regra muda ou não se encaixa nas premissas em que foi construído. Se a elegibilidade de um detentor mudar, ou se alguma condição regulatória exigir uma exceção, tem que haver um mecanismo para lidar com esse estado, em vez de simplesmente confiar na lógica original.
Aí é que acho que a Dusk fica mais interessante do que apenas tokenizar um ativo. O próprio token é quase a camada mais fácil. O problema mais difícil é manter o registro preciso enquanto as negociações continuam acontecendo. Mas ainda fico me perguntando sobre a camada de override. Quem é realmente confiável para intervir quando as regras codificadas produzem o resultado errado, e como evitar que essa autoridade se torne o ponto mais fraco em um sistema, de outra forma, programável?
Tenho pensado um pouco diferente sobre o design pós-negociação da Dusk depois de ler o material sobre o ciclo de vida. Antes eu achava que a conformidade programável era, em grande parte, garantir que uma negociação fosse permitida antes de acontecer. Mas a pergunta mais difícil parece começar depois do negócio, quando a titularidade, os direitos de voto, a elegibilidade para dividendos e o status de conformidade precisam continuar corretos.
Isso torna a ideia de conformidade se tornar programável bem útil, mas também um pouco desconfortável. O código pode impor uma regra de forma consistente. Ele não consegue saber automaticamente o que fazer quando a situação do mundo real por trás dessa regra muda ou não se encaixa nas premissas em que foi construído. Se a elegibilidade de um detentor mudar, ou se alguma condição regulatória exigir uma exceção, tem que haver um mecanismo para lidar com esse estado, em vez de simplesmente confiar na lógica original.
Aí é que acho que a Dusk fica mais interessante do que apenas tokenizar um ativo. O próprio token é quase a camada mais fácil. O problema mais difícil é manter o registro preciso enquanto as negociações continuam acontecendo. Mas ainda fico me perguntando sobre a camada de override. Quem é realmente confiável para intervir quando as regras codificadas produzem o resultado errado, e como evitar que essa autoridade se torne o ponto mais fraco em um sistema, de outra forma, programável?