Я продолжал пялиться на блок-схему выплаты дивидендов, пока она не перестала быть понятной. DTC — брокер — суб-депозитарий — акционер: четыре перехода, и я предположил, что узкое место где-то в скорости обработки. Но это не так. Чем глубже я вникал, тем яснее становилось: реальная стоимость — в согласовании (reconciliation). Каждое звено этой цепочки независимо обновляет собственные записи, а потом все сверяются. Именно туда и уходит 58 млрд долларов в год на издержки корпоративных действий.
Что особенно бросилось мне в глаза при изучении дизайнерского решения XSC от DUSK, так это то, что оно не пытается ускорить каждый «хоп». Оно устраняет саму необходимость в согласовании между переходами: одно исполнение, один результат, и каждый держатель читает из одного и того же источника, а не четыре стороны отдельно рассчитывают и потом сверяют позже. Вот здесь подход DUSK начинает ощущаться по‑другому по сравнению с большей частью инфраструктуры, которую я раньше изучал.
И тогда для меня щёлкнуло различие между токенизацией и нативным (native). Обёртывание акции в токен всё равно опирается на те же самые «трубопроводы» DTC, поверх которых вы добавили слой, а не заменили один на другой. Нативная эмиссия на чём-то вроде DUSK задаёт более прямой вопрос: а нужно ли вам всё ещё тысячи платёжных агентов, которые независимо обрабатывают одно и то же событие по дивидендам, если есть один уровень расчётов, из которого все читают? Вся архитектура DUSK, похоже, ставит на то, что ответ — «нет».
Но меня всё ещё беспокоит вопрос о распределении ответственности. Если смарт‑контракт DUSK неправильно рассчитает выплату, кто несёт ответственность: цепочка, эмитент или платёжный агент, который раньше существовал? Думаю, это пока не прояснено, и я не уверен, что это можно замалчивать только потому, что архитектура стала чище.
#dusk $DUSK @Dusk
Что особенно бросилось мне в глаза при изучении дизайнерского решения XSC от DUSK, так это то, что оно не пытается ускорить каждый «хоп». Оно устраняет саму необходимость в согласовании между переходами: одно исполнение, один результат, и каждый держатель читает из одного и того же источника, а не четыре стороны отдельно рассчитывают и потом сверяют позже. Вот здесь подход DUSK начинает ощущаться по‑другому по сравнению с большей частью инфраструктуры, которую я раньше изучал.
И тогда для меня щёлкнуло различие между токенизацией и нативным (native). Обёртывание акции в токен всё равно опирается на те же самые «трубопроводы» DTC, поверх которых вы добавили слой, а не заменили один на другой. Нативная эмиссия на чём-то вроде DUSK задаёт более прямой вопрос: а нужно ли вам всё ещё тысячи платёжных агентов, которые независимо обрабатывают одно и то же событие по дивидендам, если есть один уровень расчётов, из которого все читают? Вся архитектура DUSK, похоже, ставит на то, что ответ — «нет».
Но меня всё ещё беспокоит вопрос о распределении ответственности. Если смарт‑контракт DUSK неправильно рассчитает выплату, кто несёт ответственность: цепочка, эмитент или платёжный агент, который раньше существовал? Думаю, это пока не прояснено, и я не уверен, что это можно замалчивать только потому, что архитектура стала чище.
#dusk $DUSK @Dusk
