Binance Square
Mst_Fatema_khatunn
163 投稿

Mst_Fatema_khatunn

101 フォロー
88 フォロワー
279 いいね
投稿
ポートフォリオ
·
--
翻訳参照
#dusk $DUSK @Dusk_Foundation So what happens if you try to buy more of something than you are allowed to hold? Until recently I would have said this is not a real situation. If you have funds and the market has supply, you buy. Any limit would be an artificial restriction bolted on by someone. Then I looked at what regulated instruments actually require, and the situation turns out to be ordinary rather than exotic. Some instruments carry caps. A single holder may not exceed a certain share. Certain categories of investor may only take a limited position. These limits exist in the legal documentation of the asset, and they are not optional for the issuer. What caught my attention is where the limit has to live. If it exists only in a policy document, someone has to check it manually after the fact and unwind anything that breached it. If it exists in the asset itself, the transfer simply does not complete, and there is nothing to unwind. That difference sounds small and is not. Prevention and remediation cost completely different amounts, and the second one usually involves lawyers. What I cannot judge is how flexible this stays when a rule changes, since the limit written today may not be the limit required next year. From here I stopped reading transfer restrictions as friction added to a token. Sometimes the restriction is the reason the instrument is legally allowed to exist at all.
#dusk $DUSK @Dusk
So what happens if you try to buy more of something than you are allowed to hold?
Until recently I would have said this is not a real situation. If you have funds and the market has supply, you buy. Any limit would be an artificial restriction bolted on by someone.
Then I looked at what regulated instruments actually require, and the situation turns out to be ordinary rather than exotic.
Some instruments carry caps. A single holder may not exceed a certain share. Certain categories of investor may only take a limited position. These limits exist in the legal documentation of the asset, and they are not optional for the issuer.
What caught my attention is where the limit has to live. If it exists only in a policy document, someone has to check it manually after the fact and unwind anything that breached it. If it exists in the asset itself, the transfer simply does not complete, and there is nothing to unwind.
That difference sounds small and is not. Prevention and remediation cost completely different amounts, and the second one usually involves lawyers.
What I cannot judge is how flexible this stays when a rule changes, since the limit written today may not be the limit required next year.
From here I stopped reading transfer restrictions as friction added to a token. Sometimes the restriction is the reason the instrument is legally allowed to exist at all.
#dusk $DUSK @Dusk_Foundation 以前、私は即時決済を当然の改善だと考えていました。取引が、その場で直ちに決済される――つまり翌日まで待つのではなく、間に待機や取引相手(カウンターパーティ)リスクも存在しない。そう聞くと、純粋な進歩のように思えたのです。 既存の市場で実際に決済がどのように機能しているのかを読み、その考えは変わりました。 従来の市場では、すべての取引を個別に決済するわけではありません。一定期間に発生した取引を集計し、互いに相殺(ネット)することで、同じものを何度も売買した企業は、最後に差額だけを動かせばよいようになっています。人々が不満を抱く「遅延」が、相殺を可能にしている要因なのです。 この遅延を取り除けば、相殺も取り除かれます。すると、あらゆる取引がそれぞれ単独で、全額がその場で決済されることになり、日次の最後に計算された差額ではなく、取引の瞬間に双方が利用可能な「全額」が必要になります。 私が特に注目したのは、これは技術的なコストではなく、流動性(リクイディティ)のコストだという点です。あるチェーンが、即時決済を完全に実現できるとしても、それを使う機関が、以前よりもはるかに多くの現金をアイドル(滞留)させておく必要があることを突きつけられるかもしれません。 つまり、即時決済は単に速くするだけではありません。コストを一箇所から別の場所へ移し替えるのです。取引から決済までの間にある信用リスクを取り除き、その代わりに資金調達(ファンディング)の要件を増やします。 私は、この取引上のトレードオフが、実際にそれを検討している機関によってどのように評価されているのかは分かりませんし、取引する内容によって答えが変わるのではないかとも思っています。 ここから先は、決済スピードを単純なメリットとして読むのをやめました。それは、どちらの問題を抱えたいのかという選択なのです。
#dusk $DUSK @Dusk
以前、私は即時決済を当然の改善だと考えていました。取引が、その場で直ちに決済される――つまり翌日まで待つのではなく、間に待機や取引相手(カウンターパーティ)リスクも存在しない。そう聞くと、純粋な進歩のように思えたのです。
既存の市場で実際に決済がどのように機能しているのかを読み、その考えは変わりました。

従来の市場では、すべての取引を個別に決済するわけではありません。一定期間に発生した取引を集計し、互いに相殺(ネット)することで、同じものを何度も売買した企業は、最後に差額だけを動かせばよいようになっています。人々が不満を抱く「遅延」が、相殺を可能にしている要因なのです。
この遅延を取り除けば、相殺も取り除かれます。すると、あらゆる取引がそれぞれ単独で、全額がその場で決済されることになり、日次の最後に計算された差額ではなく、取引の瞬間に双方が利用可能な「全額」が必要になります。

私が特に注目したのは、これは技術的なコストではなく、流動性(リクイディティ)のコストだという点です。あるチェーンが、即時決済を完全に実現できるとしても、それを使う機関が、以前よりもはるかに多くの現金をアイドル(滞留)させておく必要があることを突きつけられるかもしれません。

つまり、即時決済は単に速くするだけではありません。コストを一箇所から別の場所へ移し替えるのです。取引から決済までの間にある信用リスクを取り除き、その代わりに資金調達(ファンディング)の要件を増やします。
私は、この取引上のトレードオフが、実際にそれを検討している機関によってどのように評価されているのかは分かりませんし、取引する内容によって答えが変わるのではないかとも思っています。
ここから先は、決済スピードを単純なメリットとして読むのをやめました。それは、どちらの問題を抱えたいのかという選択なのです。
#dusk $DUSK @Dusk_Foundation Duskの古いリポジトリの中に、プロジェクト全体の見方を作り替えてくれたものがありました。 Succinct Attestation以前、DuskのコンセンサスはSegregated Byzantine Agreementと呼ばれていて、その中心にある仕組みはProof of Blind Bidでした。プライバシー志向のプルーフ・オブ・ステーク(PoS)プロトコルの実装であると説明されている「dusk-blindbidproof」というリポジトリ名も、今でも残っています。 もう一度読み直してください。入札した金額──あなたのステーク──が隠されている、という合意設計です。 それは、財務情報はデフォルトで公開されるべきではない、というチェーンの主張そのものと極めて整合的な発想です。残高には秘密性が必要だと考えるなら、なぜバリデータの残高だけ例外なのでしょう? 今日、それがまさにそうなっています。Provisionerのステークは公開されています。委員会選出はステークに重み付けされたソーティションで、ドキュメントには「ソーティションにおいて使用される“有効ステーク”を減らす」ことによるペナルティが記載されています。つまり、すべて見える。 なぜそうなるのか、という私の読みはこうです。なお、これはDuskの主張というより私の推論だという点を明確にしておきます。隠されたステークは、必要なほぼすべての要件と衝突します。スラッシングには帰属可能な不正行為が必要です。委員会が正しく選ばれたことを検証するには、重みを知る必要があります。制度的な取引相手(カウンターパーティ)は、誰が決済を担保しているのかを知りたいのです。ブラインド・ビッディングはエレガントですが、これらの問題をすべて、より難しくします。 なので、現実的な選択としてはおそらく正しかったのでしょう。とはいえトレードオフでもあります。機密性の理念はコンセンサス層で止まり、私はDuskがその境界を公に説明しているのを見たことがありません。 では、プライバシー・チェーンのバリデータも同様に非公開であるべきなのでしょうか?それとも、透明性のあるセキュリティが、規制された資産を任せられることに対する代償なのでしょうか?
#dusk $DUSK @Dusk Duskの古いリポジトリの中に、プロジェクト全体の見方を作り替えてくれたものがありました。
Succinct Attestation以前、DuskのコンセンサスはSegregated Byzantine Agreementと呼ばれていて、その中心にある仕組みはProof of Blind Bidでした。プライバシー志向のプルーフ・オブ・ステーク(PoS)プロトコルの実装であると説明されている「dusk-blindbidproof」というリポジトリ名も、今でも残っています。
もう一度読み直してください。入札した金額──あなたのステーク──が隠されている、という合意設計です。
それは、財務情報はデフォルトで公開されるべきではない、というチェーンの主張そのものと極めて整合的な発想です。残高には秘密性が必要だと考えるなら、なぜバリデータの残高だけ例外なのでしょう?
今日、それがまさにそうなっています。Provisionerのステークは公開されています。委員会選出はステークに重み付けされたソーティションで、ドキュメントには「ソーティションにおいて使用される“有効ステーク”を減らす」ことによるペナルティが記載されています。つまり、すべて見える。
なぜそうなるのか、という私の読みはこうです。なお、これはDuskの主張というより私の推論だという点を明確にしておきます。隠されたステークは、必要なほぼすべての要件と衝突します。スラッシングには帰属可能な不正行為が必要です。委員会が正しく選ばれたことを検証するには、重みを知る必要があります。制度的な取引相手(カウンターパーティ)は、誰が決済を担保しているのかを知りたいのです。ブラインド・ビッディングはエレガントですが、これらの問題をすべて、より難しくします。
なので、現実的な選択としてはおそらく正しかったのでしょう。とはいえトレードオフでもあります。機密性の理念はコンセンサス層で止まり、私はDuskがその境界を公に説明しているのを見たことがありません。
では、プライバシー・チェーンのバリデータも同様に非公開であるべきなのでしょうか?それとも、透明性のあるセキュリティが、規制された資産を任せられることに対する代償なのでしょうか?
Twitter、Discord、TelegramでDuskの議論を数週間スクロールしていると、ひとつのことがやけに目立っていました。 目にしたものの大半は価格に関する内容でした。チャート、ブレイク、目標、そしてDUSKが動くのかどうか。 その後、GitHubを開きました。 そこにはまったく別の光景がありました。 Duskは公開情報として、開発を3週間ごとのリリースサイクルに沿って進めていると説明しており、異なる部分のスタックにまたがるアクティブなリポジトリや、コミット履歴はいずれも数百件規模に及んでいます。 このギャップが、何が本当はより重要なのかを考えさせました。 たぶん無害です。市場は価格の話をします。ビルダーは作ります。プロダクトチームが、コミュニティのチャットで何が主流になっていようと関係なく出荷を続けているなら、問題はないのかもしれません。 ただ、別の可能性もあります。つまり、その技術の進歩が、それを取り巻く開発者エコシステムの進歩よりも速いということです。 それなら、より大きな問題になります。 チェーンは、コアチームがコードを出し続けるだけでは有用になりません。外部の開発者が、その上にアプリやビジネス、インフラを作ることを選んで初めて有用になります。 Duskには開発者向けのツール、ドキュメント、そして助成プログラムがあります。難しいのは、それらが十分な「引力」を生み出せているのかどうかです。 優れた技術だけではエコシステムは育ちません。 ビルダーには、使えるツール、資金、流通(ディストリビューション)、ユーザー、そして、他のどこかではなくここで数か月かけて作るだけの本当の理由が必要です。 もしコミュニティの注目がトークンに固定されたままで、ビルダー基盤が小さいままだと、やがて「技術」と「利用」のギャップのほうが、次のリリースよりも重要になってくるでしょう。 だから私は、価格中心の会話が無意味だとは思えません。 価格の話は単に、コミュニティにとって自然な振る舞いなのでしょうか。それとも、Duskの本当の有用性(ユーティリティ)という物語が、まだ多くの人に届いていないことを示しているのでしょうか? #dusk $DUSK @Dusk_Foundation
Twitter、Discord、TelegramでDuskの議論を数週間スクロールしていると、ひとつのことがやけに目立っていました。

