All skills
uniswap avatar

/v4-security-foundations

@a718080
by Uniswap Labsuniswap/uniswap-ai233 stars
39

Security-first Uniswap v4 hook development. Use when user mentions "v4 hooks", "hook security", "PoolManager", "beforeSwap", "afterSwap", or asks about V4 hook best practices, vulnerabilities, or audit requirements.

Use this Skill: https://skilld.dev/gh/uniswap/uniswap-ai/v4-security-foundations

This session only. Nothing lands on disk.

referencesaudit-checklist.md

≈2.1k tokens on demand. Your agent reads this file only when SKILL.md points to it.

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 functionality
  • Griefing attacks considered

6. Input Validation

6.1 Parameter Validation

  • All external inputs validated
  • hookData properly decoded and validated
  • No assumptions about parameter ranges
  • Overflow/underflow protection (Solidity 0.8.x or SafeMath)

6.2 Pool Key Validation

  • Hook is authorized for the pool
  • Currency addresses validated
  • Fee tier validated if relevant

7. State Management

7.1 Storage

  • No sensitive data stored on-chain
  • Storage slots don't collide (if using assembly)
  • Transient storage used appropriately
  • Storage variables initialized correctly

7.2 State Transitions

  • All state transitions have valid preconditions
  • No invalid intermediate states possible
  • State can be recovered from errors

8. Upgrade Safety (if applicable)

8.1 Proxy Patterns

  • Upgrade mechanism is access-controlled
  • Timelock or governance required for upgrades
  • Storage layout documented
  • Upgrade path tested

8.2 Migration Safety

  • Old state can be migrated to new implementation
  • No loss of funds during migration
  • Rollback plan exists

9. Testing Requirements

9.1 Unit Tests

  • Every public/external function tested
  • Every require/revert condition tested
  • Edge cases tested (zero amounts, max values, etc.)
  • All code paths covered

9.2 Fuzz Testing

  • Foundry fuzz tests for all state-changing functions
  • Minimum 10,000 fuzz runs
  • Custom fuzz invariants defined
  • No failures in extended fuzzing

9.3 Invariant Testing

  • Core invariants defined and tested
  • Delta accounting invariants tested
  • Balance invariants tested
  • Access control invariants tested

9.4 Integration Testing

  • Fork tests against mainnet state
  • Tests with real pool addresses
  • Tests with various token types
  • End-to-end swap flow tested

10. Static Analysis

10.1 Automated Tools

  • Slither analysis completed (all findings addressed)
  • Mythril analysis completed
  • Solhint linting passed
  • Custom detectors for v4-specific issues

10.2 Manual Review

  • Line-by-line code review completed
  • Business logic reviewed against specification
  • Comparison with similar audited hooks

11. Documentation

11.1 Code Documentation

  • NatSpec comments for all public functions
  • Complex logic explained in comments
  • Assumptions documented

11.2 External Documentation

  • Architecture diagram
  • Threat model document
  • Deployment procedure
  • Emergency procedures

12. Deployment Preparation

12.1 Pre-Deployment

  • Hook address mined with correct permission bits
  • Constructor parameters verified
  • Deployment script reviewed and tested
  • Gas estimation for deployment

12.2 Post-Deployment

  • Verify source code on block explorer
  • Verify permissions match expected
  • Test transaction on mainnet
  • Monitoring and alerting configured

Audit Sign-Off

Role Name Date Signature
Lead Auditor
Security Reviewer
Code Owner

Risk Assessment Summary

Category Risk Level Notes
Access Control
Delta Accounting
Reentrancy
DoS
Upgrade Safety
Overall

Findings Log

ID Severity Description Status Resolution

Audit Tier Guidelines

Based on risk assessment, determine required audit level:

Tier 1: Self-Audit (Risk Score 0-5)

  • Internal code review
  • Full test coverage
  • Static analysis tools

Tier 2: Peer Audit (Risk Score 6-12)

  • Tier 1 requirements
  • External developer review
  • Extended fuzz testing

Tier 3: Professional Audit (Risk Score 13-20)

  • Tier 2 requirements
  • Audit by security firm
  • Bug bounty program

Tier 4: Multi-Audit (Risk Score 21+)

  • Tier 3 requirements
  • Multiple independent audits
  • Formal verification considered
  • Extended bug bounty with significant rewards

Source: SKILL.md on GitHub

No alerts17d4 checks · Risk SAFE
  • Gen Agent Trust Hub17d

    The analyzed skill contains only educational material, security templates, and audit checklists for Uniswap v4 hook development. There is no executable code or scripts, and no security risks were identified.

  • Socket17d

    No alerts

  • Snyk17d

    Risk: LOW · No issues

  • Runlayer6mo

    2/4 files flagged

Signed by skilld at a718080. This ties the file your Agent reads to that commit on GitHub. It does not review the instructions.

Last checked against GitHub yesterday.

Activeupdated 8 months ago
What it can do
Reads files Network Runs commands
Modelopus
model
opus
metadata
{
  "author": "uniswap",
  "version": "1.1.0"
}
All 5 allowed tools
ReadGlobGrepWebFetchTask(subagent_type:Explore)

README badge

README badge for uniswap/uniswap-ai/v4-security-foundations