Correct SwingHook metadata and swap access classification

[Hooknomics]

Summary

This PR corrects the metadata and swap access classification for SwingHook on Ethereum.

Changes

• Replaces “lottery-style settlement” with “randomness-based settlement”.
• Adds the deployer address provided in the original submission.
• Changes swapAccess from governance to temporal.

Classification rationale

During Launch, swaps are restricted to the immutable SwingRouter and require non-empty hookData. This restriction is not controlled by an owner, administrator, or governance role.

The restriction is removed permanently when developmentUnlocked() becomes true, after either the 100 ETH reserve threshold or the 30-day time condition is reached. No privileged role can extend, modify, or restore it.

References

• Original submission: hook: SwingHook #1052
• Original PR: Add SwingHook hook on ethereum #1053
• Public source: https://github.com/Hooknomics/swinghook-smartcontract

[vercel]

@Hooknomics is attempting to deploy a commit to the Uniswap Team on Vercel.

A member of the Team first needs to authorize it.

[marktoda]

Maintainer verification (not an approval)

Because this PR is from an external contributor, the review GitHub Action (anthropics/claude-code-action) can't run for a read-only actor, so the required review status check cannot post SUCCESS and this PR is structurally unmergeable through the normal path regardless of content. Posting this as a manual source verification instead.

I verified against the on-chain verified Etherscan source at 0xad3cc8eb…40c8 (Solidity 0.8.29, src/SwingHook.sol).

On the swapAccess reclassification

Your premise is correct: governance is wrong. There is no owner/admin/governance flag — swingRouter is immutable, there are no owner setters (the source explicitly notes "There are no owner setters; wrong deployment parameters require redeployment"), and no Ownable/onlyOwner/tradingEnabled-style gate exists.

However, temporal is not the most accurate replacement. The check that beforeSwap actually enforces is an address allowlist, not a timestamp/block comparison:

// beforeSwap
if (ethSettlementVault.launchProtectionActive()) _requireSwingRouterAndHookData(sender, hookData);
// _requireSwingRouterAndHookData
if (sender != swingRouter) revert Errors.OnlySwingRouterDuringLaunch(sender);
if (hookData.length == 0)  revert Errors.HookDataRequiredDuringLaunch();

There is no block.timestamp/block.number comparison in this contract's swap gate. The one-way unlock (developmentUnlocked(), triggered by 100 ETH reserve OR 30 days) lives in the external ETHSettlementVault, and it's a hybrid threshold-OR-time condition, not purely temporal.

Per the registry's definition (swapAccess = the mechanism gating a swap in beforeSwap), the enforced check is a single-address allowlist. Recommend swapAccess: "allowlist" (or "other" if you'd rather characterize the hybrid auto-unlock). I'd ask you to change temporal → allowlist before this is mergeable.

Also worth correcting: requiresCustomSwapData

Currently false, but during launch protection an empty-hookData swap reverts (HookDataRequiredDuringLaunch()), and non-router callers are rejected. That matches the definition of requiresCustomSwapData: true for the live launch phase. Consider setting it true.

Confirmed correct in your PR

• Description reword (lottery → randomness-based settlement): factual, 289 chars, under the 500 limit. ✅
• deployer: 0x37f99BF9C2eb7Ba2D862E871B303634fF5658C91 matches the Etherscan contract creator. ✅
• dynamicFee: false (static 1% fee, no dynamic sentinel), upgradeable: false (no proxy/delegatecall/selfdestruct), vanillaSwap: false (beforeSwapReturnsDelta=true + custom delta accounting) — all correct. ✅

Summary: the governance → temporal direction is right (governance was wrong) but the target should be allowlist, and ideally set requiresCustomSwapData: true. This is a maintainer verification, not an approval; the review check remains a structural blocker for external PRs.