存入和提现在链上各经过哪几部合约？OP Stack 桥的合约分工

存入走的不是同一条门

在 OP Stack 链之间转资产，用户面对的是”一个网页、一次点击”，链上实际走过的是一串各司其职的合约。官方文档把 L1 侧的这串合约按用途分成三组：桥接与消息、配置、争议裁决。存入方向的第一站是 OptimismPortal，它是底层存入与提出合约；它上面垫着 L1CrossDomainMessenger，负责把调用包装成一条可重试的跨链消息；再上面才是普通用户最熟的 L1StandardBridge，处理 ETH 与 ERC-20 的锁定与铸造。三层各拆各的活：合约升级换掉某一层的实现，另外两层的接口不必跟着抖。

逐层各管一段

https://assets.skjop.cn/articles/202609021034/content-1.jpg

消息层与桥层管的是”语义”——资产锁定之后，另一头必须收到一条结构一致的消息才能 mint；而资产怎么进、怎么出、按什么规则记，交给 OptimismPortal 与数据可用性机制处理。拆开还有个现实好处：消息携带的调用目标、gas 参数与重试状态由 Messenger 记账，一条消息在对端执行失败后可以按相同参数重放，而不是把整笔转账退回。L2 侧有一套地址固定的预部署合约与之镜像：L2CrossDomainMessenger 是推荐的高层消息接口，L2ToL1MessagePasser 专门登记提现消息，L2StandardBridge 和 L2ERC721Bridge 与 L1 端一一对应。NFT 走单独的 ERC-721 桥路线，不与 ERC-20 混用同一套登记。还有一类开发者自定义的跨链调用，绕过资产桥直接走消息层，收端合约必须自行验证消息确实来自对端 Messenger，这道校验漏掉就是冒领消息的事故现场。

提现是”先记后取”的两段

提现方向顺序反过来：用户在 L2 上发起取款，L2ToL1MessagePasser 先把消息哈希记进自己的清单；等排序器把对应状态提交、输出提案在 L1 上度过质疑期后，用户先在 L1 提交一笔证明交易、把消息纳入一棵默克尔证明，再提交一笔提取交易、由 OptimismPortal 验证证明并付款。中间那段等待期本质是留给欺诈证明的窗口。L2 提现为什么要等七天？三段流程里发生了什么 把这段流程的等待项逐项拆过账。两笔提款交易都可能失败，且失败点各有含义：证明交易报错多半是提议尚未可证或参数错位，提取交易报错则常是”证明了但还没到取的时候”或已经取过——先分清卡在哪一步再重试，能省下不少重复 gas。

升级时钱在哪里

另一件容易被忽略的事：存入的资产并不搬运，ETH 与代币安静地躺在 L1 一侧的桥合约里，L2 上流转的是凭证；桥的流动性、配置与裁决权也都长在 L1。这意味着一条 OP Stack 链的安全底色由主网决定——二层再怎么重组排序器，赎回的最后一道门始终在以太坊上。官方文档把 L1 合约按升级路径归到一套合约管理器下成组发布，也就是说版本切换时三层桥合约作为一整套轮换，用户看到的桥地址通常保持代理不变。理解这一点，排查”桥是不是被升级了”就有了抓手：查 L1 上代理合约指向的实现是否更换、更换是否走了既定的治理流程，比围观任何群聊传言都直接。

普通用户对着区块浏览器就能把这条链路上大部分锚点核对一遍：发起存入的交易调用了哪个 L1StandardBridge 地址、事件里的消息哈希能否在提现阶段原样找回、OptimismPortal 是否是对应那条链的规范合约。这些地址的权威来源是官方文档地址页与 superchain 登记册；批次收件地址这类特殊账户——规范注明它不是合约、按惯例从链 ID 推导——也值得顺手认个脸熟。核对的动作不需要任何工具权限，全部是浏览器里的读操作，却能把”点了假桥”这类最常见的资金事故挡在签名之前。本文为机制说明，不构成任何投资建议；跨链桥交互存在合约与操作风险，转账前请逐项核对链上参数。