O pitch de “fluxos de trabalho unificados” me fez imaginar um único encanamento contínuo: emissão, negociação, liquidação — tudo dentro de um mesmo ambiente de execução. O que encontrei, na prática, foi algo mais próximo de um conjunto de etapas especificadas separadamente, que apenas compartilham uma camada de liquidação. DUSK, $DUSK , #dusk , @Dusk As frames de emissão, transferência de propriedade, checagens de conformidade e a liquidação final são passos distintos, cada um com seu próprio módulo ou lógica de contrato, que convergem para o mesmo livro-razão base, em vez de passarem por um único mecanismo de fluxo de trabalho compartilhado. A unificação é, na verdade, no nível de finalização da liquidação, não no nível do processo: transações da Phoenix e da Moonlight resolvem na mesma cadeia, mas a lógica de conformidade que governa um ativo a montante é configurada por emissão; isso significa que dois tokens podem atravessar conjuntos de regras bem diferentes antes de sequer tocarem as mesmas garantias de liquidação. Eu inicialmente li “unificado” como significando comportamento padronizado de ponta a ponta, e tive de revisar isso para algo mais próximo de “estado final compartilhado, caminhos divergentes para chegar lá”. Não é um design ruim — arguivelmente é mais realista dadas as variações dos ativos regulados —, mas isso significa que a coerência vive na base da pilha, não no topo. Ainda estou avaliando se essa distinção importa muito para um usuário final, ou apenas para quem está construindo em cima disso.
#dusk $DUSK @Dusk