Четыре состояния standard withdrawal в OP Mainnet
- Initiate
L2-транзакция создаёт withdrawal message и даёт первый hash.
- Prove
После появления пригодного output/dispute game отдельная L1-транзакция доказывает inclusion.
- Challenge и maturity
Proof ждёт установленные protocol delays; статус надо читать, а не вычислять только по календарю.
- Finalize
Ещё одна L1-транзакция исполняет withdrawal, если все проверки portal пройдены.
Один вывод оставляет несколько независимых следов
Initiation подтверждается в OP Mainnet как обычная L2-транзакция. Базовый материал про Layer 2 и rollup объясняет связь двух сетей, но для вывода нужен более узкий state machine. Состояние L2 должно стать доступным для proof в Ethereum; proof и finalization оплачиваются и подтверждаются уже в L1. Поэтому explorer одной сети не обязан показывать весь путь, а один transaction hash не заменяет withdrawal hash и два L1 receipts.
Статус определяет следующее действие, а не наоборот
| Наблюдение | Что проверить | Безопасное следующее действие |
|---|---|---|
| Initiation не найдена | chain, sender, nonce, receipt status | Не создавать новый вывод, пока неизвестен исход подписи |
| Initiation successful, prove недоступен | withdrawal event и готовность output | Ждать state-aware статуса официального bridge |
| Proof successful, finalize недоступен | proof timestamp, game status, portal state | Дождаться finalizable или инструкции re-prove |
| Finalize reverted | revert data, уже finalized, pause и gas | Исправлять конкретную precondition, не повторять вслепую |
| Finalize successful, баланс не виден | recipient, L1 token address и wallet display | Добавить корректный token либо обратиться к получателю |
- Наблюдение
- Initiation не найдена
- Что проверить
- chain, sender, nonce, receipt status
- Безопасное следующее действие
- Не создавать новый вывод, пока неизвестен исход подписи
- Наблюдение
- Initiation successful, prove недоступен
- Что проверить
- withdrawal event и готовность output
- Безопасное следующее действие
- Ждать state-aware статуса официального bridge
- Наблюдение
- Proof successful, finalize недоступен
- Что проверить
- proof timestamp, game status, portal state
- Безопасное следующее действие
- Дождаться finalizable или инструкции re-prove
- Наблюдение
- Finalize reverted
- Что проверить
- revert data, уже finalized, pause и gas
- Безопасное следующее действие
- Исправлять конкретную precondition, не повторять вслепую
- Наблюдение
- Finalize successful, баланс не виден
- Что проверить
- recipient, L1 token address и wallet display
- Безопасное следующее действие
- Добавить корректный token либо обратиться к получателю
Глубина подтверждений и finality блока — связанные, но не одинаковые с готовностью withdrawal понятия. Блок L2 может быть finalized относительно Ethereum, пока конкретный withdrawal ещё ждёт proof maturity или L1 finalization. Интерфейс должен называть обе стадии отдельно, иначе фраза «транзакция завершена» вводит в заблуждение.
Недействительный proof не обязан навсегда блокировать вывод
В fault-proof path OP Stack withdrawal связывается с dispute game. Если game признана недействительной или исключена из допустимого пути, proven withdrawal не финализируется против неё. Спецификация предусматривает re-prove против другого корректного game; при повторном proof временная отсечка обновляется. Это recovery path протокола, но не обещание срока конкретного случая.
Пакет данных для восстановления статуса
- L2 chain ID, initiation hash, receipt и block number;
- withdrawal hash, sender, target, value и calldata;
- L1 proof hash, proof submitter и связанный dispute game;
- текущий withdrawal status из официальной библиотеки или bridge;
- L1 finalization hash либо полный revert, если попытка была;
- точный bridge UI и URL: standard и fast bridge не взаимозаменяемы.
Адрес, который отправляет prove или finalize, не следует автоматически считать получателем. Получатель и вызываемые данные зафиксированы в withdrawal message, а proof submitter — отдельное поле протокольной записи. При ручном восстановлении сначала декодируют исходное сообщение и только потом сравнивают caller L1-транзакций, чтобы не принять relayer за владельца средств.
Standard и fast bridge имеют разные источники доверия
Fast bridge может выдать ликвидность раньше, но это отдельный продукт с собственными contracts, fees, routes и рисками. Его receipt нельзя считать finalization Standard Bridge. Перед новой операцией сначала определите, какой кроссчейн-мост создал исходный message, и проверяйте статус именно в его документации.
Если L1 proof или finalization остаётся pending, разбирайте её как pending Ethereum-транзакцию: проверяйте nonce, fee и replacement. Но увеличение fee не ускоряет protocol challenge period. Рабочая граница проста: fee помогает включению конкретной L1-транзакции, а protocol delay определяется контрактами и состоянием withdrawal.
Источники
Мы используем прямые ссылки и фиксируем дату проверки. Полный текст чужих материалов не перепечатывается.
- Optimism Docs — Using the Standard Bridge Optimism · Проверено 19 августа 2026 г. в 20:11 GMT+5
- Optimism Docs — L2 to L1 messaging Optimism · Проверено 19 августа 2026 г. в 20:11 GMT+5
- Optimism Docs — Withdraw ETH tutorial Optimism · Проверено 19 августа 2026 г. в 20:11 GMT+5
- Optimism Docs — Transaction finality Optimism · Проверено 19 августа 2026 г. в 20:11 GMT+5
- OP Stack Spec — Optimism Portal Optimism · Проверено 19 августа 2026 г. в 20:11 GMT+5
- OP Stack Spec — Bridge Integration Optimism · Проверено 19 августа 2026 г. в 20:11 GMT+5