Uniswap v4 introduces hooks, allowing developers to customize pool behavior like dynamic fees and external integrations. This shifts security responsibilities to application and hook code, as demonstrated by the Cork and Bunni exploits totaling over $20 million. These exploits stemmed from application-level logic, not Uniswap v4 core protocol flaws. Analysis of audits reveals seven common failure patterns in hook code.The PoolManager now holds all pool state, with hooks acting as independent contracts executing at specific lifecycle points. A pool's identity includes its hook address, meaning trusting the wrong PoolKey affects the pool being interacted with. The session-based model, similar to flash loans, ensures currency deltas settle to zero by the end of a transaction. Hook developers must validate assumptions, including caller authorization, legitimate pools, custom accounting, and external integration safety.A critical failure is not checking callers, allowing direct malicious calls to hook functions. Using BaseHook and SafeCallback, along with onlyPoolManager, helps enforce caller checks. Another issue is treating any pool as legitimate; hooks must bind to canonical pools or maintain an allowlist and re-check PoolIds. Custom accounting bugs can silently leak value, as settlement only checks overall deltas, not internal hook accounting accuracy.Developers must place logic in the correct hook for the intended state, as beforeSwap uses pre-swap data while afterSwap uses post-swap data. The hook address itself encodes permissions; developers must keep these bits in sync with implemented functions to avoid errors. Lastly, hook failures can block pool actions; essential logic should not revert and block user flows, and external dependencies must be handled carefully to prevent denial of service.