ブリッジ送金がpending・failed・未着金のときの確認順｜source・message・destination

ブリッジ画面がpendingのまま、source chainのtransactionはsuccessなのにdestinationへ反映されない。このとき、同じ送金を繰り返したり、検索広告やDMのsupportを開いたりする前に、source transaction、cross-chain message、protocol stage、destination transactionまたはclaim、token mappingを分けて確認します。

source側のsuccessは、そのchain上のcallが成功した証拠です。destination側で同じmessageが実行され、意図したtoken contractへ到達した証拠ではありません。

この記事は公開testnetのreceiptとlogをread-onlyで照合します。wallet接続、署名、claim、retry、approve、bridge送信、mainnet資産操作は行いません。

先に止めること、保存すること

原因が分かるまでは、次の操作を止めます。

同じroute・amountの再送
pendingを消すためだけのspeed up、cancel、claim、redeem
検索広告、SNS返信、DMから開く「recovery」「bridge support」
seed phrase、private key、keystore、remote-control appの共有
destinationに見えないtokenを別bridgeへ送り直す操作

代わりに、次の項目を一つの調査メモへ保存してください。

層	保存する値	理由
route	利用した公式URL、bridge名、canonical / third-party	同じ名前でもstatus modelが違うため
direction	source chain → destination chain、deposit / withdrawal	往路と復路でstageが違うため
asset	symbol、amount、source token contract、想定destination token contract	symbolだけではrepresentationを区別できないため
source	tx hash、block、receipt status、bridge contract、event	source callとmessage作成を分けるため
message	sourceHash、withdrawal hash、ticket ID、position、provider order IDなど	chain間の同じ1件を結ぶため
protocol	relay、prove、challenge、confirm、executableなどの公式status	時間だけで停止箇所を決めないため
destination	tx hash、receipt status、event、claim / execution state	到着処理が実行されたか確認するため
display	wallet / bridge UIの表示、確認時刻、browser・app version	chain stateとの表示遅延を分けるため

tx hashやaddressは省略せずコピーし、chain IDと確認時刻も添えます。公開supportへ出す場合は、個人情報、残高全体、email、IP address、未公開order情報を必要な範囲まで隠します。seed phraseとprivate keyは、supportの本人確認にも使いません。

ブリッジ送金をsource transaction、message identifier、protocol stage、destination transactionまたはclaim、token mappingへ分ける流れ

source transactionのsuccessは最初のcheckpoint

EVMのeth_getTransactionReceiptは、receiptがまだなければnull、取り込まれた後はstatusとlogsを返します。まずsource chainの正しいRPCまたはblock explorerでtx hashを確認します。

sourceの証拠	読めること	まだ読めないこと
receiptが`null`	未採用、dropped / replaced、またはRPC lagの候補	cross-chain messageが確定したとは言えない
`status = 0`	source callがrevertした	正常なsource eventやdestination実行が成立したとは言えない
`status = 1`、対象eventなし	callは成功したが、想定したbridge経路か再確認が必要	message IDとdestination実行
`status = 1`、対象eventあり	source callとmessage作成の証拠を取得できる	relay、proof、destination receipt、token表示

receiptがないときのnonce、replacement、dropped transactionの切り分けはtransactionがpendingのときの確認順で先に確認できます。source側を飛ばしてbridgeの待ち時間だけを調べると、そもそも別chain、別hash、reverted callを待ち続けることがあります。

message identifierで同じ送金をchain間につなぐ

cross-chain messageは、source transactionからdestination executionへ渡す指示です。ただし、すべてのbridgeがmessage hashという同じ名前・計算式を使うわけではありません。

OP Stack deposit: L1 block hashとTransactionDepositedのlog indexから作るsourceHash
OP Stack withdrawal: withdrawal transaction / messageを識別するhashとproof対象
Arbitrum parent-to-child: retryable ticketを追跡するidentifier
Arbitrum child-to-parent: L2ToL1TxのpositionとOutbox execution
third-party liquidity bridge: provider order ID、deposit event、relayer / liquidity settlementの組み合わせ

bridge UIに短いIDしか出ない場合でも、source event、公式explorer、公式SDK・status APIがどの値を対応させるかを一次情報で確認します。別のbridge向けのhash calculatorへtx hashを貼っても、同じmessageを追跡できるとは限りません。

