Увидев «Atomic Settlement», я поначалу подумал, что главная сложность DvP — добиться того, чтобы обе «ноги» сделки, и актив, и платеж, одновременно не сошли с рельс. Сегодня, вновь разложив по полочкам рыночную инфраструктуру из документации @Dusk , я остановился на более неприятном слое: атомарность и детерминизм могут устранить сделку «в полдела», но не подскажут институту, что делать после того, как провал действительно произошёл.
Официальная рамка Dusk пытается встроить в один рыночный рабочий поток решения для проверок допуска, принадлежности адресов, ограниченных переводов, координации платежей и окончательного расчёта; DuskDS после ratification в блоке предоставляет детерминированную финальность. Этот набор способен изменить один из самых дорогих в традиционных ценных бумагах классов проблем — участникам больше не нужно многократно подтверждать между разными реестрами вопрос «актив всё-таки передали или нет» и «деньги всё-таки дошли или нет».
Но стоит перенести сценарий на однократную подписку на облигацию — и аномалии появляются сразу. Инвестор сначала проходит проверку квалификации, наличные резервируются, а доли ждут поставку; однако при подаче может выясниться, что квалификация истекла, средств недостаточно, подпись(и) недоступны офлайн, тайм-аут интерфейса кастодиана, или внешний платёжный статус не синхронизирован. Если обе «ноги» действительно управляются одними и теми же атомарными условиями, лучший исход — когда всё получается вместе или всё проваливается вместе; но «вместе провалиться» — это лишь ончейн-результат, а не замкнутый бизнес-цикл.
Вот где, как мне кажется, у направления Dusk есть ценность, но пока недостаточно доказательств. Финальность DuskDS делает границы отказа яснее: успех или ошибка в финальном блоке больше не остаются надолго в подвешенном состоянии, а при сбое выполнения можно получить проверяемый результат. Но сайт Dusk Trade в тот же день всё ещё помечен как Building и открывает waitlist; в публичных материалах нет данных о готовности/проценте завершения DvP в production, распределении аномалий или сведений об ручном вмешательстве.
Риски при этом вполне конкретные. Во‑первых, приватность и селективное раскрытие, если отсутствуют зрелые инструменты авторизационного аудита, могут сделать расследование аномалий даже медленнее. Во‑вторых, если «активная нога» и «платёжная нога» проходят через разные системы, граница атомарности сужается — и тогда ручные компенсации снова возвращаются в процесс. Техническая финальность может не подвести, но бизнес-обязательство всё равно может остаться невыполненным.
Что, по вашему мнению, организациям при приёмке DvP стоит в первую очередь оценивать: A — скорость прохождения нормального пути, B — автоматическое восстановление при сбоях, или C — сверку данных между системами? #dusk $DUSK
Официальная рамка Dusk пытается встроить в один рыночный рабочий поток решения для проверок допуска, принадлежности адресов, ограниченных переводов, координации платежей и окончательного расчёта; DuskDS после ratification в блоке предоставляет детерминированную финальность. Этот набор способен изменить один из самых дорогих в традиционных ценных бумагах классов проблем — участникам больше не нужно многократно подтверждать между разными реестрами вопрос «актив всё-таки передали или нет» и «деньги всё-таки дошли или нет».
Но стоит перенести сценарий на однократную подписку на облигацию — и аномалии появляются сразу. Инвестор сначала проходит проверку квалификации, наличные резервируются, а доли ждут поставку; однако при подаче может выясниться, что квалификация истекла, средств недостаточно, подпись(и) недоступны офлайн, тайм-аут интерфейса кастодиана, или внешний платёжный статус не синхронизирован. Если обе «ноги» действительно управляются одними и теми же атомарными условиями, лучший исход — когда всё получается вместе или всё проваливается вместе; но «вместе провалиться» — это лишь ончейн-результат, а не замкнутый бизнес-цикл.
Вот где, как мне кажется, у направления Dusk есть ценность, но пока недостаточно доказательств. Финальность DuskDS делает границы отказа яснее: успех или ошибка в финальном блоке больше не остаются надолго в подвешенном состоянии, а при сбое выполнения можно получить проверяемый результат. Но сайт Dusk Trade в тот же день всё ещё помечен как Building и открывает waitlist; в публичных материалах нет данных о готовности/проценте завершения DvP в production, распределении аномалий или сведений об ручном вмешательстве.
Риски при этом вполне конкретные. Во‑первых, приватность и селективное раскрытие, если отсутствуют зрелые инструменты авторизационного аудита, могут сделать расследование аномалий даже медленнее. Во‑вторых, если «активная нога» и «платёжная нога» проходят через разные системы, граница атомарности сужается — и тогда ручные компенсации снова возвращаются в процесс. Техническая финальность может не подвести, но бизнес-обязательство всё равно может остаться невыполненным.
Что, по вашему мнению, организациям при приёмке DvP стоит в первую очередь оценивать: A — скорость прохождения нормального пути, B — автоматическое восстановление при сбоях, или C — сверку данных между системами? #dusk $DUSK
