Approved workflow

The hook only acts on the single pool whose key is (ETH, HIRING, poolFee, 60, hooks = this hook); every other key is rejected by authenticated with WrongPool (line 63). The approved launch creates the pool through ProjectFactory with the factory-supplied PoolInitializationGuard as the pool's hook (initialization-only, no swap callbacks).

A v4 pool key carries exactly one hook address and the key is hashed into the pool id, so deploying HiringFreezeHook as an application contract does not attach it to the launch pool and it cannot be attached afterwards.

The brief's only required behaviour, 'on every swap on this launch's pool 1% of the HIRING side goes to dEaD', therefore never executes on the pool the factory seeds, totalBurned() stays 0 and the site's 'tokens laid off' counter is permanently zero (or, worse, counts a separate unofficial pool anyone may initialise with the hook's key at any price).

The builder disclosed this in README/DEPLOYMENT.md; it is still an unresolved blocking conflict between the accepted source and the launch policy. Needed evidence before admission: a service-approved path that initialises the launch pool with hooks = HiringFreezeHook (and seeds liquidity in the same transaction), or a requester decision that the burn is dropped and the README/site stop advertising it. No manifest field can express this; it is a policy/factory gap.

Hooks.validateHookPermissions reverts with HookAddressNotValid unless uint160(address(this)) & 0x3fff == 0x20cc, i.e. the deployment address must be mined (1 in 16384 salts). The factory deploys application contracts with salts chosen by the service (the protected floor reads IMD_PROJECT_SALT_i from the environment) and the LaunchManifest schema has only contract and constructorArgs per entry, so neither the manifest author nor this source can pin a salt.

Unless the deployer's salt derivation is extended to search for the 0x20cc suffix against the exact factory address and keccak256(creationCode ++ abi.encode(manager, token, fee)), the hook constructor fails, ProjectDeploymentProbe.deploy reverts with 'project constructor failed', and the whole launch transaction reverts.

Needed evidence: confirmation from the deployer that it mines hook-compatible salts for this contract, or the hook cannot be listed in contracts at all.

Trust gap (access x asymmetry): the only pool HiringFreezeHook will act on is the one whose key has hooks == address(this) (line 69, hashed into the immutable poolId at line 56 and enforced by authenticated at line 63). The canonical launch path (evm-project-launch guidance) opens exactly one pool for the launch token and sets that pool's hook to the factory-supplied PoolInitializationGuard, which has no swap callbacks.

A Uniswap v4 pool key carries a single hook address, and the hook address is part of the pool id, so the launch pool and the hook's pool are two different pools. Deploying HiringFreezeHook as an application contract therefore attaches nothing to the pool the frontend, the deployer and the admission check describe.

The approved requirement 'On every swap, 1% of the HIRING side is permanently removed' is not enforced by any deployed code, the totalBurned counter the site must display stays at 0, and because both the hook and the guard pool are immutable there is no post-deployment repair. The builder's README and docs/DEPLOYMENT.md already record this conflict; it remains an unresolved blocking item for the launch, not something the Solidity author can fix in source.

Needed evidence/decision from services: either an approved factory path that uses HiringFreezeHook (deployed at a mined address, constructed with the real PoolManager and the real pool-key fee) as the launch pool's hook, or an explicit decision to launch without the burn and to remove the burn claim from the brief, README and site.

No Foundry proof is attached: a test asserting the burn on a guard-keyed pool fails today and can only be made to pass by a change outside this source tree (changing the factory's pool key) or by a transfer-tax token, which the launch rules forbid.

Trust gap between the source and the deployment inputs. Uniswap v4 only invokes callbacks whose permission bits are encoded in the hook address, so the constructor correctly calls Hooks.validateHookPermissions and reverts with HookAddressNotValid for any address whose low 14 bits are not 0x20cc.

The LaunchManifest schema for contracts entries has only contract and constructorArgs; there is no salt field, and the protected Project floor takes IMD_PROJECT_SALT_i from the service.

Unless the deployment service derives a salt by searching against the exact factory address and keccak256(creationCode ++ abi.encode(manager, token, fee)), the probability that an arbitrary salt yields a valid address is 1/16384, and the factory's single launch transaction reverts at the hook constructor, taking the token deployment and pool creation with it. Changing any constructor argument, compiler setting or deploying factory invalidates a mined salt.

Needed evidence: the service's salt-derivation for this launch (and the protected floor's IMD_PROJECT_SALT_0) shown to produce an address with & 0x3fff == 0x20cc for the final creation code and arguments. This is a service/configuration gap; removing the validation in source is not a fix because the pool manager would then silently skip the callbacks.

