みなさんがコンプライアンスについて話すとき、KYCをただのプラグインみたいに捉えがちですが、竹竹は最初から問いの立て方が違うと思っています。
Citadelの設計思想は私をはっとさせました。そもそもこれはKYCのプラグインではなく、「自己主権型ID + 許可証(ライセンス)ベースのインフラ」なのです。許可証の契約を通じた発行、検証、取消しのプロセスによって、コンプライアンス上の身分が“プラットフォームに1つのファイルを保管する”ものから、“ユーザーが保持する検証可能な資格(クレデンシャル)”へと変わりました。
さらに重要なのは、選択的開示です。ユーザーは「ある属性を満たしている」こと(つまり適格投資家、居住地域、年齢層)を示すだけでよく、完全な身元をすべては公開しません。
そしてPhoenix/Zedgerと組み合わせることで、本人確認の証明と資産移転が徹底的に切り離されます。これで、コンプライアンスとプライバシーの両立が実現するのです。
竹竹が特に興味を持っているのは、その背後にある判断です。コンプライアンスはプラットフォームの負担であるべきではなく、ユーザーの権利であるべきだという考えです。この順序は、ある意味で「プライバシーKYC」という概念そのものよりも、Citadelが本当に機関のために働いているのかをより正確に示していると思います。
ただ、竹竹もこの仕組みがすでに十分に検証済みだと“偽る”わけにはいきません。許可証契約の設計がどれほど精緻でも、実際のシーンで回してみて初めて使い勝手が分かります。現時点で公開されている導入事例はまだ多くありません。この仕組みが、機関レベルのコンプライアンス需要を本当に支えられるのかは、より多くの契約が稼働してから答えが出るかもしれません。
みなさんは、この「ユーザーが検証可能なクレデンシャルを保有する」ルートと、「プラットフォームがファイルを1つ保管する」ルートでは、長期的にどちらのほうが機関に受け入れられやすいと思いますか?
竹竹は、どちらを選んでも@Dusk Foundationは$ DUSKによってコンプライアンス基盤を再定義しているのだと考えます。これこそが、真のネイティブ・コンプライアンス!
#dusk $DUSK
Citadelの設計思想は私をはっとさせました。そもそもこれはKYCのプラグインではなく、「自己主権型ID + 許可証(ライセンス)ベースのインフラ」なのです。許可証の契約を通じた発行、検証、取消しのプロセスによって、コンプライアンス上の身分が“プラットフォームに1つのファイルを保管する”ものから、“ユーザーが保持する検証可能な資格(クレデンシャル)”へと変わりました。
さらに重要なのは、選択的開示です。ユーザーは「ある属性を満たしている」こと(つまり適格投資家、居住地域、年齢層)を示すだけでよく、完全な身元をすべては公開しません。
そしてPhoenix/Zedgerと組み合わせることで、本人確認の証明と資産移転が徹底的に切り離されます。これで、コンプライアンスとプライバシーの両立が実現するのです。
竹竹が特に興味を持っているのは、その背後にある判断です。コンプライアンスはプラットフォームの負担であるべきではなく、ユーザーの権利であるべきだという考えです。この順序は、ある意味で「プライバシーKYC」という概念そのものよりも、Citadelが本当に機関のために働いているのかをより正確に示していると思います。
ただ、竹竹もこの仕組みがすでに十分に検証済みだと“偽る”わけにはいきません。許可証契約の設計がどれほど精緻でも、実際のシーンで回してみて初めて使い勝手が分かります。現時点で公開されている導入事例はまだ多くありません。この仕組みが、機関レベルのコンプライアンス需要を本当に支えられるのかは、より多くの契約が稼働してから答えが出るかもしれません。
みなさんは、この「ユーザーが検証可能なクレデンシャルを保有する」ルートと、「プラットフォームがファイルを1つ保管する」ルートでは、長期的にどちらのほうが機関に受け入れられやすいと思いますか?
竹竹は、どちらを選んでも@Dusk Foundationは$ DUSKによってコンプライアンス基盤を再定義しているのだと考えます。これこそが、真のネイティブ・コンプライアンス!
#dusk $DUSK