canonical bridgeとthird-party bridgeを分ける

canonical rollup bridgeは、rollup protocolのdeposit / withdrawal messageを通して資産表現をmint・burn・lock・releaseします。一方、third-party liquidity bridgeはdestination側のpoolから先に支払い、後でrelayerや別routeがrebalanceする方式があります。

比較	canonical bridge	third-party liquidity bridge
主なidentifier	protocol message、withdrawal、ticket、position	order ID、deposit event、provider message
destination処理	rollup messenger / gateway / outbox	relayer、liquidity pool、provider contract
待ち状態	protocol proof・confirmation・execution	relayer、liquidity、quote expiry、provider settlementもあり得る
問い合わせ先	rollup / bridgeの公式statusとsupport	利用したproviderの公式order statusとsupport

third-party bridgeのsource txを、canonical bridgeの公式UIへ入れても追跡できない場合があります。逆に、provider画面のcompletedだけでcanonical destination receiptやtoken contractを確認したことにもなりません。利用したURLとsource contractを最初に固定してください。

OP Stackはdepositとwithdrawalでstageが違う

OP Stack Standard Bridgeでは、両chainのtoken representationをlocalTokenとremoteTokenのpairとして扱います。source transactionの成功、cross-domain message、destination側のfinalize、token mappingを分けて読みます。

EthereumからOP Stackへのdeposit

典型的なL1 → L2 depositでは、L1のOptimismPortalがTransactionDeposited eventを出し、そのL1 block hashとlog indexからuser-deposit domainのsourceHashを作ります。L2側ではtype 0x7eのdeposited transactionに同じsourceHashが入ります。

depositId  = keccak256(l1BlockHash || bytes32(l1LogIndex))
sourceHash = keccak256(bytes32(uint256(0)) || depositId)

この対応が見つかって初めて、source eventとL2 transactionを同じdepositとして結べます。L1 receiptのstatus = 1だけでは、L2 receiptのstatusを確認したことになりません。

OP StackからEthereumへのwithdrawal

L2 → L1 withdrawalはdepositの逆再生ではありません。withdrawalをL2で開始し、L1側で出力・proof条件を満たし、challenge periodなどrouteの条件を経てfinalizeします。initiated、ready to prove、proven、ready to finalize、finalizedは同じ状態ではありません。

所要時間を「必ず7日」のような一つの数字へ固定しないでください。network、fault proof構成、対象output、proof / finalizeの実行状況で変わります。選んだchainとrouteの公式statusを、同じwithdrawal identifierで確認します。

OP StackとArbitrumのcanonical L2→L1を、実際のwithdrawal hash、dispute game、assertion、Outbox receiptまで追う手順はL2出金のprove・finalize・claim確認手順で分けて解説しています。

ArbitrumはretryableとOutbox withdrawalを分ける

Arbitrumのparent-to-child messageはretryable ticketとして追跡します。source L1 transaction、ticket作成、automatic redemptionまたはretryable state、L2 execution receiptを分けます。source L1 receiptの成功だけで、ticketがL2でredeem済みとは言えません。

child-to-parent withdrawalでは、ArbSysのL2ToL1Tx eventに固有のpositionが記録されます。その後、batch / assertion、confirmationを経てclaimableになり、OutboxでexecuteされるとOutBoxTransactionExecutedのtransaction indexへ同じpositionが現れます。

公式monitoring資料の状態は、概ね次の境界を持ちます。

状態	意味	読者が確認する証拠
`UNCONFIRMED`	assertionのconfirmation条件を満たしていない	L2 event、position、対象assertion
`CONFIRMED`	protocol上はexecution可能	official route、Outbox、未実行であること
`EXECUTED`	Outbox transactionが実行済み	L1 receiptと`OutBoxTransactionExecuted`

CONFIRMEDはEXECUTEDと同じではありません。manual claimが必要か、自動実行されるかは利用したrouteに依存します。この記事はclaim操作を実行せず、公式statusが実行可能と示す地点までをread-onlyで確認します。

OP StackとArbitrumの語を置き換えない