目にしたものの大半は価格に関する内容でした。チャート、ブレイク、目標、そしてDUSKが動くのかどうか。

その後、GitHubを開きました。

そこにはまったく別の光景がありました。

Duskは公開情報として、開発を3週間ごとのリリースサイクルに沿って進めていると説明しており、異なる部分のスタックにまたがるアクティブなリポジトリや、コミット履歴はいずれも数百件規模に及んでいます。

このギャップが、何が本当はより重要なのかを考えさせました。

たぶん無害です。市場は価格の話をします。ビルダーは作ります。プロダクトチームが、コミュニティのチャットで何が主流になっていようと関係なく出荷を続けているなら、問題はないのかもしれません。

ただ、別の可能性もあります。つまり、その技術の進歩が、それを取り巻く開発者エコシステムの進歩よりも速いということです。

それなら、より大きな問題になります。

チェーンは、コアチームがコードを出し続けるだけでは有用になりません。外部の開発者が、その上にアプリやビジネス、インフラを作ることを選んで初めて有用になります。

Duskには開発者向けのツール、ドキュメント、そして助成プログラムがあります。難しいのは、それらが十分な「引力」を生み出せているのかどうかです。

優れた技術だけではエコシステムは育ちません。

ビルダーには、使えるツール、資金、流通(ディストリビューション)、ユーザー、そして、他のどこかではなくここで数か月かけて作るだけの本当の理由が必要です。

もしコミュニティの注目がトークンに固定されたままで、ビルダー基盤が小さいままだと、やがて「技術」と「利用」のギャップのほうが、次のリリースよりも重要になってくるでしょう。

だから私は、価格中心の会話が無意味だとは思えません。

価格の話は単に、コミュニティにとって自然な振る舞いなのでしょうか。それとも、Duskの本当の有用性(ユーティリティ)という物語が、まだ多くの人に届いていないことを示しているのでしょうか?

#dusk $DUSK @Dusk
TermMaxのアルファ・フィー・ページには、支払う保険料(プレミアム)に対して7%の取引手数料が記載されており、オプションの建玉の開始時と決済時の両方で課されます。 そして要約では、括弧書きで「アルファ・ブースティング・プログラム期間中は手数料無料」とされています。 つまり現時点でアルファ・オプションを取引する際の見出しコストはゼロです――一時的に。 その一語が、今月引用されているあらゆるアルファ指標の読み方を変えてしまいます。活動はプロモーション価格のもとで行われています。真の試験は、免除が解除されて、各取引の両方のレッグに対してプレミアムの7%が着地し始めるときに訪れます。 ただし、正確に言うと、今日のトレーダーは無料で取引しているわけではありません。撤去されたのは、3つのコストのうち最小のものです。 テイクプロフィット手数料は依然として課されます。プレミアムではなく想定元本(ノーション)に対して、1.9%から始まり満期に向けて直線的に減衰します。さらにファイナンスは、AMMレートに基づくノーションに対して1秒ごとに発生し続けます。 つまり免除されているのは、目に見える手数料だけです。ポジション規模と保有時間に比例して伸びる2つは、どちらもまだ稼働しています。 評価すべき点として、これは手数料のドキュメント自体に開示されています。キャンペーン用のバナーのどこかに埋め込まれているのではなく、完全なスケジュールのすぐ隣にあります。そこが正しい場所です。 私がどこを探しても見つけられなかったのは、ブースティング・プログラムの終了日です。これがないと、比較がいつ意味のあるものになるのか、トレーダーにどれくらいの予告があるのかを誰も判断できません。 これは正直、TermMax固有の話ではありません。業界のすべてのインセンティブ時代の数字に当てはまります。免除の下での出来高は「無料がどれほど魅力的か」を測ります。免除が終わった後の出来高は「そのプロダクト」を測ります。 手数料が戻ってきたら、現在の活動のうちどれだけが生き残ると思いますか? #termmax @termmax
TermMaxのアルファ・フィー・ページには、支払う保険料(プレミアム)に対して7%の取引手数料が記載されており、オプションの建玉の開始時と決済時の両方で課されます。
そして要約では、括弧書きで「アルファ・ブースティング・プログラム期間中は手数料無料」とされています。
つまり現時点でアルファ・オプションを取引する際の見出しコストはゼロです――一時的に。
その一語が、今月引用されているあらゆるアルファ指標の読み方を変えてしまいます。活動はプロモーション価格のもとで行われています。真の試験は、免除が解除されて、各取引の両方のレッグに対してプレミアムの7%が着地し始めるときに訪れます。
ただし、正確に言うと、今日のトレーダーは無料で取引しているわけではありません。撤去されたのは、3つのコストのうち最小のものです。
テイクプロフィット手数料は依然として課されます。プレミアムではなく想定元本(ノーション)に対して、1.9%から始まり満期に向けて直線的に減衰します。さらにファイナンスは、AMMレートに基づくノーションに対して1秒ごとに発生し続けます。
つまり免除されているのは、目に見える手数料だけです。ポジション規模と保有時間に比例して伸びる2つは、どちらもまだ稼働しています。
評価すべき点として、これは手数料のドキュメント自体に開示されています。キャンペーン用のバナーのどこかに埋め込まれているのではなく、完全なスケジュールのすぐ隣にあります。そこが正しい場所です。
私がどこを探しても見つけられなかったのは、ブースティング・プログラムの終了日です。これがないと、比較がいつ意味のあるものになるのか、トレーダーにどれくらいの予告があるのかを誰も判断できません。
これは正直、TermMax固有の話ではありません。業界のすべてのインセンティブ時代の数字に当てはまります。免除の下での出来高は「無料がどれほど魅力的か」を測ります。免除が終わった後の出来高は「そのプロダクト」を測ります。
手数料が戻ってきたら、現在の活動のうちどれだけが生き残ると思いますか?

