本文へ移動

トークンの小数桁を検証する方法

正しいコントラクトとブロックから ERC-20 の decimals を確認し、浮動小数点誤差なしで生の残高、送金、承認、ブリッジ変換を照合します。

更新日

教育目的の情報であり、投資またはセキュリティ助言ではありません。小数桁はトークンの同一性、価値、裏付け、安全性を証明しません。

直接の回答

ERC-20 トークンの decimals() は、整数のトークン単位を画面にどう表示するかを示す任意のメタデータです。戻り値が d なら、通常の表示額は raw / 10^d です。コントラクト内の計算を変えず、トークンの真正性も証明しません。結果を信頼する前に、チェーン、正確なコントラクトアドレス、コードまたはプロキシ実装、ブロックを確認します。

指定ブロックで独立した RPC から decimals() を直接読み、戻り値を ABI で uint8 としてデコードし、発行者の公式コントラクト一覧と信頼できるエクスプローラーで照合します。さらに、生の balanceOf、送金、承認、レシート、イベント値で倍率を検算します。呼び出しが存在しない、リバートする、データが不正、または他の証拠と矛盾する場合に 18 を黙って仮定してはいけません。

仕組み

ERC-20 が保存し移転する金額は符号なし整数です。小数点を挿入するのは表示層で、コントラクトが受け取る値は整数のままです。ユーザー入力は十進文字列か任意精度整数で変換し、二進浮動小数点を使いません。10^d を掛けた結果が整数になる数量だけが表現可能です。

decimals() は任意なので、準拠トークンが実装していない場合があります。独自実装やアップグレード可能な実装は予想外の値を返したり、アップグレード後に動作を変えたりもします。ERC-1967 プロキシでは、プロキシアドレス、実装またはビーコン、管理者、アップグレードイベントを調べます。トークン状態はプロキシアドレスで読み、すべてを同じブロックで比較します。

Allowance と ERC-2612 permit の値も生の整数です。送金表示が正しくても、承認、ルーターの最小額、ブリッジ額、会計データベースが同じ倍率を使った証明にはなりません。ブリッジの送信元と送信先で小数桁が異なることもあるため、文書化された変換・丸め規則に従って両側の表示価値と生単位を比較します。

次の手順を使います。

  1. チェーン ID またはドメイン、トークンコントラクト、ブロック番号、RPC エンドポイント、観測時刻を固定します。
  2. 発行者の公式一覧でアドレスを確認し、名前、シンボル、アイコン、検索結果を権威ある証拠とみなしません。
  3. デプロイ済みコードとプロキシかどうかを調べ、実装またはビーコン、管理者、最近のアップグレードを記録します。
  4. decimals() を呼び、ABI で uint8 をデコードします。既定値を補わず、成功、リバート、空、不正出力を記録します。
  5. 整合するブロックで生の balanceOftotalSupply、allowance、取引 calldata、レシート、イベントを読み、確認した倍率で表示します。
  6. 手数料、丸め、端数、リベース、転送税を含め、送金、承認、見積り、ブリッジ額を整数演算で再計算します。
  7. シミュレーション後に少額取引を送り、前後の生残高を照合します。画面、RPC、イベント、残高に不一致があれば停止します。

  • 同じ生値と2つの倍率。 raw = 123456789 のとき、d = 6 では 123.456789d = 18 では 0.000000000123456789 と表示され、差は 10^12 倍です。
  • 表現可能性が重要です。 d = 6 なら 1.25 トークンは生単位 1250000 です。0.0000001 トークンは1生単位未満なので、拒否するか明示した規則で丸める必要があります。
  • 承認倍率の不一致。 d = 6100 トークンの allowance は 100000000 です。d = 18 で符号化すると 100000000000000000000 となり、意図より 10^12 倍大きくなります。
  • ブリッジでの再スケーリング。 文書化された 1:1 ルートが d = 6 の送信元トークンを d = 18 の送信先表現へ変換する場合、生値 25000002.5 トークン、送信先の 25000000000000000002.5 を表します。手数料、上限、端数、実受取残高は別途検証します。

リスク

  • 正しいアドレスを誤ったチェーンで照会する。
  • コピーされた名前、シンボル、アイコンが別のコントラクトを隠す。
  • 以前の確認後にプロキシ実装またはビーコンが変わる。
  • RPC やエクスプローラーが古い、未確定、または矛盾する状態を返す。
  • 欠落または不正なメタデータが黙って 18 に置き換えられる。
  • 二進浮動小数点変換が大きい値や高精度の値を丸める。
  • ウォレットが送金を正しく表示しても allowance や permit を誤表示する。
  • データベースが生単位と表示額を混在させる。
  • ブリッジが同じ小数桁を仮定するか、端数の丸めを開示しない。
  • 転送手数料、リベース、発行、焼却、一時停止、凍結が単純な照合を壊す。
  • 取引 calldata、イベント、レシート、実際の残高差が一致しない。
  • 小数桁確認を発行者、準備資産、流動性、安全性の証明と誤認する。

よくある誤解

  • すべての ERC-20 は小数桁が 18 です。 メタデータは任意で、別の値を返す実装もあります。
  • 小数桁は EVM が使う精度ビットです。 これは十進表示の規約で、トークン演算は整数のままです。
  • エクスプローラーの整形済み残高は独立した確認です。 同じメタデータ呼び出しに依存し、同じ誤りを共有し得ます。
  • 同じシンボルと小数桁なら同じ資産です。 正しいチェーン、正確なコントラクト、発行者の証拠も必要です。
  • 少額送金の成功ですべての統合が検証されます。 承認、ルーター、ブリッジ、取引所、会計システムは別々に倍率を適用し得ます。

関連トピック

出典

ナビゲーション

Wiki を検索...