Binance Square
Asif The Trader
441 投稿

Asif The Trader

The Ultimate Trader
取引を発注
超高頻度トレーダー
1.3年
538 フォロー
152 フォロワー
449 いいね
投稿
ポートフォリオ
·
--
本人確認中
翻訳参照
There's a frosted glass partition at my accountant's office. From the waiting room you can see shapes moving, hear murmurs through the wall - but nothing readable. Only the person behind the desk, holding the right file, ever gets to see the actual numbers. I kept thinking about that partition while reading how Hedger works on @Dusk_Foundation DuskEVM. Most people hear "confidential smart contracts" and picture something sealed shut entirely - a vault nobody gets into, not even the people who'd need to. That's the part that sat with me longer than I expected. Hedger isn't one wall, it's the partition doing three jobs at once: a fund's rebalancing trade clears without broadcasting its size to competitors, an issuer's cap table updates without exposing every holder's position, an auditor pulls the one file they're authorized to see without touching the rest. Homomorphic encryption plus zero-knowledge proofs, running on rails a Solidity developer already knows. Privacy and audit aren't fighting each other here. They're routed through the same door. What's easy to skip past is how early this still is. DuskEVM mainnet is arriving, Hedger is the pitch - but a pitch isn't the same as volume. Nobody's published how many contracts are actually live through it yet, or whether any regulated desk has routed real flow through the confidential path versus just testing it in a sandbox. "Reviewable privacy" is a strong claim to make before anyone's reviewed anything. So is the partition actually load-bearing, or is it just glass hung on a frame, waiting for someone on the other side to show up? $DUSK usage says nothing until builders actually walk through that door. Not yet. #dusk {spot}(AAVEUSDT) {spot}(BTCUSDT)
There's a frosted glass partition at my accountant's office. From the waiting room you can see shapes moving, hear murmurs through the wall - but nothing readable. Only the person behind the desk, holding the right file, ever gets to see the actual numbers.
I kept thinking about that partition while reading how Hedger works on @Dusk DuskEVM. Most people hear "confidential smart contracts" and picture something sealed shut entirely - a vault nobody gets into, not even the people who'd need to.
That's the part that sat with me longer than I expected. Hedger isn't one wall, it's the partition doing three jobs at once: a fund's rebalancing trade clears without broadcasting its size to competitors, an issuer's cap table updates without exposing every holder's position, an auditor pulls the one file they're authorized to see without touching the rest. Homomorphic encryption plus zero-knowledge proofs, running on rails a Solidity developer already knows. Privacy and audit aren't fighting each other here. They're routed through the same door.
What's easy to skip past is how early this still is. DuskEVM mainnet is arriving, Hedger is the pitch - but a pitch isn't the same as volume. Nobody's published how many contracts are actually live through it yet, or whether any regulated desk has routed real flow through the confidential path versus just testing it in a sandbox. "Reviewable privacy" is a strong claim to make before anyone's reviewed anything.
So is the partition actually load-bearing, or is it just glass hung on a frame, waiting for someone on the other side to show up? $DUSK usage says nothing until builders actually walk through that door. Not yet.
#dusk
一部該当
#dusk $DUSK @Dusk_Foundation NPEXがDusk上で実際に$300M以上の実在・トークン化された資産を稼働させているのを見て、Citadelのドキュメントに戻って確認しました。これはもうテストネットの例ではありません。だからこそ、「プライバシーの主張」が、ホワイトペーパーの図解だけでなく、実際の規制のある場で本当に成り立つのかを確かめたくなったんです。 結論、プロトコルは「1つ」ではなく、実際には「別々の2つのフロー」から成っています。 まず、ユーザーはステルスアドレスを使ってLicense Providerにライセンスの発行を依頼します。これにより、発行されたライセンスが依頼側に紐づけられないようになります。 次に、ユーザーがサービスを使いたいとき、ライセンスを再送するわけではありません。代わりに、その有効なライセンスを所持していることを示すゼロ知識証明を送ります。サービスプロバイダー(SP)が見るのは、その証明だけです。そして、十分とみなす基準を決めるのはSP自身のポリシーです。 ここで私が足を止めたポイントがあります。その証明はただではありません。ライセンス保有を証明するためのCitadelの回路は、だいたい34,800 constraints程度で、その半分ほどは、ライセンスが実際に登録されていることを確認するために、深さ17のメルカリツリーを辿る処理だけに費やされています。 つまり「明かさずに証明する」には、スライド上の設計思想に留まらない、すべてのサービスリクエストに組み込まれた現実の計算コストがあるんです。 「IDを見せて、プラットフォームにすべて検証させる」とは別のモデルです。 より近いのは:やり取りごとに、一定の証明コストを一度支払う代わりに、その場(会場)には「はい/いいえ」以外は何も見せない、という考え方です。 ただ、まだ分からないのは、そのコストが今日のNPEXユーザーにとって実際に“見えない”のか、ウォレットが裏で処理してしまうのか。それとも、規制のある取引の当事者と誰かが実際に取引をするまでの間に、感じられる遅延として存在するのか、という点です。 {spot}(MORPHOUSDT) {spot}(BNBUSDT) {spot}(AAVEUSDT)
#dusk $DUSK @Dusk
NPEXがDusk上で実際に$300M以上の実在・トークン化された資産を稼働させているのを見て、Citadelのドキュメントに戻って確認しました。これはもうテストネットの例ではありません。だからこそ、「プライバシーの主張」が、ホワイトペーパーの図解だけでなく、実際の規制のある場で本当に成り立つのかを確かめたくなったんです。
結論、プロトコルは「1つ」ではなく、実際には「別々の2つのフロー」から成っています。
まず、ユーザーはステルスアドレスを使ってLicense Providerにライセンスの発行を依頼します。これにより、発行されたライセンスが依頼側に紐づけられないようになります。
次に、ユーザーがサービスを使いたいとき、ライセンスを再送するわけではありません。代わりに、その有効なライセンスを所持していることを示すゼロ知識証明を送ります。サービスプロバイダー(SP)が見るのは、その証明だけです。そして、十分とみなす基準を決めるのはSP自身のポリシーです。
ここで私が足を止めたポイントがあります。その証明はただではありません。ライセンス保有を証明するためのCitadelの回路は、だいたい34,800 constraints程度で、その半分ほどは、ライセンスが実際に登録されていることを確認するために、深さ17のメルカリツリーを辿る処理だけに費やされています。
つまり「明かさずに証明する」には、スライド上の設計思想に留まらない、すべてのサービスリクエストに組み込まれた現実の計算コストがあるんです。
「IDを見せて、プラットフォームにすべて検証させる」とは別のモデルです。
より近いのは:やり取りごとに、一定の証明コストを一度支払う代わりに、その場(会場)には「はい/いいえ」以外は何も見せない、という考え方です。
ただ、まだ分からないのは、そのコストが今日のNPEXユーザーにとって実際に“見えない”のか、ウォレットが裏で処理してしまうのか。それとも、規制のある取引の当事者と誰かが実際に取引をするまでの間に、感じられる遅延として存在するのか、という点です。
翻訳参照
@Dusk_Foundation #dusk $DUSK The Aug 16 bridge incident made me look at Dusk differently. Not because of the blocklist. Because it made me wonder: After an onchain action is approved, who actually needs to see the data behind it? For regulated finance, you may need to prove: eligibility. ownership. transfer conditions. My first assumption was simple: if something has to be verified, more of the underlying data probably has to be visible. Then I went back into the Dusk docs and the actual citadel paper. Citadel's proof of ownership does not put personal data onchain. The user proves inside a circuit that they hold a validly signed credential; the verifier only learns that the statement is true. The number that stuck with me: verifying that proof takes 0.007 seconds. Generating it takes around 16 seconds on a laptop-grade chip. The expensive part proving happens once, offline, on the user's side. The part a verifier actually does, at the moment someone needs access, is near-instant and reveals nothing beyond "valid." That split matters for regulated assets. An institution needs to confirm eligibility. It doesn't need the applicant's full KYC file to do that it needs a proof that resolves to true or false, and Citadel lets the service provider define exactly which attributes that proof has to cover. So the interesting question isn't " is the blockchain private? " It's: of everything sitting in a typical KYC payload, how much of it actually needs to touch a verifier once the proof not the data is the thing being checked ? {spot}(AAVEUSDT) {spot}(MORPHOUSDT) For regulated onchain finance, what matters more?
@Dusk #dusk $DUSK
The Aug 16 bridge incident made me look at Dusk differently.
Not because of the blocklist.
Because it made me wonder:
After an onchain action is approved, who actually needs to see the data behind it?
For regulated finance, you may need to prove:
eligibility.
ownership.
transfer conditions.
My first assumption was simple:
if something has to be verified, more of the underlying data probably has to be visible.
Then I went back into the Dusk docs and the actual citadel paper.
Citadel's proof of ownership does not put personal data onchain. The user proves inside a circuit that they hold a validly signed credential; the verifier only learns that the statement is true.
The number that stuck with me: verifying that proof takes 0.007 seconds. Generating it takes around 16 seconds on a laptop-grade chip. The expensive part proving happens once, offline, on the user's side. The part a verifier actually does, at the moment someone needs access, is near-instant and reveals nothing beyond "valid."
That split matters for regulated assets.
An institution needs to confirm eligibility. It doesn't need the applicant's full KYC file to do that it needs a proof that resolves to true or false, and Citadel lets the service provider define exactly which attributes that proof has to cover.
So the interesting question isn't " is the blockchain private? "
It's: of everything sitting in a typical KYC payload, how much of it actually needs to touch a verifier once the proof not the data is the thing being checked ?


