误把所有大滑点都当作 Sandwich 攻击
Sandwich 攻击常见错误的第一名，是把任何「价格不如预期」的交易都归咎于夹击。事实上，链上滑点偏差的来源很多：池子流动性不足、价格在区块间正常波动、聚合器路径未及时刷新等。真正的 Sandwich 攻击必须满足在同一区块内、由同一地址或关联地址插入两条对冲交易的特征。
建议在排查时先用区块浏览器调出目标交易的 receipt 与同区块前后两笔交易，对比 to 字段与 input data。若发现机器人交易的目标合约与用户一致，且方向相反，那才是典型夹击。否则更可能是 Binance 智能链上一次正常的市场波动。
私有 RPC 配置失误导致防御失效
不少团队把交易转发到私有 RPC，以为可以彻底规避 MEV。但常见错误是仍在前端默认使用公共节点，导致部分关键交易被泄漏到公共 mempool。正确的姿势是确保 wallet provider、签名流程与 broadcast 端点完全一致，必要时在前端检测 RPC URL，提示用户使用受保护通道。
另一个高频错误是误用某些声称「保护交易」的服务，实际上这些服务把订单回灌给自家做市商，等同变相 internal MEV。建议在选型时验证服务是否真的把交易直送给 builder，并查看其历史成交回报。
滑点设置的两类极端
一种极端是把滑点设得过松（5% 以上），等于把利润拱手让给夹击机器人；另一种极端是过紧（0.05% 以下），导致绝大多数交易因小幅波动失败。
合理做法是根据交易体量与池子深度动态计算。对小额交易，可以使用聚合器自动估算；对大额交易，应主动拆单或借助 BN交易所 等中心化平台的 OTC 通道完成主力部分，链上仅留尾单。理解这一点之后，再回头看 bn 生态里的大额 swap 路由，你会发现先进协议早已在前端嵌入了智能拆单逻辑。
协议层防御常见误区
部分协议尝试用「最小输出限制 + 区块号校验」来抵御 Sandwich 攻击，但忽略了 builder 可以重排 nonce 的事实。常见错误是仅校验 block.number，没有引入序列证明，结果机器人仍能在同区块内插队。
更稳妥的做法是引入 commit-reveal：用户先提交承诺哈希，再在下一区块揭示参数。配合限定揭示窗口，机器人即便看到承诺也无法计算最优夹击参数。需要注意的是，commit-reveal 会增加一次链上交互，使用前需评估对 UX 的影响。
排查清单与修复路线
面对一次疑似夹击事件，建议按以下顺序排查：
- 验证「同区块、相反方向、同合约」三要素是否同时成立。
- 检查交易源 RPC 是否为受保护通道，若非则迁移。
- 评估当前滑点策略是否与体量匹配，必要时切换聚合器。
- 审视协议是否启用了批量撮合或 RFQ，未启用则推动产品迭代。
- 与 币安交易所 等头部平台对比同时段中间价，量化损失。
按这份清单走一遍，绝大多数 Sandwich 攻击常见错误都能被快速识别与修复。