beforeInitialize sets the transient flag OPENING_TX and beforeAddLiquidity waives the 60-minute lock for every sender while that flag is set, i.e. for the whole remainder of the transaction that initialized the pool, not only for the factory or for the seeding step. The design accepts this so a factory that seeds through another contract works.

The residual exposure: if the launch factory's transaction hands execution to any address the payer controls after PoolManager.initialize (an ETH refund by call to the payer, a token callback, a post-launch notification), that code can add an IMD-only range beside the opening price inside the same transaction. That is exactly the route the lock was added to close in launch #1173 (sellers then convert the attacker's IMD into SVO at the opening price with no 50% buy fee).

Whether the real factory makes such a call could not be verified here (factory source not in this tree), so the severity is bounded to low and this is for the adapter and panel to confirm against the factory. A narrower exemption (factory sender, or a seeder the factory names in hookData) would remove the dependence on the factory's call graph; no source change was made.

afterSwap pays the fee by poolManager.take(IMD, vault, fee) in the middle of the swap, which lowers the manager's IMD balance. PoolManager.settle() credits balanceNow - balanceAtLastSync. A router that calls sync(IMD) and transfers its input before the swap and settles after it is credited input - fee and the unlock reverts CurrencyNotSettled, while the identical swap on a pool without this hook succeeds.

