「Connect Wallet」が実際にdAppにどの情報へのアクセスを許すのかを知りたくて、Duskテストネット上のDarioとPieswapで実機のフローを試しました。どちらも最初の接続では、返ってきたのはプロフィールIDと公開アカウントのみでした。ポップアップには明確にこう書かれていました。『このサイトは、選択したプロフィールの公開アカウントのみを使用できるようになります。』シールドされた受信アドレスを要求したときだけ、2回目の同意ステップが表示され、そこで初めてレスポンスにshieldedAddressが含まれました。ポップアップも変化し、『共有可能なシールドされた受信アドレス』という名称になっていました。両方の統合で同じ手順でした。

ここがポイントです。私は「Connect Wallet」を1つの権限イベントだと捉えていました。違います。テストの制御条件では、同意時点で公開アカウントへのアクセスと、シールドされた受信アドレスの共有が分離されていました。

この分離によって、最小限開示の境界の一部が、ウォレットの同意フロー内に組み込まれています。ユーザーが完全に管理すべきとは限りません。どちらのテストでも、「Connect」をクリックしただけではシールドされたアドレスのスコープは付与されませんでした。dAppがそれを得るには、別の同意ステップをまたいで進む必要がありました。

調査中に私が誤解していた点もあります。132文字のアカウント文字列がシールドされたアクセスを示唆しているのではないかと思っていました。違いました。両方のdAppはベースラインでは同じ形式のアカウントを返しましたが、shieldedAddressは明示的な要求があるまで存在しませんでした。

残っている未解決の疑問が1つあります。以前のDarioメインネットのセッションでは挙動が異なっていましたが、同じ制御条件では再現できていないため、リークとは断言しません。確認できたのは、私がテストネット統合2件で見た範囲では公開のみの権限境界が維持されていた、ということだけです。もちろん、すべての環境で保証できるとは言えません。

『ウォレット接続は、承認したスコープを公開すべきであり、それを推測させるべきではない。』

次に見たいのは、同じウォレットバージョンで、メインネット上でも同じ制御テストを行い、クリーンな権限設定と同一の計測を維持して、境界が環境をまたいで保持されるかを確認することです。

#dusk $DUSK @Dusk