L2出金の待ち時間は何日？届くまでの段階表示と高速出金の選び方

L2の上で動くあるサービスのサポート窓口に、問い合わせが届きました。「出金したのに、Ethereum（L1）の口座に届かない」。画面には確かに「成功」と出ていました。けれども、それはL2で出金を始めたという意味にすぎません。L1で使えるようになるまでには、方式ごとの待ち時間があります。途中で、利用者自身の操作が必要になることもあります。

この出金画面を作り直すことになったプロダクト責任者は、まず表示を変えることにしました。「7日」と待ち時間だけを出すのではなく、次の3つを出します。

• いまどの段階か
• 次に何が起きるか、その条件は何か
• 利用者が何をすべきか（どのチェーンで受け取るか）

すぐ受け取れる高速出金を選ばせる場合は、待ち時間だけでなく、費用、立て替える資金の有無、失敗したときの扱い、追加で信頼する相手も並べて見せます。

待ち時間が生じる理由は方式によって違います。Optimistic Rollupの標準の出金には、異議申立の期間があります。ZK Rollupでも、証明の作成、L1への反映、プロトコルごとの遅延が残ります。以下では、このプロダクト責任者が画面と運用を作り直す順に、待ち時間を「状態」と運用の目標値（SLO）に置き換える方法を見ていきます。L2の基礎はLayer 2の解説を参照してください。

「成功」の後、出金はどんな段階を通って届くか

出金ボタンを押した直後に出る「成功」は、L2で取引が通ったという意味です。L1で資金を使える状態とは違います。

OP Stackの標準の出金を例にとると、流れは次のとおりです。

1. L2で出金を始める
2. 出力（L2の状態をL1に記録した要約）に対する証明を出す
3. 異議申立期間を待つ
4. L1で最終実行する

公式仕様によれば、証明の後に原則7日の異議申立期間があります。その後、中継実行者が最終実行できます（OP Stack Withdrawals specification）。

ただし、途中の証明が後から取り消されると、証明をやり直すことになります。そのため、7日ちょうどで終わるとは限りません。仕組みの詳しい条件は、後半の「開発チーム向けの詳細」にまとめました。待つ長さは、対象チェーンの設定値で確かめます。

そこで画面には、段階ごとに次のことを出します。

段階は、画面の文言として持つのではなく、DBに保存します。保存するのは、どの出金かを特定できる情報です。画面を閉じても元に戻せること、同じ最終実行を二重に送らないことが最低の条件です。保存する項目は後半に載せました。

待ち時間は、方式の名前ではなく区間ごとに見積もる

OP Mainnetの公式ドキュメントは、通常のL2取引の確定と、L2→L1の出金を分けています。7日待つのは、Ethereumへ資金を戻す出金の場合だと説明しています（OP Mainnet Transaction finality）。

一方ZKsyncでは、L2トークンの焼却、L2→L1のメッセージ、バッチの実行、L1での最終実行が必要です（ZKsync Bridging assets）。

2026年9月24日時点のZKsync公式ドキュメントは、安全のため最小3時間の実行遅延を設けていると説明しています。証明の作成やバッチの集約で、さらに1〜2時間以上かかりうるとしています（ZKsync Withdrawal delay）。

このように、どちらの方式も一言ではくくれません。「Optimisticは7日、ZKはすぐ」という比べ方は、採用を判断するには粗すぎます。

ですから、受け取れる時刻は区間ごとの所要時間を足して見積もります。L2への収録、L1への反映、証明や異議申立の条件、プロトコルの遅延、最終実行の送信、混雑の余裕です。計算式は後半に載せました。

実際の出金では、出力の出し直し、証明の遅れ、L1の混雑、最終実行をまだしていない、といったことが起きます。そのため、固定のカウントダウンだけを出すと、ゼロになっても完了しないことがあります。

画面では、「通常の目安」と「いちばん早く実行できる時刻」を分けます。後者は、条件を確かめ直すたびに更新します。期限を過ぎたら「遅延中」に変えるだけでなく、どの区間で止まっているかと、運営側の対応状況も示します。

高速出金は、待ち時間が消えるのではなく誰かが立て替えている

高速ブリッジでは、中継実行者や、資金を用意しておく流動性提供者が、受け取る側のチェーンで利用者に先に支払います。その後、標準の出金などを通して精算を受けます。

ethereum.orgも、Optimistic Rollupの待ち時間を避ける方法として、この仕組みを説明しています。流動性提供者が保留中の出金を引き受け、手数料と引き換えにL1で支払う、というものです（ethereum.org Optimistic rollups）。

2つの出金方法は、次のように違います。

見積もりの画面には、次の5つを出します。

• 受取額と、全部の手数料
• 見積もりの有効期限と、受け取れる時間の目安
• 返金先のチェーンとアドレス

高速出金も失敗することがあります。Acrossの公式ドキュメント（2026年9月24日確認）では、入金期限（fillDeadline）までに中継実行者が入金せず、一部の入金もなければ、返金の対象になります。返金はすぐではなく、数時間かかるとされています。

状態は、処理中（pending）から入金済み（filled）へ進むか、期限切れ（expired）から返金済み（refunded）へ進みます（Across Refunds）。高速出金でも「失敗＝資金がなくなった」とまとめて表示してはいけません。返金されるかどうかと、必要な操作を状態として持ちます。

画面、通知、サポートで同じ状態を使う

出金の履歴、メール・プッシュ通知、サポートの管理画面が別々の言葉を使っているとします。すると、「L2では成功したが、L1ではまだ受け取っていない」状態を、障害や資金の消失として扱ってしまいます。冒頭の問い合わせも、こうして生まれます。すべての窓口で、1つの出金IDと同じ状態を見るようにします。