#termmax @TermMax
「『アトミック・セトルメント(Atomic settlement)』」は、トークン化において最も繰り返し用いられるフレーズの一つです。そしてそれは、意味のあるものとして成立するためにどれほどの条件が必要かを、静かに見えなくしています。 アトミック・セトルメントとは、資産レグと支払いレグが同時に動く、またはどちらも動かないこと。これだけです。ですが、それを口にした瞬間に必要なのは、「一つ」ではなく「同じレール上にある三つ」の条件です。 まず「資産レグ」です。これはトークン化された有価証券であり、暗号資産が本当に得意とする領域の部分です。 次に「支払いレグ」。現金は、同じインフラ上で、同じ瞬間に決済されなければなりません。そして、規制された取引所(レギュレーテッドな会場)が法的に受け入れ可能な形である必要があります。だからこそ、@Dusk_Foundation が規制ユーロ・ステーブルコインに関してQuantozと組むことは、その発表が示していた以上に重要なのです。コンプライアンスを満たす現金レグがなければ、「atomic DvP」は、別の日にクリアされるトークン・トランスファーと銀行振込へと逆戻りします。これはまさに、トークン化が消し去るはずだった照合(リコンシリエーション)の問題です。 そして「カストディ・レグ(custody leg)」です。機関は無記名の受領者保有(ベアラ)型のインストゥルメントを自社で自己保管しません。これがCordial Systemsの要素であり、三つのうち最も語られていません。 私が本当に面白いと思うのは、三つが2025年2月にそれぞれおよそ1週間のうちに同時期に到着したことです。まずステーブルコイン、その次にカストディのパートナー。これは、日和見的な発表というより、意図的な順序に見えます。つまり、決済をうたう前にレグを揃えるのです。 正直なギャップはこうです。構成要素として名前が挙がっているのは分かります。ですが、三つのレグがライブ取引をエンドツーエンドで決済していることを示す公開の証拠は見えていません。私が実際にカレンダーに印を付けるべきマイルストーンは、そこです。 RWAウォッチャーの皆さんへ。実際のボリュームが出たとき、どのレグが最初に破綻すると思いますか?資産、現金、それともカストディですか? #dusk $DUSK @Dusk_Foundation
「『アトミック・セトルメント(Atomic settlement)』」は、トークン化において最も繰り返し用いられるフレーズの一つです。そしてそれは、意味のあるものとして成立するためにどれほどの条件が必要かを、静かに見えなくしています。
アトミック・セトルメントとは、資産レグと支払いレグが同時に動く、またはどちらも動かないこと。これだけです。ですが、それを口にした瞬間に必要なのは、「一つ」ではなく「同じレール上にある三つ」の条件です。
まず「資産レグ」です。これはトークン化された有価証券であり、暗号資産が本当に得意とする領域の部分です。
次に「支払いレグ」。現金は、同じインフラ上で、同じ瞬間に決済されなければなりません。そして、規制された取引所(レギュレーテッドな会場)が法的に受け入れ可能な形である必要があります。だからこそ、@Dusk が規制ユーロ・ステーブルコインに関してQuantozと組むことは、その発表が示していた以上に重要なのです。コンプライアンスを満たす現金レグがなければ、「atomic DvP」は、別の日にクリアされるトークン・トランスファーと銀行振込へと逆戻りします。これはまさに、トークン化が消し去るはずだった照合(リコンシリエーション)の問題です。
そして「カストディ・レグ(custody leg)」です。機関は無記名の受領者保有(ベアラ)型のインストゥルメントを自社で自己保管しません。これがCordial Systemsの要素であり、三つのうち最も語られていません。
私が本当に面白いと思うのは、三つが2025年2月にそれぞれおよそ1週間のうちに同時期に到着したことです。まずステーブルコイン、その次にカストディのパートナー。これは、日和見的な発表というより、意図的な順序に見えます。つまり、決済をうたう前にレグを揃えるのです。
正直なギャップはこうです。構成要素として名前が挙がっているのは分かります。ですが、三つのレグがライブ取引をエンドツーエンドで決済していることを示す公開の証拠は見えていません。私が実際にカレンダーに印を付けるべきマイルストーンは、そこです。
RWAウォッチャーの皆さんへ。実際のボリュームが出たとき、どのレグが最初に破綻すると思いますか?資産、現金、それともカストディですか?

#dusk $DUSK @Dusk
Duskの仕組みがどのように証明を生成するかを読み始めて以来、ずっと気になっている小さなことがある。 ゼロ知識証明は高コストです。あなたの電話はそれをやりたがりません。そこでDuskは抜け道を用意します。wallet-coreは、証明生成を外部のProverに委任できるようにしていて、Proverは実際に実行できるドキュメント化されたノードタイプです。ProvisionerやArchiveと並んで使えます。 それは筋の通ったエンジニアリング上の回答です。これを導入するエンジニアリングアップデートでは、委任は可塑性(malleability)を避けるよう設計されている、と明記されています。つまりProverは、あなたが依頼した内容をこっそり改変できない。 ただし委任は、いつも一つの疑問に答えつつ、別の疑問を生みます。可塑性とは、Proverがあなたのトランザクションを変更できるかどうかの話です。それは、Proverがあなたのために証明を組み立てる際に何を見られるのか、という問題とは同じではありません。 ではHedgerを並べて見てください。EVM側についてのHedgerの売り文句は、まったく逆です。軽量な回路、ブラウザ上で2秒未満のクライアント側での証明生成。第三のマシンは不要です。 だから@Dusk_Foundation は、同じスタックの中に両方の形を持っています。重いネイティブ回路向けの委任型の証明経路と、秘密に関わるEVMレイヤー向けのローカル証明経路。 どちらも間違っているとは思いません。ローカル証明はプライバシー面ではよりクリーンですが、弱いデバイスには不利です。委任型はその逆です。ほとんどのチェーンはどちらかを選んで、それ以上は議論を止めています。 ただ、ドキュメントからはまだ分からない点があります。通常のユーザーは、いまの時点で自分がどちらを使っているのかをどうやって知ることになっているのか。銀行がクライアントを載せる前に、ここは明確にしてほしいところです。 もし、あなたのプライバシー用の証明を代わりに生成してくれるサービスがあって、より速く、無料だったら——それを使いますか?それとも、あなたにとっては肝心な点が損なわれることになりますか? #dusk $DUSK @Dusk_Foundation
Duskの仕組みがどのように証明を生成するかを読み始めて以来、ずっと気になっている小さなことがある。
ゼロ知識証明は高コストです。あなたの電話はそれをやりたがりません。そこでDuskは抜け道を用意します。wallet-coreは、証明生成を外部のProverに委任できるようにしていて、Proverは実際に実行できるドキュメント化されたノードタイプです。ProvisionerやArchiveと並んで使えます。
それは筋の通ったエンジニアリング上の回答です。これを導入するエンジニアリングアップデートでは、委任は可塑性(malleability)を避けるよう設計されている、と明記されています。つまりProverは、あなたが依頼した内容をこっそり改変できない。
ただし委任は、いつも一つの疑問に答えつつ、別の疑問を生みます。可塑性とは、Proverがあなたのトランザクションを変更できるかどうかの話です。それは、Proverがあなたのために証明を組み立てる際に何を見られるのか、という問題とは同じではありません。
ではHedgerを並べて見てください。EVM側についてのHedgerの売り文句は、まったく逆です。軽量な回路、ブラウザ上で2秒未満のクライアント側での証明生成。第三のマシンは不要です。
だから@Dusk は、同じスタックの中に両方の形を持っています。重いネイティブ回路向けの委任型の証明経路と、秘密に関わるEVMレイヤー向けのローカル証明経路。
どちらも間違っているとは思いません。ローカル証明はプライバシー面ではよりクリーンですが、弱いデバイスには不利です。委任型はその逆です。ほとんどのチェーンはどちらかを選んで、それ以上は議論を止めています。
ただ、ドキュメントからはまだ分からない点があります。通常のユーザーは、いまの時点で自分がどちらを使っているのかをどうやって知ることになっているのか。銀行がクライアントを載せる前に、ここは明確にしてほしいところです。
もし、あなたのプライバシー用の証明を代わりに生成してくれるサービスがあって、より速く、無料だったら——それを使いますか?それとも、あなたにとっては肝心な点が損なわれることになりますか?

#dusk $DUSK @Dusk
シタデルを間違えて理解していました。オンチェーンのKYCだと勘違いしていたんです。つまり、一度確認されるとバッジがあなたのウォレットアドレスにスタンプされ、すべてのアプリがそのバッジを読み取って入場を許可する——というような仕組みだと思っていました。そこで、$DUSK ' のドキュメントの1行を読んで、メモを書き直す必要が出ました。シタデルはセッションが暗号学的に有効であることを証明しますが、サービスのポリシーを決めるのはシタデルではありません。 (DOCS) 以下が実際の流れです。あなたは、あなたのドキュメントを取り扱うことを許可された事業者(License Provider)にライセンスを要求します。ライセンスは単なる秘密の資格情報です。LPはオフチェーンであなたを審査し、属性データに署名し、暗号化したライセンスを公開して、それをシタデルのコントラクトに登録します。 (DOCS) 次に、何かへのアクセスが必要になったとき、あなたはLPによって署名された登録済みライセンスを保有していることを示すゼロ知識証明を生成します——ただし、どのライセンスかは開示しません。 (DOCS) コントラクトはその証明を検証し、公開セッションを記録します。 (DOCS) その後、あなたはセッションクッキー(ライセンスが正しく使用されたことを示す短い値)をサービスプロバイダーに渡します。 ドキュメントでは、オンチェーンに載らないものが正確に明記されています。あなたのウォレット鍵でもありませんし、使用したライセンスでもありません。LPやSPの鍵でもありません。署名された属性でもありません。さらに、登録済みセットの中であなたのライセンスがどこにあるかを明らかにしうるメルクルパスでもありません (DOCS)。 制限はあっさりと書かれています。SPは依然として、どのLPを信頼するか、どの属性を受け付けるか、セッションが期限切れまたは無効化(revoked)されているか、そしてクッキーを再利用できるかどうかを選択します。 (DOCS) 信頼の問題は消えません。台帳(レジャー)から外れて、会社の中で行われるポリシー判断へ移るだけです。完全なJavaScript SDKは依然として「近日公開」として記載されているため (DOCS)、現時点の開発者向けの表面はRustとCLIウォレットです。 ポリシーをオフチェーンに移すのはおそらく正しいと思います。規制は、デプロイ済みのコントラクトよりも速く変わるからです。けれども、だからといって「信頼不要なコンプライアンス」はスローガンであって、説明にはなっていません。 それでは、認定(アクレディテーション)の判断はどこに置かれるべきなのでしょうか:) コントラクトの中か、それとも会場(venue)の側か? そして、あなたならその2つのうちどちらに判断を委ねたいですか? #dusk @Dusk_Foundation $DOCS.US
シタデルを間違えて理解していました。オンチェーンのKYCだと勘違いしていたんです。つまり、一度確認されるとバッジがあなたのウォレットアドレスにスタンプされ、すべてのアプリがそのバッジを読み取って入場を許可する——というような仕組みだと思っていました。そこで、$DUSK ' のドキュメントの1行を読んで、メモを書き直す必要が出ました。シタデルはセッションが暗号学的に有効であることを証明しますが、サービスのポリシーを決めるのはシタデルではありません。 (DOCS)
以下が実際の流れです。あなたは、あなたのドキュメントを取り扱うことを許可された事業者(License Provider)にライセンスを要求します。ライセンスは単なる秘密の資格情報です。LPはオフチェーンであなたを審査し、属性データに署名し、暗号化したライセンスを公開して、それをシタデルのコントラクトに登録します。 (DOCS) 次に、何かへのアクセスが必要になったとき、あなたはLPによって署名された登録済みライセンスを保有していることを示すゼロ知識証明を生成します——ただし、どのライセンスかは開示しません。 (DOCS) コントラクトはその証明を検証し、公開セッションを記録します。 (DOCS) その後、あなたはセッションクッキー(ライセンスが正しく使用されたことを示す短い値)をサービスプロバイダーに渡します。
ドキュメントでは、オンチェーンに載らないものが正確に明記されています。あなたのウォレット鍵でもありませんし、使用したライセンスでもありません。LPやSPの鍵でもありません。署名された属性でもありません。さらに、登録済みセットの中であなたのライセンスがどこにあるかを明らかにしうるメルクルパスでもありません (DOCS)。
制限はあっさりと書かれています。SPは依然として、どのLPを信頼するか、どの属性を受け付けるか、セッションが期限切れまたは無効化(revoked)されているか、そしてクッキーを再利用できるかどうかを選択します。 (DOCS) 信頼の問題は消えません。台帳(レジャー)から外れて、会社の中で行われるポリシー判断へ移るだけです。完全なJavaScript SDKは依然として「近日公開」として記載されているため (DOCS)、現時点の開発者向けの表面はRustとCLIウォレットです。
ポリシーをオフチェーンに移すのはおそらく正しいと思います。規制は、デプロイ済みのコントラクトよりも速く変わるからです。けれども、だからといって「信頼不要なコンプライアンス」はスローガンであって、説明にはなっていません。
それでは、認定(アクレディテーション)の判断はどこに置かれるべきなのでしょうか:) コントラクトの中か、それとも会場(venue)の側か? そして、あなたならその2つのうちどちらに判断を委ねたいですか?