direction	OP Stackで見る主な段階	Arbitrumで見る主な段階
parent → child	`TransactionDeposited` → `sourceHash` → L2 deposited tx	L1 message → retryable ticket → L2 redeem / execution
child → parent	initiate → prove → challenge条件 → finalize	`L2ToL1Tx.position` → assertion confirm → Outbox execute

どちらにもpendingやclaimというUI語はありますが、内部の証拠は同一ではありません。さらに他のL1 / L2、sidechain、light-client bridge、MPC bridgeでは別のstate machineを使います。

公開testnetでsource・message・destinationを照合する

2026-08-31に、実資産や個人walletを使わず、公開RPCから2つの完了済みtestnet例を固定しました。検証用JSONにはchain ID、tx hash、block hash、event identifier、timestampを収録しています。

OP Sepolia depositはsourceHashで一致する

層	固定した証拠
source	Ethereum Sepolia block `11,600,446`、tx `0x5e1d…5f1b`、receipt success
source event	OP Sepolia Portal `0x16fc…8bc`の`TransactionDeposited`、log index `122`
message	`sourceHash = 0x9b028f28…932f4f6b`
destination	OP Sepolia block `48,155,271`、type `0x7e` tx `0x2700…454`、同じsourceHash、receipt success
observed time	`2026-08-30 18:03:24 UTC` → `18:04:42 UTC`、78秒

78秒はこのtestnet transaction pairの観測差であり、平均、SLA、次回の所要時間、mainnetの着金保証ではありません。重要なのは時間ではなく、L1 eventから再計算したsourceHashとL2 transactionのsourceHashが一致したことです。

Arbitrum Sepolia withdrawalはpositionで一致する

層	固定した証拠
source	Arbitrum Sepolia block `303,468,608`、tx `0x559f…ab13`、receipt success
message	`L2ToL1Tx.position = 117,694`、event hash `0xcdd0…0f8b`
destination	Ethereum Sepolia block `11,598,850`、Outbox tx `0x54cc…71e8`、receipt success
execution event	`OutBoxTransactionExecuted.transactionIndex = 117,694`
observed time	`2026-08-30 03:44:12 UTC` → `12:34:48 UTC`、8時間50分36秒

この時間もArbitrum mainnetのchallenge periodや将来のtestnet cadenceを示しません。OPの例はparent-to-child deposit、Arbitrumの例はchild-to-parent withdrawalであり、速度比較にも使えません。2例は「source txとdestination txをprotocol固有のidentifierで結ぶ」方法だけを示します。

保存済み値と計算をofflineで検証するには次を実行します。

node scripts/build-bridge-lifecycle-fixture.mjs --check

現在の公開RPCへread-onlyで再照合する場合だけ--liveを付けます。実行するRPC methodはeth_chainId、eth_getTransactionReceipt、eth_getTransactionByHashです。transaction送信、wallet、API key、秘密情報は不要です。

node scripts/build-bridge-lifecycle-fixture.mjs --live

pending・failed・UI lag・manual claimを分ける

source receipt、message ID、公式protocol status、destination receiptからwaiting、failed、UI lag、manual claim候補を切り分ける判断図

観測	分類	次に確認するread-only evidence
source receiptなし	source pending / dropped / replaced / RPC lag	source chain、nonce、replacement hash、複数RPC
source `status = 0`	source failed	revert、input、gas、正しいbridge contract。正常なmessage IDを待たない
source success、対象eventなし	route / call mismatch	called contract、event topics、deposit / withdrawal方向
message IDあり、destination txなし	protocol waiting / relayer waiting	公式status、proof / assertion / retryable / relayer state
official statusがexecutable	manual execution候補	利用routeがclaim必須か、公式URL・chain・ID・未実行state
destination receipt `status = 0`	destination failed	destination revert、message再実行規則、公式support
destination receipt `status = 1`、UIはpending	UI / indexer lag	block explorer、finality、bridge indexer確認時刻
destination success、walletにtokenなし	token mapping / display	destination chain、recipient、token contract、balance、wallet import設定

waitingは「あと何分」だけで判定しない

待ち時間はnetwork finality、batch / assertion、challenge、relayer、destination congestion、indexerで変わります。公式statusが同じmessageを追跡できているか、どのstage名で止まっているか、最終更新blockはどこかを保存します。