Asymmetry between the manifest's view of the pool and the hook's immutable view. The hook hashes fee into poolId (lines 55-56) and rejects any other key with WrongPool (line 63). The launch guidance says the manifest's pool.fee stays 3000 for admission while the pool itself opens at the network trading fee read from the chain's LaunchFees contract (1.25% = 12,500 millionths by default, and changeable on chain).

The hook's fee is a constructor argument chosen at manifest time, so it is fixed before the factory reads LaunchFees.

If the manifest copies the schema value 3000, or LaunchFees changes between manifest and deployment, then (a) if the hook is ever attached as the pool's hook, the factory's PoolManager.initialize -> beforeInitialize reverts WrongPool and the entire launch transaction fails; (b) if it is not attached (finding 1), the hook is bound to a pool key that is never created. The project tests assume 12_500 but nothing binds that assumption to the chain.

Needed evidence: the final manifest constructorArgs fee value shown equal to the fee the factory will actually place in the launch pool key at deployment, from the target chain's LaunchFees.

Flow gap (execution x periphery x first principles). The brief's only application behaviour is 'on every swap on this launch's pool, 1% of the HIRING side goes to DEAD'. A Uniswap v4 pool is identified by its full key, and the key has exactly one hooks address.

The canonical launch guidance says the factory initialises and seeds the launch pool with its own initialization-only PoolInitializationGuard as the hook and makes no further calls.

HiringFreezeHook binds its poolId to a key whose hooks field is address(this) (line 69) and reverts WrongPool for any other key, so deploying it as an application contract produces an orphan contract: the factory pool (ETH, HIRING, fee, 60, PoolInitializationGuard) has no swap callbacks and never burns, while the hook's own pool (ETH, HIRING, poolFee, 60, HiringFreezeHook) is a second, unseeded pool that anyone may initialise and seed.

The website's 'tokens laid off' counter (hook.totalBurned()) therefore stays at 0 for all trading on the launch pool, and the site would misrepresent the launch. A second binding gap compounds this: the constructor's fee argument fixes the key's fee, the manifest fee for admission is 3000, and the pool actually opens at the LaunchFees rate (12,500 by default); a hook built with 3000 keys a third pool.

The builder's README and docs/DEPLOYMENT.md already flag this conflict; it is recorded here as a blocking review finding because no manifest, policy or factory path in the supplied material attaches a swap hook to the launch pool. No in-repo Solidity change can fix it: either the platform provides an approved path to make HiringFreezeHook the launch pool's hook (and mine its address, see finding 2), or the launch ships without the burn and the README/site must say so.

That is a scope decision for the requester, so no proof test is attached (no fix in src/ would make one pass).

Deployment-time economic/flow gap. Uniswap v4 encodes hook permissions in the hook's address; validateHookPermissions reverts HookAddressNotValid unless address & 0x3fff == 0x20cc (beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta). Only 1 in 16,384 CREATE2 salts satisfies this.

The launch manifest schema carries no salt field (contracts items are {contract, constructorArgs} only), and the canonical guidance says the factory deploys every application contract in one transaction from its own salt derivation.

Unless that derivation specifically mines for these bits against keccak256(creationCode ++ abi.encode(manager, token, fee)) and the factory address, the hook's constructor reverts, the ProjectDeploymentProbe/factory requires deployed != 0, and the whole launch transaction (token, pool, distributor and all contracts) fails.

The project floor test (Project.protected.t.sol setUp, 'project constructor failed') would also fail for the service-supplied IMD_PROJECT_SALT_0. docs/DEPLOYMENT.md item 2 names this; it is a concrete constructor conflict for the manifest/service stage.

There is no Solidity fix that keeps the hook (v4 requires the address bits); the needed evidence is a factory/service salt-mining path for this exact init-code hash and deployer, or the hook must be dropped from the contracts list. No proof test is attached for that reason.