For regulated onchain finance, what matters more?
Prove without revealing data
0%
Verify it by seeing the data
100%
1 投票 • 投票は終了しました
·
--
弱気相場
翻訳参照
#dusk $DUSK @Dusk_Foundation I used to think that putting a financial asset onchain automatically meant making the whole financial process better. Then I tried looking at it from the perspective of a bank or investment fund. Imagine putting a bond or fund onchain. It sounds like the problem is solved. But then I started wondering: What if the token is onchain, but the financial process around it still isn't? The institution still has to decide who can own it, how it can be traded, how payments move, and how settlement remains compliant. That made me rethink what “tokenization” actually means. Is tokenizing the asset enough, or should the financial lifecycle move with it too? That question is what drew me toward Dusk. What interested me about Dusk Trade was seeing the problem approached from the workflow side, not just the token side. Dusk is working toward bringing assets such as MMFs, ETFs, bonds and other RWAs into an onchain environment. The way I now think about tokenization is: ownership → eligibility → trading → payment → settlement Maybe the real question isn't: “How many assets can we put onchain?” Maybe it's: “How much of the financial process can actually work there?” Because if only the representation moves onchain, can we really say the market moved with it? That distinction is what makes Dusk interesting to me. {spot}(DUSKUSDT) What matters most when bringing real-world assets onchain?
#dusk $DUSK @Dusk

I used to think that putting a financial asset onchain automatically meant making the whole financial process better.

Then I tried looking at it from the perspective of a bank or investment fund.

Imagine putting a bond or fund onchain.

It sounds like the problem is solved.

But then I started wondering:

What if the token is onchain, but the financial process around it still isn't?

The institution still has to decide who can own it, how it can be traded, how payments move, and how settlement remains compliant.

That made me rethink what “tokenization” actually means.

Is tokenizing the asset enough, or should the financial lifecycle move with it too?

That question is what drew me toward Dusk.

What interested me about Dusk Trade was seeing the problem approached from the workflow side, not just the token side.

Dusk is working toward bringing assets such as MMFs, ETFs, bonds and other RWAs into an onchain environment.

The way I now think about tokenization is:

ownership → eligibility → trading → payment → settlement

Maybe the real question isn't:

“How many assets can we put onchain?”

Maybe it's:

“How much of the financial process can actually work there?”

Because if only the representation moves onchain, can we really say the market moved with it?

That distinction is what makes Dusk interesting to me.


