Uniswap v4 引入了钩子（hooks），使开发者能够自定义池的行为，例如动态费用和外部集成。这将安全责任转移到了应用层和钩子代码上，正如 Cork 和 Bunni 漏洞所示，两者造成的损失合计超过 2000 万美元。这些漏洞源于应用层逻辑，而非 Uniswap v4 核心协议的缺陷。对审计报告的深入分析揭示了钩子代码中七种常见的失败模式。PoolManager 现在持有所有池的状态，而钩子作为独立合约在特定的生命周期点执行。池的身份包含其钩子地址，因此信任错误的 PoolKey 会影响所交互的池。基于会话的模型类似于闪电贷，确保在交易结束时货币差额结算为零。钩子开发者必须验证各项假设，包括调用者授权、合法池、自定义会计逻辑以及外部集成的安全性。一个关键的失败模式是未检查调用者，从而允许直接恶意调用钩子函数。使用 BaseHook、SafeCallback 以及 onlyPoolManager 有助于强制执行调用者检查。另一个问题是误将任何池视为合法；钩子必须绑定到规范池，或维护允许列表并重新检查 PoolIds。自定义会计错误可能导致价值静默泄露，因为结算仅检查总体差额，而不验证内部钩子会计的准确性。开发者必须将逻辑放置在针对预期状态的正确钩子中，因为 beforeSwap 使用换汇前的数据，而 afterSwap 使用换汇后的数据。钩子地址本身编码了权限；开发者必须保持这些位与已实现函数同步，以避免错误。最后，钩子故障可能阻塞池的操作；关键逻辑不应回滚并阻断用户流程，且必须谨慎处理外部依赖，以防止拒绝服务。