#dusk @Dusk $DOCS.US
確認済み
この前提を置いている自覚が、文書でそれが否定されているのを見て初めて出てきました。「金庫(バルタ)からの “withdraw(引き出し)” は、自分が入れたのとまったく同じ資産を取り戻すことを意味する」という点です。しかしTermMax自身のリスク文書では、それが保証されないとされています。 仕組みはこうです。金庫は、たとえばUSDCのような1つの負債トークン建てで、そこに対してERC-4626のシェアを発行します。金庫がエクスポージャーを持つ市場で、ローンが完全に清算(liquidated)されない場合、現物引き渡しが発動し、その結果、基礎となる担保――ETH、PTトークンなど――がキャッシュではなく金庫に入ってきます。流動性が薄い状態で退出しようとすると、利用可能な流動性が不足しているときは、流入する流動性を待てる、または金庫シェアを焼却(burn)して、引き渡された担保を直接請求できる、とドキュメントには書かれています。いずれにせよ、「withdraw」は、入金時に自分が想定していたものとは別の意味になり得ます。 私が引っかかっているのは、これがどこに書かれているかです。TermMaxのリスクページに、あくまで平易に明記されています。これは、金庫商品が自分たちを説明する際に使う言葉の中には出てきません。たとえば、先行する<b>@termmax </b>のコピーが「いつでも」引き出せると約束しているようにです。開示とマーケティングが別々の台本から読んでいます。 このリスクは、金庫が吸収したからといって消えたわけではありません。退出が、自分が入金画面で見ている資産で決済されるはずだと考えた人のところへ移っただけです。 代わりに担保を渡してくれるステーブルコインの金庫は、やはりステーブルコインの金庫と言えるのか、それとも同じラベルを着た別の商品なのでしょうか? #termmax $ETH $USDC
この前提を置いている自覚が、文書でそれが否定されているのを見て初めて出てきました。「金庫(バルタ)からの “withdraw(引き出し)” は、自分が入れたのとまったく同じ資産を取り戻すことを意味する」という点です。しかしTermMax自身のリスク文書では、それが保証されないとされています。
仕組みはこうです。金庫は、たとえばUSDCのような1つの負債トークン建てで、そこに対してERC-4626のシェアを発行します。金庫がエクスポージャーを持つ市場で、ローンが完全に清算(liquidated)されない場合、現物引き渡しが発動し、その結果、基礎となる担保――ETH、PTトークンなど――がキャッシュではなく金庫に入ってきます。流動性が薄い状態で退出しようとすると、利用可能な流動性が不足しているときは、流入する流動性を待てる、または金庫シェアを焼却(burn)して、引き渡された担保を直接請求できる、とドキュメントには書かれています。いずれにせよ、「withdraw」は、入金時に自分が想定していたものとは別の意味になり得ます。
私が引っかかっているのは、これがどこに書かれているかです。TermMaxのリスクページに、あくまで平易に明記されています。これは、金庫商品が自分たちを説明する際に使う言葉の中には出てきません。たとえば、先行する<b>@TermMax </b>のコピーが「いつでも」引き出せると約束しているようにです。開示とマーケティングが別々の台本から読んでいます。
このリスクは、金庫が吸収したからといって消えたわけではありません。退出が、自分が入金画面で見ている資産で決済されるはずだと考えた人のところへ移っただけです。
代わりに担保を渡してくれるステーブルコインの金庫は、やはりステーブルコインの金庫と言えるのか、それとも同じラベルを着た別の商品なのでしょうか?

#termmax $ETH $USDC
·
--
弱気相場
#dusk $DUSK @Dusk_Foundation Duskの全スタックはモジュール式に構築されています。DuskDSは決済およびデータ可用性レイヤーであり、Succinct Attestationコンセンサスを実行し、ステーキングを扱い、基礎となるDUSK資産を保持します。DuskEVMは独立したSolidity互換の実行レイヤーで、OP Stack(op-gethを動かすシーケンサーと、トランザクションデータをブロブとしてDuskDSに投稿するバッチャー)上に構築されており、独自のインディペンデントなセキュリティに依存するのではなく、DuskDSへ決済を戻します。DuskVMはさらに、Rust/WASMコントラクト向けのネイティブ実行環境で、ネイティブなプライバシーやプロトコルレベルの統合を必要とするアプリケーションを対象に、まだ新しく立ち上がりつつあります。PiecrustはWasmランタイム(Wasmerに基づく)で、もともとはDuskDSに組み込まれていましたが、現在はDuskVMへ抽出されています。ネットワーキングはKadcast上で動作します。これは、ランダムなゴシップではなく、構造化されたKademliaスタイルのブロードキャストプロトコルです。 このアーキテクチャの背景にある考え方は、「すべてのための1つの実行環境」では、DeFi型の合成可能性と規制対象の資産発行を同時に提供しようとするチェーンではうまく機能しない、というものです。Solidity開発者をネイティブのRust/WASM環境に無理に寄せるのではなく、あるいはネイティブなプライバシーアプリケーションをEVMの制約に無理に押し込むのでもなく、決済とコンセンサスは共通のベースレイヤーに置き、実行環境はその上で専門化します。Kadcastも同様のロジックに合致しています。構造化されたブロードキャストは、最終性を確率的に扱うチェーンよりも、「決定的な最終性」を主張するチェーンにとって重要となる、より予測可能な帯域幅とレイテンシをもたらすからです。 実行と決済を分離することは、さらに、DuskEVMの保証の強さが、それをDuskDSへ接続するブリッジとバッチング機構にしか依存しないことも意味します。DuskVMがDuskEVMと並行して成熟していくにつれ、ネットワークは1つの決済レイヤーに対して3つの実行サーフェスを走らせることになります。この分割は本当に、開発者の統合の摩擦を減らすのでしょうか。それとも、「どのVMを使うべきか」という複雑さを、「私の保証を実際に保持しているのはどのレイヤーか」という複雑さへ移しただけなのでしょうか?
#dusk $DUSK @Dusk
Duskの全スタックはモジュール式に構築されています。DuskDSは決済およびデータ可用性レイヤーであり、Succinct Attestationコンセンサスを実行し、ステーキングを扱い、基礎となるDUSK資産を保持します。DuskEVMは独立したSolidity互換の実行レイヤーで、OP Stack(op-gethを動かすシーケンサーと、トランザクションデータをブロブとしてDuskDSに投稿するバッチャー)上に構築されており、独自のインディペンデントなセキュリティに依存するのではなく、DuskDSへ決済を戻します。DuskVMはさらに、Rust/WASMコントラクト向けのネイティブ実行環境で、ネイティブなプライバシーやプロトコルレベルの統合を必要とするアプリケーションを対象に、まだ新しく立ち上がりつつあります。PiecrustはWasmランタイム(Wasmerに基づく)で、もともとはDuskDSに組み込まれていましたが、現在はDuskVMへ抽出されています。ネットワーキングはKadcast上で動作します。これは、ランダムなゴシップではなく、構造化されたKademliaスタイルのブロードキャストプロトコルです。

このアーキテクチャの背景にある考え方は、「すべてのための1つの実行環境」では、DeFi型の合成可能性と規制対象の資産発行を同時に提供しようとするチェーンではうまく機能しない、というものです。Solidity開発者をネイティブのRust/WASM環境に無理に寄せるのではなく、あるいはネイティブなプライバシーアプリケーションをEVMの制約に無理に押し込むのでもなく、決済とコンセンサスは共通のベースレイヤーに置き、実行環境はその上で専門化します。Kadcastも同様のロジックに合致しています。構造化されたブロードキャストは、最終性を確率的に扱うチェーンよりも、「決定的な最終性」を主張するチェーンにとって重要となる、より予測可能な帯域幅とレイテンシをもたらすからです。

