L2出金はどこで止まった？OP Stack・Arbitrumのprove・finalize・claim確認手順

L2の出金transactionがsuccessなのに、L1へまだ反映されない。このとき、L2 receiptは出金の開始を示すだけで、proof、challengeまたはfinality、L1でのfinalize / executeまで完了した証拠ではありません。

OP StackとArbitrumでは、同じpendingやclaimという表示でも内部のstate machineが異なります。まず利用したcanonical routeを固定し、route、withdrawal identifier、proofまたはassertion、challenge / finality、L1 execution receiptを同じ一件へ対応させることが重要です。

この記事では公開testnetの完了済みtransactionをread-onlyで照合します。wallet接続、署名、prove、finalize、execute、claim、transaction送信、実資産移動、個人balanceの取得は行いません。

先に止める操作と保存する値

状態が分かるまでは、同じ出金の再送、別bridgeへの移し替え、検索広告やDMから開くclaim、手当たり次第のprove / finalizeを止めます。seed phraseやprivate keyをsupportへ渡す必要もありません。

最初に次の値を一つの調査メモへ保存します。

項目	保存する値	なぜ必要か
route	公式URL、canonical / third-party、source L2、destination L1、chain ID	別routeのstatusを見ないため
asset	native / ERC-20、amount、L2 token、想定L1 token	symbolだけで別representationを混同しないため
recipient	L1 recipient address	自分のwallet表示ではなく実行先を固定するため
initiation	L2 tx hash、block、receipt status、called contract、event	出金開始が成立したか確認するため
identifier	OP withdrawal hash、Arbitrum positionなど	同じ一件をL2とL1で結ぶため
proof / assertion	proof tx、output / dispute game、assertion status	待機前の条件を分けるため
challenge / finality	公式status、contract値、確認block・時刻	固定日数の転載で判断しないため
L1 execution	finalize / execute tx、receipt、event、未実行state	claimableとexecutedを分けるため
version	Portal、Bridge、Outboxなどのaddress・implementation・version	upgrade前後の手順を混ぜないため

一般的なbridge未着金のsource・message・destinationの確認順はブリッジ送金がpending・failed・未着金のときの確認順で先に整理できます。ここではcanonical optimistic rollupのL2→L1だけを深掘りします。

L2→L1出金は一つのtransactionではない

L1→L2 depositとL2→L1 withdrawalは逆再生ではありません。optimistic rollupのwithdrawalでは、L2上の開始、L1で参照できるoutputやassertion、異議申立て・finality条件、L1 executionが別の境界になります。

境界	OP Stack	Arbitrum	完了を示す主な証拠
initiation	L2 withdrawalとMessagePassed	ArbSysのL2ToL1Tx	L2 receipt、対象event
identifier	withdrawal hash	position / child-to-parent message	eventから得たprotocol固有値
proof / assertion	outputを参照してPortalへprove	batch化されassertionへ含まれる	proof event、公式message status
challenge / finality	fault proof gameとPortal条件	assertion confirmation条件	game / assertionの現在state
executable	finalize条件を満たす	CONFIRMED	公式statusと未実行state
L1 execution	finalizeWithdrawalTransaction	Outbox executeTransaction	L1 receipt、実行event、spent state

initiated、proven、confirmed、claimable、finalized、executedは同じ意味ではありません。UIのボタン名ではなく、対象routeのcontractとeventを照合します。

OP Stackはinitiate・prove・wait・finalizeを分ける

1. L2でinitiation receiptとwithdrawal hashを得る

OP Stackのwithdrawalは、L2側のbridgeやmessengerを通り、L2ToL1MessagePasserのMessagePassedを発生させます。まずL2 receiptのstatus = 1、called contract、event contract、sender、target、value、gas limit、dataを確認します。

withdrawal hashは、対象message tupleをABI encodeして計算する識別子です。

withdrawalHash = keccak256(
  abi.encode(nonce, sender, target, value, gasLimit, data)
)

L2 tx hashとwithdrawal hashは別物です。proofとfinalizeのL1 eventへ同じwithdrawal hashが現れるかを確認します。

2. outputとproof transactionを確認する

initiation直後に、どのoutputでもproveできるわけではありません。対象L2 blockを含むoutputと、routeが採用するproof systemの条件が必要です。

fault proof構成のPortalでは、prove時に参照したdispute game、proof submitter、proof timestampがwithdrawalへ対応します。WithdrawalProvenがあるだけでL1 execution済みとは言えません。対象gameのtype、status、L2 block、created / resolved timestampも保存します。

3. challenge・maturity・finalityを現在のcontractで確認する

「OP出金は必ず7日」のような固定値だけで次の操作を決めないでください。network、Portal version、respected game type、proof maturity、game finalityの構成は変わり得ます。

確認時点の公式registryとPortalで、少なくとも次を対応させます。

