😀 ユーザーへの入金（チャージ）の計上で最も危険なのは、備考がないことではなく、備考を身分証明書のように扱うことです。
私は @Dusk の Moonlight チャージ用スキャンガイドで、ほぼ隣り合う2つの文に目を引かれました。
文書では memo を16進数で返し、「まず形式を検証すべき、信頼できないルーティングデータ」に分類しています。
続く注意はさらに直接的です。memo を決して冪等キーとして扱わないこと。唯一として扱うべきは Dusk の取引IDです。
この違いが、入金システムが何を事実と見なすかを決めます。memo はシステムに「誰に渡す可能性があるか」を示すだけの手がかりであり、取引IDこそが「このお金が処理済みかどうか」を答えます。プラットフォームが両者を混同すると、便利なフロント側のラベル付けが、バックエンドの台帳として誤って解釈されてしまいます。
悪いシナリオは、2つのチャージが同じで、欠落していたり、形式が異常な memo を持っていることです。システムが備考で重複排除してしまうと、1件の計上漏れが起きます。逆に、それをそのまま帰属として扱うと、異常なリクエストを誤ったアカウントに押し付けてしまうかもしれません。ユーザーには入金がいつまでも反映されないだけが見え、運営チームは資金・ログ・顧客の間で何度も突合作業をすることになります。
これは $DUSK の備考設計が問題なのではなく、統合相手がルーティング情報は本来検証が必要だと認めるかどうかの問題です。@Dusk のドキュメントはすでに方針を示しています。不明または無効なメタデータは、サイレントに破棄するのではなく、人手による再確認（人的レビュー）に回すべきだ、と。
本当に検証に値するのは、接続側がこのルールをプロダクトに組み込み、ユーザーに「いま自分が人手の再確認の対象になっている」ことを見せられるかどうかです。#dusk