接着Yishi老板的继续往下讲 其实单纯开源的合约设计本身出问题的并不多 而且在合约层纪律出状况的大团队，基本上没有不是多轮审计、形式化验证的，其中很多也是上线纪律尚可的团队，但是仍然没防住 审计公司并不会为此负责 更多的安全事故其实来自权限管理、参数管理上，不管是Drift和KELP的事故都是如此 这里有个核心问题：DeFi产品是不是应该追求并且推定“无事故”？ 现在的绝大多数DeFi（其实也包括CeFi）项目的逻辑是：“因为我做了如何如何多层的措施，所以我不会有事故” 这样导致的直接结果就是，一旦出了事故，很难救。因为所有的方案都是优雅的“治未病” 那如果我们假设事故不可避免呢？ 设计思路就会从“防病”变成“治病”。从“安全措施”变成止损方案 最大的几个方面就会变成： 1. 升级合约的时间锁（这个老生常谈） 2. 偿付能力监控（保持协议偿付能力与资金入金的覆盖比例）： 这个问题其实就是为什么很多lending有“赚白菜钱，操白粉心的原因 微薄的利差生意堆了太多的TVL，协议本身根本不可能偿付 3. 大额异动熔断 这一点现在基本上很少有协议有，但是在CEX是标配 在发生大额资金异动交易，尤其是提现的时候，自动触发风控延迟提现，给风控机制介入的时间 所有的黑客攻击不管是怎么产生的，最终的结果一定是大额资金异动提现，那么堵不住漏洞本身，可以堵的住造成损失的最后一关本身 这种风控在dapp协议级别、稳定币级别、桥级别都可以做，对于正常的用户影响并不会太大（包括高频套利，他们并不会一直高频提现） 这对于ETH是极大劣势，但是对于@BNBCHAIN 这样的交易所公链来说，是非常大的优势 BNB之前可以成功通过节点级别的Goodwill Alliance让MEV抢跑问题下降95%，那么同样有可能在桥一级别加上同样的类时间锁风控机制 即使发生攻击，桥就是最后一道保险，在被盗资金逃逸最后一关卡住资金。所有涉及到BNB的跨链协议都应该推同一套标准 这一方法的有效性，在Sui和Hyperliquid等公链和CEX的安全事故处置中被反复证明有效 - 当然前提是没有USDC CCTP不作为这样的漏勺存在的前提下 另外则是稳定币级别的大额转账时间锁和黑名单机制，逻辑和桥一样，但是这个可能会影响采用 总的来说我认为这是属于L1的机会，关键就是四个大字：自主可控 在这样的前提下，甚至公链一级别可以实现真正的“事故包赔”，而不是umbrella那样的“商业保险”。谁能做这个，谁就可能吃下ETH丧失的TVL份额