验证者提款：核验手续费地址之外的接收目标
验证者的执行层手续费接收地址，不一定是其提款目的地。只去手续费地址寻找提款，或者只查普通交易列表，都可能错误报告款项失踪。核验链条应从验证者记录及适用提款凭证，连接到已接受执行载荷中的具体提款对象，再对接收地址余额做数量核对。
本文交付的是某一笔提款去了哪里的证据表，不把奖励、处罚和费用重新混成总收益桥，也不从验证者收款地址直接推定质押池客户的法律受益权。协议到账与客户最终分配应能分别核对。
把四种身份分栏保存
至少记录验证者索引、提款凭证、提款对象的全局索引以及执行层接收地址。区块feeRecipient另放一栏。验证者签名密钥用于共识职责，并不自动等于控制提款钱包的私钥。
EIP4895的提款对象定义列有index、validator_index、address和amount。index标识全局提款序列中的对象，validator_index才对应验证者记录，两者不在同一个命名空间。不能因为字段都叫索引，就用同一数字互相连接。amount的单位是Gwei，而执行层账户余额通常用wei表示，展示为ETH之前要先保存原始整数。
凭证与地址的连接，本文主例采用consensus-specs的v1.6.0标签下Capella历史规则。在该固定版本源码中定位Withdrawal、ExecutionPayload、get_expected_withdrawals和process_withdrawals：相应构造取提款凭证最后二十字节作为接收地址，fee_recipient则是独立的载荷字段。这里限定历史类型一例，不声称Capella文件可以单独规定所有当前凭证类型，也不声称所有网络默认启用了相同分叉。
从原始对象核对一笔提款
假设某网络的一个历史区块适用上述Capella类型一规则，验证者索引42持有有效0x01执行提款凭证，其最后二十字节对应地址W。凭证可以示意写成“0x01、十一字节零、W的二十字节”。W和F都是虚构标签，不能复制到钱包作为真实地址。
已接受执行载荷中包含如下内容。
| 字段 | 假设值 | 核验含义 |
|---|---|---|
| 提款全局索引 | 900 | 唯一提款对象 |
| 验证者索引 | 42 | 要连接的验证者 |
| 接收地址 | W | 执行层余额接收者 |
| 数量 | 2,000,000,000 Gwei | 原始提款单位 |
| 区块手续费接收者 | F | 独立费用目的地 |
设F与W不同。先换算数量：2,000,000,000乘以1,000,000,000，得到2,000,000,000,000,000,000 wei，即2 ETH。再把提款900连到验证者42，在相关历史状态中确认凭证目标为W，最后核对W的余额。
F没有收到这2 ETH符合此例，不是提款失败证据。同样，拿900去查验证者，会跟到错误对象。索引转换错误和数量单位错误，都可能制造看似严重、其实来自工作表连接方式的异常。
假设W区块前有5 ETH，该区块没有其他余额变化，提款后应有7 ETH。如果W同区块还转出1 ETH并支付0.01 ETH执行费，期末则可能是5.99 ETH，即5加2减1减0.01。净增少于2，不代表系统提款变小；要先拆开其他收支再判断不一致。
余额差只是一项交叉核验，不能单独标识提款。另一笔普通转入2 ETH也会产生同样的增量。载荷中的提款对象补上了余额差本身缺少的全局索引、验证者及接收者连接，不能因为净变化对上了就跳过这些字段。
不要求普通交易收据或回调
EIP4895的状态转换及设计理由把提款写成系统操作，直接增加指定接收账户余额，不执行通用EVM调用。因此接收合约不需要运行fallback才“接受”这笔提款，缺少ERC20 Transfer事件也与这笔原生ETH信用无关。
不要给提款900虚构一个用户交易哈希，也不要因为浏览器普通交易页没显示向W转账，就否定系统到账。应保存已接受区块哈希、载荷中的位置及提款字段。合约可以在原生余额增加后，仍未在自己应用账本中为任何客户记入存款；随后谁能提走合约资金，是另外的控制权限问题。
系统入账不向接收者收gas，不能推广为所有提款相关动作都免gas。发起、修改或请求提款可能走另一套操作。请求交易和最终余额入账各占一行，分别保存标识、数量与费用，避免把触发成本错误扣在系统提款数量里。
历史类型一与当前复利机制分开
本次查阅的Ethereum提款说明页标注更新于二〇二六年八月十七日，区分传统类型一与复利类型二：前者说明超过32 ETH的余额自动清扫；后者说明有效余额可复利至2048 ETH，超过该水平才自动清扫。类型二低于该水平时的手动部分提款请求是另一机制，可能需要执行层gas。
因此，当前页面用来识别应追查的凭证类型和请求机制，历史Capella文件用来解释主例的0x01地址连接，两者不能混成“所有时期、所有验证者都超过32即自动提款”的单一规则。一个类型二验证者有100 ETH，是不同机制的直接边界：不能仅凭余额就说68 ETH自动提款已经失踪。
旧0x00凭证还需另查转换状态，不能像已经是0x01那样直接抽取收款地址。符合资格、排队清扫、请求被处理及执行载荷已入账是不同阶段。请求事件或凭证更新并不是最终付款对象，也不能凭一次队列截图承诺固定完成时间。
执行目的地核验表
| 步骤 | 取得的输入 | 应暂缓结论的情形 |
|---|---|---|
| 固定上下文 | 网络、分叉、区块哈希、最终性要求 | 测试网与主网或不同历史规则混用 |
| 连接验证者 | 索引及相应历史凭证 | 只有运营方显示名称 |
| 寻找提款对象 | 全局索引、载荷、原始数量 | 浏览器只有请求记录 |
| 核对目的地 | 凭证规则与完整二十字节地址 | 地址被截断或历史状态缺失 |
| 换算数量 | Gwei、wei、ETH三栏 | 单位或小数格式冲突 |
| 对账余额 | W前后余额及其他收支 | 净变化尚有无法解释项目 |
共识层和执行层证据应属于同一区块谱系。重组或浏览器缓存不同链头，会使各自看似合理的记录无法互相对应。先比较原始字段和区块哈希，再诊断错误目的地。如果归档服务无法提供历史凭证，连接状态应保留未解决，不能用今天的验证者记录补写过去。
对质押池，再附独立的客户权益记录，包括服务合约、客户请求及分配条款。协议可能已正确把2 ETH送到W，客户尚未得到分配；客户后来收到付款，也不能单独证明款项来自提款900。目的地证据与后续分配证据分开，才不会把运营延迟误报为协议未到账。
更新触发条件包括找到已接受载荷、纠正历史凭证查询、明确分叉适用范围，或重组移除了原区块。后续付款可以解决待办，但应保留最初观察日期，不能把请求标识直接改名为提款标识。复核者需要同时看到当时知道什么，以及新证据改变了哪一环。
共享收款地址仍按验证者逐笔保留
多个验证者可以使用同一接收地址。继续构造一个独立对账分支：提款900来自验证者42，向W记入2 ETH；同区块另一提款901来自验证者43，向W记入1 ETH。W余额中来自提款的部分合计3 ETH，但不能因为正在调查42，就把3 ETH全部归给42。应先每个提款一行，再按目的地汇总。
这也说明不能用“地址加数量”替代全局索引。不同日期或同一区块都可能有相同地址、相同展示数量；反过来，同一个对象可能被两个浏览器导出两次。先检查对象身份，才能区分两笔同额提款和同一笔重复导入，否则余额桥可能表面相等，归因却错了。
数量本身还不能确定是全额还是部分提款。若研究需要该分类，应连接当时验证者状态和适用资格规则；不能因为金额很大就标全额，也不能因为最终地址已有余额就说它是再次提款。提款对象描述这次交付，验证者状态说明触发背景，两者各自保留。
导出工具若只提供收款地址和展示金额，应回到原始载荷补索引及validator_index；无法补齐时，合计数量可以作为待核总额，逐验证者归属仍未知。不要为了让总表完整，用运营方地址标签分摊未知部分。
最终应同时有逐对象明细和地址汇总两层。明细检查身份、单位及目的地，汇总检查未重复后的余额桥。任一层冲突都应暂停相关归因，先处理区块谱系、重复导入和漏项，再讨论协议是否交付错误。
常见问题
手续费接收者是否自动控制验证者提款？
不能仅凭该身份得出结论。应匹配提款凭证与实际载荷收款地址，两者可以不同于手续费地址。
接收合约必须执行回调吗？
EIP4895系统入账不执行通用回调，但合约自己的客户记账与后续支出规则仍需另查。