What matters most when bringing real-world assets onchain?
Tokenizing the asset
0%
Ownership & eligibility
25%
Trading + settlement
0%
The full financial lifecycle
75%
4 投票 • 投票は終了しました
·
--
ブリッシュ
本人確認中
Duskを通じてオンチェーンに乗せる予定の資産は300M+ EUR。 その数字を見て、「トークン化」が実際に何を意味するのかを考え直しました。 以前は、債券やファンドをオンチェーンに載せる面白さは「トークン」にあると思っていました。 でも、トークンこそが最も面白くない部分かもしれないと気づきました。 オンチェーン・トークンであることが、必ずしもオンチェーンの金融ライフサイクルを意味するわけではありません。 資産はオンチェーンに存在していても、適格性(エリジビリティ)、コンプライアンス、譲渡制限、開示、さらには決済でさえ、他のシステムに依存することがあります。 では、トークン化は実際にオンチェーン上で何を動かしたのでしょう? だからこそ、@Dusk_Foundation のネイティブ発行ディレクションが私の関心を引きました。単にトークンを作ることを超えて、より広いライフサイクル――発行、適格性、譲渡、開示、決済――に目を向けているように見えるからです。 そして、プライバシーはそのライフサイクルをより難しくします。 規制のある市場では、すべてを公開する必要も、すべてを隠す必要もありません。必要なのは、制御された可視性です。 情報の一部は非公開のまま。 一部は証明可能。 一部は、許可された場合に開示できる。 そこで問いはこうなります: プライバシー、検証、開示を、金融アプリケーションのルールそのものの一部にできるのでしょうか? ライフサイクルのより多くを実際にオンチェーンに置けるのなら、より厳しいボトルネックはもはやブロックチェーンではないのかもしれません。 あるいは、その資産を取り巻く法的・制度的インフラなのかもしれません。 そのとき、ネイティブ発行はトークン化というより、金融ライフサイクルの一部を作り直すことのように見えてきます。 @Dusk_Foundation $DUSK #dusk {spot}(BTCUSDT) {spot}(BNBUSDT) {spot}(DUSKUSDT) 現実世界の資産トークン化において最も重要なのは何でしょう?
Duskを通じてオンチェーンに乗せる予定の資産は300M+ EUR。

その数字を見て、「トークン化」が実際に何を意味するのかを考え直しました。

以前は、債券やファンドをオンチェーンに載せる面白さは「トークン」にあると思っていました。

でも、トークンこそが最も面白くない部分かもしれないと気づきました。

オンチェーン・トークンであることが、必ずしもオンチェーンの金融ライフサイクルを意味するわけではありません。

資産はオンチェーンに存在していても、適格性(エリジビリティ)、コンプライアンス、譲渡制限、開示、さらには決済でさえ、他のシステムに依存することがあります。

では、トークン化は実際にオンチェーン上で何を動かしたのでしょう?

だからこそ、@Dusk のネイティブ発行ディレクションが私の関心を引きました。単にトークンを作ることを超えて、より広いライフサイクル――発行、適格性、譲渡、開示、決済――に目を向けているように見えるからです。

そして、プライバシーはそのライフサイクルをより難しくします。

規制のある市場では、すべてを公開する必要も、すべてを隠す必要もありません。必要なのは、制御された可視性です。

情報の一部は非公開のまま。

一部は証明可能。

一部は、許可された場合に開示できる。

そこで問いはこうなります:

プライバシー、検証、開示を、金融アプリケーションのルールそのものの一部にできるのでしょうか?

ライフサイクルのより多くを実際にオンチェーンに置けるのなら、より厳しいボトルネックはもはやブロックチェーンではないのかもしれません。

あるいは、その資産を取り巻く法的・制度的インフラなのかもしれません。

そのとき、ネイティブ発行はトークン化というより、金融ライフサイクルの一部を作り直すことのように見えてきます。

@Dusk $DUSK #dusk
現実世界の資産トークン化において最も重要なのは何でしょう?
🔹 Token issuance
29%
🔹 Onchain compliance
43%
🔹 Privacy + verification
14%
🔹 Full lifecycle onchain
14%
7 投票 • 投票は終了しました
翻訳参照
superb
superb
Tasifch786
·
--
ブリッシュ
以前は、資産を担保に借り入れることは、基本的に可能な限り低い金利を得ることが主だと思っていました。

しかし、別の問題を考えることになりました。

流動性が必要だけれど、その判断が、私が築こうとしているポジションの邪魔にならないとしたら?

それが私にとって@TermMax をより興味深いものにしてくれました。

固定の期間構造があると、借り入れの意思決定は次の3つの要素に沿って組み立てやすくなります。

コスト+期間+担保バッファ

FT/XT構造は、すべてを単なる1つのローンとして扱うのではなく、債務側のエクスポージャーを固定金利トークン(FT)とイールドトークン(XT)に分けることで、それをより具体的にします。

ただし、定められた期間があるからといって、保証された安全性だと混同してはいけません。

満期までの間に担保が不利に動けば、ポジションは依然として圧力を受ける可能性があります。担保を監視し、市場の変動に耐えられる十分な余裕を維持する必要があります。

この違いが重要なのは、次のとおりです。

金利の確実性が、借り入れコストを教えてくれる。

期間の確実性が、いつ備える必要があるかを教えてくれる。

前者は、流動性の価格を理解するのに役立つ。

後者は、ポジションを見据えた計画を立てるのに役立つ。

そして私が最も有用だと感じるのはここです。借り入れは「いくら借りられるか?」だけで考える必要はありません。

それはまた、

この構造が、自分が実際に資本で成し遂げようとしていることに合っているか?

という問いでもあります。

固定期間のポジションを開く前に、答えを得たいのはまさにその点です。

#termmax @TermMax $BTC #defi #Crypto

本人確認中
私の見た目の捉え方を変えたひとつが、@termmax について重要なのは「固定金利を得ること」だけではない、という点です。 ポジションが始まる前に、資金調達のあり方を決められることがポイントです。 一見すると些細に聞こえるかもしれませんが、これは取引そのものの中で、資金調達が果たせる役割を変えてしまいます。 典型的な変動金利の市場では、まずどれくらい借りたいかを決めて、その後は市場が提示する資金調達条件を受け入れることになります。 TermMax では、そうした条件が取引そのものの一部になり得ます。 借り手は、支払ってもよい最大金利と希望する満期を指定できます。一方で貸し手は、受け入れてよい最低金利を設定できます。 そのため、問いは次のように変わります。 「今すぐいくらの金利を得られるか?」 から、 「このポジションを取る価値があるのは、どんな条件か?」 ということです。 これは大きな転換です。 もはや、使う流動性の量を選ぶだけではありません。ポジションをコミットする前に、資本のコストと期間を固定してしまうのです。 そして、それはトレーダーだけの話ではありません。 トレジャリーは、定義された期間と借入コストに基づいて予算を組めます。 配分担当者は、今日の資金調達金利が明日もそのままあると前提せずに、機会を比較できます。 見落としやすいと思うのはここです。 予測可能な資金調達は、不確実性を減らすだけでなく、資本を管理しやすくします。 だから私は、TermMax を「別の固定金利の貸付プロトコル」以上のものだと捉えています。 それは、借り入れを、ポジションが開いた後に常に反応しながら決めるものではなく、最初に設計できる領域へと近づけるものです。 そして、より本格的な資本がオンチェーンで動くほど、この違いは無視しにくくなるはずです。 @termmax #TermMax #BTC #crypto {spot}(BTCUSDT) {spot}(BNBUSDT) オンチェーンの資金調達を選ぶとき、最も重要なのは何ですか?
私の見た目の捉え方を変えたひとつが、@TermMax について重要なのは「固定金利を得ること」だけではない、という点です。