実行と決済を分離することは、さらに、DuskEVMの保証の強さが、それをDuskDSへ接続するブリッジとバッチング機構にしか依存しないことも意味します。DuskVMがDuskEVMと並行して成熟していくにつれ、ネットワークは1つの決済レイヤーに対して3つの実行サーフェスを走らせることになります。この分割は本当に、開発者の統合の摩擦を減らすのでしょうか。それとも、「どのVMを使うべきか」という複雑さを、「私の保証を実際に保持しているのはどのレイヤーか」という複雑さへ移しただけなのでしょうか?
#dusk $DUSK @Dusk_Foundation Duskの中核コンポーネントを読み進める中で、つい見落としがちな点に気づきました。規制対象資産を発行・管理するためのプロトコルが2つあり、1つだけではないのです。ZedgerはDuskDS上でネイティブに動作します。DuskDSはベースの決済レイヤーです。Hedgerはその上にあるEthereum互換の実行環境であるDuskEVM上で動作します。どちらも同じ考え方をベースにしています。つまり、資産そのものの発行・管理の仕方に、コンプライアンスとプライバシーの制約を組み込むことです。ただし、それを2つの異なる環境で実装しているだけです。 最初に湧いた疑問は、「実質的に同じ規制ロジックを2つも維持するのなら、1つに絞って全員にそれへ対応させた方がよいのでは?」というものでした。ですが、実際に規制対象の有価証券を発行するのは誰なのかを考えると、より納得がいきます。機関の既存のツール群、監査プロセス、開発チームは、別の決済レイヤーの方が効率的だからといってリセットされるわけではありません。EVM向けのツール群を前提に、すでに発行体側の法務・コンプライアンス体制が深く作り込まれているところもあれば、ゼロから始められる状態でネイティブに構築できるところもあります。制約セットを2つの入口で同じように提供することで、どちらのグループにも現状の延長線上で対応してもらえ、単一の移行経路を全員に押し付けることを避けられます。 ただし、その柔軟性にはコストもあります。コンプライアンスに敏感なプロトコルを2つ実装するということは、規制要件が変化していく中で、それぞれを独立して監査し、独立して同期を保ち、さらに時間の経過とともに微妙に乖離しないように独立して信頼する必要がある、ということです。片方にだけ出て、もう片方には出ないようなバグや不整合は、単一の統合実装なら管理しなくて済むリスクの一類型になります。 ですから、実務的に問うべきなのは、「ネイティブ対EVMの任意性がそもそも良いアイデアかどうか」ではありません。これは、発行体の種類に応じた参入障壁を下げることにつながるので、明らかに意義があります。問題は、規制対象資産の発行に実際に必要とされる保証のレベルにおいて、Duskが2つのプロトコルを同一に振る舞わせ続けられるかどうかです。特に、それぞれが独自の実行環境で時間とともに発展していく場合に、その点が維持できるかどうかが鍵になります。 $DUSK
#dusk $DUSK @Dusk

Duskの中核コンポーネントを読み進める中で、つい見落としがちな点に気づきました。規制対象資産を発行・管理するためのプロトコルが2つあり、1つだけではないのです。ZedgerはDuskDS上でネイティブに動作します。DuskDSはベースの決済レイヤーです。Hedgerはその上にあるEthereum互換の実行環境であるDuskEVM上で動作します。どちらも同じ考え方をベースにしています。つまり、資産そのものの発行・管理の仕方に、コンプライアンスとプライバシーの制約を組み込むことです。ただし、それを2つの異なる環境で実装しているだけです。

最初に湧いた疑問は、「実質的に同じ規制ロジックを2つも維持するのなら、1つに絞って全員にそれへ対応させた方がよいのでは?」というものでした。ですが、実際に規制対象の有価証券を発行するのは誰なのかを考えると、より納得がいきます。機関の既存のツール群、監査プロセス、開発チームは、別の決済レイヤーの方が効率的だからといってリセットされるわけではありません。EVM向けのツール群を前提に、すでに発行体側の法務・コンプライアンス体制が深く作り込まれているところもあれば、ゼロから始められる状態でネイティブに構築できるところもあります。制約セットを2つの入口で同じように提供することで、どちらのグループにも現状の延長線上で対応してもらえ、単一の移行経路を全員に押し付けることを避けられます。

ただし、その柔軟性にはコストもあります。コンプライアンスに敏感なプロトコルを2つ実装するということは、規制要件が変化していく中で、それぞれを独立して監査し、独立して同期を保ち、さらに時間の経過とともに微妙に乖離しないように独立して信頼する必要がある、ということです。片方にだけ出て、もう片方には出ないようなバグや不整合は、単一の統合実装なら管理しなくて済むリスクの一類型になります。

ですから、実務的に問うべきなのは、「ネイティブ対EVMの任意性がそもそも良いアイデアかどうか」ではありません。これは、発行体の種類に応じた参入障壁を下げることにつながるので、明らかに意義があります。問題は、規制対象資産の発行に実際に必要とされる保証のレベルにおいて、Duskが2つのプロトコルを同一に振る舞わせ続けられるかどうかです。特に、それぞれが独自の実行環境で時間とともに発展していく場合に、その点が維持できるかどうかが鍵になります。

$DUSK
「TradFiがオンチェーンに来る」というスレッドを読むたびに、同じ矛盾に気づいてしまいます。誰もが債券のトークン化、ファンド、クレジット…にワクワクしているのに、なぜまだ大規模に実現していないのか、肝心の“本当の理由”は誰も語りません。スループットの問題でもありません。カストディの問題でもありません。すべての競合や無作為のウォッチャーが取引の規模、価格、そして誰が背後にいるのかを見られる、公開台帳に銀行が取引を載せられない——それが壁です。Duskはその壁に座っているように見えます。歩き回って避けるのではなく。 多くの人はDuskを「プライバシーチェーン」と呼びますが、もっと興味深いのは、Duskが同時に相反する2つの要件を解決しようとしている点です。規制当局は、誰が取引しているのか、そしてルールが守られたことを知る必要があります。一方、機関は機密性を必要とします——公開チェーンにポジション規模やカウンターパーティを晒せない。通常は、どちらか一方を選びます。Duskは、ゼロ知識アイデンティティ層であるCitadelを通じて、ユーザーが自分がコンプライアンスに適合していること——検証済み、参加資格あり、制裁対象ではない——を、ネットワーク全体に「自分が誰か」をブロードキャストせずに証明できます。コンプライアンスから逃げるのではなく、機微な活動を不要な公開の露出から遠ざける。 オンチェーンでトークン化されたRWAの価値は2026年半ばまでずっと$30B超を維持し、BlackRockとFranklin Templetonはトークン化されたトレジャリーですでに活動を始めています。ただし、そのほとんどはプライベートには動いていません。基本的に“デフォルトで透明”なインフラに、コンプライアンスのラベルを貼っているに近い。Duskは、機関が最初に本当に必要になるであろうプライバシー層を作ろうとしている数少ないチェーンの一つです。 とはいえDUSK自体は、その主張が検証されるのを待つプロジェクトのような値動きのまま——約6.5セント、CoinMarketCapで見た時価総額は約3,200万ドル程度。RWAの物語の中で見れば、その規模は小さい位置づけです。 まだ考えていることがあります。ゼロ知識証明への規制当局の信頼が、ここでの最後の“本当の障壁”なのか。それとも、TradFiは「可視性を手放すこと」について別の何かを受け入れないのか。 #dusk $DUSK @Dusk_Foundation
「TradFiがオンチェーンに来る」というスレッドを読むたびに、同じ矛盾に気づいてしまいます。誰もが債券のトークン化、ファンド、クレジット…にワクワクしているのに、なぜまだ大規模に実現していないのか、肝心の“本当の理由”は誰も語りません。スループットの問題でもありません。カストディの問題でもありません。すべての競合や無作為のウォッチャーが取引の規模、価格、そして誰が背後にいるのかを見られる、公開台帳に銀行が取引を載せられない——それが壁です。Duskはその壁に座っているように見えます。歩き回って避けるのではなく。

多くの人はDuskを「プライバシーチェーン」と呼びますが、もっと興味深いのは、Duskが同時に相反する2つの要件を解決しようとしている点です。規制当局は、誰が取引しているのか、そしてルールが守られたことを知る必要があります。一方、機関は機密性を必要とします——公開チェーンにポジション規模やカウンターパーティを晒せない。通常は、どちらか一方を選びます。Duskは、ゼロ知識アイデンティティ層であるCitadelを通じて、ユーザーが自分がコンプライアンスに適合していること——検証済み、参加資格あり、制裁対象ではない——を、ネットワーク全体に「自分が誰か」をブロードキャストせずに証明できます。コンプライアンスから逃げるのではなく、機微な活動を不要な公開の露出から遠ざける。

オンチェーンでトークン化されたRWAの価値は2026年半ばまでずっと$30B超を維持し、BlackRockとFranklin Templetonはトークン化されたトレジャリーですでに活動を始めています。ただし、そのほとんどはプライベートには動いていません。基本的に“デフォルトで透明”なインフラに、コンプライアンスのラベルを貼っているに近い。Duskは、機関が最初に本当に必要になるであろうプライバシー層を作ろうとしている数少ないチェーンの一つです。

