截止到目前为止， 我们的产品已经完成了主要问题的修复。 但在说修复之前， 我们还是先把问题讲清楚，也向大家认真道个歉。 1，为什么同一个 CA，会出现不同的结果？ 这个问题，确实是我们的失误。 当时产品是今天通宵赶工上线的，过程中出现了服务器不一致的问题——旧服务器还在跑旧规则，而新服务器已经更新了逻辑，导致同一个 CA 在不同请求下返回了不同结果，而且旧服务器的根本问题是，旧规则本身就不严谨。 我们当时只做了很粗的判断，看到 mint 就当成“可以增发”，看到 setFee 就当成“可以改税”。但在像 PancakeSwap V2 这样的协议里，mint(address) 是给 LP 提供者发 LP 代币的正常机制， setFeeTo / setFeeToSetter 也是协议级的收款地址设置，跟项目方权限没有关系。 也就是说：我们把正常逻辑，当成了风险，这也是为什么会出现“同一个 CA，不同时间检查，结果不一致”的情况。 目前旧服务器已经同时更新了新规则。 2，为什么蝴蝶官方通过审核的币会误报？ 因为穿透后挑的"项目核心"挑错了，我们本来是想找到项目真正的核心合约，但实际结果是——我们把一个链上的公共基础设施，也就是把所有 PCS 池共享的基础设，当成了"项目核心"，具体来说，就是把通过 mainPool.factory() 穿透出来的PancakeSwap V2 Factory，当成了“项目核心”，但这个合约是什么？它是所有接入 PancakeSwap 的项目都会用到的公共组件。这又进而导致我们所有的问题回到了第1个问题，也就是为什么大家会看到增发和税的权限。 于是就出现了连锁问题：真正的项目合约被顶掉了，UI 只展示了这个“选错的地址”，用户看到的，其实是在分析一个公共组件，然后又回到了第一个问题 —— 在这个合约里，我们又误判了 mint / setFee，最终变成大家看到的结果：一个正常项目，被判成“可以增发、可以改税”。 但，由于犯了错误，直接顶掉了真正的项目合约，导致了一连锁反应，UI 只展示了这一个“被选错的地址”用户看到的分析，其实是在分析一个“公共组件”然后又回到了第一个问题 ——在这个公共合约里，我们又误判了 mint / setFee，于是就变成了大家看到的情况：一个正常项目，被系统判成“能增发、能改税”。 3，我们已经做的修复： 统一服务器规则，彻底移除旧逻辑 风险判断从“单函数匹配”改为“上下文判断” 建立 SHARED_INFRA 白名单（PCS V2/V3 Router + Factory 直接过滤） 重写评分机制，确保只选中项目自身合约 优化展示逻辑，避免“只看到一个错误地址”的问题 后想说一点实话： 我们知道，一旦信任被打破，是很难修复的。 这次的问题，也确实是我们在产品还不成熟的时候，过早地推到了大家面前。该承担的，我们承担。 我们没法要求大家立刻重新相信我们，但还是希望你们能多用一用、多测一测，把问题继续打出来。 对一个做“防诈”的产品来说，也许现阶段最重要的不是功能多，而是——尽量不出错。 这件事，我们会继续往这个方向改。对所有被影响到的朋友，说一声对不起。—— 蝴蝶防诈团队