ポジションが始まる前に、資金調達のあり方を決められることがポイントです。

一見すると些細に聞こえるかもしれませんが、これは取引そのものの中で、資金調達が果たせる役割を変えてしまいます。

典型的な変動金利の市場では、まずどれくらい借りたいかを決めて、その後は市場が提示する資金調達条件を受け入れることになります。

TermMax では、そうした条件が取引そのものの一部になり得ます。

借り手は、支払ってもよい最大金利と希望する満期を指定できます。一方で貸し手は、受け入れてよい最低金利を設定できます。

そのため、問いは次のように変わります。

「今すぐいくらの金利を得られるか?」

から、

「このポジションを取る価値があるのは、どんな条件か?」

ということです。

これは大きな転換です。

もはや、使う流動性の量を選ぶだけではありません。ポジションをコミットする前に、資本のコストと期間を固定してしまうのです。

そして、それはトレーダーだけの話ではありません。

トレジャリーは、定義された期間と借入コストに基づいて予算を組めます。

配分担当者は、今日の資金調達金利が明日もそのままあると前提せずに、機会を比較できます。

見落としやすいと思うのはここです。

予測可能な資金調達は、不確実性を減らすだけでなく、資本を管理しやすくします。

だから私は、TermMax を「別の固定金利の貸付プロトコル」以上のものだと捉えています。

それは、借り入れを、ポジションが開いた後に常に反応しながら決めるものではなく、最初に設計できる領域へと近づけるものです。

そして、より本格的な資本がオンチェーンで動くほど、この違いは無視しにくくなるはずです。

@TermMax #TermMax #BTC #crypto

オンチェーンの資金調達を選ぶとき、最も重要なのは何ですか?
Fixed borrowing cost
43%
Defined maturity
14%
Variable rates
43%
Flexible liquidity
0%
7 投票 • 投票は終了しました
·
--
ブリッシュ
#Dusk 私は、オンチェーンに金融資産を持ち込む際の難しい部分は、単にそこに資産を用意することだと最初は考えていました。 問題を深く見れば見るほど、難しいのはその周りで起きなければならないあらゆることだと気づきました。 たとえば規制を受けたファンドを考えてみてください。 保有者が参加資格を持つことを証明する必要があるかもしれませんが、その保有者のあらゆる詳細をネットワーク全体にさらさずに済むようにしなければなりません。 それでも取引は検証可能である必要があります。 ルールはなおも執行可能である必要があります。 しかし、基盤となる情報が必ずしも公開される必要はありません。 その視点の転換こそが @Dusk_Foundation を私にとってより興味深いものにしました。 私にとって本当の機会は、単なる「トークン化」ではありません。 それは、プライバシー、検証、決済をインフラ層で一つに結びつけることです。 ここで特に注目すべきなのは、ゼロ知識証明と選択的開示です。これは、証明の背後にあるすべてを明かさずに、重要なことを証明できるモデルを示唆しているからです。 十分に証明する。明かすのはより少なく。 そして DuskEVM は、その主張をさらに現実的にします。 開発者が、プライバシー重視の金融インフラを作りながらも、なじみのある EVM 環境で作業できるなら、こうしたアイデアを試すためのハードルは大きく下がります。 だから私は、大きな物語が単に債券やファンド、証券をオンチェーンに載せることだとは思いません。 それは、基盤となる金融インフラが、最初からより選択的な透明性という考え方に基づいて設計されているときに起こることです。 つまり: 「すべてを公開する。」 ではなく: 「正しい情報を、正しい当事者により検証可能にする。」 この違いは、トークン化という物語そのものよりも、ずっと重要になってくるかもしれません。 $DUSK #dusk #crypto $BTC $BNB {spot}(BTCUSDT) {spot}(DUSKUSDT)
#Dusk
私は、オンチェーンに金融資産を持ち込む際の難しい部分は、単にそこに資産を用意することだと最初は考えていました。

問題を深く見れば見るほど、難しいのはその周りで起きなければならないあらゆることだと気づきました。

たとえば規制を受けたファンドを考えてみてください。

保有者が参加資格を持つことを証明する必要があるかもしれませんが、その保有者のあらゆる詳細をネットワーク全体にさらさずに済むようにしなければなりません。

それでも取引は検証可能である必要があります。

ルールはなおも執行可能である必要があります。

しかし、基盤となる情報が必ずしも公開される必要はありません。

その視点の転換こそが
@Dusk を私にとってより興味深いものにしました。

私にとって本当の機会は、単なる「トークン化」ではありません。

それは、プライバシー、検証、決済をインフラ層で一つに結びつけることです。

ここで特に注目すべきなのは、ゼロ知識証明と選択的開示です。これは、証明の背後にあるすべてを明かさずに、重要なことを証明できるモデルを示唆しているからです。

十分に証明する。明かすのはより少なく。

そして DuskEVM は、その主張をさらに現実的にします。

開発者が、プライバシー重視の金融インフラを作りながらも、なじみのある EVM 環境で作業できるなら、こうしたアイデアを試すためのハードルは大きく下がります。

だから私は、大きな物語が単に債券やファンド、証券をオンチェーンに載せることだとは思いません。

それは、基盤となる金融インフラが、最初からより選択的な透明性という考え方に基づいて設計されているときに起こることです。

つまり:

「すべてを公開する。」

ではなく:

「正しい情報を、正しい当事者により検証可能にする。」

この違いは、トークン化という物語そのものよりも、ずっと重要になってくるかもしれません。