とはいえDUSK自体は、その主張が検証されるのを待つプロジェクトのような値動きのまま——約6.5セント、CoinMarketCapで見た時価総額は約3,200万ドル程度。RWAの物語の中で見れば、その規模は小さい位置づけです。

まだ考えていることがあります。ゼロ知識証明への規制当局の信頼が、ここでの最後の“本当の障壁”なのか。それとも、TradFiは「可視性を手放すこと」について別の何かを受け入れないのか。

#dusk $DUSK @Dusk
確認済み
ヘッジャーとプライバシー プライバシーとは通常、すべてを隠すことを意味します。Duskのヘッジャーは、その概念を静かに再定義します。 DuskEVM専用に構築されており、2つの異なる暗号技術を組み合わせています——楕円曲線上でのElGamalベースの準同型暗号により、暗号化された値のまま計算を実行し、その値を明かさずに処理できます。そしてゼロ知識証明により、基となる入力を公開することなく、その計算が正しく行われたことを確認します。要するに、ネットワークは数値を一度も見ずに、計算が正しいかどうかを検証できるのです。 注目すべきは、Duskの他のプライバシーシステムであるZedgerとの違いです。ZedgerはUTXOベースのレイヤー向けに作られています。一方でヘッジャーはEVM環境専用に構築されています。つまり、馴染みのあるEthereum風のツールを使っている開発者が、そのスタックを捨てることなく、機密性のある残高、所有権、そして送金を構築できます。 しかし本当の目的は、取引を隠すことだけではありません。同時に監査可能性も保持することにあります。規制のある金融では、プライバシーと説明責任は通常、逆方向に引っ張られます——一方が増えるほど、もう一方が減りがちです。ヘッジャーが本当に両立できるかどうかが、ここでの本当の試験であり、暗号そのものではありません。 また、長期的に注目すべき観点もあります。意図やポジションを開示しないことを目的とした、秘匿化されたオーダーブックのための土台です。これはまだ初期段階で、実運用にはまだ至っていません。 プライバシーと監査可能性が、同じシステム内で本当に共存できるなら、それは実際に規制当局を満足させるのでしょうか——それとも、より技術的に複雑な妥協に過ぎないのでしょうか? #dusk $DUSK @Dusk_Foundation
ヘッジャーとプライバシー
プライバシーとは通常、すべてを隠すことを意味します。Duskのヘッジャーは、その概念を静かに再定義します。
DuskEVM専用に構築されており、2つの異なる暗号技術を組み合わせています——楕円曲線上でのElGamalベースの準同型暗号により、暗号化された値のまま計算を実行し、その値を明かさずに処理できます。そしてゼロ知識証明により、基となる入力を公開することなく、その計算が正しく行われたことを確認します。要するに、ネットワークは数値を一度も見ずに、計算が正しいかどうかを検証できるのです。
注目すべきは、Duskの他のプライバシーシステムであるZedgerとの違いです。ZedgerはUTXOベースのレイヤー向けに作られています。一方でヘッジャーはEVM環境専用に構築されています。つまり、馴染みのあるEthereum風のツールを使っている開発者が、そのスタックを捨てることなく、機密性のある残高、所有権、そして送金を構築できます。
しかし本当の目的は、取引を隠すことだけではありません。同時に監査可能性も保持することにあります。規制のある金融では、プライバシーと説明責任は通常、逆方向に引っ張られます——一方が増えるほど、もう一方が減りがちです。ヘッジャーが本当に両立できるかどうかが、ここでの本当の試験であり、暗号そのものではありません。
また、長期的に注目すべき観点もあります。意図やポジションを開示しないことを目的とした、秘匿化されたオーダーブックのための土台です。これはまだ初期段階で、実運用にはまだ至っていません。
プライバシーと監査可能性が、同じシステム内で本当に共存できるなら、それは実際に規制当局を満足させるのでしょうか——それとも、より技術的に複雑な妥協に過ぎないのでしょうか?

#dusk $DUSK @Dusk
確認済み
Citadelのライセンスフローがアイデンティティ漏えいなしにコンプライアンスをどう解決するのか、実際に仕組みを一つずつ検討するのに時間を費やしましたが、そのメカニズムは「プライバシーを保護するKYC」という一行の示唆よりもずっと面白いです。 ライセンス提供者 — たとえば規制されたオンボーディングの主体 — が通常どおりオフチェーンでユーザーを確認し、そのうえで特定の属性について署名付きのアテステーションを作成して、暗号化されたライセンスをオンチェーンに登録します。ユーザーは、利用したいすべてのサービスに対して毎回書類をアップロードし直すことはありません。代わりに、サービス提供者が適格性の証明を必要とする際、ユーザーは有効な、プロバイダー署名のライセンスを保有していることを示すゼロ知識証明を生成します。これにより、ウォレットも、基礎となる属性も、どの特定のライセンスが証明を生んだのかも開示せずに済みます。サービス提供者はその証明を検証し、アイデンティティではなくセッションを記録します。 ここで実際に分散されているのは、コンプライアンス判断そのものではありません。分散されているのは、開示(ディスクロージャー)のイベントです。信頼の問題は消えませんが、場所が移ります。サービス提供者は、どのライセンス提供者を信頼するか、そしてどの属性がそのルールを満たすかを、依然として自分で決めます。Citadelは規制上の判断を置き換えるのではなく、その判断を、生の個人データに対して毎回行う必要をなくします。 フラグを立てておきたいポイントは、これはリピート検証モデルであってワンタイムのバッジではないということです。セッションは期限切れになり、無効化され、あるいは適格性条件の変化に応じて更新が必要になります。セキュリティトークン・プラットフォームにとって、こうした「引き続き適格である」ことの再証明は、その上に乗っているプライバシー層よりも、実際のプロダクトにより近いのではないでしょうか。規制された場は、「一度適格だった」ことを知るだけでは不十分で、重大な変更がないことを継続的に保証する必要があるからです。 正直な言い方をすると、Citadelは単一の信頼ポイントを「あなたのデータを目にするすべての相手」から「誰もが受け入れる署名を持つ、少数のライセンス提供者」へ移します。これはより小さな攻撃対象なのでしょうか、それとも単により集中したものになっただけなのでしょうか? #dusk $DUSK @Dusk_Foundation
Citadelのライセンスフローがアイデンティティ漏えいなしにコンプライアンスをどう解決するのか、実際に仕組みを一つずつ検討するのに時間を費やしましたが、そのメカニズムは「プライバシーを保護するKYC」という一行の示唆よりもずっと面白いです。
ライセンス提供者 — たとえば規制されたオンボーディングの主体 — が通常どおりオフチェーンでユーザーを確認し、そのうえで特定の属性について署名付きのアテステーションを作成して、暗号化されたライセンスをオンチェーンに登録します。ユーザーは、利用したいすべてのサービスに対して毎回書類をアップロードし直すことはありません。代わりに、サービス提供者が適格性の証明を必要とする際、ユーザーは有効な、プロバイダー署名のライセンスを保有していることを示すゼロ知識証明を生成します。これにより、ウォレットも、基礎となる属性も、どの特定のライセンスが証明を生んだのかも開示せずに済みます。サービス提供者はその証明を検証し、アイデンティティではなくセッションを記録します。
ここで実際に分散されているのは、コンプライアンス判断そのものではありません。分散されているのは、開示(ディスクロージャー)のイベントです。信頼の問題は消えませんが、場所が移ります。サービス提供者は、どのライセンス提供者を信頼するか、そしてどの属性がそのルールを満たすかを、依然として自分で決めます。Citadelは規制上の判断を置き換えるのではなく、その判断を、生の個人データに対して毎回行う必要をなくします。
フラグを立てておきたいポイントは、これはリピート検証モデルであってワンタイムのバッジではないということです。セッションは期限切れになり、無効化され、あるいは適格性条件の変化に応じて更新が必要になります。セキュリティトークン・プラットフォームにとって、こうした「引き続き適格である」ことの再証明は、その上に乗っているプライバシー層よりも、実際のプロダクトにより近いのではないでしょうか。規制された場は、「一度適格だった」ことを知るだけでは不十分で、重大な変更がないことを継続的に保証する必要があるからです。
正直な言い方をすると、Citadelは単一の信頼ポイントを「あなたのデータを目にするすべての相手」から「誰もが受け入れる署名を持つ、少数のライセンス提供者」へ移します。これはより小さな攻撃対象なのでしょうか、それとも単により集中したものになっただけなのでしょうか?

