最初に確認対象を定める
一つの報告書で、送金確認、資産移動、サービスとの関係、アカウント帰属、価値算定を扱う場合があります。それぞれ必要データは異なります。争う結論と対応する質問を並べることで、必要な事実を調べたか、別の近い事実に置き換えたかを確認できます。
アドレスへの送金と特定の取引所利用者への入金は、異なる根拠を要します。前者は台帳記録、後者はアドレス・入金・アカウントを結ぶ情報が必要です。経路図だけでは証明できません。
元の情報を確認する
ネットワーク、完全なアドレス、取引識別子、期間、資産識別子を照合します。トークンの銘柄名だけでは足りず、コントラクト等を確認します。同じ名前でも同一資産とは限りません。
次に状態と実際の実行結果を確認します。ハッシュの発見だけでは送金分析に代わりません。スマートコントラクトでは呼出しと実行結果を考慮し、エクスプローラー情報と取引内容を照合します。金額は単位と小数桁も確認します。
台帳記録と推測を区別する
直接の送金記録、アドレスのグループ化、所有者名の記載は証拠の根拠が異なります。直接のデータ、分析、外部資料のどれによる関係かを説明します。外部ラベルでは出典、取得日、裏付けの内容が重要です。
入金の混在、一括支払い、サービス内部処理には特に注意します。混在資金の配分規則を使う場合、内容と経路・最終金額への影響を説明します。
再確認が可能かを評価する
別の専門家が元データと手順を理解できる必要があります。取引表、リンクや識別子、図の説明、ツール、取得日を確認します。対応する取引の一覧がない色付きの矢印だけでは、経路の説明として不十分です。
元資料が不足する場合は制約として記録します。付録の欠落だけで結論を誤りとはできません。確認できない記述と回答上の重要性を先に特定します。
レビューに提出する資料
報告書全文、付録、質問、手元の元資料が必要です。ページ・取引を示す具体的な疑問一覧も役立ちます。一部の結論を確認し、他に不備を見つける場合もあり、依頼者の立場で結果は決まりません。
レビューは技術上の不備、根拠、結論への影響を記載します。大量の取引を新たに調査する必要があれば、独立した調査となる場合があります。形式、範囲、成果は資料確認後に合意します。
まず課題から
状況、手元の資料、回答が必要な質問を説明してください。