$DUSK #dusk #crypto $BTC $BNB
@termmax は、貸出市場の別の側面について考えさせられました。つまり「確実性」の価値です。 固定された借入の構造は、最初は制約があるように見えるかもしれません。特に市場環境が素早く変わるときはなおさらです。 しかし、柔軟性にもコストがあります。 変動金利の債務では、借り手は常に金利や資金調達環境の変化にさらされます。固定の満期ポジションは、その柔軟性を一部手放す代わりに、借入がその存続期間を通じてどのような資金調達になるのかをより明確に把握できるようにします。 だからこそTermMaxが私にとって興味深いのです。問題は単に、固定金利の借入が安いのか、より柔軟なのかということだけではありません。事前に自分の資金調達条件が分かることが、一定のオプション性を手放すことを正当化するほど価値があるのか、という点です。 市場が落ち着いているときは、柔軟性が優先されるかもしれません。しかし金利の見通しが難しくなると、確実性の価値は大きく高まります。 私がTermMaxで最も興味を持っているのは、まさにそこです。確実性は単なる価格の特徴ではありません。それ自体が商品になり得る、つまり市場があなたに代わって決める前に、自分の債務がどのように見えるのかを把握できる能力のことです。 #TermMax {spot}(BTCUSDT) {spot}(BNBUSDT)
@TermMax は、貸出市場の別の側面について考えさせられました。つまり「確実性」の価値です。

固定された借入の構造は、最初は制約があるように見えるかもしれません。特に市場環境が素早く変わるときはなおさらです。

しかし、柔軟性にもコストがあります。

変動金利の債務では、借り手は常に金利や資金調達環境の変化にさらされます。固定の満期ポジションは、その柔軟性を一部手放す代わりに、借入がその存続期間を通じてどのような資金調達になるのかをより明確に把握できるようにします。

だからこそTermMaxが私にとって興味深いのです。問題は単に、固定金利の借入が安いのか、より柔軟なのかということだけではありません。事前に自分の資金調達条件が分かることが、一定のオプション性を手放すことを正当化するほど価値があるのか、という点です。

市場が落ち着いているときは、柔軟性が優先されるかもしれません。しかし金利の見通しが難しくなると、確実性の価値は大きく高まります。

私がTermMaxで最も興味を持っているのは、まさにそこです。確実性は単なる価格の特徴ではありません。それ自体が商品になり得る、つまり市場があなたに代わって決める前に、自分の債務がどのように見えるのかを把握できる能力のことです。

#TermMax
ブロックチェーン上のプライバシーは、「何が起きたのかを検証できなくなる」ことを意味するべきではありません。 その緊張関係こそが、私にとってDuskが興味深い理由です。 従来のパブリック・台帳は活動を監査可能にするのに優れていますが、金融アプリケーションでは、そもそも誰にでも公開してはならない情報を扱うことがよくあります。 @Dusk_Foundation は、機密性をスマート コントラクトの層そのものに取り込むことで、別のアプローチを取っています。 それにより、より現実的な可能性が開けます。つまり、機密性の高い金融オペレーションは保護したまま、ネットワークはルールを強制し、結果を検証できるというアプリケーションです。 これは、ウォレット残高を隠すことよりもずっと大きな発想です。 プライバシーと検証可能性が対立する必要のない、金融インフラを構築することです。 私が特に注目しているのは、そのDuskの部分です。 @Dusk_Foundation $DUSK #dusk {spot}(DUSKUSDT) {spot}(BTCUSDT)
ブロックチェーン上のプライバシーは、「何が起きたのかを検証できなくなる」ことを意味するべきではありません。

その緊張関係こそが、私にとってDuskが興味深い理由です。

従来のパブリック・台帳は活動を監査可能にするのに優れていますが、金融アプリケーションでは、そもそも誰にでも公開してはならない情報を扱うことがよくあります。

@Dusk は、機密性をスマート
コントラクトの層そのものに取り込むことで、別のアプローチを取っています。

それにより、より現実的な可能性が開けます。つまり、機密性の高い金融オペレーションは保護したまま、ネットワークはルールを強制し、結果を検証できるというアプリケーションです。

これは、ウォレット残高を隠すことよりもずっと大きな発想です。

プライバシーと検証可能性が対立する必要のない、金融インフラを構築することです。

私が特に注目しているのは、そのDuskの部分です。

@Dusk $DUSK #dusk
翻訳参照
#termmax @termmax The more I dig into TermMax, the more interesting the curator model becomes. Curators can control capital allocation and define their own AMM pricing curves across different depths, with curator incentives tied to strategy performance. What stands out to me is the trade-off this creates. If two curators both perform well, but one competes mainly for the most attractive rates while the other provides meaningful depth beyond the most competitive part of the curve, what makes that broader liquidity strategy economically competitive? And more importantly, does the incentive design account for where liquidity sits across the curve, alongside the performance it generates? Because deeper liquidity may matter most when demand reaches beyond the best priced part of the curve. So the question I keep coming back to is: Can curator competition reward both competitive pricing and meaningful depth across the curve ? That’s a market design question I’d genuinely like to see TermMax address.
#termmax @TermMax
The more I dig into TermMax, the more interesting the curator model becomes.

Curators can control capital allocation and define their own AMM pricing curves across different depths, with curator incentives tied to strategy performance.

What stands out to me is the trade-off this creates.

If two curators both perform well, but one competes mainly for the most attractive rates while the other provides meaningful depth beyond the most competitive part of the curve, what makes that broader liquidity strategy economically competitive?

And more importantly, does the incentive design account for where liquidity sits across the curve, alongside the performance it generates?

Because deeper liquidity may matter most when demand reaches beyond the best priced part of the curve.

So the question I keep coming back to is:

Can curator competition reward both competitive pricing and meaningful depth across the curve ?

