Dusk を調べているとき、ひとつ気になったことがあります。あるウォレットが身元（identity）に正しく紐づいたままであっても、その転送の裏にある適格性（eligibility）判断がもはや最新ではないために、転送に失敗し得るという点です。

最初は、これらは基本的に同じ 1 つの検証ステップだと思っていました。

しかし違います。

アーキテクチャを見るほど、これはウォレットの問題というより、状態管理（state-management）の問題に見えてきました。

ウォレットのバインド（binding）は、身元とウォレットの間に暗号学的な関係を確立します。

その関係は、転送の適格性に影響する外部条件が変わっても、まったく問題なく有効であり続け得ます。

たとえば、月曜日にバインドされたウォレットを想像してください。火曜日に、オフチェーンのコンプライアンス・パラメータが変更されます。

身元の関連付けは取り消されていない、ウォレットも変わっていない、ユーザーは引き続きそのウォレットを支配していることを証明できます。

ですが、トランザクション評価に用いられるポリシー状態が再計算されていなければ、転送はまったく別の結果に遭遇する可能性があります。#dusk 。

この違いは見落とされやすいです。UI は複数のチェックをひとつの体験に圧縮してしまうためです。「verified（検証済み）」が必ずしも「今この瞬間に eligible（適格）」を意味するわけではありません。

内部では、いくつかの独立した状態遷移が存在し得ます。たとえば、署名の検証、身元の関連付け、資格情報（credential）やポリシーのステータス、そして最終的な転送の許可です。@Dusk 。

重要なエンジニアリング上の問いは、外部ポリシーの変更が、トランザクションが実際に評価する状態へどのように伝播（propagate）するのかです。

$DUSK の場合、これは興味深いトレードオフを生みます。ポリシー状態を保守的に保つことでコンプライアンスの露出を減らせる一方、古い状態は転送の拒否や運用上の摩擦につながります。

より積極的に更新すれば鮮度は上がりますが、追加の計算、調整、インフラ依存が発生します。

私がまだ理解しようとしているのは、インセンティブの層です。有効なウォレットが古くなった許可（outdated permission）になったとき、その状態を更新することに対して誰が経済的・運用的に責任を負うのか、という点です。