Area: boundary (pool-key identity). The approved workflow requires that every swap on this launch's pool burns 1% of the HIRING side. The hook authenticates the complete pool key, including hooks = address(this), and derives its immutable poolId from it (line 56).

The canonical launch guidance says the factory supplies PoolInitializationGuard as the pool's hook and that the project must not list it. A v4 PoolKey has exactly one hooks address, and changing it changes the pool id.

Therefore the pool the factory initializes and seeds (currency0 = ETH, currency1 = $token, fee = LaunchFees value, tickSpacing = 60, hooks = PoolInitializationGuard) has a different id from hook.poolId(), the PoolManager never invokes HiringFreezeHook for that pool, totalBurned stays 0 and TokensLaidOff is never emitted. Deploying HiringFreezeHook as an application contract does not attach it; it also cannot be attached later because the pool id is immutable.

The builder's README (line 5) and docs/DEPLOYMENT.md (item 1) already flag this as unresolved. It is the single concrete conflict between the accepted source and the launch path, and it decides whether the brief's core feature exists at all. Required evidence before release: an approved launch path whose actual pool key names the deployed HiringFreezeHook address as hooks, or an explicit decision that the launch ships without the burn and the site displays it as unavailable.

Area: boundary (constructor input vs. external pool state). The hook's third constructor argument is the static fee that must appear in the pool key, and it is baked into poolId. The launch guidance gives two different fee numbers: the manifest's pool.fee stays 3000 for admission, while the pool itself opens at the network's trading fee read from LaunchFees (12,500 by default, and changeable on chain before the deployment executes).

Only one value can be in the actual PoolKey. If the manifest writer passes 3000 (matching pool.fee) and the factory initializes with 12,500, or vice versa, beforeInitialize reverts WrongPool inside Hooks.callHook, PoolManager.initialize reverts with WrappedError(hook, beforeInitialize.selector, WrongPool, HookCallFailed), and the launch transaction fails. If the pool is initialized with a different hook (finding 1) the hook is simply orphaned.

Nothing in the hook or the protected floor validates the constructor fee against the chain, so this is a manifest/constructor input the independent review must pin to the exact fee the factory will use at execution time, read from LaunchFees on the target chain, not from pool.fee. The project tests use 12,500 and docs/DEPLOYMENT.md item 3 names the ambiguity but does not resolve it.

Second-round settlement of finding f47c3e03 (merged root cause of audit_economics #1, audit_flow #1, audit_permissions #1, audit_math #1). The author's answer is accurate on every factual point and I accept it: the burn is absent, a manifest-only revision cannot attach a swap hook to the factory's guard-keyed pool, and the manifest writer has no authority to invent a service path or waive the brief. None of that closes the finding.

The tree I am reading is unchanged in src/ (HiringFreezeHook.sol lines 53-69 and 138 are byte-identical to last round) and launch.json still has "contracts": [] with token.contract = LaunchToken; only the notes paragraph grew. The approved workflow's sole application requirement is 'a Uniswap v4 hook on this launch's pool called HiringFreezeHook. On every swap, 1% of the HIRING side is permanently removed'.

With this manifest the factory opens one pool keyed on PoolInitializationGuard (no swap callbacks), deploys no hook, and the 'tokens laid off' counter the site must show has no contract to read. The pool key is hashed into the pool id and immutable, so there is no post-deployment fix. Notes carry no deployment authority.

This therefore remains a blocking requirements/policy conflict, not a Solidity defect, and no Foundry proof is attached because no change under src/ can make a guard-keyed pool call the hook (my control test shows the same hook does burn when it is the key's hook).

What closes it, exactly as stated last round: (a) a service-approved launch path that places the deployed HiringFreezeHook (mined to bits 0x20cc, constructed with the verified target-chain PoolManager and the exact fee the factory writes into the key) in the launch pool key and initialises and seeds that pool atomically, after which launch.json must list the hook with constructorArgs [, "$token", ] and findings 2-6 below become binding; or (b) an explicit requester decision to launch without the burn, with the brief, README and site changed to stop claiming it.

Neither is evidenced in the inputs to this round. Admission must not treat the current manifest as fulfilling the approved workflow.