That’s a market design question I’d genuinely like to see TermMax address.
·
--
弱気相場
#dusk $DUSK 今週少し時間を使って、なぜ @Dusk_Foundation は通常のEVMチェーンに“後付け”する形でプライバシーをそのまま出荷しなかったのかを理解しようとしていました。結局のところ、多くの人が見落としがちな問題がありました。公開されたEVMでは、誰かが見ようとすれば、すべての残高や送金が見えてしまうのです。たとえ、その上に「プライベート」なアプリを載せたとしても同じ。つまり基盤レイヤーが情報を漏らしています。 Duskの答えが Hedger です。ホモモルフィック暗号化とゼロ知識証明を組み合わせて、DuskEVM に機密なトランザクションの流れを直接追加します。考え方としては、コントラクトが暗号化された残高に対して計算を行っても、基礎となる数値を一切復号しないまま、その計算が正しく行われたことの証明を生成できるというものです。検証者はデータではなく、証明を検査します。これは「フロントエンドが残高を隠してくれる」というのとはまったく別の保証で、そもそもチェーンが平文を保持していないため、漏らしようがないという意味です。 完全に独自のVMではなく、EVM互換レイヤーにこれを載せるのはなぜでしょう? 機関側には、すでに10年以上かけてSolidityのツール、監査、ワークフローが整備されているからです。DuskEVM(OP Stack、DuskDSへと決済が戻る)は、そのツール群を維持しつつ、Hedgerが“基盤レイヤーが見てよいもの”を変えることで、プライバシーをUIの小技ではなく、決済の特性として実現します。 また、実際の取引量が入ってきたときに、ガスコストと証明生成のスケールがどうなるかも追っています。ただ、今のところ価格チャートよりも、アーキテクチャそのものの話のほうが面白いです。 $DUSK #dusk {spot}(DUSKUSDT)
#dusk $DUSK
今週少し時間を使って、なぜ @Dusk は通常のEVMチェーンに“後付け”する形でプライバシーをそのまま出荷しなかったのかを理解しようとしていました。結局のところ、多くの人が見落としがちな問題がありました。公開されたEVMでは、誰かが見ようとすれば、すべての残高や送金が見えてしまうのです。たとえ、その上に「プライベート」なアプリを載せたとしても同じ。つまり基盤レイヤーが情報を漏らしています。
Duskの答えが Hedger です。ホモモルフィック暗号化とゼロ知識証明を組み合わせて、DuskEVM に機密なトランザクションの流れを直接追加します。考え方としては、コントラクトが暗号化された残高に対して計算を行っても、基礎となる数値を一切復号しないまま、その計算が正しく行われたことの証明を生成できるというものです。検証者はデータではなく、証明を検査します。これは「フロントエンドが残高を隠してくれる」というのとはまったく別の保証で、そもそもチェーンが平文を保持していないため、漏らしようがないという意味です。
完全に独自のVMではなく、EVM互換レイヤーにこれを載せるのはなぜでしょう? 機関側には、すでに10年以上かけてSolidityのツール、監査、ワークフローが整備されているからです。DuskEVM(OP Stack、DuskDSへと決済が戻る)は、そのツール群を維持しつつ、Hedgerが“基盤レイヤーが見てよいもの”を変えることで、プライバシーをUIの小技ではなく、決済の特性として実現します。
また、実際の取引量が入ってきたときに、ガスコストと証明生成のスケールがどうなるかも追っています。ただ、今のところ価格チャートよりも、アーキテクチャそのものの話のほうが面白いです。
$DUSK #dusk
·
--
ブリッシュ
翻訳参照
#termmax @termmax TVL tells you what showed up. Utilization tells you what's actually being used — and today TermMax's numbers make that gap worth noticing. $34M deposited, ~$29.5M borrowed, sitting near 87% utilization. That's an actively used pool, not just parked liquidity. What stands out is the structure underneath it. Instead of one shared pool rate, lenders choose their own rate curve through range orders. So that 87% isn't one uniform number — it's an aggregate built from many individual curve choices. Early days still, one day's data isn't a trend. What I'm watching next is whether this utilization holds once incentive programs start winding down. #TermMax @termmax
#termmax @TermMax
TVL tells you what showed up. Utilization tells you what's actually being used — and today TermMax's numbers make that gap worth noticing.
$34M deposited, ~$29.5M borrowed, sitting near 87% utilization. That's an actively used pool, not just parked liquidity.
What stands out is the structure underneath it. Instead of one shared pool rate, lenders choose their own rate curve through range orders. So that 87% isn't one uniform number — it's an aggregate built from many individual curve choices.
Early days still, one day's data isn't a trend. What I'm watching next is whether this utilization holds once incentive programs start winding down.
#TermMax @TermMax
本人確認中
@Dusk_Foundation $DUSK #dusk 以前は、ブロックチェーンを機関投資家向けに「導入可能な状態」にすることは、主にEVMへの互換性の問題だと思っていました。 開発者にSolidityのツールを提供し、UXは馴染みのある形を保てば、導入は後からついてくるはずだと。 しかしDuskEVMを見ていくほど、難しい課題は実は「プライバシー」だと感じるようになりました。 規制のある金融には、バランス(中間地点)が必要です。すべての取引サイズやポジション、あるいは顧客データを完全に透明な台帳に載せることはできません。ですが、すべてを見えなくしてしまうこともできない。 規制当局、監査人、そして権限のある参加者は、それぞれが必要とする情報を、必要なタイミングで得られることが求められます。 そこでHedgerが面白くなります。 Duskは、アクセスが必要になったときに選択的に開示できる一方で、トランザクションは機密のまま保つよう設計された、EVM向けのプライバシーモジュールとしてHedgerを提示しています。 そして、それは私のプライバシーの捉え方を変えます: プライバシーとは、すべてを隠すことではありません。 それは「誰が」「何を」「いつ見られるのか」「なぜ見られるのか」を制御することです。 この最後の部分が、規制市場では特に重要です。 NPEXとのつながりが、このアイデアをさらに興味深いものにしています。現実世界の資産をオンチェーンに載せていく流れと組み合わさることで、典型的なクリプトネイティブ層だけを対象にしたユースケースを超えていくことを示唆しています。 とはいえ、私はこの問題が解決されたとまでは言いません。 本当の試金石は、このアーキテクチャが、深刻な開示要件、監査要件、そしてコンプライアンス要件を満たしながら、機関レベルの規模での活動を扱えるかどうかです。 それが私の注目ポイントです。 なぜなら、もしかすると本当の問いはこうではないかもしれません: プライバシーか、それとも透明性か? おそらくはこうです: どの情報に対して、誰がアクセスできるのか。どんなルールのもとで、そしてどのレベルまで? @Dusk_Foundation $DUSK #dusk
@Dusk $DUSK #dusk
以前は、ブロックチェーンを機関投資家向けに「導入可能な状態」にすることは、主にEVMへの互換性の問題だと思っていました。
開発者にSolidityのツールを提供し、UXは馴染みのある形を保てば、導入は後からついてくるはずだと。
しかしDuskEVMを見ていくほど、難しい課題は実は「プライバシー」だと感じるようになりました。
規制のある金融には、バランス(中間地点)が必要です。すべての取引サイズやポジション、あるいは顧客データを完全に透明な台帳に載せることはできません。ですが、すべてを見えなくしてしまうこともできない。
規制当局、監査人、そして権限のある参加者は、それぞれが必要とする情報を、必要なタイミングで得られることが求められます。
そこでHedgerが面白くなります。
Duskは、アクセスが必要になったときに選択的に開示できる一方で、トランザクションは機密のまま保つよう設計された、EVM向けのプライバシーモジュールとしてHedgerを提示しています。
そして、それは私のプライバシーの捉え方を変えます:
プライバシーとは、すべてを隠すことではありません。
それは「誰が」「何を」「いつ見られるのか」「なぜ見られるのか」を制御することです。
この最後の部分が、規制市場では特に重要です。
NPEXとのつながりが、このアイデアをさらに興味深いものにしています。現実世界の資産をオンチェーンに載せていく流れと組み合わさることで、典型的なクリプトネイティブ層だけを対象にしたユースケースを超えていくことを示唆しています。
とはいえ、私はこの問題が解決されたとまでは言いません。
本当の試金石は、このアーキテクチャが、深刻な開示要件、監査要件、そしてコンプライアンス要件を満たしながら、機関レベルの規模での活動を扱えるかどうかです。
それが私の注目ポイントです。
なぜなら、もしかすると本当の問いはこうではないかもしれません:
プライバシーか、それとも透明性か?
おそらくはこうです:
どの情報に対して、誰がアクセスできるのか。どんなルールのもとで、そしてどのレベルまで?
@Dusk $DUSK #dusk
@Dusk_Foundation #dusk $DUSK 私は、オンチェーンに金融資産を載せるうえで最も難しいのは、単にその資産をそこに送り込むことだと思いがちでした。 しかしDuskを見れば見るほど、発行の後に出てくる難問がより複雑に思えてきます: 誰が何を見られるべきで、誰が何を証明できるべきなのでしょう? 規制された債券を例に取れば、譲渡には検証が必要になるかもしれませんが、それは誰もが保有者の残高やポジション、相手方(カウンターパーティ)を見てよいという意味ではありません。 このジレンマがあるのです: プライバシーを損なわずに、証明を失わないこと。 Duskは、シールドトランザクション、ゼロ知識証明、選択的開示によってそれに取り組みます。さらにDuskEVMとHedgerは、Solidityベースのアプリケーションに機密性のあるワークフローをもたらします。 ですが、もう一つ疑う価値のある前提があります。資産をオンチェーンに置いたからといって、そのライフサイクルが自動的にそこに移るわけではない、という点です。 発行、保有、譲渡、決済、サービシングは、切り離された複数のシステムにまたがって配置され続けることもあります。 だからこそ、Duskのネイティブ発行アプローチに私は惹かれています。単にトークンを作るだけでなく、資産のライフサイクルのより多くをオンチェーンにつなぎ続けることです。 本当の試金石は、規制された市場が、必要なところではそのライフサイクルをプライベートにし、必須のところでは証明可能にし、発行から決済、サービシングに至るまでを連結できるかどうかです。 そのバランスが大規模に機能するなら、トークン化の本当の価値は、そのトークンそのものから、トークンの周りのすべてを調整するインフラへと移っていくのでしょうか? オンチェーン・ファイナンスで最も重要なのは何でしょう?
@Dusk #dusk $DUSK
私は、オンチェーンに金融資産を載せるうえで最も難しいのは、単にその資産をそこに送り込むことだと思いがちでした。

