vAPI Network

Treasury and fee redemption outside the boundary: treasury is an owner-set address, validated only against the zero address, the hook itself, the PoolManager, and registry members. Because remediation credits fees as ERC-6909 claims on the PoolManager, realising them requires the treasury to burn those claims inside a PoolManager unlock, which an EOA or Safe can only do by authorising a redeemer contract through IERC6909Claims.setOperator. Neither the treasury account nor any redeemer contract is part of this review, so whether collected fees can be withdrawn, and in which currency the treasury is able to hold them, rests on configuration outside the audited boundary.

Uniswap V4 BaseHook and PoolManager dependency: FeeHook inherits BaseHook from v4-periphery, binds to IPoolManager from v4-core, and routes fees exclusively through poolManager.take inside _collectFee, which remediation replaced with poolManager.mint in both variants. Pool acceptance, swap deltas, and fee extraction rely on that external callback framework (getHookPermissions, _beforeInitialize, _beforeSwap, _afterSwap). Defects, unavailability, or currency-accounting changes in the Uniswap V4 hook or PoolManager path would directly affect fee charging, launch-guard enforcement, and delivery to treasury.

Coupling to Uniswap V4 swap lifecycle: Swap fees and launch-guard checks execute only inside Uniswap V4 pool callbacks for pools that pass _beforeInitialize registry checks (allowedTokens, allowedPairs, poolFeeToken). Ordinary ERC-20 transfers of Token are untaxed; all fee and antisnipe behavior is inseparable from V4 pool initialization and PoolManager.swap caller semantics (sender is the router contract, not the end-user EOA).

Fixed total supply determined at construction: Token defines TOTAL_SUPPLY as the constant 100_000_000e18 and mints that entire amount once in the constructor to the recipient parameter, with no subsequent mint path. Name, symbol, and initial holder are constructor inputs; after deployment, circulating supply can only decrease through ERC20Burnable burns. Misallocation of the initial recipient or incorrect name/symbol at deploy time is permanent for the minted supply distribution.

Owner-managed fee and launch caller allowlists: FeeHook maintains feeExempt and launchCallerAllowed, both writable only by the owner via setFeeExempt and setLaunchCallerAllowed. feeExempt causes an early return at the top of _beforeSwap (and skips fee charging in _afterSwap), so an exempt V4 sender pays no fee and is also never launch-gated. A non-empty launchCallerAllowed registry (launchAllowedCallers != 0) restricts buys while launchGuardActive is true; an empty registry disables only that caller gate, while any configured priority-fee floor or cap still applies. Incorrect exemption of a public router enables fee-free and guard-free swaps for all users of that router.

Immediate owner control without on-chain delay: The FeeHook owner can call setFee, setTreasury, setFeeThreshold, setFeeExempt, setTokenAllowed, setPairAllowed, setFeeRange, setLaunchCallerAllowed, endLaunchGuard, and lockLists in the same transaction that invokes each setter, with no on-chain timelock. setLaunchGuard is likewise immediate when callable, but only before the token's first accepted pool and only once. Fee rate (up to MAX_FEE), treasury destination, per-token shutoff thresholds, registry membership until lock, and global priority-fee bounds therefore take effect with no mandatory notice window. After launch, mid-flight reshaping of gating is limited to setFeeRange, setLaunchCallerAllowed, and one-way endLaunchGuard, not re-arming the buy budget.

Multi-sig recommended but not enforced: Constructor NatSpec for FeeHook recommends a Safe multisig as _owner, yet the contract accepts any non-zero address and performs no on-chain multi-signature or threshold check. Deployment may therefore leave fee, treasury, registry, and launch-guard powers under a single EOA. Off-chain custody choices cannot be verified from the in-scope bytecode alone.

Single administrative point of failure on FeeHook: Operational control of allowed tokens and pairs, fee rate, treasury, fee exemptions, launch-guard budgets, launch callers, and priority-fee range concentrates in the FeeHook owner. Loss, coercion, or compromise of that key or controlling contract can halt intended administration or force adversarial reconfiguration of all listed pools' fee and launch behavior. Token itself exposes no post-deployment admin surface.

Owner key liveness as ongoing dependency: renounceOwnership on FeeHook is overridden to revert with RenounceDisabled, so ownership cannot be burned away. Continued correct operation of fee updates, treasury rotation, and optional early endLaunchGuard therefore requires the owner key or owner contract to remain available and uncompromised for the lifetime of mutable configuration.

Count-based antisnipe budget can be burned by dust buys: Each token's launch guard is armed once via setLaunchGuard with a fixed launchGuardBuys budget; successful non-exempt buys that pass _checkLaunchBuy increment launchBuyCount until the budget is exhausted or endLaunchGuard ends it. Rejected buys revert and do not consume budget, but successful minimal buys through an allowed caller permanently advance the counter. A determined actor can exhaust the guard at gas, tip, and dust cost, after which priority-fee and caller checks permanently cease for that token.

One-way freezes and permanent guard termination: lockLists permanently sets listsLocked, after which setTokenAllowed and setPairAllowed always revert with ListsFrozen. endLaunchGuard sets launchGuardEnded for a token and cannot be undone; setLaunchGuard is set-once and unavailable after tokenHasPool is true. Premature locking freezes the registry against future tokens or pairs, and premature guard termination removes antisnipe protections with no re-arm path.

Partial fills rejected on the fee-specified swap path: When the fee currency is the swap's specified currency, _beforeSwap charges fee on the full requested amountSpecified, and _afterSwap reverts PartialFillNotSupported unless the realised specified-side delta matches that amount plus the fee. A fill an unmodified V4 pool would truncate is therefore rejected outright, which is protective rather than a defect, since V4 applies an _afterSwap return delta to the unspecified currency and the pre-charge cannot be refunded. The protected cells follow the fee side, so the pair-side variant moves the rejection onto exact-input buys, the ordinary retail path, where a buy exceeding pool depth reverts even under the canonical router's unbounded price limit. The contract NatSpec documents the behavior, the retail-path consequence included.