一条 OP Stack 链收的手续费并不自动归排序器运营方所有，也不烧掉——它们被分门别类存进四个协议内置的合约金库。官方运维文档给出了四个金库的地址、归属与提款方式，这是把链当作一家机构来做账本审计时最容易忽略的一层。
四个金库各收什么钱
四个金库都住在 0x42 开头的预部署地址段上。排序器费用金库（SequencerFeeVault，地址尾号 11）收优先费，也就是用户给排序器的小费，这个金库在 Bedrock 之前就存在。基础费金库（BaseFeeVault，尾号 19）收基础费：以太坊主网会烧掉基础费，L2 上则不销毁，整段流入这个金库。L1 费用金库（L1FeeVault，尾号 1A）收数据费，也就是每笔交易为把数据发布到以太坊而多付的那一段。第四个是运营者费用金库（OperatorFeeVault，尾号 1B），从 Isthmus 升级起收集运营者费。四个金库对应四种成本与四类归属方，混在一起看就会误判一条链的收入结构。
三个可配置的字段
每个金库有三项核心配置：收款人（recipient）、最小提款额（minWithdrawalAmount）与提款网络（withdrawalNetwork）。收款人决定资金最终流向哪个地址；最小提款额是一道门槛，金库余额没攒够之前没人能触发提款；提款网络取零或一，零表示送往以太坊一层，一表示留在二层。读写这些配置需要 ProxyAdminOwner 权限——如果链上这个角色是多签，所有改动都得过多签。对普通用户来说，用公开 RPC 只读调用 recipient 与 totalProcessed，就能核对这条链的钱正在流向谁、历史上已经提走多少。
提款是任何人都能按的按钮
一旦余额达到最小提款额，提款是无许可的：任何人调用 withdraw 都能把金库的全部余额转给配置的收款人，不需要运营者身份。这个设计的意义是把金库变成自动售货机而不是保险柜——运营者不需要定期人工搬运，链下也没有必须保持在线的单点。提款的落地路径取决于提款网络：设为一时，资金一步到位转给二层内的收款人；设为零时，要走完整的二层到一层消息流程——等这笔提款被包进一个 L2 输出根、在以太坊上提交证明、等过挑战期、最后再完成最终化。同一笔费用，选不同的提款网络，到账时间差着以天计的窗口。
从金库读出一条链的账本
运维文档建议运营方持续监控两项数据：金库余额（判断何时可提款）与 totalProcessed（累计已提款额，用于观察收入趋势）。把两者按季度连成曲线，配合区块浏览器里金库地址的进出记录，基本可以重建一条 OP Stack 链的费用收入全貌。有两个容易踩的坑：其一，totalProcessed 统计的是历史累计提款额，不是金库当前余额，链上余额为零并不说明这条链没赚到钱，只说明最近被提走了；其二，基础费在 L2 上不销毁，意味着一部分在传统以太坊上被烧掉的等价价值在二层流向了运营方或治理金库，判断链的净成本时要记得这笔差价。金库地址是协议级的常量，换链不换地址段，用尾号就能对号入座。
与费用参数的接口
金库只负责收与转，用户端付多少由另一组 SystemConfig 参数决定：基础费的调整速率、数据费的标量、运营者费的乘数与固定值，都在系统配置合约里由治理设定。运维视角下两套账要连着看——参数改动先反映进区块内每笔交易的费用构成，隔一段周期后才以余额增长的形式出现在对应金库里。若一条链刚经历一次降低最小基础费的参数变更，BaseFeeVault 的进账曲线会先于其他金库出现拐点，这也是核对参数是否真正生效的间接证据之一。
风险提示：本文仅解释协议机制，不构成投资建议；各链参数与费用结构可能调整，请以官方文档与链上实际数据为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。