bridge UIとchain stateが違う場合は、確認時刻とUI versionを添えてください。取引所の入金表示も別systemなので、chain receiptとservice内statusを分ける考え方は暗号資産の入金が反映されないときの確認順が使えます。

failedはsourceとdestinationを混ぜない

source failedなら、正常なmessage eventはそのtransactionから成立していません。destination failedなら、messageは到達したがdestination callがrevertした可能性があります。どちらも「もう一度同額を送る」でまとめず、失敗したchain、transaction、revert、再実行規則を分けます。

event dataの読み方が必要ならABI・calldata・logsの基礎を参照してください。verified contractという表示だけでbridge、gateway、proxyの安全性を保証しない点にも注意します。

manual claimは公式stateが示したときだけ候補にする

claim / finalize / redeemボタンが見えることと、対象messageが実行可能で未実行であることは別です。操作前に少なくとも次を同じrouteへ対応させます。

自分でbookmarkまたは公式project pageから開いたURL
source / destination chain IDとdirection
tx hashとprotocol固有message ID
official statusがexecutable / confirmed / readyであること
destination executionがまだ存在しないこと
contract address、recipient、token、表示されるcall内容

この記事の範囲はここまでです。claimを実行する場合は、利用したbridgeの最新公式手順とrisk noticeを別途確認します。DMのsupportが送るURL、seed phrase入力、remote-control、追加送金を「unlock fee」とする案内は使いません。

native tokenとbridged tokenをcontractで分ける

destination transactionが成功しても、walletに想定symbolが出ないことがあります。まず「native token」と「bridged representation」を分けます。

native token: そのchain側で基準となるasset / contract
bridged token: bridgeが対応するremote assetを表すtoken contract
wrapped native token: native assetをERC-20として扱う別contract
third-party representation: canonical bridgeとは別のissuer / routeが作るtoken

OP Standard Bridgeの資料が示すように、同じnative tokenに複数の独立したbridged representationが対応し得ます。symbol、name、iconは識別子ではありません。source chain ID、source token contract、bridge route、destination chain ID、destination token contractのpairで確認します。

destination receiptが成功した後は、recipient addressのtoken balance、transfer / mint event、local / remote token pairを確認します。walletへcustom tokenを追加する前にも、公式registryやbridge contractが示すdestination addressと一致するか確認してください。destination上のbalanceOfはあるのにwalletへ出ない場合は、chain・contract・decimals・indexerを分ける確認手順へ進みます。

wrong network、同じaddress形式、管理主体の違いは別networkへ送ったときの確認順で切り分けられます。回収や返金が可能だと先に断定せず、誰がdestination keyやcontractを管理するかを固定します。

L2 data availabilityやfinalityと利用者表示を混ぜない

rollupのbatch dataがL1へ投稿されたこと、protocolがmessageを認識したこと、withdrawalがprove / confirmされたこと、destination transactionが実行されたこと、walletやbridge indexerが表示を更新したことは別のeventです。

blobやL2 batch投稿の仕組みはFusaka・PeerDASとL2 feeの記事で扱っています。data availabilityの改善やL1 batch receiptを、個別bridge messageのdestination実行証拠へ置き換えないでください。

公式supportへ渡すevidence package

自力でstageを特定できない場合は、自分で開いた公式siteのsupport入口から、次をまとめて渡します。

checked at:
bridge URL / provider:
canonical or third-party:
source chain ID -> destination chain ID:
deposit or withdrawal:
source tx hash / receipt status / event:
message identifier and where it was obtained:
official protocol status / last updated block:
destination tx hash / receipt status, if any:
source token contract -> expected destination token contract:
recipient address:
UI status and screenshot time:

tx hashとpublic addressはchain上で公開されていますが、support ticket自体の公開範囲は別です。email、電話番号、残高全体、本人確認書類、API key、session cookie、raw wallet backupは必要性と送信先を確認します。seed phrase、private key、keystore passwordは渡しません。

最終チェックリスト

ブリッジ未着金の切り分けは、source transaction、message identifier、protocol stage、destination transactionまたはclaim、token mappingを同じrouteへ対応させ、最初に証拠が途切れた地点を特定することです。

この記事にはbridge、swap、wallet、recovery serviceのaffiliate CTAを置いていません。特定サービスへの送金を促すのではなく、追加操作の前にread-only evidenceを揃える順序を示しています。