#dusk $DUSK @Dusk 昨日、友人に送金しようとしましたが、彼の口座がKYCのためにフラグを立てられていたため、銀行がその場で送金を止めました。取引はそもそも実行されず、実際には通りませんでした。あれは強く印象に残っています。こうしたチェックは「あとで」行うのではなく、「先に」行われるべきです。
@Dusk は、この考え方を規制対象資産の移転にも同様に適用しています。通常の暗号資産の送金は残高とガスさえあれば通ります。しかし規制対象資産では、Dusk が最初に受取ウォレットが対象として適格かどうかを確認します。
投資家のオンボーディング中に、ウォレットは検証済みの資格情報に紐づけられ、資産が発行される際に適格性ルールが定義されます。そのため送金が提出されると、システムはまずそのルールに照らしてチェックします。相手方が適格でない場合、その送金は単に実行されません。後から取り消したり、凍結したりする必要はありません。
これは、規制のある金融ではとても重要です。仮に不適格な送金が実際に決済されてしまったら、それは単なる不具合ではなく、事後に解消しなければならないコンプライアンス違反になり、場合によっては規制当局も関与することになります。提出前にブロックすることで、それを完全に回避できます。これはまさに、#Dusk. がプロトコルレベルで解決するために作られた種類の問題です。
私が以前考えていなかったのは、この仕組みにはどれほどの維持管理(アップキープ)が必要かという点です。投資家のステータス、管轄、資格情報などは固定されません。それらのデータが古くなると、本当に適格な投資家までもブロックされてしまう可能性があります。
この経験は、ここでのコンプライアンスの見方を変えました。事後に付ける書類のようなものではなく、そもそも送金が起こる前に満たされるべき条件なのだ、というふうに捉えるようになりました。
では、これらの適格性ルールを最新の状態に保つ責任を負うのは誰で、どうすればそれ自体がボトルネックにならないのでしょうか?
誰が適格性ルールを更新すべきですか?
@Dusk #Dusk/usdt✅
$TUT
$PORTAL
@Dusk は、この考え方を規制対象資産の移転にも同様に適用しています。通常の暗号資産の送金は残高とガスさえあれば通ります。しかし規制対象資産では、Dusk が最初に受取ウォレットが対象として適格かどうかを確認します。
投資家のオンボーディング中に、ウォレットは検証済みの資格情報に紐づけられ、資産が発行される際に適格性ルールが定義されます。そのため送金が提出されると、システムはまずそのルールに照らしてチェックします。相手方が適格でない場合、その送金は単に実行されません。後から取り消したり、凍結したりする必要はありません。
これは、規制のある金融ではとても重要です。仮に不適格な送金が実際に決済されてしまったら、それは単なる不具合ではなく、事後に解消しなければならないコンプライアンス違反になり、場合によっては規制当局も関与することになります。提出前にブロックすることで、それを完全に回避できます。これはまさに、#Dusk. がプロトコルレベルで解決するために作られた種類の問題です。
私が以前考えていなかったのは、この仕組みにはどれほどの維持管理(アップキープ)が必要かという点です。投資家のステータス、管轄、資格情報などは固定されません。それらのデータが古くなると、本当に適格な投資家までもブロックされてしまう可能性があります。
この経験は、ここでのコンプライアンスの見方を変えました。事後に付ける書類のようなものではなく、そもそも送金が起こる前に満たされるべき条件なのだ、というふうに捉えるようになりました。
では、これらの適格性ルールを最新の状態に保つ責任を負うのは誰で、どうすればそれ自体がボトルネックにならないのでしょうか?
誰が適格性ルールを更新すべきですか?
@Dusk #Dusk/usdt✅
$TUT
$PORTAL
Issuer
60%
Compliance provider
0%
Regulator
20%
On-chain automation
20%
5 投票 • 投票は終了しました