Sells (fee on the output side) and routers that sync after the swap (Uniswap's V4Router / Universal Router pattern) are unaffected. The README discloses the condition and states no delivered test exercises it; this finding supplies the reproduction. Impact is availability for that router class only, no loss of funds.

No source change was made; a fix that preserves the design is to document the required ordering in the manifest notes for integrators or to settle the fee via claims when a pre-synced balance is detected (a design decision for the author).

Commit 20c673e changed launch.json (pool.initialPrice from 45742400955009932534161870629490 to 79228162514264337593543950336, and the notes text) without regenerating the delivered attestation or the script that checks it.

Three things now disagree with the tree: (a) launch-attestation.json line 55 binds launch.json to sha256 77c83561..., while the committed file hashes to d3e79b3b5f16a242e236981ff5207f00fa22bec4bbcc7320eb817159d297f400; (b) launch-attestation.json line 23 records pool.initialPrice 45742400955009932534161870629490 while launch.json says 79228162514264337593543950336; (c) script/attest.py line 40 hard-asserts the old initialPrice, so python3 script/attest.py --check (the verification step README line 103 tells the deployer to run) raises AssertionError at build_record() before it even compares hashes.

The source hashes and the three creation-bytecode keccaks in the attestation DO match the current build (checked with forge inspect + cast keccak), so this is a provenance/documentation inconsistency, not a bytecode one. README line 17 is also stale: it still describes the manifest's indicative price as a 3,000 IMD cap with IMD as currency0, but 2^96 is a 1:1 sqrt price.

The service builds its own signed ReleaseAttestation, so this does not change what is deployed; it does mean the repository's own provenance check fails on the tree being launched, and anyone following README to verify the build gets a failure.

Fix: regenerate launch-attestation.json and update the asserted pool block in script/attest.py (and README line 17) for the committed manifest, or revert the manifest price to the attested value.

Access-control trust gap between the hook and the launch factory, which is outside this repository. beforeAddLiquidity admits an add during the first 3,600 s only when (a) the PoolManager's msg.sender is exactly the constructor's factory address, or (b) the transient flag set in beforeInitialize is still live, i.e. the add happens inside the initializing transaction. sender is the contract that calls PoolManager.modifyLiquidity, so a factory that seeds through a position manager or a helper in a separate transaction is refused as if it were an attacker, while the pool sits initialized and empty for an hour (an empty v4 pool's price can be moved to any limit by a zero-delta swap, README line 107).

Nothing in the repository can verify the real factory's seeding flow, and the manifest cannot express it. This is the same condition the manifest notes list as imported finding (2); it is restated here because it is the one remaining access-control path by which admission's deployer simulation can revert with LiquidityLocked on correct code.

Needed evidence before launch: confirmation that the launch factory adds the seed liquidity either from its own address or within the transaction that calls PoolManager.initialize. No source change is proposed; narrowing or widening the exemption is a design decision.

Flow-gap seam (execution x first principles). openedAt is written once in beforeInitialize (src/SovrnHook.sol:115) and both launchFeeNow() (lines 143-147: elapsed = block.timestamp - openedAt, elapsed >= DECAY ? NORMAL_FEE : ...) and the liquidity lock (line 138: block.timestamp < openedAt + DECAY) count from it. Nothing in the hook ties the clock to the first liquidity.

The brief's guarantee 'buys 50% at pool opening decaying linearly to 3.5% over 3,600 seconds' therefore holds only if the launch factory seeds the pool in the initializing transaction (or the same second).

If the factory initializes in one transaction and seeds from its own address later (which the lock permits: sender == factory), the opening window is partly or fully consumed before any buy can be filled: seeding 1800 s later gives the first buyer a 26.75% fee, seeding 3600 s later gives 3.5%, and the vault collects correspondingly less.

The repository cannot verify the real factory's flow; the manifest notes already require atomic seeding for the lock, and the same requirement is needed for the fee schedule. No unprivileged actor can trigger it, no funds are lost or misdirected, so this is informational: a deployment-flow precondition to record, not a source defect. Reproduced with a scratch test (src unchanged): both assertions below pass on the current code.

All four fee formulas (lines 179, 182-191, 239) use floor division, and the README states this ("Integer divisions round down"). The Math Precision guide asks that fees round up; here the vault under-collects by up to 1 wei of IMD per swap and collects nothing when the IMD leg is below 1/rate wei: 1 wei at the opening rate (0.5e18), 28 wei at the normal rate (0.035e18).

The exact-output sell quote at line 182 (gross = floor(requested * WAD / (WAD - rate))) and the charge at line 191 compose so that the trader always receives exactly the requested net (proved for requested in [1, 1e18] and every elapsed in [0, 7200] s, both currency orders, 2000 fuzz runs), so the only leak is the floor itself.

Per-swap loss is < 1 wei of IMD (1e-18 IMD) and a sub-29-wei swap costs far more in gas than the fee it avoids, so there is no exploitable value; reported for the record because it is the one place the arithmetic departs from the guide's rounding rule. No change is recommended for this launch.

Execution trace, buy with IMD as input. A router that pays before it swaps does poolManager.sync(IMD) (reserves R recorded), transfers its payment P to the manager (balance R+P), then poolManager.swap(). Inside that swap SovrnHook.afterSwap finds the manager's IMD balance >= fee and runs poolManager.take(IMD, vault, fee), which moves fee out of the manager while IMD is still the synced currency (PoolManager.take does not touch CurrencyReserves).

The router's poolManager.settle() then computes paid = balanceNow - R = P - fee and credits the router that much. The hook's own delta nets to zero (+fee from the hook delta, -fee from the take), but the router's IMD delta is short by exactly fee however large P is, and the unlock ends with CurrencyNotSettled.

Sending more IMD does not help: the shortfall is always the fee, because every wei above the debt is refunded by the router's own take and the fee was removed from the measured reserves. Sells are unaffected (SVO is the synced currency while the IMD fee is taken) and swap-then-settle routers (v4 Router, Universal Router with SWAP, SETTLE_ALL, TAKE_ALL) work, which the two control tests show.

The claim path (mint) is only used when the manager's balance is below the fee, so a pre-paid buy, which raises the balance, always goes through the direct take.

Impact: every buy through a pre-paying integration (a router or aggregator adapter that settles its input first, or a contract that holds IMD claims-free and settles before swapping) reverts; no funds are lost. The author notes this as a router constraint (manifest notes item 3 and the README) and it is reported here with a reproducing test because the reviewed area is the swap execution path and nothing in the suite exercises a sync-before-swap order.

Cross-transaction execution trace of beforeAddLiquidity. The exemption has exactly two legs: the modifyLiquidity caller is the constructor's factory address, or the transient flag written by beforeInitialize is still set, which is only true inside the transaction that called PoolManager.initialize. Any other (sender, transaction) pair is refused with LiquidityLocked for 3600 seconds after openedAt.

The launch factory's seeding flow is not in this repository. If it adds the opening liquidity from its own address, or in the same transaction as initialize through any contract, the lock is transparent.

If it initializes in one transaction and seeds in a later one through a position manager or any helper whose address is not the $factory argument, that seeding reverts and the pool stays empty for an hour, during which any swap against the empty pool moves sqrtPriceX96 to the caller's price limit at zero cost (both deltas zero, no fee), so the opening price the factory set is not preserved. Removal is never blocked.

The author documents this constraint (README, manifest notes item 2); it is listed here because it is the one remaining path by which this exact source can stall at the deployer, and whether it is hit depends on the factory's order of calls, which must be confirmed from the factory before the launch transaction is sent.

Commit 20c673e (the manifest assignment) changed launch.json pool.initialPrice from 45742400955009932534161870629490 to 79228162514264337593543950336 (line 29) and rewrote the notes.

The committed launch-attestation.json (line 23) and the assertion in script/attest.py build_record (lines 37-41) still hold the old value, so the record the README step 4 points reviewers at describes a pool block that no longer matches the manifest, and the repository's own reproducibility check fails before it compares any artifact.

Source hashes in the record still match src/ (SovrnHook 512aae25..., LifeForceVault 7060791f..., SovrnToken 3632f774..., Interfaces aca1fa33...).

No deployment impact: the service signs its own ReleaseAttestation and the hook accepts any opening price (the manifest price is indicative; the factory sets the real one).

Fix outside src/: regenerate launch-attestation.json and the attest.py assertion for the new manifest, or restore the previous price in launch.json.

Merged from audit_flow (06830bf5). A router that pays its input before swapping does sync(IMD), transfers P to the manager, then swap(). Inside that swap afterSwap finds the manager's IMD balance >= fee and runs take(IMD, vault, fee) while IMD is still the synced currency; PoolManager.take does not touch CurrencyReserves, so the router's later settle() measures paid = balance - reserves = P - fee.

The hook's own delta nets to zero (+fee hook delta, -fee take) but the router's IMD delta is short by exactly the fee however large P is, and the unlock ends with CurrencyNotSettled. Sells are unaffected (SVO is the synced currency while the IMD fee is taken) and swap-then-settle routers (v4 Router, Universal Router SWAP/SETTLE_ALL/TAKE_ALL) work. The claim (mint) fallback is only chosen when the manager's balance is below the fee, which a pre-paid buy never is.

Impact: every buy through a pre-paying integration reverts; no funds are lost, and the author documents it as a router constraint (manifest notes item 3, README). It is a compatibility limitation of the accepted design, not a loss path, so it is kept at low; it does not block admission. A fix outside this launch would mint the fee as a claim whenever IMD is the synced currency, or take it after settlement.

Merged from audit_permissions (479c17e8), audit_flow (c12a95f1) and audit_economics (1aafa3f7): one root cause, three consequences. beforeInitialize writes openedAt = block.timestamp (line 115) and sets a transient flag; beforeAddLiquidity admits an add during the first 3,600 s only when the modifyLiquidity caller is exactly the constructor's factory address or the transient flag is still live (same transaction as PoolManager.initialize).

(a) A factory that initializes in one transaction and seeds in a later one through a position manager or helper whose address is not $factory is refused with LiquidityLocked for an hour, while the empty pool's price can be moved to any limit by a zero-delta, zero-fee swap.

(b) launchFeeNow() and the lock both count from openedAt, not from the first liquidity, so if the factory seeds from its own address later, the opening window is consumed before any buy can be filled (seeding at +1800 s gives the first buyer 26.75%, at +3600 s 3.5%). (c) Inside the initializing transaction every sender is exempt, so any contract the factory calls after initialize (a contributor callback, a helper) could add an IMD-only range beside the price.

None of this is triggered by an unprivileged actor and no funds are lost or misdirected; whether any of it is hit depends solely on the launch factory's order of calls, which the repository cannot show and the manifest cannot express. The author documents the constraint (README line 86 'Deployment, initialization and initial liquidity seeding must be atomic', manifest notes items 1 and 2).

Kept at low as a deployment precondition to confirm from the factory before the launch transaction is sent; if the factory initializes and seeds from its own address in one transaction, as the reference describes, every consequence is moot. No source change proposed.

Merged from audit_permissions (0847dc2c) and audit_flow (adb223b3).

Commit 20c673e changed launch.json (pool.initialPrice from 45742400955009932534161870629490 to 79228162514264337593543950336 and the notes text) without regenerating the attestation or the check script. launch-attestation.json line 55 binds launch.json to sha256 77c83561..., but the committed file hashes to d3e79b3b5f16a242e236981ff5207f00fa22bec4bbcc7320eb817159d297f400; line 23 records the old initialPrice; script/attest.py line 40 hard-asserts the old pool block, so the verification step README line 103 tells the deployer to run raises AssertionError before comparing any artifact.

Everything else in the record still matches the tree: the five src/ sha256 hashes and the three creationBytecodeKeccak256 values (SovrnToken 0xd0c3bc18..., SovrnHook 0xf78b7a97..., LifeForceVault 0x6e583423...) equal forge inspect bytecode | cast keccak on the current build. The service signs its own ReleaseAttestation, so nothing deployed changes and the hook accepts any opening price; this is a provenance/documentation inconsistency in files this task may not edit.

Fix outside src/: regenerate launch-attestation.json and the asserted pool block in script/attest.py for the committed manifest.