• CC-01: 是否正确验证跨链消息来源（Message Authentication）？

    • 描述：跨链消息若未严格校验 sourceChainId、sourceAddress 或签名验证逻辑，攻击者可能伪造消息，从目标链释放资产或执行 mint。
    • 建议：合约应严格校验跨链消息的来源链 ID 与可信桥接合约地址，禁止仅依赖 msg.sender 进行判断。签名验证逻辑应采用标准化域分离机制（如 EIP-712），并确保签名数据中包含链 ID、目标合约地址及 nonce 等关键信息，从根本上避免伪造消息执行的风险。

  • CC-02: 是否防范 Replay Attack（重放攻击）？

    • 描述：若跨链 payload 未记录 nonce 或 message hash，攻击者可重复提交同一跨链消息，多次提款。
    • 建议：系统应为每条跨链消息设置唯一 nonce，并按链维度进行隔离管理。消息执行后必须立即将其标记为已处理，防止重复调用。同时建议使用 message hash 映射进行状态记录，并确保 nonce 单调递增且不可复用。

  • CC-03: 是否防范 Liquidity Imbalance 攻击？

    • 描述：在 liquidity-based bridge 中，攻击者可能在某条链集中提现，造成单链流动性耗尽。
    • 建议：协议应设置单笔提现上限与单链流动性上限，并引入动态费率机制，使流动性失衡程度越高时手续费越高，从经济上抑制单边流出。同时应持续监控跨链净流动情况，并设计自动或人工再平衡机制。

  • CC-04: 是否存在跨链执行失败导致资金卡死（Stuck Funds）？

    • 描述：目标链执行失败但源链资产已锁定，可能造成资金永久卡死。
    • 建议：协议应设计可重试机制或超时回滚逻辑，并允许在目标链执行失败时通过备用流程进行资产赎回。此外，应记录失败状态并提供管理员或自动恢复机制，避免用户资金永久锁定。

  • CC-05: 是否存在跨链回调重入风险？

    • 描述：某些桥协议支持回调执行，若合约未加 reentrancy 防护，可能导致重复提款。
    • 建议：所有涉及跨链执行与资产转移的函数应添加重入保护，并严格遵循 Checks-Effects-Interactions 模式。跨链执行后应避免立即调用外部合约，以降低回调重入风险。

  • CC-06: 是否存在权限过度集中风险？

    • 描述：管理员可能具备修改费率、替换 bridge、升级 implementation 的能力，存在 Rug 风险。
    • 建议：关键管理权限应交由多签钱包控制，并为关键参数修改与升级操作设置时间锁机制。同时建议对桥接地址、费率参数与升级逻辑进行权限隔离，避免单点控制风险。

  • CC-07: 是否存在 Flashloan 价格操纵风险？

    • 描述：若跨链 liquidity fee 或兑换比例依赖即时 AMM 价格，可能被 flashloan 操纵。
    • 建议：协议应采用 TWAP 或多区块平均价格作为参考，并加入价格偏差限制机制。同时限制单区块内的大额操作，以降低瞬时操纵价格的可能性。

  • CC-08: 是否存在 Gas DoS 风险？

    • 描述：跨链执行若包含 unbounded loop，可能因 gas 限制导致消息永久失败。
    • 建议：避免在跨链执行逻辑中遍历动态数组或无上限数据结构，必要时采用分批处理机制，并为循环设置最大长度限制，以确保交易始终可执行。

  • CC-09: 是否验证签名安全性？

    • 描述：签名验证若未校验 signer 或未限制 quorum，可能被绕过。
    • 建议：签名验证逻辑应严格校验签名者身份与最小签名数量阈值，避免 quorum 被绕过。同时应防止签名可塑性问题，并使用标准化签名结构进行验证。

  • CC-10: 是否存在跨链经济套利风险？

    • 描述：不同链资产价格或流动性不同，可能被反复套利耗尽流动性。
    • 建议：应引入动态费率调节机制，并持续监控跨链流动性变化情况。在流动性严重失衡时，应限制提款或提高费用，以降低跨链循环套利的风险。

  • CC-11: 是否处理不同链间状态同步边界条件？

    • 描述：在多链环境下，某些跨链事件可能因为异步执行或延迟而导致状态不同步。
    • 建议：应明确各链的事件执行顺序与依赖关系；并在代码设计中确保消息处理逻辑可容忍 out-of-order delivery 或延时消息，从而防止状态不一致导致逻辑攻击。

  • CC-12: 是否确保资产恒等守恒（Supply Conservation）？

    • 描述：跨链流动性协议必须确保 wrapped token 的总供应 ≤ 源链锁定资产量；否则会造成无限铸造风险。
    • 建议：所有跨链 mint 操作必须依赖于严格验证源链锁定事件的证明，并确保每次 mint 都对应锁定或 burn 事件；不得存在可由管理员任意 mint 的接口。

  • CC-13: 是否正确处理 fee-on-transfer / rebasing / 非标准 token？

    • 描述：某些 token 会在转账时扣费或自动调整余额，若未正确处理，会造成账务漂移。
    • 建议：跨链协议在处理这些 token 类型时必须测量实际收到数量，并据此更新内部账务。若无法正确处理，则应明确禁止这些 token 的跨链交易或提供兼容适配逻辑。

  • CC-14: 是否存在 Liquidity Imbalance 与 Hedge 风险？

    • 描述：在 liquidity pool 模式下，部分链的流动性突然耗尽会导致兑换失败或高滑点。
    • 建议：设置单链 liquidity cap、单笔交易的最大额度限制，并可引入动态费率机制（imbalance 越大费率越高）减少单边流失风险。此外，可设计 rebalancing 逻辑，并对其经济安全性进行审查。

  • CC-15: 是否存在基于 block.number 的硬编码时间逻辑？

    • 描述：不同链的出块时间存在差异（L1、L2、侧链差异明显），若使用 block.number 作为时间计算依据（例如锁仓时间、奖励周期等），可能导致在不同链上产生时间偏差或逻辑异常。
    • 建议：避免使用 block.number 进行时间计算，应使用 block.timestamp 或可配置参数，并在不同链环境下进行测试验证。

  • CC-16: 是否评估目标链之间的差异？

    • 描述：不同链在 gas 模型、预编译合约、交易排序、最终性机制等方面存在差异，若未评估这些差异，可能导致部署后出现不可预期行为。
    • 建议：在部署前系统性审查目标链之间的技术差异，并在代码层或参数层进行适配与说明文档记录。

  • CC-17: 是否验证所使用的 EVM Opcode 在所有目标链上均被支持？

    • 描述：某些 L2 或侧链可能未完全支持所有 EVM Opcode（如 PUSH0 等），若使用未支持指令，可能导致合约无法正常执行。
    • 建议：在部署前确认目标链的 opcode 支持情况，尤其是在使用较新 Solidity 版本时，验证编译产物在目标链上的兼容性。

  • CC-18: tx.origin 与 msg.sender 在不同链上的行为是否一致？

    • 描述：不同链的交易封装方式或跨链调用机制可能影响 tx.origin 与 msg.sender的行为，若依赖其进行权限判断，可能出现安全漏洞。
    • 建议：避免使用 tx.origin 进行权限控制，并在所有目标链上测试调用路径，确保 msg.sender 逻辑符合预期。

  • CC-19: 是否存在低 Gas 成本环境下的经济攻击风险？

    • 描述：在 Gas 成本较低或 TPS 较高的链上，某些高频攻击（如循环调用、套利尝试）成本极低，可能使原本在以太坊主网不可行的攻击变得可行。
    • 建议：评估低 Gas 环境下的攻击模型，必要时增加频率限制、最小金额限制或经济门槛。

  • CC-20: ERC20 的 decimals 在不同链之间是否一致？

    • 描述：同一资产在不同链上的 decimals 可能不同，若跨链或多链系统未统一处理，可能导致资产计算错误或精度丢失。
    • 建议：统一内部精度标准，并在跨链资产映射时显式进行 decimals 转换与校验。

  • CC-21: 是否评估不同链上的合约可升级性差异？

    • 描述：某些 Token 或合约在某条链上可升级，而在另一条链上不可升级（如某些 USDT 实现），若未评估可能引发信任或安全问题。
    • 建议：在集成前验证目标链上合约是否可升级，并在文档中记录升级权限及风险。

  • CC-22: 是否严格审查跨链消息组件的权限控制？

    • 描述：跨链消息模块若未进行严格权限控制，可能被未授权调用，导致资产释放或状态变更异常。
    • 建议：为跨链入口函数添加明确的访问控制，仅允许可信桥合约或消息验证模块调用。

  • CC-23: 是否存在支持链白名单机制？

    • 描述：若允许来自任意链的跨链消息，而未做来源链限制，可能导致来自未支持链的非法消息被执行。
    • 建议：建立 sourceChainId 白名单机制，仅允许来自已审核和支持的链的消息执行。

  • CC-24: 是否验证在 zkSync Era 等特殊 L2 上的兼容性？

    • 描述：zkSync Era 等 ZK Rollup 在存储访问、Gas 模型或系统合约方面与主网存在差异，可能导致部署异常或运行错误。
    • 建议：在 zkSync Era 等目标链上进行专项测试与部署验证，确保兼容性。

  • CC-25: 是否考虑区块生成不稳定性？

    • 描述：某些链可能存在区块生成不稳定、间隔变化大等情况，若协议依赖固定出块节奏，可能出现异常行为。
    • 建议：设计逻辑时假设区块时间可能波动，避免依赖严格区块间隔假设。

  • CC-26: Solidity >= 0.8.20 使用的 PUSH0 是否在目标链支持？

    • 描述：Solidity 0.8.20 及以上版本会生成 PUSH0 opcode，但某些链尚未支持该指令，可能导致部署或执行失败。
    • 建议：在部署前确认目标链是否支持 PUSH0，或使用兼容编译选项。