• L1 chain IDとPortal address
• Portal proxyのversionとimplementation
• proofMaturityDelaySeconds
• disputeGameFinalityDelaySeconds
• respectedGameType
• prove時に使ったgameのstatusとresolution
• withdrawalがすでにfinalizedか

過去の所要時間は、その一件の観測値です。現在の別withdrawalに残り時間を保証する値ではありません。

4. finalizeとL1 receiptを確認する

finalize可能な条件と、誰かがfinalize transactionを送ったことは別です。L1 receiptでPortalのWithdrawalFinalizedを探し、同じwithdrawal hashとsuccessを確認します。さらにPortalのfinalizedWithdrawals(withdrawalHash)がtrueかをread-onlyで照合できます。

WithdrawalFinalizedが成功しても、ERC-20ならL1 token、recipient、bridge eventを追加で確認します。この記事の公開例はnative testnet ETHであり、個人balanceを取得せず、contract executionまでを証拠境界にします。

OP Sepoliaの完了例を一件追跡する

2026-08-31に、公開testnetの完了済みwithdrawalを固定しました。以下は速度の見積もりではなく、各stageを同じwithdrawal hashで結ぶ例です。

stage	固定した公開証拠
route	OP Sepolia 11155420 → Ethereum Sepolia 11155111、canonical Standard Bridge
asset / recipient	native testnet ETH 1 ETH、recipient 0x6e94…bce2
initiation	L2 tx 0x52a8…5854、block 47,798,324、receipt success
identifier	withdrawalHash = 0x02e37383…e2a995、MessagePassed log index 5
proof	L1 tx 0xeec0…c93c、WithdrawalProven log index 52
game	index 84,080、proxy 0x44d8…ed6f、type 8、status DEFENDER_WINS
finalization	L1 tx 0x87f4…c00a、WithdrawalFinalized success
route version	L2 Standard Bridge 1.13.2、Portal 5.6.1、Portal implementation 0xe89f…d3c2（2026-08-31確認）

eventの452バイトのdataから再計算したwithdrawal hashは、proveとfinalizeのevent topicにある0x02e37383…e2a995と一致しました。PortalのfinalizedWithdrawalsもtrueでした。

観測時刻はinitiationが2026-08-22 11:46:28 UTC、proofが2026-08-23 09:05:00 UTC、finalizationが2026-08-30 10:06:12 UTCです。21時間18分32秒、7日1時間1分12秒、合計7日22時間19分44秒という差は、このtestnet例の履歴にすぎず、mainnet、別version、次の出金の待ち時間ではありません。

Arbitrumはinitiate・assertion・confirm・executeを分ける

1. L2ToL1Txのpositionを保存する

Arbitrumのchild-to-parent withdrawalでは、ArbSysのL2ToL1Tx eventを探します。caller、destination、valueに加え、固有のpositionを保存します。このpositionがL1 Outbox executionと同じ一件を結びます。

OPのwithdrawal hash計算をArbitrumへ流用したり、ArbitrumのpositionをOP Portalへ照会したりはできません。

2. assertionとchallengeの状態を確認する

公式monitoring資料では、開始後のmessageはbatch化とassertionを経て、概ねUNCONFIRMED、CONFIRMED、EXECUTEDとして区別されます。

status	読めること	まだ完了していないこと
UNCONFIRMED	initiationを追跡できるが、assertionのconfirmation条件を満たしていない	L1でのexecute
CONFIRMED	protocol上、Outbox executionの候補になった	execute transactionとL1 receipt
EXECUTED	Outbox executionが記録された	UIやwallet表示は別途確認が必要な場合がある

confirmPeriodBlocksはparent chainのblock数であり、固定した日数の保証ではありません。対象networkのRollup contract、現在値、message statusを確認します。

3. Outboxのexecuteとspent stateを確認する

CONFIRMEDと表示されても自動でexecute済みとは限りません。L1のOutbox transaction receiptでOutBoxTransactionExecutedを探し、eventのtransaction indexがL2のpositionと一致するかを確認します。

OutboxのisSpent(position)がtrueなら、そのpositionは実行済みです。未実行なのにclaimボタンが見える場合も、公式route、chain、destination、call内容を確認するまでは署名しません。

Arbitrum Sepoliaの完了例を一件追跡する

stage	固定した公開証拠
route	Arbitrum Sepolia 421614 → Ethereum Sepolia 11155111、canonical Outbox route
asset / recipient	native testnet ETH 0.5 ETH、destination 0xce23…3276
initiation	L2 tx 0x559f…ab13、block 303,468,608、receipt success
identifier	L2ToL1Tx.position = 117,694、event hash 0xcdd0…0f8b
network state	Rollup 0xd808…81c8、確認時のconfirmPeriodBlocks = 20
execution	L1 tx 0x54cc…71e8、OutBoxTransactionExecuted log index 23
spent / version	isSpent(117694) = true、Outbox 0x65f0…b78f、implementation 0xfed2…224f（2026-08-31確認）