しかしDuskを見れば見るほど、発行の後に出てくる難問がより複雑に思えてきます:

誰が何を見られるべきで、誰が何を証明できるべきなのでしょう?

規制された債券を例に取れば、譲渡には検証が必要になるかもしれませんが、それは誰もが保有者の残高やポジション、相手方(カウンターパーティ)を見てよいという意味ではありません。

このジレンマがあるのです:

プライバシーを損なわずに、証明を失わないこと。

Duskは、シールドトランザクション、ゼロ知識証明、選択的開示によってそれに取り組みます。さらにDuskEVMとHedgerは、Solidityベースのアプリケーションに機密性のあるワークフローをもたらします。

ですが、もう一つ疑う価値のある前提があります。資産をオンチェーンに置いたからといって、そのライフサイクルが自動的にそこに移るわけではない、という点です。

発行、保有、譲渡、決済、サービシングは、切り離された複数のシステムにまたがって配置され続けることもあります。

だからこそ、Duskのネイティブ発行アプローチに私は惹かれています。単にトークンを作るだけでなく、資産のライフサイクルのより多くをオンチェーンにつなぎ続けることです。

本当の試金石は、規制された市場が、必要なところではそのライフサイクルをプライベートにし、必須のところでは証明可能にし、発行から決済、サービシングに至るまでを連結できるかどうかです。

そのバランスが大規模に機能するなら、トークン化の本当の価値は、そのトークンそのものから、トークンの周りのすべてを調整するインフラへと移っていくのでしょうか?

オンチェーン・ファイナンスで最も重要なのは何でしょう?
🔘 Privacy + proof
83%
🔘 Asset lifecycle
17%
🔘 Transparency
0%
🔘 Settlement
0%
6 投票 • 投票は終了しました
本人確認中
翻訳参照
I have noticed something about Dusk Trade that made me rethink what tokenization is actually trying to solve. At first, a neobroker for tokenized assets sounded like another interface for buying and selling digital securities. But the deeper I looked, the more I realized the asset itself may not be the hardest part. In regulated markets, the difficult part is everything around it — onboarding investors, checking eligibility, connecting investor wallets, executing trades, coordinating payment, and ultimately settling ownership. That creates an interesting tension. Putting a bond, ETF or other financial asset on-chain can make it programmable. But programmability alone does not answer who is allowed to access it, what information should remain private, how authorized parties can verify activity, or how an executed trade ultimately becomes settled ownership. This is where Dusk Trade becomes more interesting to me. It is positioned as the application layer for tokenized financial assets, while DuskEVM provides EVM-compatible execution and DuskDS supports settlement and data availability. The real question is not whether these components exist, but whether they can operate together across the same financial workflow. And that is the part I’m still watching. Because tokenizing the asset may only be the beginning. The harder test is whether the infrastructure around it can actually make regulated markets more efficient — rather than simply recreating familiar complexity in a different form. Can Dusk Trade genuinely simplify the regulated financial workflow by bringing more of it on-chain or will the same complexity simply take a different form? @Dusk_Foundation $DUSK #dusk
I have noticed something about Dusk Trade that made me rethink what tokenization is actually trying to solve.

At first, a neobroker for tokenized assets sounded like another interface for buying and selling digital securities. But the deeper I looked, the more I realized the asset itself may not be the hardest part. In regulated markets, the difficult part is everything around it — onboarding investors, checking eligibility, connecting investor wallets, executing trades, coordinating payment, and ultimately settling ownership.

That creates an interesting tension.

Putting a bond, ETF or other financial asset on-chain can make it programmable. But programmability alone does not answer who is allowed to access it, what information should remain private, how authorized parties can verify activity, or how an executed trade ultimately becomes settled ownership.

