UserOperation如何变成链上执行？

UserOperation 是用户交给 bundler 的操作对象，随后由 bundler 把它纳入调用 EntryPoint 的链上交易。读懂这一转换，能够回答智能账户钱包里最常见的困惑：为什么页面已经给出一个操作标识，却还不能按普通交易的方式判断它是否上链？关键是分清对象、处理阶段与链上承载交易，不把三者缩成一个“发送成功”。

先看两种对象，再看钱包提示

普通链上交易与 UserOperation 的关系，可以用“外层承载与内部操作”来理解。ERC-4337 没有要求为这条路径修改以太坊共识层，而是通过替代内存池、bundler 与 EntryPoint 协作实现账户抽象。用户提交操作，bundler 再构造调用 EntryPoint 的交易，把这些操作带到链上处理。

对象	主要观察问题	应避免的等同
UserOperation	这份用户操作是否被接收、验证与纳入打包	操作已接收等于已上链
调用 EntryPoint 的交易	承载操作的交易是否已进入链上执行	有交易标识等于内部业务全部成功
钱包的状态说明	前端所说成功对应哪一个处理阶段	一句成功覆盖所有阶段

这张表并不假设任何钱包采用固定按钮或固定文案。本文没有核验某个具体产品界面；它提供的是提问框架，让读者在看到状态时追问“这个状态是针对哪个对象”。如果服务只给出接收结果，应该继续寻找链上处理证据，而不是把返回值自动解读为最终确认。

第一层：bundler接收操作

用户先将 UserOperation 交给 bundler。ERC-4337 对 bundler 的验证设置了多个时点：接收操作时、构建 bundle 时以及提交 bundle 之前。这里的验证不是一次做完后永远不变的承诺；收到操作与将操作带入链上交易之间，仍有后续检查环节。

对使用钱包的人而言，最有价值的区别是“已被接收”与“已被打包”不能混用。前者说明服务进入了接收处理，后者才涉及操作是否纳入承载交易。仅凭前端给出的一个 UserOperation 标识，无法跳过中间阶段。这也是为什么查询时应说明自己要查询的是用户操作状态，而不是只把它粘贴到一个普通交易查询框后凭无结果下结论。

本文不提供某家 bundler 的服务地址，不承诺其响应速度、覆盖网络或收费。若产品接入依赖具体服务，应该查对应官方文档，并保存它实际提供的状态解释。协议角色的说明，不能替代产品可用性核验。

第二层：EntryPoint与账户验证

bundler 将操作纳入调用 EntryPoint 的交易后，账户通过 validateUserOp 校验操作的签名与有效性。账户的验证逻辑与 bundler 的接收判断分属不同职责，不能认为某个服务收下数据就等于账户已经认可全部请求。

可以把这一层理解成“把操作送到统一入口，再由账户规则判断”。EntryPoint 是这条链上处理路径的重要入口，而操作是否符合账户要求，需要由相应验证逻辑核查。对普通用户，无须背下每一个编码字段，但需要知道钱包便利界面背后仍有真实的账户验证；操作对象中出现了签名，也不自动意味着最终有效。

如果希望查看更细的执行路径，可以阅读 ERC-4337的执行参与者。本文使用对象与状态对照解释用户能看到什么，不将所有 EntryPoint 版本的字段排列写成一份通用配置单。

第三层：可选代付没有取消验证

paymaster 可以参与验证与费用支付，但它是可选角色。理解它时要保留“参与”两个字：代付机制没有把其他验证角色合并掉，也不应被理解成只要出现赞助就可以忽略账户签名与操作有效性。

用户看到“有人代付”时，应继续核对产品对费用与资格的说明。本文没有核验任何实际赞助条件、收费金额或服务承诺，所以不把可选 paymaster 写成每个钱包都免费，也不推断失败情况下产品如何向用户收费。机制允许一种费用参与方式，与某个服务是否真的承担某笔费用，需要分别验证。

若希望继续了解代付概念，可参阅 ERC-4337 Paymaster的职责。这有助于分开看 bundler、账户与 paymaster：一个负责收集和带入交易，一个按账户规则验证，另一个可能参与费用支付。明确角色后，就不容易将所有错误都归因于“网络手续费不够”。

查询时同时保存操作与承载交易的线索

UserOperation hash 与承载它的交易 hash 对应不同层次。查询操作时，关心这份用户请求的处理阶段；查询交易时，关心 bundler 发出的链上承载是否得到处理。因此若钱包或服务能提供二者，宜分别保存，并按照它们所属的对象理解结果，不互相替换。

一个防止误判的顺序是：先确认钱包报告的是接收还是打包；再确认是否有对应链上交易；最后结合产品与链上记录判断该操作的执行结果。这个顺序不保证每个平台都能展示同样多的信息，但能让用户明确缺的证据在哪里。缺少信息时应查官方说明，而不能把“尚未看到”改写为“肯定失败”或“肯定成功”。

关于智能账户的整体背景，可补充阅读账户抽象钱包的机制。普通交易与用户操作的区别不只在字段名字，而在谁接收对象、谁验证它、哪笔交易承载它，以及状态证据如何对应。这些问题讲清后，便利体验才不会遮住核验过程。

版本边界与使用风险

本文按 2026 年 10 月 11 日核验的 ERC-4337 与官方文档解释流程，未核验每条网络的 EntryPoint 部署版本、SDK 编码和钱包新增字段支持。实际接入时必须按具体网络、合约与 SDK 文档确认；不能因为规范出现某项能力，就默认所用钱包已经实现。

账户抽象不会消除签名误用、目标合约漏洞和服务故障。代付也不是业务成功或资产安全的保证。本文仅作协议教育，不构成投资建议或钱包推荐；数字资产价格可能剧烈波动，链上操作可能造成本金损失，请独立核验账户规则、网络与费用条件，对无法解释的请求暂停确认。