#dusk $DUSK @Dusk
トークン化は通常、資産をオンチェーンに載せることだと説明されます。実際はそうとは限りません。オンチェーンになるのは資産そのものではなく、資産に対する請求（クレーム）です。一方で資産自体は、常に存在していた登録機関のデータベースにそのまま残り、ライフサイクルもそれに連動してそこで管理され続けます。
ライフサイクルこそがコストのかかる部分です。債券は静的なオブジェクトではありません。クーポンを支払い、保有者台帳を持ち、コーポレートアクションを経て、担保として差し入れられ、満期を迎えます。これらの各イベントは、単一の真実の源（ソース・オブ・トゥルース）を共有していないシステム同士の突合・照合（リコンサイル）です。金融商品をトークンで包んでも、それらが消えるわけではありません。むしろ、ラッパー（包む側）と基礎となる資産（アンダーライイング）が食い違う可能性があるため、1つ追加されるとも言えます。
ネイティブ発行とは、@dusk が実際に行おうとしている請求（クレーム）です。つまり、そもそもプロトコル層で、適格性・譲渡制限・決済ロジックを表現し、後付けで取り付けるのではなく、その場でオンチェーンに金融商品を作成することです。Zedger はそのための資産プロトコルで、DuskDS 上でネイティブに動作し、Citadel がアイデンティティと選択的開示を取り扱うことで、誰が保有者かを公開せずとも適格性を証明できるようにします。
ここでの正直な難しさは、技術ではなく法律です。チェーン上の記録が、それの「ミラー（写し）」ではなく登録（レジスター）になるには、法律がそう定めている必要があります。EU の DLT パイロット制度はまさにそれを、商品上限（インストゥルメント・キャップ）と限られた期間の中で試すために作られました。
したがって、$DUSK に対して問うべきなのは、原理的にネイティブ発行のほうが良いかどうかではありません。そういう形で最初の本物の金融商品が発行され、そのクーポン日程そのものを生き延びられるかどうかです。#dusk