トークンがウォレットに表示されない時の確認手順：chain・contract・decimalsを分ける
送金・swap・bridge後にERC-20が見えないとき、chain、account、Transfer log、token contract、balanceOf、decimals、token detection、indexerを順に確認します。
送金、swap、bridgeのtransactionが成功したのに、ウォレットの資産一覧へtokenが出てこない。ここで最初に分けるべきなのは、wallet表示に行がないことと、正しいchain・account・token contractのbalanceOfが0であることです。前者だけでは資産消失を証明しません。
反対に、tokenが一覧へ表示されたことも、公式、換金可能、安全、正しいbridge representationである証拠にはなりません。この記事では、chain、account、Transfer log、contract、balanceOf、decimalsを先に固定し、その後でtoken detection、token list、RPC、indexer、cache、非表示設定を調べます。
wallet接続、署名、custom token import、approve、swap、burn、claim、transaction送信、実資産移動は行いません。掲載する検証例は架空addressだけを使うread-only dataです。
先に止める操作と保存する値
原因が分かるまでは、同じtokenの再送、検索結果から開く「表示解除」や「cash out」、未知tokenのswap・burn・approve、DM supportへの接続を止めます。表示の問題を直すためにseed phrase、private key、keystore、remote-control appが必要になることはありません。
最初に次を一つの調査メモへ保存します。
| 項目 | 保存する値 | なぜ必要か |
|---|---|---|
| chain | network名ではなくchain ID、利用RPC、確認block | 同名networkや別chainを混ぜないため |
| account | 受取予定address、walletで選択中のaccount | 別accountの一覧を見ないため |
| transaction | tx hash、receipt status、block、to、logs |
broadcast・成功・token移動を分けるため |
| token | Transfer logのaddress、公式sourceが示すcontract |
symbolやiconをasset IDにしないため |
| recipient | Transfer logのto |
wallet所有addressと一致するか確認するため |
| balance | balanceOf(account)のraw uint256とblock |
UIではなくcontract stateを確認するため |
| metadata | 同じcontractのdecimals、symbol、name | raw integerの表示方法を確認するため |
| display | wallet/version、token detection、非表示、RPC、確認時刻 | indexer・cache・設定の観測を再現するため |
bridgeのdestination transaction自体がまだない場合は、先にbridge未着金をsource・message・destinationへ分ける手順へ戻ります。取引所内残高へ反映されない場合はchain statusと取引所statusを分ける手順、別networkへ送った可能性がある場合は送信chainと管理主体の確認順を使ってください。
表示ではなく証拠を上から順に確認する
順番は次のとおりです。
- receiptを開いたExplorerとRPCのchain IDを固定する
- walletで選んだaccountとTransfer logのrecipientを照合する
- Transfer logを発生させたcontract addressをtoken候補にする
- 同じchain・contractへ
balanceOf(account)をread-onlyで呼ぶ - raw integerを同じcontractのdecimalsで整形する
- on-chain balanceがある場合だけwalletの表示層を調べる
最初の不一致が原因候補です。後ろの表示設定から先に触ると、別contractを追加して「直ったように見える」状態を作りやすくなります。
1. chain IDとaccountを固定する
tokenは「どのchainの、どのcontractが、どのaccountについて返すbalanceか」で読みます。walletに表示されたnetwork名や同じ0x形式だけでは足りません。
確認する値は次の4つです。
- transaction receiptを取得したchain ID
- walletが現在読んでいるchain ID
- Transfer logのrecipient address
- walletで選択中のaccount address
例えばEthereum Mainnetのcontract addressと、Base上で同じ文字列になるcontract addressは、同じasset IDではありません。account addressの文字列が複数EVM chainで同じでも、balance stateはchainごとに別です。
RPCを使う場合はeth_chainIdを先に記録し、後続readを同じendpointへ対応させます。過去transactionと現在balanceを再現したい場合は、latestではなく確認対象blockを保存してください。複数readを同じblockへ固定する方法はRPC snapshotの作り方で詳しく説明しています。
2. Transfer logからtoken contractとrecipientを得る
ERC-20のTransfer eventは次の形です。
Transfer(address indexed from, address indexed to, uint256 value)receiptでは、eventを発生させたlog.addressがtoken contract候補です。transaction本体のtoはrouter、bridge、vault、multisigなど別contractの場合があります。
| receiptの場所 | 読む値 | 間違えやすい点 |
|---|---|---|
receipt.status |
transaction全体の成功・失敗 | successだけで受取残高を断定する |
transaction.to |
最初に呼ばれたaddress | token contractとは限らない |
log.address |
eventをemitしたcontract | 公式tokenかは別途照合が必要 |
topics[1] |
indexed from |
32-byte wordの末尾20 bytesがaddress |
topics[2] |
indexed to |
受取予定accountと一致するか確認 |
data |
raw uint256 value |
decimals適用前の整数 |
公開検証JSONでは、transactionのtoを架空router 0x3333…3333、Transfer logのcontractを0x0000…1006に分けています。recipientは0x1111…1111、raw valueは123456789です。
Transfer logがrecipientへ向いていても、そのtokenが公式、安全、売買可能という証拠ではありません。spam tokenもTransfer eventを作れます。まず「どのcontractの値が動いたか」を特定する証拠として使います。
3. balanceOfでon-chain balanceを読む
ERC-20のbalanceOf(address)は、指定accountのbalanceをraw integerで返します。eth_callはtransactionを作らず、chain stateをread-onlyで実行するJSON-RPC methodです。
架空account 0x1111…1111のcalldataは次の形になります。
0x70a08231
00000000000000000000000011111111111111111111111111111111111111110x70a08231はbalanceOf(address)の4-byte selectorで、その後ろにaddressを32 bytesへ左paddingします。RPC requestではtoへTransfer logで得たtoken contract、dataへこのcalldata、block parameterへ記録したblockを指定します。
{
"jsonrpc": "2.0",
"id": 1,
"method": "eth_call",
"params": [
{
"to": "0x0000000000000000000000000000000000001006",
"data": "0x70a082310000000000000000000000001111111111111111111111111111111111111111"
},
"0xFIXED_BLOCK"
]
}0xFIXED_BLOCKは説明用placeholderです。そのまま送信せず、調査対象chainの実在block numberへ置き換えます。この記事の検証dataはRPCへ接続せず、wallet、secret、signer、write methodを持ちません。
結果が0の場合でも、すぐ「消失」と結論づけません。次を再確認します。
- chain IDとblockが正しいか
- accountがrecipientと一致するか
- contractがTransfer logと公式sourceの両方に一致するか
- transfer後のblockを読んでいるか
- bridgeやvaultが別representation・claimable balanceを使っていないか
- callがrevert、空response、RPC errorになっていないか
結果が0より大きく、wallet表示だけがないなら、on-chain balanceと表示層を切り分けられます。
4. raw integerをdecimalsで表示額へ変換する
ERC-20のbalanceは小数ではなく整数です。decimalsがdなら、人が読む表示は概念上raw / 10^dです。JavaScriptのNumberへ大きな値を入れると丸める可能性があるため、rawは文字列またはBigIntのまま扱います。
架空の検証dataは同じように見えるsymbol BOXで、0・6・8・18 decimalsを分けています。
| decimals | raw integer | 正しい表示 |
|---|---|---|
| 0 | 42 |
42 |
| 6 | 123456789 |
123.456789 |
| 8 | 123456789 |
1.23456789 |
| 18 | 1234567890123456789 |
1.234567890123456789 |
小数点を文字列で置く最小例です。
function formatUnits(rawValue, decimals) {
const digits = BigInt(rawValue).toString()
if (decimals === 0) return digits
const padded = digits.padStart(decimals + 1, '0')
const whole = padded.slice(0, -decimals)
const fraction = padded.slice(-decimals).replace(/0+$/, '')
return fraction ? `${whole}.${fraction}` : whole
}raw 123456789のcontract decimalsが6なら123.456789です。walletへ18と誤登録すると0.000000000123456789に見えますが、on-chain raw balanceは変わりません。custom tokenを再追加してもassetを移動・回収したことにはなりません。
EIP-20ではname、symbol、decimalsはoptional metadataです。getterがない、標準的なABI encodingを返さない、proxyや古い実装に癖があるtokenもあるため、metadata取得失敗とbalance 0を同じ意味にしないでください。
5. symbolではなくchain IDとcontractでassetを分ける
name、symbol、icon、decimalsは表示metadataです。同じ文字が見えてもasset identityは一致しません。
| 見た目 | 実際に比較する値 | 判断 |
|---|---|---|
| 同じsymbol・同じdecimals | chain ID、contract address | contractが違えば別token |
| 同じcontract文字列 | chain ID | chainが違えば別state |
| nativeとwrapped | ERC-20 contractの有無 | wrapping前後は別representation |
| canonical bridgedとthird-party bridged | source token、route、destination contract | issuer・backing・redeem経路が異なり得る |
| 同じlogo・name | 公式registryとcontract | asset identityの証拠にならない |
Uniswap Token Listsのschemaもtoken metadataとしてchainIdとaddressを別々に持ちます。ただし、schemaへ適合するlistを誰でも作れるため、list掲載だけで公式性や安全性を保証しません。listの配布元、version、確認日、issuerやbridgeの公式contract sourceを別に照合します。
Explorerのverified表示もtokenの公式性や安全性を保証しません。compiler・constructor・proxy・metadataからverified sourceを再ビルドする手順で、sourceとruntime bytecodeの対応、proxy先、ownerやadminの別評価まで確認できます。
bridge後にdestination receiptが成功している場合は、source tokenとdestination tokenのmappingを利用routeの公式情報で確認します。native、wrapped、bridged、third-party representationの違いはbridgeのtoken mapping確認も参照してください。
6. on-chain balanceがある場合だけwallet表示層を調べる
ここまでで正しいchain・account・contractのbalanceOfが0より大きければ、次にwallet側の表示経路を確認します。
| 表示層 | 確認すること | 境界 |
|---|---|---|
| selected network | walletが正しいchainを表示しているか | network切替はasset移動ではない |
| selected account | recipientと同じaccountか | account追加はbalance複製ではない |
| automatic detection | 対象chainとtokenが現在の検出対象か | 未検出はbalance 0を意味しない |
| token list / metadata API | chain ID、contract、decimals、更新時刻 | list掲載は公式・安全保証ではない |
| hidden / spam filter | 手動非表示・自動filter対象か | 非表示はburnや削除ではない |
| RPC | chain ID、head、error、別endpointとの差 | RPC追加はasset回収ではない |
| indexer / cache | Explorer・wallet・portfolioの更新blockと時刻 | 遅延はchain stateと別 |
2026-08-31確認時点のMetaMask公式案内は、automatic token detectionと、searchまたはcontract addressによるmanual importを分けています。また、MetaMask自身が「有効tokenの権威的な一覧」を維持しているわけではないと説明しています。対応networkや画面位置は変わり得るため、wallet versionと公式の現行手順を確認してください。
別RPCへ切り替える場合も、公式network情報から選び、chain IDが一致することを先に確認します。未知サイトが指定するRPCやnetwork追加を、残高表示のためにそのまま承認しないでください。
7. custom token importで変わるもの・変わらないもの
custom token importは、walletへ「このchainのこのcontractを一覧で追跡する」と教える表示操作です。
変わり得るものは次です。
- asset rowが一覧へ追加される
- symbol、decimals、iconなどの表示が補われる
- walletが対象contractのbalanceを定期取得する
変わらないものは次です。
- contract storageの
balanceOf - tokenの所有者、issuer、backing、transfer制限
- bridge前後のrepresentation
- swap可能性、価格、流動性、安全性
- assetの公式性
EIP-747のwallet_watchAssetも、walletがasset追加要求を認識したことと、実際に表示・承認されたことを分けています。DAppからtoken追加promptが出ても、chain IDとcontractを独立して確認し、未知サイトの要求を表示修正として承認しないでください。
8. spam・airdrop tokenは「表示するために触る」を止める
身に覚えのないtokenがExplorerやportfolioに見える場合、表示されたこと自体は被害ではありません。危険は、token名、symbol、error message、metadataに誘導され、外部siteを開いて署名・approve・swap・burn・claimすることです。
MetaMaskのfailed transaction scam案内は、動かせないairdrop tokenを送付し、失敗messageからphishing siteへ誘導する手口を説明しています。
未知tokenでは次を行いません。
- error messageやtoken名に書かれたURLを開く
- 「換金確認」のためにapprove、swap、burnを試す
- gasや解除料を追加送金する
- seed phraseやprivate keyを入力する
- token list掲載やwallet表示を安全評価に使う
walletに非表示機能があるなら、interactせず表示だけ隠す選択肢があります。非表示にしてもon-chain tokenはburnされません。
状態別の次の確認先
| 観測 | 分類 | 次に確認するread-only evidence |
|---|---|---|
| receiptなし | pending / dropped / wrong chain / RPC lag | tx hash、from・nonce、chain ID、別Explorer |
| receipt failed | transaction failed | revert、called contract、fee。正常なTransferを想定しない |
| receipt success、対象Transferなし | route / event mismatch | logs全体、bridge / router event、recipient |
| Transferあり、recipient不一致 | different account / destination | topics、受取address、custodial / contract管理主体 |
Transferあり、balanceOf = 0 |
later transfer / wrong block / wrong identity | transfer後block、chain、account、contract、subsequent logs |
balanceOf > 0、表示なし |
wallet display / detection / indexer | decimals、hidden state、RPC、wallet version、更新時刻 |
| rawは一致、表示額が違う | decimals / formatter | same contractのdecimals、BigInt整形、manual metadata |
| symbolだけ一致 | identity unknown | chain ID、contract、issuer / bridge公式source |
| 未知tokenが表示された | spam候補 | interactせず、公式source不在なら非表示のまま停止 |
公式supportへ渡すevidence package
walletまたはserviceの公式supportへ問い合わせる場合は、次をまとめます。
checked at:
wallet / app version:
chain name and chain ID:
RPC hostname, without credential:
account / recipient:
transaction hash and block:
receipt status:
Transfer log contract / from / to / raw value:
balanceOf block / calldata / raw result:
name / symbol / decimals results:
correct formatted value:
wallet display state / hidden state / last refresh:
official token or bridge source used to verify the contract:public chain dataをsupportへ渡す場合も、ticketの公開範囲は別です。email、電話番号、他assetの残高、本人確認書類、API key、session cookie、wallet backupは必要性を確認して最小限にします。seed phrase、private key、password、2段階認証code、remote-controlは渡しません。
よくある質問
custom tokenを追加すれば資産を回収できますか？
できません。importはwallet表示を追加する操作です。正しいchain・contractにbalanceがあれば見える可能性がありますが、別chainのassetを移動したり、誤送金を返還したりしません。
symbolとdecimalsが同じなら同じtokenですか？
同じとは限りません。同じchainでもcontractが違えば別tokenです。同じcontract文字列でもchain IDが違えば別stateです。symbol、name、iconはasset identityの根拠にしません。
Explorerではtokenがあるのにwalletだけ0です
Explorerが見ているchain、account、contract、blockを先に固定し、同じ条件でbalanceOfを読みます。一致するならwalletのselected network / account、decimals、token detection、hidden state、RPC、indexer時刻を確認します。
tokenが表示されたのでswapして安全か確かめてもよいですか？
未知tokenでは行いません。表示やbalanceOf > 0は、安全性、transferability、価格、流動性を証明しません。失敗transactionや外部URLを使うscamがあるため、独立した公式sourceがないtokenはinteractせず停止します。
最終チェックリスト
- transactionとwalletのchain IDを記録した
- Transfer logのrecipientと選択中accountを照合した
- transaction
toではなくTransferlog.addressからcontract候補を得た - contractをissuer・bridgeの公式sourceと照合した
-
balanceOf(account)のraw resultとblockを保存した - 同じcontractのdecimalsでBigIntのまま表示額を計算した
- symbol、name、iconをasset identityにしていない
- native、wrapped、bridged、third-party representationを分けた
- on-chain balance確認後にtoken detection、list、RPC、indexer、cache、hidden stateを調べた
- custom token importを回収・移動・安全保証として扱っていない
- 未知tokenでapprove、swap、burn、claim、外部URLを試していない
- supportへsecretや不要な個人情報を渡していない
token未表示の切り分けは、chain ID、account、Transfer logのcontract、固定blockのbalanceOf、同じcontractのdecimalsを一つの証拠列へ対応させ、walletのtoken detection・list・indexerは最後に確認することです。
この記事にはwallet、swap、bridge、token import tool、取引所、recovery serviceのaffiliate CTAを置いていません。表示の不安から追加transactionへ誘導せず、read-only evidenceを先に揃える順序を示しています。
確認した一次情報
- ERC-20 Token Standard確認日: 2026/08/31
- wallet_watchAsset RPC Method確認日: 2026/08/31
- Ethereum JSON-RPC API確認日: 2026/08/31
- MetaMask token display and import guidance確認日: 2026/08/31
- MetaMask missing or incorrect token balance guidance確認日: 2026/08/31
- MetaMask failed transaction scam guidance確認日: 2026/08/31
- Uniswap Token Lists types at pinned commit確認日: 2026/08/31
