少し前に、ある資産がトークン化されれば、それを保有することは他のどんなトークンを所有するのも同じように簡単になるのだと考えていました。ウォレットに送ればそれで終わり、というわけです。ですが、Duskが規制対象資産にどう取り組んでいるかを調べたことで、その前提がコンプライアンスの存在によってすぐに崩れることに気づきました。規制対象の証券は、要求してきたどんなウォレットにもただ置いておけるものではありません。銀行が、本人確認をせずに誰かの口座を開設できないのと同じです。
Duskは、1つのゲートに頼るのではなく、複数のポイントにまたがってアクセス制御を重ねることでこれを扱います。アイデンティティの認証情報は、参加者が実際に誰であるかを定める一方で、チェーン上に不要な個人データを公開しません。ウォレットのバインディングは、検証済みのアイデンティティを特定のアドレスに結びつけ、その認証情報が気軽に受け渡しされないようにします。そしてスマートコントラクトは、譲渡の瞬間に実際のルールを強制し、取引が許可された上で決済できるかどうかをチェックします。さらにアプリケーションレベルのチェックがその上にもう一層加わり、発行者が管轄や資産の種類に応じて独自の条件を適用できるようになります。
私が印象に残ったのは、すべてを1つの仕組みが担っているのではなく、いくつかの独立したチェックがあり、それぞれが通過しなければならない点です。この冗長性はコンプライアンス面では有用ですが、一方で、正当な保有者に対して慎重に実装しないと、失敗や摩擦につながる可能性のある可動部が増えることも意味しています。
これにより、トークン化された規制対象資産を別の見方で捉えるようになりました。難しいのはトークンを発行することではありません。時間とともに状況が変わっていく中で、誰がそれを保有し続けてよいのかを維持することこそが難点でした。Duskがこのように層状のアプローチを組み立てる方法を理解したことで、「適格性」という問いが、単発のチェックのようではなく、進行するプロセスのように感じられるようになりました。
@Dusk $DUSK #dusk
保有者の適格性が発行後に変化した場合、強制はどのように機能すべきですか?
Duskは、1つのゲートに頼るのではなく、複数のポイントにまたがってアクセス制御を重ねることでこれを扱います。アイデンティティの認証情報は、参加者が実際に誰であるかを定める一方で、チェーン上に不要な個人データを公開しません。ウォレットのバインディングは、検証済みのアイデンティティを特定のアドレスに結びつけ、その認証情報が気軽に受け渡しされないようにします。そしてスマートコントラクトは、譲渡の瞬間に実際のルールを強制し、取引が許可された上で決済できるかどうかをチェックします。さらにアプリケーションレベルのチェックがその上にもう一層加わり、発行者が管轄や資産の種類に応じて独自の条件を適用できるようになります。
私が印象に残ったのは、すべてを1つの仕組みが担っているのではなく、いくつかの独立したチェックがあり、それぞれが通過しなければならない点です。この冗長性はコンプライアンス面では有用ですが、一方で、正当な保有者に対して慎重に実装しないと、失敗や摩擦につながる可能性のある可動部が増えることも意味しています。
これにより、トークン化された規制対象資産を別の見方で捉えるようになりました。難しいのはトークンを発行することではありません。時間とともに状況が変わっていく中で、誰がそれを保有し続けてよいのかを維持することこそが難点でした。Duskがこのように層状のアプローチを組み立てる方法を理解したことで、「適格性」という問いが、単発のチェックのようではなく、進行するプロセスのように感じられるようになりました。
@Dusk $DUSK #dusk
保有者の適格性が発行後に変化した場合、強制はどのように機能すべきですか?
Next transfer only
Retroactive now
Depends on asset
Issuer decides
2 残り時間