V4 Security Foundations
Audit a Uniswap v4 hook contract against PoolManager access control, delta accounting, and settlement invariants before you deploy to mainnet.
Overview
v4-security-foundations is an agent skill for the Ship phase that guides a structured pre-deployment security audit of Uniswap v4 hooks.
Install
npx skills add https://github.com/uniswap/uniswap-ai --skill v4-security-foundationsWhat is this skill?
- Access-control section covers PoolManager-only callbacks, router allowlists, and admin transfer safeguards
- Delta-accounting section enforces zero-sum deltas, fee-on-transfer/rebasing handling, and sync-transfer-settle ordering
- Token-handling checks call out ERC-777 reentrancy and decimal queries instead of hard-coded assumptions
- Settlement-flow checks guard against partial settlements and bad state after reverts
- Permission section continues the audit beyond accounting (checklist extends past delta invariants)
- Checklist spans access control, delta accounting, and permissions with 20+ discrete audit items in the published section
Adoption & trust: 631 installs on skills.sh; 212 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are about to deploy a custom v4 hook but lack a Uniswap-specific checklist for access control, delta math, and settlement invariants.
Who is it for?
Solo builders with a v4 hook in late testnet who want agent-assisted walkthrough of PoolManager-centric security items.
Skip if: Teams not building Uniswap v4 hooks, or projects that only need generic OWASP-style app audits without on-chain hook semantics.
When should I use this skill?
You have a v4 hook nearing deployment and need to systematically verify access control, deltas, token edge cases, and settlement flow.
What do I get? / Deliverables
You finish a sectioned audit with explicit pass/fail items across access control and delta accounting so deployment blockers are documented before go-live.
- Completed pre-deployment audit checklist with noted gaps
- Documented fixes for access-control and accounting findings
Recommended Skills
Journey fit
Pre-deployment hook review belongs on the Ship shelf because it is the last structured security gate before launch, not day-one ideation or growth work. Security subphase is the canonical home for checklist-driven contract review and deployment readiness for on-chain integrations.
How it compares
Use instead of ad-hoc chat review when you need Uniswap v4–specific invariants, not a generic Solidity linter pass.
Common Questions / FAQ
Who is v4-security-foundations for?
Indie and solo developers shipping Uniswap v4 hook contracts who want a repeatable pre-mainnet security review with their AI coding agent.
When should I use v4-security-foundations?
Use it in Ship (security) after hook implementation and tests, immediately before deployment, when you need to verify PoolManager access, delta backing, and settlement ordering.
Is v4-security-foundations safe to install?
Treat it as review guidance only; confirm behavior against current Uniswap v4 docs and review the Security Audits panel on this Prism page before trusting third-party skill packages.
SKILL.md
READMESKILL.md - V4 Security Foundations
# v4 Hook Pre-Deployment Audit Checklist Comprehensive checklist for auditing Uniswap v4 hooks before deployment. ## 1. Access Control ### 1.1 PoolManager Verification - [ ] All hook callbacks verify `msg.sender == address(poolManager)` - [ ] Verification uses modifier or explicit check at function start - [ ] No code paths bypass the verification ### 1.2 Router Authorization - [ ] Router allowlisting implemented if hook restricts callers - [ ] Allowlist modifications are admin-protected - [ ] Cannot add zero address to allowlist ### 1.3 Admin Functions - [ ] Admin role transfer is two-step (propose/accept) or timelock-protected - [ ] Critical admin functions have event emissions - [ ] Admin cannot brick the contract (e.g., renounce without safeguards) ## 2. Delta Accounting ### 2.1 Balance Invariants - [ ] All returned deltas are backed by actual token movements - [ ] `take()` calls match returned delta values - [ ] `settle()` calls properly account for received tokens - [ ] Invariant: `sum(all deltas) == 0` for every transaction ### 2.2 Token Handling - [ ] Fee-on-transfer tokens handled (measure actual received amounts) - [ ] Rebasing tokens handled or explicitly blocked - [ ] ERC-777 reentrancy considered - [ ] Token decimals not assumed (queried from token) ### 2.3 Settlement Flow - [ ] Correct order: `sync()` -> `transfer()` -> `settle()` - [ ] No partial settlements left hanging - [ ] Error handling doesn't leave accounting in bad state ## 3. Permissions Review ### 3.1 Enabled Permissions Audit For each enabled permission, document: | Permission | Enabled | Justification | Risk Level | | ------------------------------- | ------- | ------------- | ---------- | | beforeInitialize | [ ] | | | | afterInitialize | [ ] | | | | beforeAddLiquidity | [ ] | | | | afterAddLiquidity | [ ] | | | | beforeRemoveLiquidity | [ ] | | | | afterRemoveLiquidity | [ ] | | | | beforeSwap | [ ] | | | | afterSwap | [ ] | | | | beforeDonate | [ ] | | | | afterDonate | [ ] | | | | beforeSwapReturnDelta | [ ] | | | | afterSwapReturnDelta | [ ] | | | | afterAddLiquidityReturnDelta | [ ] | | | | afterRemoveLiquidityReturnDelta | [ ] | | | ### 3.2 Delta Return Permissions (Critical Review) If any delta return permission is enabled: - [ ] NoOp attack vector analyzed and mitigated - [ ] All code paths returning non-zero deltas reviewed - [ ] Deltas are always backed by liquidity provision - [ ] Multiple independent reviewers have verified ## 4. Reentrancy Protection ### 4.1 External Calls - [ ] All external calls identified and documented - [ ] Reentrancy guards applied where needed - [ ] State changes follow checks-effects-interactions pattern - [ ] No callbacks to untrusted contracts ### 4.2 Token Callbacks - [ ] ERC-777 `tokensReceived` hook considered - [ ] ERC-721/1155 callbacks considered if applicable - [ ] Flash loan callbacks considered ## 5. Gas and DoS ### 5.1 Loop Bounds - [ ] All loops have maximum iteration limits - [ ] Limits are appropriate for block gas limit - [ ] User-controllable arrays bounded ### 5.2 Gas Estimation - [ ] Gas usage tested for worst-case scenarios - [ ] No operations that could exceed block gas limit - [ ] External call gas limits are reasonable ### 5.3 DoS Vectors - [ ] No unbounded array iterations - [ ] No unbounded mapping iterations - [ ] Failed external calls don't block hook