Ті, хто хоч раз проходив комплаєнс-аудит, мають спільне відчуття: найстрашніше — не сама перевірка, а те, що потрібно одночасно підтвердити, що клієнт не порушував, і при цьому не розкрити повністю приватні дані клієнта. Традиційний підхід — ганяти грошові потоки, збирати документи особи, підтвердження адреси, а після перевірки ще й усе архівувати. Кожен документ в архіві — це ризик.
Тому, коли я дивлюся на Dusk, який грає картами «комплаєнс + приватність», перша реакція — подивитися, як він обходить цю суперечність. Ідентифікаційний шар Citadel іде шляхом вибіркового розкриття: користувач має сертифікати, видані установою; під час транзакції використовують докази з нульовим знанням — криптографічний інструмент, який не розкриває конкретні дані, але дозволяє довести, що «я відповідаю вимогам». Ти підтверджуєш, що умови виконані, без передачі оригіналів. Moonlight публікує облікові записи для звичайних переказів, Phoenix — privacy UTXO: схожа на біткоїн модель невитрачених виходів транзакцій, де кожна транзакція ізолюється окремо й не розкриває баланс, а чутливі операції обробляються окремо; два напрямки розведені. @Dusk
Для активів під регуляторним наглядом ця логіка працює: передача активів має одночасно проходити комплаєнс-перевірку і забезпечувати захист приватності; не можна заради приватності відмовитися від KYC.
Не буду його прикрашати. Довіра в Citadel «вкорінена» в постачальника, який видає сертифікати: хто має право видавати, як саме відкликаються сертифікати, чи має значення, що установа збанкрутувала, якщо старі сертифікати вже видані — це не питання криптографії, це питання управління (governance). Якщо глянути через документацію, деталі механізму відкликання викладені слабко. Так само проблема — кросюрисдикційність: визначення «кваліфікованого інвестора» в ЄС відрізняється від США, тож сертифікати не можна напряму перезастосувати. У квітні 2026 року виявили вразливість у криптобібліотеці — її вже виправили, але змушує задуматися: чи немає інших проблем?
Екосистема теж «тонка»: GitHub оновлюють повільно, сторонніх застосунків мало, документація не дружня до новачків. Технічний напрямок правильний, але ніхто не будує будинок — хороший фундамент, як відомо, без пустого простору нічого не вартий.
Моя думка: Dusk «проковтнув» складну технічну задачу «і комплаєнс, і приватність» — напрямок правильний. А все, що лишилося, — це бізнес-перемовини та регуляторний діалог; і це набагато повільніше, ніж писати код.
Як змусити ліцензовані установи відмовитися від власного ровa з даними їхніх клієнтів — за рахунок чого це взагалі можна зрушити? #dusk $DUSK
Тому, коли я дивлюся на Dusk, який грає картами «комплаєнс + приватність», перша реакція — подивитися, як він обходить цю суперечність. Ідентифікаційний шар Citadel іде шляхом вибіркового розкриття: користувач має сертифікати, видані установою; під час транзакції використовують докази з нульовим знанням — криптографічний інструмент, який не розкриває конкретні дані, але дозволяє довести, що «я відповідаю вимогам». Ти підтверджуєш, що умови виконані, без передачі оригіналів. Moonlight публікує облікові записи для звичайних переказів, Phoenix — privacy UTXO: схожа на біткоїн модель невитрачених виходів транзакцій, де кожна транзакція ізолюється окремо й не розкриває баланс, а чутливі операції обробляються окремо; два напрямки розведені. @Dusk
Для активів під регуляторним наглядом ця логіка працює: передача активів має одночасно проходити комплаєнс-перевірку і забезпечувати захист приватності; не можна заради приватності відмовитися від KYC.
Не буду його прикрашати. Довіра в Citadel «вкорінена» в постачальника, який видає сертифікати: хто має право видавати, як саме відкликаються сертифікати, чи має значення, що установа збанкрутувала, якщо старі сертифікати вже видані — це не питання криптографії, це питання управління (governance). Якщо глянути через документацію, деталі механізму відкликання викладені слабко. Так само проблема — кросюрисдикційність: визначення «кваліфікованого інвестора» в ЄС відрізняється від США, тож сертифікати не можна напряму перезастосувати. У квітні 2026 року виявили вразливість у криптобібліотеці — її вже виправили, але змушує задуматися: чи немає інших проблем?
Екосистема теж «тонка»: GitHub оновлюють повільно, сторонніх застосунків мало, документація не дружня до новачків. Технічний напрямок правильний, але ніхто не будує будинок — хороший фундамент, як відомо, без пустого простору нічого не вартий.
Моя думка: Dusk «проковтнув» складну технічну задачу «і комплаєнс, і приватність» — напрямок правильний. А все, що лишилося, — це бізнес-перемовини та регуляторний діалог; і це набагато повільніше, ніж писати код.
Як змусити ліцензовані установи відмовитися від власного ровa з даними їхніх клієнтів — за рахунок чого це взагалі можна зрушити? #dusk $DUSK