先写明条件再发交易：eth_sendRawTransactionConditional 的四类前提

把交易直接广播进公共内存池，等于把自己的意图摊开给所有打包者看：价格好的交易可能被夹在前后两笔之间执行。普通对策是滑点与防夹通道，见 交易被三明治夹了？滑点设置与防夹通道讲解。ERC-7796 则在另一层发力：让发送方在提交交易时就写明“什么条件下才准把我放进块”，条件不满足，交易根本不会被执行，而不是进块再回滚。这份标准的载体是一个新的 JSON-RPC 方法 eth_sendRawTransactionConditional。

方法形状：原交易加一组前提

参数只有两个：签名后的原始交易十六进制，与一个选项对象。选项里允许写四类前提。第一类是状态前提 knownAccounts：给一组地址，各自声明预期的存储槽值、整棵存储根哈希，或者用特殊键声明余额、随机数、字节码——把字节码写成空串表示预期这个地址还没有代码，带 0xef0100 前缀则对应账户代码委托那类新形态。第二类是区块区间 blockNumberMin 与 blockNumberMax；第三类是时间区间 timestampMin 与 timestampMax；第四类是 paysCoinbase，声明这笔交易愿意付给打包者的最低总额。接收方在受理前应当逐项核对这些前提，任何一项不满足就应当拒绝请求。

失败与成功各长什么样

条件验证当场失败时，标准建议返回带原因的错误码：条件不符用 -32003 transaction rejected，状态前提太大处理不动用 -32005 limit exceeded。特别注意规范那句提醒：即使调用没有报错、交易已被 builder 的内部池接受，发送方也不得假定它一定进块，仍要盯着链。也就是说，这个接口改变的是“什么条件下值得试一次”，并不改变“最终确认看区块浏览器”的老纪律，广播后交易去向的排查可参考 广播过的交易怎么“不见了”：被挤出、到期清理与正确的重发姿势。

它替你省下什么、省不掉什么

省掉的部分很实在：传统私有通道的做法是打包方先模拟你的交易、看它是否合格，这很费 CPU；写明前提后，不满足的交易可以被直接拒之门外，也就不会有一笔注定回滚的执行去烧手续费——手续费账目的三种口径见 一笔手续费的三本账：钱包估算、签名上限与链上回执怎么对上。省不掉的部分是前提本身要写对：存储槽的含义、余额的单位、区块与时间区间的宽严，都是提交前就要核对的内容——前提写错的直接后果通常是请求被当场拒绝或交易迟迟无人受理，你得改条件重新签名再发，而不是进块后才发现。

和相邻机制的边界：条件、断言、替换

条件发送容易和几个近邻混淆。它不是 ERC-5792 那种把多笔调用打包进一次钱包授权的分层执行，那是批量的事；也不是替换交易那种靠提高费用挤掉旧交易的机制，那是 nonce 的事。它更不是协议层的条件交易——协议层另有 EIP-7793（状态行同样是停滞类）想把槽位与区块内位置直接写进交易类型、由执行层强制，两者不能混为一谈。ERC-7796 的全部承诺只发生在发送通道一层：builder 与排序器受理前核对，核不过就拒。理解这层边界，也就理解了为什么钱包即便支持条件发送，滑点设置、deadline 参数这些链上自带的防线一条都不能撤——它们是协议内最通用的两类自保手段，条件接口只是发送通道上追加的一层保险，不能替代它们。

现状提醒

按标准仓库的文本，ERC-7796 的分类是 ERC、状态行是 Review，面向的是区块构建者与排序器的接口层；普通用户一般通过钱包的“保护性发送”“防夹通道”之类的功能间接接触它。你的钱包是否用、怎么用这个接口，以钱包官方文档为准，不要凭界面按钮猜机制。

以上内容是交易提交机制的技术说明，不构成任何投资建议；条件设置只是降低失败执行的概率，不能保证成交，更不能保证任何价格或收益。