L2 eventとL1 eventのpositionはどちらも117,694で一致しました。開始は2026-08-30 03:44:12 UTC、executeは12:34:48 UTCで、観測差は8時間50分36秒です。この値はArbitrum mainnetのchallenge期間や将来のtestnet cadenceを示しません。

公開検証データを保存値・公開RPCで再確認する

検証用JSONには、2例のchain ID、tx / block hash、identifier、contract、version、timestamp、観測差を収録しています。公開addressはeventを結ぶためだけに記録し、人物特定、balance、wallet stateには使いません。

保存済みデータの整合だけならnetwork accessなしで確認できます。

node scripts/build-l2-withdrawal-fixture.mjs

現在の公開RPCへread-onlyで照合する場合だけ--liveを付けます。

node scripts/build-l2-withdrawal-fixture.mjs --live

公開RPCでの再確認に使うのはeth_chainId、eth_getTransactionReceipt、eth_getBlockByHash、eth_call、eth_getStorageAtだけです。wallet、signer、API secret、transaction送信はありません。public RPCがhistorical dataを返さない場合は、保存データの不一致と決めつけず、同じchainのarchive対応RPCやofficial explorerでblock hashを再確認します。

「何日」ではなく現在のstageを確認する

観測	現在の分類	次のread-only確認
L2 receiptなし	initiation未確定 / dropped / RPC lag	L2 chain、nonce、replacement、別RPC
L2 receipt status = 0	initiation failed	revert、called contract。正常なproofを待たない
receipt success、対象eventなし	route / call mismatch	bridge contract、direction、event topics
identifierあり、proof / assertion未成立	protocol waiting	対象output / assertion、最終更新block
OP proof済み、Portal条件未成立	challenge / finality waiting	game status、maturity、finality、Portal version
Arbitrum UNCONFIRMED	assertion confirmation待ち	position、assertion、Rollup contract
executable / CONFIRMED、L1 receiptなし	manual execution候補	公式route、未実行state、recipient、call内容
L1 receipt status = 0	L1 execution failed	revert、再実行規則、公式support
L1 eventとidentifier一致	protocol execution済み	token / recipient / UI反映を分けて確認
chain上は実行済み、UIはpending	indexer / UI lag候補	block explorer、確認時刻、status page

RPCの値を同じblockへ固定して比較したい場合はEthereum RPC snapshotを同じblockへ固定する方法が使えます。rollupのdata availabilityやL1 feeを「出金の実行済み」と混ぜないためにはFusaka・PeerDAS後のL2 dataとblob feeの確認方法も参照してください。

route・token・recipient・contract versionを最後に照合する

L1 executionまで見つかっても、walletに期待したsymbolが出ないことがあります。そのときは、次を同じreceiptへ対応させます。

1. source L2とdestination L1のchain ID
2. canonical bridge / Portal / Outboxのaddress
3. proxy implementationとversionの確認時点
4. native assetかERC-20か
5. L2 tokenとL1 tokenのcontract pair
6. amountとrecipient
7. L1 execution eventとreceipt status
8. walletが表示しているchain・token contract・indexer時刻

contract upgradeがあると、古いblogやスクリーンショットのbutton名、待機値、functionが現在のrouteと一致しない場合があります。official registryとverified sourceを確認し、確認日とblockをメモします。verified表示だけを安全保証にせず、公式registryのaddressと一致するかを先に見ます。

third-party fast bridgeを使った場合は、このcanonical lifecycleをそのまま当てはめません。liquidity provider、relayer、order ID、settlement routeという別のstateがあり得ます。トラブル対応中に「待たずに移せる」という広告から追加送金しないでください。

supportへ渡すevidence package

公式supportへ問い合わせる場合は、秘密情報ではなく次の公開証拠を渡します。

• 利用した公式route URL、source / destination chain ID、確認時刻
• L2 initiation tx hash、block hash、receipt status、event log index
• OP withdrawal hashまたはArbitrum position
• proof tx / dispute game、またはassertion / message status
• L1 finalize / execute txがある場合はhash、receipt、event
• token contract、amount、recipient。公開投稿では必要に応じて一部mask
• Portal / Bridge / Rollup / Outbox address、version / implementation
• UI表示とchain stateが違う場合は、個人情報を除いた画面とbrowser version

seed phrase、private key、keystore、remote-control app、追加の「unlock fee」は渡しません。supportが操作を求める場合も、URL、chain、contract、decoded call、asset effectを確認し、分からなければ署名前で止めます。

まとめ

L2出金のL2 receiptは、L1受領receiptではありません。OP Stackではinitiate → withdrawal hash → prove → fault proof / finality → finalize、ArbitrumではL2ToL1Tx.position → assertion / challenge → CONFIRMED → Outbox executeを別々に確認します。

経過日数だけを答えにせず、route、token、recipient、contract version、protocol固有identifier、現在のofficial status、L1 receiptを一つのevidence packageへまとめてください。状態が分からない間は、再送、非公式claim、追加bridge、秘密情報の共有を止めるのが安全です。