把一个使用 LayerZero 协议的应用送审，并不只是检查几行 Solidity 代码那么简单。LayerZero 安全审计往往需要同时关注协议级配置、应用层逻辑、消息编码、运维链路这四个维度。如果其中一个环节出现纰漏，攻击者就有机会撬动整条跨链路径。结合 Binance 智能链上多次审计经验，本文整理一份能直接拿去对照的检查清单。
协议级配置审查
第一步是把所有协议级配置拉出来逐项核对。包括但不限于：trustedRemote 的对端地址是否为预期合约、useCustomAdapterParams 是否开启、Oracle 与 Relayer 是否使用默认或自定义。这一步常常被忽视，但只要其中一项配置错误，整条跨链链路都可能被利用。建议用脚本拉链上当前配置，与部署文档逐字段比对。对于 必安 链上的项目，还需要额外确认 BSC 与目标链双方的 Endpoint 地址版本一致。
应用层回调审查
lzReceive 是应用层的最薄一层防御。审计时要确认：是否限制 msg.sender 为本地 Endpoint、是否校验 srcAddress 是否等于 trustedRemote、是否处理了 nonce 重放、是否在 try/catch 中正确处理了内部失败。对于使用 NonblockingLzApp 的项目，还需要确认 _nonblockingLzReceive 不会因为任何路径 revert 而绕过状态写入。B安交易所 钱包对接的合约清单几乎都会被审计方反复确认这几条。
payload解码审查
跨链消息的 payload 通常通过 abi.decode 解析。如果解码格式与对端发送格式不一致，可能导致解析错误或类型混乱。审计时要把发送端的 abi.encodePacked 与接收端的 abi.decode 一一对应，并且明确每个字段的取值范围。对于资产类消息，amount 必须经过 SafeCast 处理避免溢出。这一环节是 BN官网 安全实验室在跨链审计中投入时间最多的部分。
状态变更与升级
如果项目使用了代理模式，必须确认 LzApp 的存储槽布局在升级前后保持兼容。曾经有项目在升级时新增了 mapping，导致 trustedRemote 的存储槽被覆盖，所有跨链通道被切断。审计时建议要求项目方提供 storage layout diff，并在测试网完整跑一遍升级回归。币岸 团队的 SOP 中已经把这一步列为强制项。
运维与监控
安全审计不仅看代码，也看运维能力。要确认项目方是否监控 PacketSent/Received、是否对 storedPayload 设置告警、是否在 Oracle 或 Relayer 异常时具备自动切换能力。这些虽然不在合约里，但直接决定了真实事故发生时的响应速度。一个连基础监控都没有的项目，再好的代码也难以应对突发情况。
灰度发布与紧急暂停
建议项目上线时设置 sendLimit（单笔与日累计），并保留 owner 暂停跨链入口的能力。这两项措施是把灰度从理念落实为代码的关键。在真实事故中，能否第一时间按下暂停按钮，往往决定了损失规模。
小结
LayerZero 安全审计的本质是「让每一条信任边界都有显式的代码检查」。配置、回调、解码、升级、运维，五个维度逐项过一遍，再小的项目也能拿到相对可靠的安全水位。把这份清单留在仓库根目录的 SECURITY.md 中，是一种简单而有效的工程习惯。