Uniswap v4は、開発者が動的な手数料や外部連携など、プールの動作をカスタマイズできるフックを導入しました。これにより、セキュリティの責任はアプリケーションとフックコードに移管され、CorkとBunniのエクスプロイトでは合計2,000万ドル以上が失われました。これらのエクスプロイトは、Uniswap v4コアプロトコルの欠陥ではなく、アプリケーションレベルのロジックに起因するものでした。監査の分析によると、フックコードには7つの一般的な失敗パターンが見られます。PoolManagerがすべてのプールの状態を保持するようになり、フックは特定のライフサイクルポイントで実行される独立したコントラクトとして機能します。プールのIDにはフックのアドレスが含まれるため、間違ったPoolKeyを信頼すると、対話しているプールに影響します。フラッシュローンと同様のセッションベースのモデルは、トランザクションの終了時に通貨の差額がゼロになることを保証します。フック開発者は、呼び出し元の承認、正当なプール、カスタム会計、外部連携の安全性を含む仮定を検証する必要があります。重要な失敗は、呼び出し元をチェックしないことで、フック関数への悪意のある直接呼び出しを許可することです。BaseHookとSafeCallback、およびonlyPoolManagerを使用することで、呼び出し元のチェックを強制するのに役立ちます。もう1つの問題は、任意のプールを正当なものとして扱うことです。フックは、正規のプールにバインドするか、許可リストを維持し、PoolIdsを再チェックする必要があります。カスタム会計のバグは、決済は全体の差額のみをチェックし、内部フック会計の精度はチェックしないため、静かに価値を漏らす可能性があります。beforeSwapはスワップ前のデータを使用し、afterSwapはスワップ後のデータを使用するため、開発者は意図した状態に対して正しいフックにロジックを配置する必要があります。フックアドレス自体が権限をエンコードします。開発者は、エラーを回避するために、これらのビットを実装された関数と同期させておく必要があります。最後に、フックの失敗はプールの操作をブロックする可能性があります。不可欠なロジックはリバートして