#dusk $DUSK @Dusk
私が初めてバビロンの最終性プロバイダー(FP)システムを読んだとき、「標準的な委任ステーキング」のように機能するのだと考えました――つまり、誰でもFPを運用でき、誰でも任意のFPへ委任できる、と。ところがドキュメントの一行が引っかかりました。現在のフェーズでは、BTCの委任額上位60のFPだけが報酬の対象として実際に有効です。 最初は些細な違いに見えました。でも本質はインセンティブ構造です。小さな委任しかない新しいFPは、その上位60に食い込むまで「有効なアクティブ」として扱われません――つまり報酬を追うステーカーの合理的な行動は、すでに大きいFPに委任することになります。これが何千ものステーカーにわたって繰り返されることで、まさに大きなFPがさらに成長し続けるのです。 ここには、語られる物語と仕組みの間にあるギャップがあります。提案では「どこにでも委任できる」「分散して集中リスクを減らせ」とされています。ドキュメントでも分散を推奨しています。ですが、このフェーズにおける資格(エリジビリティ)ルールが、静かにステーカーを逆方向へ押し出しているのです。 仕組みはシンプルです。各FPはEOTSの鍵ペアを登録し、それでブロックに署名します。同一高さで二重署名が行われると、その鍵からFPの秘密鍵を回復でき――これがオンチェーンのスラッシングの根拠になります。暗号は問題なく成立しています。本当の論点はセキュリティではなく、委任が実際にどう分配されるか、という点でした。 ライブの数字が状況を補足します。BABYの取引価格は約$0.011〜$0.015、時価総額はおよそ46〜55M、流通供給量は約37〜40億(総供給約109億のうち約3.7〜4B)です。次のアンロックは8月10日で、約136.11Mトークン(供給量の約1.2%)が解放されます。しかしFP側で本当に重要なのはトークンではなく委任シェアであり、それが分散しているのか、上位のいくつかのFPに積み上がっているのかは、どの価格チャートにも出てきません。確認するには自分でエクスプローラーを見る必要があります。 これは新しい話ではありません。イーサリアムの流動性ステーキング提供者たちも、利便性のために「最大手」へ引き寄せられる同様の流れを見ました。違いは、ここでの圧力が単なる市場行動だけでなく、プロトコル自身の資格ルールに組み込まれていることです。 では結論として、上位60モデルは一時的な移行ステップなのか、それとも、トレーニングホイールが外れた後も、今生まれる集中がそのまま恒久的になるのか? #baby $BABY @babylonlabs_io
私が初めてバビロンの最終性プロバイダー(FP)システムを読んだとき、「標準的な委任ステーキング」のように機能するのだと考えました――つまり、誰でもFPを運用でき、誰でも任意のFPへ委任できる、と。ところがドキュメントの一行が引っかかりました。現在のフェーズでは、BTCの委任額上位60のFPだけが報酬の対象として実際に有効です。
最初は些細な違いに見えました。でも本質はインセンティブ構造です。小さな委任しかない新しいFPは、その上位60に食い込むまで「有効なアクティブ」として扱われません――つまり報酬を追うステーカーの合理的な行動は、すでに大きいFPに委任することになります。これが何千ものステーカーにわたって繰り返されることで、まさに大きなFPがさらに成長し続けるのです。
ここには、語られる物語と仕組みの間にあるギャップがあります。提案では「どこにでも委任できる」「分散して集中リスクを減らせ」とされています。ドキュメントでも分散を推奨しています。ですが、このフェーズにおける資格(エリジビリティ)ルールが、静かにステーカーを逆方向へ押し出しているのです。
仕組みはシンプルです。各FPはEOTSの鍵ペアを登録し、それでブロックに署名します。同一高さで二重署名が行われると、その鍵からFPの秘密鍵を回復でき――これがオンチェーンのスラッシングの根拠になります。暗号は問題なく成立しています。本当の論点はセキュリティではなく、委任が実際にどう分配されるか、という点でした。
ライブの数字が状況を補足します。BABYの取引価格は約$0.011〜$0.015、時価総額はおよそ46〜55M、流通供給量は約37〜40億(総供給約109億のうち約3.7〜4B)です。次のアンロックは8月10日で、約136.11Mトークン(供給量の約1.2%)が解放されます。しかしFP側で本当に重要なのはトークンではなく委任シェアであり、それが分散しているのか、上位のいくつかのFPに積み上がっているのかは、どの価格チャートにも出てきません。確認するには自分でエクスプローラーを見る必要があります。
これは新しい話ではありません。イーサリアムの流動性ステーキング提供者たちも、利便性のために「最大手」へ引き寄せられる同様の流れを見ました。違いは、ここでの圧力が単なる市場行動だけでなく、プロトコル自身の資格ルールに組み込まれていることです。
では結論として、上位60モデルは一時的な移行ステップなのか、それとも、トレーニングホイールが外れた後も、今生まれる集中がそのまま恒久的になるのか?

#baby $BABY @BabylonLabs_io
最初、$BABY のリキッド・ステーキングは他のどこでもそうであるように、1つのプロトコルで1つのレシートトークン、これで終わりだと思っていました。ところが Babylon Genesis で今実際に稼働している内容を見てみると、同じ仕事を並行して行う3つの別々の発行元が見つかりました。SatLayer は cBABY を鋳造します。Escher Finance は eBABY を鋳造します。MilkyWay は milkBABY を鋳造します。基になっているステークは同じで、ラッパーが3種類競合している。しかも同じようなタイミングのウィンドウの中で立ち上がっています。これは冗長性ではなく、まだ決着のついていない市場です。各プロトコルは、スタックのどの部分に賭けるのか、カストディ設計、償還スピード、あるいはどのDeFi統合が最初に取り込むか、といった別の要素を狙っています。そして、それらはホワイトペーパーで決着がつくのではなく、「どのトークンDEXやレンディング市場が実際に流動性をルーティングするか」で決まります。一方で基盤レイヤーは3つすべての下で拡張を続けています。たとえば Noble USDC は今 IBC 経由で動き、Tower DEX でスワップできたり、Eureka を通じて Arbitrum のようなチェーンへブリッジし直せます。さらに Union や Axelar の Squidrouter も追加のブリッジ経路として稼働しています。つまりエコシステムはレール不足ではなく、「集中する理由」が不足しているのです。新しいブリッジが増え、新しい LST が増えるたびに別の出口が増え、どの出口もあることで、流動性がどこかに落ち着いて長く滞留せず、その結果コンパウンドする前に分散しやすくなります。本当の論点は、どのリキッド・ステーキングトークンが勝つかではありません。Babylon Genesis が、DeFi が実際に積み上げていける「深い」流動性プールを1つ持つのか、それとも、実際に大きな資金を動かそうとすると結局は浅い、でも誰かが触るまで活動しているように見えるプールが3つになるのか——それが問題です。 @babylonlabs_io $BABY #baby
最初、$BABY のリキッド・ステーキングは他のどこでもそうであるように、1つのプロトコルで1つのレシートトークン、これで終わりだと思っていました。ところが Babylon Genesis で今実際に稼働している内容を見てみると、同じ仕事を並行して行う3つの別々の発行元が見つかりました。SatLayer は cBABY を鋳造します。Escher Finance は eBABY を鋳造します。MilkyWay は milkBABY を鋳造します。基になっているステークは同じで、ラッパーが3種類競合している。しかも同じようなタイミングのウィンドウの中で立ち上がっています。これは冗長性ではなく、まだ決着のついていない市場です。各プロトコルは、スタックのどの部分に賭けるのか、カストディ設計、償還スピード、あるいはどのDeFi統合が最初に取り込むか、といった別の要素を狙っています。そして、それらはホワイトペーパーで決着がつくのではなく、「どのトークンDEXやレンディング市場が実際に流動性をルーティングするか」で決まります。一方で基盤レイヤーは3つすべての下で拡張を続けています。たとえば Noble USDC は今 IBC 経由で動き、Tower DEX でスワップできたり、Eureka を通じて Arbitrum のようなチェーンへブリッジし直せます。さらに Union や Axelar の Squidrouter も追加のブリッジ経路として稼働しています。つまりエコシステムはレール不足ではなく、「集中する理由」が不足しているのです。新しいブリッジが増え、新しい LST が増えるたびに別の出口が増え、どの出口もあることで、流動性がどこかに落ち着いて長く滞留せず、その結果コンパウンドする前に分散しやすくなります。本当の論点は、どのリキッド・ステーキングトークンが勝つかではありません。Babylon Genesis が、DeFi が実際に積み上げていける「深い」流動性プールを1つ持つのか、それとも、実際に大きな資金を動かそうとすると結局は浅い、でも誰かが触るまで活動しているように見えるプールが3つになるのか——それが問題です。

@BabylonLabs_io $BABY #baby
#baby $BABY あまり投稿しないんだ。ほとんどの場合、他の人が共有してくれた内容を読むだけ。市場の調子が良くなかった頃は、毎日ポートフォリオを確認するだけで気が沈んでしまった。ある眠れない夜、ふとBabylonのDiscordに入ってみたら、いろんな話で盛り上がっていた。冗談を言う人もいれば、ただ一日の出来事を話している人もいた。ある人は「本当に大変な一日だったし、体調もよくない」と言っていた。そこで目立ったのは、誰も市場の価格の話を一切していなかったこと。代わりに「トレードから少し離れて、水を飲んで、休んでほしい」と声をかけていた。誰かが冗談を言って、みんなが笑って、空気が少し明るくなった。私はあまり話さなかった。ただ見ていたんだ。そこで気づいた。ここでは、トークンより先に人がいる。もう単にプロジェクトを抱えているだけじゃない。誰かが、つらい日でも聞いてくれる――そんなコミュニティの一員なんだ。市場がどうなっていようと、良い時でも悪い時でも、Babylonを開くたびに私は価格だけを見ていない。見覚えのある名前があって、しんどい日を少し楽にしてくれる人がいる。それが、私がここにい続ける理由だ。 @babylonlabs_io $BTC
#baby $BABY あまり投稿しないんだ。ほとんどの場合、他の人が共有してくれた内容を読むだけ。市場の調子が良くなかった頃は、毎日ポートフォリオを確認するだけで気が沈んでしまった。ある眠れない夜、ふとBabylonのDiscordに入ってみたら、いろんな話で盛り上がっていた。冗談を言う人もいれば、ただ一日の出来事を話している人もいた。ある人は「本当に大変な一日だったし、体調もよくない」と言っていた。そこで目立ったのは、誰も市場の価格の話を一切していなかったこと。代わりに「トレードから少し離れて、水を飲んで、休んでほしい」と声をかけていた。誰かが冗談を言って、みんなが笑って、空気が少し明るくなった。私はあまり話さなかった。ただ見ていたんだ。そこで気づいた。ここでは、トークンより先に人がいる。もう単にプロジェクトを抱えているだけじゃない。誰かが、つらい日でも聞いてくれる――そんなコミュニティの一員なんだ。市場がどうなっていようと、良い時でも悪い時でも、Babylonを開くたびに私は価格だけを見ていない。見覚えのある名前があって、しんどい日を少し楽にしてくれる人がいる。それが、私がここにい続ける理由だ。

