Eu estava cruzando $DUSK documentos regulatórios com suas próprias anotações de arquitetura quando notei dois nomes em documentos diferentes que não se alinhavam do jeito que eu esperava. Minha primeira suposição foi que isso era apenas uma rotulagem inconsistente entre equipes, nada estrutural.

Indo mais fundo, percebi que o ECSP não é um mecanismo de fato; é um status de autorização, a permissão para um negócio originar ofertas elegíveis sob as regras de crowdfunding da UE. Do lado técnico, algo semelhante estava acontecendo. XSC é o nome da funcionalidade relacionada a títulos no Dusk, enquanto Zedger, o modelo híbrido de transações UTXO e baseado em conta, é o que realmente executa essa função por baixo.

Foi aí que meu raciocínio mudou. Autorização e execução normalmente são tratadas como um único pacote, mas aqui elas são camadas claramente separadas. Uma licença concede acesso legal para levar um ativo a um mercado. Um modelo de transações movimenta esse ativo assim que ele já está lá. Nenhuma substitui a outra, e confundi-las esconde onde o verdadeiro gargalo talvez esteja.

O que eu ainda não resolvi é como essas camadas permanecem sincronizadas quando ambas estão em funcionamento. Se a aprovação regulatória avança, mas os emissores não estruturam ofertas especificamente contra o Zedger, ou se a integração técnica avança mais rápido do que as ofertas autorizadas, um lado acaba carregando peso morto para o outro.

Vou observar ofertas reais originadas sob ECSP, atividade de integração fazendo referência ao Zedger em vez de apenas XSC como rótulo e se as equipes construindo sobre @Dusk estão mirando a camada certa integralmente.

Separar permissão de execução de forma tão limpa deixa o sistema mais fácil de raciocinar, ou apenas cria mais lugares para a coordenação se romper silenciosamente?#dusk
$BTR
$TAC