• 出金の前：出金元と受取先のチェーン、トークンのコントラクト、受取額、経路、取り消せなくなる時点、必要なL1のガス代を確認してもらう。
• 処理中：いまの段階、済んだ段階、次の条件、更新時刻、ブロックエクスプローラーへのリンクを出す。
• 操作待ち：証明の提出や最終実行を利用者がするなら、ウォレットのチェーン切り替えと必要な残高を先に確かめる。中継実行者がするなら、自動で実行する予定と、ほかの手段を示す。
• 期限超過：最後に成功した出来事、RPCだけでなく別のインデクサーでも確かめた結果、再試行のID、サポートに伝える識別子を出す。
• 完了：L1の取引の成功だけでなく、受取アドレス、トークン、金額を突き合わせる。

「完了まで7日」とだけ知らせると、7日後には何の知らせも届きません。利用者は最終実行を忘れてしまいます。ですから通知は、受け取れる段階に移ったときに送ります。操作の後は、L1の取引の結果を追います。

通知のリンク先は、ウォレットをつなぐ前でも状態が見られるようにします。サポート担当が秘密鍵やシードフレーズを求めることはない、という案内もはっきり書きます。

シーケンサーの停止中に出金をどう受け付け、どこまで機能を絞るかはシーケンサー停止時のサービス継続設計、データ可用性の障害で状態を作り直して退出する条件はロールアップのデータ可用性障害で扱っています。

採用の前に、通常の場合と期限超過を同じテスト計画に入れる

• 対象チェーン・トークンごとに、標準経路の全段階と必要な操作を実際に測った
• 最短・通常・期限超過の表示が、固定のカウントダウンに頼っていない
• 高速経路の受取額、全手数料、期限、返金先、追加で信頼する相手を、選ぶ前に表示した
• 証明の提出・最終実行の二重送信、RPCのタイムアウト、再証明、未入金・返金を、わざと起こして試した
• 画面、通知、サポートが同じ出金IDと状態を見ている
• チェーン・ブリッジのアップグレードのとき、進行中の出金を見直す運用手順と責任者がいる

高速経路の流動性が薄い、対応トークンが限られる、少額が中心で待ち時間による事業の損失が小さい。こうした場合は、標準経路だけにした方が安全です。

反対に、すぐ使えることが欠かせないなら、経路をむやみに増やすのではなく、段階的に導入します。資産・金額の上限、見積もりの失効、返金までの目標時間、止める条件を決めてからです。

L1で動くアプリをL2へ移す計画の全体はL1からL2へのアプリ移行で整理しています。

開発チーム向けの詳細

ここからは、さきほどのサービスで出金の仕組みを実装する開発チームの話です。

OP Stackで7日を超えることがある理由

不正証明（fault proof）を使う現在のOP Stackでは、もう1つの条件があります。証明の元になった出力を争う異議申立ゲーム（dispute game）が、有効な結果として確定していることです。

参照したゲームが、後からブラックリスト登録などで無効になることがあります。その場合は別のゲームに対して証明し直す必要があり、7日ちょうどでは終わりません（OP Stack Specification: OptimismPortal）。

内部の状態と保存する項目

前半の段階は、内部では次の状態として持ちます。

通知はFINALIZABLEへの遷移時に送ります。各状態には、チェーンID、トランザクションハッシュ、メッセージハッシュ、ブロック、証明・出力の識別子、受取トークン、受取アドレスを持たせ、DBに永続化します。

受取時刻の見積もり式

estimated_receive_at =
  l2_inclusion
  + l1_commit_or_batch
  + proof_or_challenge_requirement
  + protocol_delay
  + l1_finalization_submission
  + congestion_margin

右辺は、すべて秒など同じ単位の所要時間です。L2/L1のブロック・バッチ・証明の状態をインデクサーで観測し、プロトコルの設定から待機の条件を取得して、計算した時刻に加えます。

障害時は「再試行」ボタンより先に冪等性を設計する

ノンスは、アカウントごとに取引へ振る通し番号です。

冪等性キー（同じ要求を何度送っても1回分として扱うためのキー）は、少なくとも次のものに結びつけます。出金元チェーン、出金トランザクションまたはメッセージハッシュ、受取チェーン、受取アドレス、トークン、金額です。APIのタイムアウトの後に、同じ出金を新しく作ってはいけません。既存のチェーンのイベントを探して復旧します。

監視の目標値（SLO）は、件数だけでなく次のものを持ちます。各状態の滞留時間のp95/p99（95%・99%が収まる時間）、期限超過の数、最終実行の失敗率、返金にかかる時間、インデクサーの遅れです。

XTELAができること

XTELAは、L2・ブリッジ連携の要件整理から、出金の状態機械、インデクサー、ウォレットの画面設計、監視と復旧の手順、PoCと開発までを行います。貴社の出金画面で「今どこにあり、次に何が起きるか」を正しく見せる仕組みを一緒に作ります。出金の設計について相談する

主要参考資料

• OP Stack Specification: Withdrawals（2026年9月24日確認）
• OP Stack Specification: OptimismPortal（fault proof）（2026年9月24日確認）
• Optimism Docs: Transaction finality
• ethereum.org: Optimistic rollups
• ZKsync Docs: Bridging assets
• ZKsync Docs: Withdrawal delay（2026年9月24日確認）
• Across Docs: Refunds（2026年9月24日確認）

資料の確認日と注意

OP Stack・ZKsync・Acrossの出金と返金の仕様は2026年9月24日に確認し直しました（OP Mainnetのfinality、ethereum.org、ZKsyncのBridging assetsは2026年8月13日確認）。待機時間、ブリッジコントラクト、管理権限、対応資産は更新されるため、本番採用前に対象ネットワークの公式仕様を確かめてください。