Add SwingHook hook on ethereum

[hooklist-generator]

Summary

A Uniswap v4 hook for an ETH/SWING token pool that applies a custom fee delta in beforeSwap for buy-side trades and validates min-output and authorizes settlement in afterSwap. Supports two trade modes via optional hookData: standard Uniswap swaps and Swing-specific swaps that create randomness-based tickets for lottery-style settlement via an external randomness manager.

Flags

Flag	Value
beforeInitialize	false
afterInitialize	false
beforeAddLiquidity	false
afterAddLiquidity	false
beforeRemoveLiquidity	false
afterRemoveLiquidity	false
beforeSwap	true
afterSwap	true
beforeDonate	false
afterDonate	false
beforeSwapReturnsDelta	true
afterSwapReturnsDelta	false
afterAddLiquidityReturnsDelta	false
afterRemoveLiquidityReturnsDelta	false

Properties

Property	Value
dynamicFee	false
upgradeable	false
requiresCustomSwapData	false
vanillaSwap	false
swapAccess	governance

Warnings

• Submitter-proposed description rejected: claims "Chainlink VRF" which is not explicitly stated in the verified source (only a generic "VRF coordinator" interface is present). Using AI-generated description.

Closes #1052

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hooklist	Ready	Preview, Comment	Jul 11, 2026 8:52am

[github-actions]

SwingHook Review — hooks/ethereum/0xad3cc8eb9d34abeb3b0ca9b98cbfd3837b7d40c8.json

Address Flag Verification

Lower 14 bits of 0xad3cc8eb9d34abeb3b0ca9b98cbfd3837b7d40c8: 0x40c8 & 0x3FFF = 0x00C8 → binary 00 0000 1100 1000

Bit	Flag	Address	Hook File
13	beforeInitialize	0	false ✓
12	afterInitialize	0	false ✓
11	beforeAddLiquidity	0	false ✓
10	afterAddLiquidity	0	false ✓
9	beforeRemoveLiquidity	0	false ✓
8	afterRemoveLiquidity	0	false ✓
7	beforeSwap	1	true ✓
6	afterSwap	1	true ✓
5	beforeDonate	0	false ✓
4	afterDonate	0	false ✓
3	beforeSwapReturnsDelta	1	true ✓
2	afterSwapReturnsDelta	0	false ✓
1	afterAddLiquidityReturnsDelta	0	false ✓
0	afterRemoveLiquidityReturnsDelta	0	false ✓

Confirmed by getHookPermissions() which sets only beforeSwap, afterSwap, and beforeSwapReturnDelta to true.

Properties Verification

• dynamicFee: false ✓ — lpFeeOverride is always returned as zero; fee capture uses BeforeSwapDelta custom accounting (beforeSwapReturnsDelta), not a dynamic LP fee override. No call to poolManager.updateDynamicLPFee().

• upgradeable: false ✓ — No proxy pattern, no delegatecall, no mutable implementation storage, no SELFDESTRUCT. All dependencies set in the constructor as immutable. source_meta.json confirms "proxy": false.

• requiresCustomSwapData: false ✓ — _buildV4BuyContext and _buildV4SellContext both handle hookData.length == 0 gracefully when launchActive == false, falling through to UniswapBuy/UniswapSell mode without reverting. Post-launch, empty hookData is fully functional.

• vanillaSwap: false ✓ — beforeSwapReturnsDelta: true mandates this per review rules. Additionally, the hook computes and captures a fee delta in beforeSwap for UniswapBuy trades via BeforeSwapDeltaLibrary.toBeforeSwapDelta.

• swapAccess: "governance" ✓ — During launch protection, swaps are gated by ethSettlementVault.launchProtectionActive(), a boolean flag managed by the vault admin/owner. This fits the "governance" classification (boolean flag set by an owner/admin, analogous to tradingEnabled). Once deactivated, all swaps are unrestricted.

Metadata Verification

• verifiedSource: true ✓ — Confirmed by source_meta.json: "verified": true.
• chainId: 1 ✓ — Ethereum mainnet.
• name: "SwingHook" ✓ — Exact contract name from source (contract SwingHook) and source_meta.json ("contractName": "SwingHook").
• description ✓ — Factually accurate. Correctly describes the ETH/SWING pool, the custom fee delta in beforeSwap for buy-side trades, min-output validation and settlement authorization in afterSwap, dual trade modes (Uniswap and Swing), and lottery-style ticket settlement via the external IRandomnessManager. No marketing language, audit claims, or unsubstantiated assertions.

[Hooknomics]

Thanks for the review. The generated summary is generally accurate, but could “lottery-style settlement” be replaced with “randomness-based settlement” to better reflect the protocol’s function?

Could you also please confirm the vanillaSwap: false and swapAccess: governance classifications? SwingHook supports standard Uniswap swaps after the Launch-stage restriction is lifted, and the hook has no owner, governance role, upgrade function, or pause function.

[Hooknomics]

Thanks for the review. Could “lottery-style settlement” be changed to “randomness-based settlement”? This describes the mechanism more accurately without changing its technical meaning.

Could you also confirm whether swapAccess: governance refers to the temporary Launch-stage router restriction? The hook has no owner, governance role, upgrade function, or pause function.