Давным-давно я предположил, что если актив токенизирован, то владение им становится таким же простым, как владение любым другим токеном: просто отправьте его в кошелёк — и всё готово. Затем я разобрался, как Dusk подходит к регулируемым активам, и понял, что это предположение быстро рушится, как только в дело вступает комплаенс. Регулируемая ценная бумага не может просто лежать в любом кошельке, который её запросит, так же, как банк не может открыть счёт для человека, не проверив сначала, кто он.
‎
‎Dusk решает эту задачу, накладывая контроль доступа в нескольких точках вместо того, чтобы полагаться на один «шлюз». Учётные данные личности определяют, кто на самом деле является участником, при этом не раскрывая излишние персональные данные в цепочке, привязка кошелька связывает подтверждённую идентичность с конкретным адресом, чтобы учётные данные нельзя было просто так передавать, а смарт-контракты обеспечивают реальное соблюдение правила в момент передачи, проверяя право до того, как транзакция будет разрешена и зафиксирована. Проверки на уровне приложения добавляют ещё один слой поверх этого, позволяя эмитентам применять собственные условия в зависимости от юрисдикции или типа актива. Больше всего выделилось то, что здесь не один механизм делает всю работу — это несколько независимых проверок, каждая из которых должна пройти, и такая избыточность полезна для комплаенса, но также означает больше компонентов, которые могут сломаться или создавать трение для законных держателей, если реализовать это неаккуратно.
‎
‎Это заставило меня иначе взглянуть на токенизированные регулируемые активы: сложность заключается не в том, чтобы выпустить токен, а в том, чтобы со временем поддерживать, кто имеет право продолжать им владеть, когда обстоятельства меняются. Понимание того, как Dusk выстраивает этот многоуровневый подход, заставило вопрос о допустимости выглядеть не как разовая проверка, а как непрерывный процесс.

‎@Dusk $DUSK #dusk
Если допустимость держателя меняется после выпуска, как должно работать принуждение?