This is where Dusk Trade becomes more interesting to me. It is positioned as the application layer for tokenized financial assets, while DuskEVM provides EVM-compatible execution and DuskDS supports settlement and data availability. The real question is not whether these components exist, but whether they can operate together across the same financial workflow.

And that is the part I’m still watching.

Because tokenizing the asset may only be the beginning. The harder test is whether the infrastructure around it can actually make regulated markets more efficient — rather than simply recreating familiar complexity in a different form.

Can Dusk Trade genuinely simplify the regulated financial workflow by bringing more of it on-chain or will the same complexity simply take a different form?

@Dusk $DUSK #dusk
翻訳参照
I still think DuskEVM is solving the easy part of the problem. Making Solidity developers comfortable on a new chain is one thing. Making regulated financial markets actually work around it is much harder. What caught my attention wasn’t the EVM compatibility. It was what sits underneath it: DuskEVM handles EVM execution, DuskDS provides settlement and data availability, while Hedger offers a route toward confidential EVM flows. Then I looked at NPEX. NPEX currently reports €217M+ in financing and 20,000+ active investors. Its partnership with Dusk is where an existing regulated market meets infrastructure being built for onchain financial workflows. But that creates the harder question: How much of that existing activity can actually become onchain secondary-market liquidity? Because tokenizing an asset isn’t the hard part. The real test is everything around it: who can access it, who can hold or transfer it, what stays private, what must be disclosed, how payments and settlement are coordinated, and whether the entire process works as one compliant workflow. That’s why Dusk Trade interests me. It is trying to connect those market processes rather than treating the token itself as the finished product. So I’m less interested in whether Dusk can put another asset onchain. I’m more interested in whether its regulated-market relationships can translate into real trading and settlement activity onchain. The architecture is one thing. Proving the liquidity is another. Can Dusk bridge that gap? @Dusk_Foundation $DUSK #dusk
I still think DuskEVM is solving the easy part of the problem.

Making Solidity developers comfortable on a new chain is one thing. Making regulated financial markets actually work around it is much harder.

What caught my attention wasn’t the EVM compatibility. It was what sits underneath it: DuskEVM handles EVM execution, DuskDS provides settlement and data availability, while Hedger offers a route toward confidential EVM flows.

Then I looked at NPEX.

NPEX currently reports €217M+ in financing and 20,000+ active investors. Its partnership with Dusk is where an existing regulated market meets infrastructure being built for onchain financial workflows.

But that creates the harder question:

How much of that existing activity can actually become onchain secondary-market liquidity?

Because tokenizing an asset isn’t the hard part.

The real test is everything around it: who can access it, who can hold or transfer it, what stays private, what must be disclosed, how payments and settlement are coordinated, and whether the entire process works as one compliant workflow.

That’s why Dusk Trade interests me. It is trying to connect those market processes rather than treating the token itself as the finished product.

So I’m less interested in whether Dusk can put another asset onchain.

I’m more interested in whether its regulated-market relationships can translate into real trading and settlement activity onchain.

The architecture is one thing. Proving the liquidity is another.

Can Dusk bridge that gap?

@Dusk $DUSK #dusk
DuskEVMは問題の「簡単な部分」を解決できている、という考えは今でも変わりません。もっと難しいのは、私がなぜ居続けるのか、という点です。 開発者向けの入口が見覚えのあるものだと気づきました。SolidityはHardhatやFoundryで動きますが、DuskEVMはメインネットでChain ID 744、テストネットで745を使います。 しかし、EVM互換性だけでは十分ではありません。 より興味深いのはHedgerです。これは同型暗号とゼロ知識証明によって、機密性のあるEVMワークフローを実現します。金融アプリケーションが、規制要件を満たす能力を失うことなくプライバシーを必要とするときに、重要になり得ます。 そしてDusk Tradeがあります。投資家のオンボーディング、管理された資産の移転、トークン化された金融資産における支払いの連携と決済など、そうした領域に焦点を当てています。 そこで私が感じる「本当の緊張感」が生まれます: EVMの互換性なら開発者を呼び込むことはできます。ですが、プライバシー、コンプライアンス、そして金融インフラは、開発者が留まる理由にならなければなりません。 Duskは、単に「もう一つのEVMチェーン」になるのではなく、馴染みのあるEVM環境を規制下の金融にとっての本当の優位性に変えられるのでしょうか? @Dusk_Foundation $DUSK #dusk 規制下の金融でDuskEVMが際立つためには、何が必要でしょうか?
DuskEVMは問題の「簡単な部分」を解決できている、という考えは今でも変わりません。もっと難しいのは、私がなぜ居続けるのか、という点です。

開発者向けの入口が見覚えのあるものだと気づきました。SolidityはHardhatやFoundryで動きますが、DuskEVMはメインネットでChain ID 744、テストネットで745を使います。

しかし、EVM互換性だけでは十分ではありません。

より興味深いのはHedgerです。これは同型暗号とゼロ知識証明によって、機密性のあるEVMワークフローを実現します。金融アプリケーションが、規制要件を満たす能力を失うことなくプライバシーを必要とするときに、重要になり得ます。

そしてDusk Tradeがあります。投資家のオンボーディング、管理された資産の移転、トークン化された金融資産における支払いの連携と決済など、そうした領域に焦点を当てています。

そこで私が感じる「本当の緊張感」が生まれます:

EVMの互換性なら開発者を呼び込むことはできます。ですが、プライバシー、コンプライアンス、そして金融インフラは、開発者が留まる理由にならなければなりません。

Duskは、単に「もう一つのEVMチェーン」になるのではなく、馴染みのあるEVM環境を規制下の金融にとっての本当の優位性に変えられるのでしょうか?

@Dusk $DUSK #dusk

規制下の金融でDuskEVMが際立つためには、何が必要でしょうか?
EVM compatibility
40%
Privacy + compliance
60%
5 投票 • 投票は終了しました
ガイドのためにフォローしてください。
ガイドのためにフォローしてください。
ガイドのためにフォローしてください。
ガイドのためにフォローしてください。
Asif The Trader
·
--
私のリターンとポートフォリオの内訳を見てください。投資のヒントをフォロー
ログインして、さらにコンテンツを読む
厳選トピックで世界の暗号資産トレーダーの仲間入り
⚡️ 暗号資産に関する最新かつ有益な情報が見つかります。
💬 世界最大の暗号資産取引所から信頼されています。
👍 認証を受けたクリエイターから、有益なインサイトを得られます。
メール / 電話番号
サイトマップ
Cookieの設定
プラットフォーム利用規約