@BabylonLabs_io $BTC
Here is your rewritten post in English, kept completely natural while conveying the original message: ​当初は、自身で保管(セルフカストディ)しながら、流動性を借りることは互いに両立しない──つまり、現金にアクセスするにはプライベートキーを手放してしまい、あとはひたすら運を天に任せるしかない、という考えが支配的でした。ネイティブのビットコイン担保ローンは、このトレードオフを覆しますが、革新は“機能そのもの”だけではありません。続くユーザー体験こそが本質です。 ​本当の難しさは、タイミングと実行にあります。担保が検証可能であり続けるためには、どうしても、わずかながら信頼の層が再び方程式に入ってきます。それは単一の中央集権的な存在に置かれるのではなく、配分されるだけです。これを些細な技術的ニュアンスだと片づける人もいますが、実際にはそれがプロダクト全体を定義しています。リピート借り手を本当に動かすのは、競争力のある金利ではありません。最初のやり取りが「完全に安全で、信頼できる」と感じられたかどうかです。それは単なる革新ではなく、継続(リテンション)の問題です。 ​結局のところ、根本的な問いは、ビットコインを手放さずにレバレッジできるかどうかではありません。これらのプロトコル設計が、本当にあなたの“コードに対する信頼”を試しているのか、それとも信頼の置き場所を移し替えているだけなのか──そこが問われています。 ​@babylonlabs_io $BABY #baby
Here is your rewritten post in English, kept completely natural while conveying the original message:

​当初は、自身で保管(セルフカストディ)しながら、流動性を借りることは互いに両立しない──つまり、現金にアクセスするにはプライベートキーを手放してしまい、あとはひたすら運を天に任せるしかない、という考えが支配的でした。ネイティブのビットコイン担保ローンは、このトレードオフを覆しますが、革新は“機能そのもの”だけではありません。続くユーザー体験こそが本質です。

​本当の難しさは、タイミングと実行にあります。担保が検証可能であり続けるためには、どうしても、わずかながら信頼の層が再び方程式に入ってきます。それは単一の中央集権的な存在に置かれるのではなく、配分されるだけです。これを些細な技術的ニュアンスだと片づける人もいますが、実際にはそれがプロダクト全体を定義しています。リピート借り手を本当に動かすのは、競争力のある金利ではありません。最初のやり取りが「完全に安全で、信頼できる」と感じられたかどうかです。それは単なる革新ではなく、継続(リテンション)の問題です。

​結局のところ、根本的な問いは、ビットコインを手放さずにレバレッジできるかどうかではありません。これらのプロトコル設計が、本当にあなたの“コードに対する信頼”を試しているのか、それとも信頼の置き場所を移し替えているだけなのか──そこが問われています。

@BabylonLabs_io $BABY #baby
#baby $BABY 何度も頭に浮かぶ疑問があります――私たちは本当に正しいことを聞いているのでしょうか?バビロン(Babylon)については特に、「Sovereign BTC」だとか、ビットコインDeFiの新時代といった物語がよく語られています。素晴らしい話に聞こえますが、数字やユーザーの行動を見ると、もう一つ別の側面があるようです。DefiLlamaによれば、TVLはこの1週間で減少しており、さらに$BABY トークンも下落しています。これは必ずしもプロジェクトが壊れていることを意味するわけではありませんが、マーケティングだけでは持続可能性は何もかもが解決しないことを示しています。私が特に注目しているのは、多くの人がまだここにいるのは、主にインセンティブのためかもしれないという点です。ですから私にとって、最大の疑問は「技術が機能するかどうか」ではありません。真の疑問はこうです――それらの報酬や付加的なベネフィットがゆっくりと薄れていったとき、人々はそれでもBTCをロックし続けるのでしょうか?それとも興味は徐々に消えてしまうのでしょうか?それが私にとって最も重要な問いです。最終的に本当に残るのは誰か、見届けましょう。 @babylonlabs_io $BABY {spot}(BABYUSDT)
#baby $BABY 何度も頭に浮かぶ疑問があります――私たちは本当に正しいことを聞いているのでしょうか?バビロン(Babylon)については特に、「Sovereign BTC」だとか、ビットコインDeFiの新時代といった物語がよく語られています。素晴らしい話に聞こえますが、数字やユーザーの行動を見ると、もう一つ別の側面があるようです。DefiLlamaによれば、TVLはこの1週間で減少しており、さらに$BABY トークンも下落しています。これは必ずしもプロジェクトが壊れていることを意味するわけではありませんが、マーケティングだけでは持続可能性は何もかもが解決しないことを示しています。私が特に注目しているのは、多くの人がまだここにいるのは、主にインセンティブのためかもしれないという点です。ですから私にとって、最大の疑問は「技術が機能するかどうか」ではありません。真の疑問はこうです――それらの報酬や付加的なベネフィットがゆっくりと薄れていったとき、人々はそれでもBTCをロックし続けるのでしょうか?それとも興味は徐々に消えてしまうのでしょうか?それが私にとって最も重要な問いです。最終的に本当に残るのは誰か、見届けましょう。

@BabylonLabs_io $BABY
#baby $BABY 以下は、コアとなるメッセージを一切変えずに、言い回しだけを自然で人間らしい表現に作り替え、元の投稿のそのままの引用に見えないようにした別の英語版です。 私が $BABY のエコシステムを掘り下げ始めたとき、私はその3つの柱——ガス、ガバナンス、セキュリティ——が、まるでよく整備された機械のように一体となって機能するものだと完全に見込んでいました。けれども、実際のオンチェーンデータはまったく別の様子を示しています。 実際に起きているのはこうです: * **ガス消費:** ただの公共料金のように振る舞っています。とても安定していて、ネットワークトラフィックのみによって決まり、市場の誇大宣伝やユーザーの感情などは完全に無視しています。 * **ガバナンス:** これは独自の気まぐれなスケジュールで動いています。活動が急に跳ねるのは、大きな提案の締切が近づくときだけです。投票が終わると、また完全に動きが止まります。 * **セキュリティ(ステーキング):** ステーキング側は、裏でただのんびりしているだけです。バリデーターはトークンをロックしており、ガスのトレンドやガバナンスの議論で何が起きていようと、まったく無関心に見えます。 私にとっていちばん驚いたのは、これらのグループがどれほど切り離されているかです。3つすべての分野にまたがって、単一のウォレットが関与しているのを目にすることはほとんどありません。ユーザーは本質的に、自分の好きなレーンを選んでそこに居続けているようです。1つの統一されたトークンというより、3つの別々の資産が、それぞれ異なる層に向けて提供されているように感じます。 これは、ユーティリティが自然に分断されやすいプロジェクトの初期段階における“普通の流れ”なのでしょうか? それとも、ネットワークがまだ十分に強いユースケースを育てられておらず、異なるユーザー層同士が互いに関わることを強制するほどの力がないということを意味しているのでしょうか? みなさんはどう思いますか? @babylonlabs_io $BABY #baby
#baby $BABY 以下は、コアとなるメッセージを一切変えずに、言い回しだけを自然で人間らしい表現に作り替え、元の投稿のそのままの引用に見えないようにした別の英語版です。
私が $BABY のエコシステムを掘り下げ始めたとき、私はその3つの柱——ガス、ガバナンス、セキュリティ——が、まるでよく整備された機械のように一体となって機能するものだと完全に見込んでいました。けれども、実際のオンチェーンデータはまったく別の様子を示しています。
実際に起きているのはこうです:
* **ガス消費:** ただの公共料金のように振る舞っています。とても安定していて、ネットワークトラフィックのみによって決まり、市場の誇大宣伝やユーザーの感情などは完全に無視しています。
* **ガバナンス:** これは独自の気まぐれなスケジュールで動いています。活動が急に跳ねるのは、大きな提案の締切が近づくときだけです。投票が終わると、また完全に動きが止まります。
* **セキュリティ(ステーキング):** ステーキング側は、裏でただのんびりしているだけです。バリデーターはトークンをロックしており、ガスのトレンドやガバナンスの議論で何が起きていようと、まったく無関心に見えます。
私にとっていちばん驚いたのは、これらのグループがどれほど切り離されているかです。3つすべての分野にまたがって、単一のウォレットが関与しているのを目にすることはほとんどありません。ユーザーは本質的に、自分の好きなレーンを選んでそこに居続けているようです。1つの統一されたトークンというより、3つの別々の資産が、それぞれ異なる層に向けて提供されているように感じます。
これは、ユーティリティが自然に分断されやすいプロジェクトの初期段階における“普通の流れ”なのでしょうか? それとも、ネットワークがまだ十分に強いユースケースを育てられておらず、異なるユーザー層同士が互いに関わることを強制するほどの力がないということを意味しているのでしょうか?
みなさんはどう思いますか?
@BabylonLabs_io $BABY #baby
ログインして、さらにコンテンツを読む
厳選トピックで世界の暗号資産トレーダーの仲間入り
⚡️ 暗号資産に関する最新かつ有益な情報が見つかります。
💬 世界最大の暗号資産取引所から信頼されています。
👍 認証を受けたクリエイターから、有益なインサイトを得られます。
メール / 電話番号
サイトマップ
Cookieの設定
プラットフォーム利用規約