先分清：批量提交≠结算完成
检索“区块链rollup”时，提现页常把“批次已上链”显示成接近完成。ethereum.org 的 Optimistic Rollups 说明写明：运营商把多笔链下交易打包成大批次再提交到以太坊，以分摊固定成本；提交之后仍存在被称为 challenge period 的时间窗口，期间任何人都可以用欺诈证明挑战批次结果。
因此“批次交易已出现在 L1”只证明状态承诺被发布，不自动等于用户资产已在主网可取。把提交成功写成提现完成，会跳过争议与最终结算阶段。
提现进度要对照争议与数据可用性
同一文档指出：若欺诈证明成立，协议会重执行交易并更新状态根；结算依赖以太坊主网提供客观最终性来仲裁争议。另在数据可用性与抗审查部分强调，若运营商扣留状态数据，用户可能无法构造证明以撤回已存入 rollup 合约的资金。
核验提现进度时，应记录：批次是否已提交、当前是否仍在挑战窗、桥/提现合约实现与配置（不同乐观 Rollup 的窗口与证明路径可不相同），以及是否具备验证所需数据。不假设所有桥共享同一等待时长。
进度 UI 不等于验证模型
对照 Bitcoin Developer Guide 的 Operating Modes：全节点与 SPV 对“已确认”的验证深度不同，服务端信任模式甚至不被推荐。Rollup 提现页若只展示运营方进度文案，更接近“信任展示层”，需要回到 L1 批次、挑战窗与桥合约事件，而不是把百分比动画当成最终性。
本篇只处理乐观 Rollup 提现阶段划分，不执行跨链操作，不保证统一等待时间，也不评估具体桥的安全性排名。
核对边界
可记录：批次提交、挑战/争议窗、欺诈证明结果、桥实现差异、数据是否可验证。不可记录：未验证的“秒到账”承诺、统一提现时长保证、代操作跨链或投资建议。