Fiquei encarando um fluxograma de pagamento de dividendos até ele deixar de fazer sentido. DTC para corretora para subcustodiante para acionista: quatro etapas, e eu presumi que o gargalo estava em alguma velocidade de processamento. Não está. Quanto mais eu investigava, mais eu via que o custo real está na conciliação: cada elo nessa cadeia atualiza seus próprios registros de forma independente, e só depois todos comparam as informações. É aí que os US$ 58B por ano em custos de corporate actions realmente vão.
O que me chamou atenção ao examinar o design XSC da DUSK é que ele não tenta tornar cada etapa mais rápida. Ele elimina a necessidade de as etapas reconciliarem de vez: uma execução, um resultado; cada titular lê da mesma fonte, em vez de quatro partes calcularem separadamente e depois se checarem. É aqui que a abordagem da DUSK começa a parecer diferente da maior parte da infraestrutura que eu tinha visto antes.
Foi então que a distinção entre tokenização e emissão nativa ficou clara para mim. Envolver uma ação em um token ainda fica por cima do mesmo encanamento da DTC que você adicionou uma camada — não substituiu. Emissão nativa em algo como a DUSK coloca uma pergunta mais direta: você ainda precisa de milhares de agentes pagadores processando independentemente o mesmo evento de dividendo se existe uma única camada de liquidação da qual todo mundo lê? Toda a arquitetura da DUSK parece apostar que a resposta é não.
Ainda estou preso à questão da responsabilidade, porém. Se um contrato da DUSK calcular um pagamento incorretamente, quem fica responsável: a cadeia, o emissor, o agente pagador que existia antes? Eu não acho que isso já esteja respondido, e não tenho certeza se deve ser ignorado só porque a arquitetura fica mais limpa.
#dusk $DUSK @Dusk
O que me chamou atenção ao examinar o design XSC da DUSK é que ele não tenta tornar cada etapa mais rápida. Ele elimina a necessidade de as etapas reconciliarem de vez: uma execução, um resultado; cada titular lê da mesma fonte, em vez de quatro partes calcularem separadamente e depois se checarem. É aqui que a abordagem da DUSK começa a parecer diferente da maior parte da infraestrutura que eu tinha visto antes.
Foi então que a distinção entre tokenização e emissão nativa ficou clara para mim. Envolver uma ação em um token ainda fica por cima do mesmo encanamento da DTC que você adicionou uma camada — não substituiu. Emissão nativa em algo como a DUSK coloca uma pergunta mais direta: você ainda precisa de milhares de agentes pagadores processando independentemente o mesmo evento de dividendo se existe uma única camada de liquidação da qual todo mundo lê? Toda a arquitetura da DUSK parece apostar que a resposta é não.
Ainda estou preso à questão da responsabilidade, porém. Se um contrato da DUSK calcular um pagamento incorretamente, quem fica responsável: a cadeia, o emissor, o agente pagador que existia antes? Eu não acho que isso já esteja respondido, e não tenho certeza se deve ser ignorado só porque a arquitetura fica mais limpa.
#dusk $DUSK @Dusk
