I found no defects in the math area (Math Precision, Boundary and Numerical Gap), so .imd-findings.json has an empty findings list. It also has a coverage row for each of the three listed entry points and for five extra checks. I changed no other files. forge test passes all 22 tests.

What I checked:

• ConditionalsToken is OpenZeppelin's ERC20 with no changes.
  • INITIAL_SUPPLY = 1_000_000_000 * 10**18 comes to exactly 1e27. That matches the configured totalSupply string and 18 decimals.
  • The whole supply is minted once, to the deployer (the launch factory). The token has no later mint, burn, fee or rounding.
  • The math in transfer and transferFrom can't overflow: balances are checked before they are reduced, and the unchecked additions can never exceed the 1e27 total supply.
  • transferFrom checks the allowance before reducing it, and a maximum allowance is treated as unlimited. A reverted call leaves no partial changes.
  • The name and symbol are passed through exactly as Conditionals / CONDITIONALS (12 characters). Nothing in the contract caps or shortens the symbol.
• ConditionalsHook does no price, tick or fee math. beforeInitialize accepts any opening price and the 12500 pool fee. It only checks that the caller is the PoolManager, then returns the correct selector. Its permission bits (0x2000) match what getHookPermissions declares.
• HookFlags is a plain mask over the 14 low bits, with no casts that could lose bits.
• tools/prepare_launch.py (an off-chain helper, outside the Solidity scope) adds cost amounts as exact integers per currency. It rejects mismatched decimals and anything that isn't an unsigned whole number, and formats amounts correctly.

Not a code defect, but worth knowing: the brief contradicts itself. It says the symbol must be exactly CONDITIONALS, then lists Token symbol: CONDITIONAL. The code and review/conditionals-review.json use CONDITIONALS. config/policy-baseline.json deliberately keeps CONDITIONAL as the "before" value.

Not covered: I did not check whether the launch form or deployer accepts a 12-character symbol, or the deployment cost, because no quote or system validation is in the repo. Those sit outside this code.

I wrote launch.json, and it's the only file I changed. Nothing has been paid, quoted or deployed: this job only writes the manifest. So I can't give you the total cost, or the token address, hook address, pool ID and transaction links, yet. Those come from later steps.

The symbol is exactly CONDITIONALS (12 characters). Your brief also has a line saying Token symbol: CONDITIONAL, which conflicts with the explicit instruction not to shorten it. I followed the explicit instruction, and the token contract in the repo already uses CONDITIONALS. The contract has no length limit on the symbol, but the launch system itself still has to confirm it accepts 12 characters. If it doesn't, the launch should stop rather than shorten it.

What the manifest says

• Hook: ConditionalsHook. Its only setup input is the chain's pool manager ("$poolManager"). Its only permission is beforeInitialize, which matches what the contract declares. It only accepts calls from the pool manager and doesn't restrict the fee. It has no owner, no fee of its own and holds no funds.
• Token: ConditionalsToken, name Conditionals, symbol CONDITIONALS, 18 decimals. Its constructor takes no arguments and mints 1 billion tokens ("1000000000000000000000000000" in the smallest unit) once, to the launch factory.
• Pool: paired with IMD at 0x5f7bb59365ce557c26dbcaa4ee9d39a4b95b7127, fee 12500 (1.25%), tick spacing 60, initial price 79228162514264337593543950336 (one to one).
• Everything else is unchanged: supply, allocation, hook behaviour, fees, recipients and permissions. The manifest has no allocation or ownership fields; those come from the launch policy.

Checks: forge build and forge test with the required fuzz seed both pass, 22 of 22 tests. I also ran the protected Hook and token tests in a scratch folder, filling in this launch's values myself; all 14 passed. To get the Hook test to compile there, I changed one fail(...) call to revert(...), because the repo's version of the test library doesn't support it. The verifier will run these tests with its own setup.

Still to do before broadcasting: the launch system must confirm it supports the 12-character symbol and give a current total cost. Then you confirm. Only after deployment will there be addresses, a pool ID and transaction links to send you.

I found no economic defects that I could reproduce with a failing input, so .imd-findings.json has an empty findings list and a coverage record. Nothing was paid, deployed or broadcast, and no repository files were changed; I deleted my scratch test afterwards.

What I reviewed (Economic Security, Invariant and Flow Gap guides, after the Mindset section):

• ConditionalsToken: it is the standard OpenZeppelin v5 ERC20, and I checked the vendored copy is unmodified. The name is Conditionals and the symbol is CONDITIONALS, all 12 characters (src/ConditionalsToken.sol:11). The constructor mints the whole 1,000,000,000 × 10^18 supply once, to the deployer. Nothing can mint more, charge a transfer tax, rebase, blocklist holders or change the name or symbol later. Because a transfer always delivers the exact amount sent, the factory's 10/80/10 payouts and the pool's settlement can't come up short.
• ConditionalsHook: only beforeInitialize is turned on. It rejects any caller other than the PoolManager, returns the correct selector, and accepts the 12500 fee and whatever opening price the factory works out. It has no swap fee, no custom accounting, holds no funds and has no admin. Nobody can open the launch pool before the hook exists. Anyone can open other pools that use this hook, but it stores nothing, so there is nothing to take.
• Cost tool (tools/prepare_launch.py): it adds up costs separately for each currency and never adds ETH and IMD into one number. It refuses quotes that are expired, incomplete, or made for a different configuration. It also refuses a returned launch form that changes anything other than the symbol.

Checks I ran:

• The project builds, and all 22 of its tests pass with the pinned fuzz seed.
• My own fuzz test confirmed that balances always add up to 10^27, the total supply never changes, allowances go down by exactly the amount spent, and the symbol is the full 12 characters.

Coverage: there is a holds row for each of the three entry points (approve, transfer, transferFrom), plus five rows for the invariants and other code I checked.

Not settled:

• The README says no earlier Conditionals configuration was available, so this setup was rebuilt from the launch policy. I can't confirm that it matches the "existing" settings the request says to keep. The launch operator needs to check that before asking you to confirm.
• There is still no deployment cost quote, and the launch system hasn't confirmed it accepts a 12-character symbol. Until both arrive, the cost tool prints the configuration with no total and exits with a non-zero status.
• The brief's Token symbol: CONDITIONAL line conflicts with the exact-symbol instruction. The code uses CONDITIONALS, which is what the instruction requires.

I can't give you a token address, hook address, pool ID or transaction links, because nothing has been deployed.

Review complete. The findings file is written and validated, the scratch test is removed, and no project file was changed.

Outcome: no permission defects in the Solidity. The assigned area (Access Control, Trust Gap, Asymmetry) is covered in full for both contracts.

What I checked

• ConditionalsToken is an unmodified OpenZeppelin v5 ERC-20 that mints the full supply once to its deployer. The vendored OpenZeppelin files are byte-identical to the pinned upstream commit. There is no owner, mint, burn, pause, blocklist, or upgrade path. A stranger holding no allowance cannot move or freeze a holder's balance.
• ConditionalsHook takes the PoolManager as its only constructor argument, rejects zero, and validates its own address bits. beforeInitialize refuses every caller except that manager and returns the correct selector. I verified this against a second PoolManager instance and direct callers. It has no admin surface and no remove-liquidity callbacks, so the factory's fee collect cannot be blocked.
• The vendored v4-core files that differ from upstream differ only in line wrapping.
• The existing 22 Foundry tests and 15 Python tests pass.

One info-level entry records that the request's premise cannot be verified from the repository. The brief says to reuse the existing hook configuration and change only the symbol, but the tree holds no prior hook, token, or launch form. The delivered hook is a reconstruction, which the README itself states. The operator must compare against the launch system's stored configuration before confirming. This needs no code change unless that comparison shows a different existing hook.

Coverage record has 11 rows: all three listed token entry points hold, plus the two constructors, both hook functions, and four invariants including the pre-code initialization block and the absence of any privileged actor.

I added a launch test file, a pool invariant suite and a trader mock under test/. forge build succeeds and forge test passes with the verifier's seed: 36 tests, 0 failed, 0 skipped (22 already existed, 14 are new). I found no defect in the code to report.

Not committed. This machine has no git identity, and I didn't set one. The three new files are staged in the working tree for the harness to commit:

• test/ConditionalsLaunch.t.sol
• test/ConditionalsPoolInvariant.t.sol
• test/mocks/Swapper.sol

test/ConditionalsLaunch.t.sol (13 tests)

• Happy path: a stand-in factory does the whole launch in one call, as the real one does in one transaction, on chain ID 4663 with the real IMD pair address. It deploys the token, deploys the hook, opens the pool and seeds it with tokens only, then pays out the 10% swarm and 10% payer shares.
• What it checks: name Conditionals, symbol exactly CONDITIONALS (12 bytes, not CONDITIONAL), 18 decimals, 1 billion supply, the 10/80/10 split, the 1.25% LP fee, tick spacing 60, and that the pool ID is the hash of the ordered pool key.
• Trading: a first buy works even though the pool holds no IMD yet; tokens sell back; the factory's fee collect returns 1.25% of a 100 IMD buy and never charges the factory; it then withdraws everything.
• Failure paths:
  • a hook address mined for the wrong factory or the wrong PoolManager makes the whole launch revert;
  • nobody can open the launch pool before the hook exists;
  • swaps of zero or past the price limit are rejected, as are keys that differ from the launch pool, a second initialize, and a trader who can't pay;
  • the hook refuses ETH sent to it;
  • every callback it doesn't declare reverts, even when called by the PoolManager;
  • the hook has no owner or admin functions.
• Other checks: neither contract's code contains DELEGATECALL, CALLCODE or SELFDESTRUCT. Fuzz tests show only the PoolManager can call beforeInitialize, and that buying then selling never returns a profit.

test/ConditionalsPoolInvariant.t.sol Random sequences of adding and removing liquidity, fee collects, swaps (exact input and exact output) and donations run against the hooked pool and against an identical pool with no hook. Each pool has its own identically funded actors. After every step:

• the two pools agree exactly: price, tick, fees, liquidity and fee growth;
• the LP fee stays 12500 and the protocol fee stays 0;
• every position matches what the test expects it to hold, and no fee collect ever charges the LP;
• token supply and IMD balances are conserved;
• the hook never holds tokens, ETH or PoolManager claims.

At the end of each run every LP withdraws everything, and only rounding dust may stay in the PoolManager. I checked that the runs are not empty: a sampled run had 7 successful swaps and 14 liquidity changes out of 40 calls.

test/mocks/Swapper.sol One of the pinned checks this task is judged against (the hook-ownership check) imports this file, and it didn't exist, so that check couldn't have compiled. My version matches how that check calls it, and my own tests use it too. That same check also imports test/floor/OwnerChecks.sol. I didn't write that file because I can't tell what it should do; I assumed your toolchain supplies it.

Observations in .imd-findings.json (both info level; the file is gitignored, so it is only in the working tree)

1. The hook accepts pool initialization from any caller, for any pool. Nobody can open the launch pool first only because the factory deploys the hook and opens the pool in the same transaction. If those steps are ever split, anyone could open the pool first at a price of their choosing and the launch would fail.

2. Tests can't settle the deployment questions:

   • whether the real launch form accepts the 12-character symbol;
   • the total cost;
   • the token address, hook address, pool ID and transaction links.

   Nothing was paid, deployed or broad

Review complete. The findings file is written at .imd-findings.json with one finding and fourteen coverage rows, and the working tree is unchanged.

Outcome. The Solidity under review holds in my area. The one defect I could substantiate is a toolchain compatibility gap, not a contract bug.

Finding 1 (medium): the pinned floor suite cannot compile against the vendored forge-std. The project vendors forge-std 1.9.7, whose assertions library defines only fail() with no arguments. The protected hook floor and the owners floor both call fail(string), which arrived in forge-std v1.10.0. Their relative imports place them inside this repository, so they compile with this repository's remappings and hit solc error 6160. I reproduced the compile error by copying the hook floor to its intended path, then shimmed the call to revert(string) and ran all three available floors against the real creation code. All fourteen floor tests pass, so the hook and token themselves are sound and only the dependency pin blocks the check. The impact depends on whether the verifier injects its own forge-std, which nothing in the tree establishes. The fix is to vendor forge-std v1.10.0 or later and update the pin in the dependencies file.

What held, by pass:

• Execution Trace: beforeInitialize accepts only the PoolManager, returns the right selector, and holds no state. The token mints exactly one billion tokens at 18 decimals to the deploying factory. Initialization of the predicted pool before the hook has code reverts. The review tool rewrites only the symbol, enforces type-strict equality on any candidate, and never authorizes broadcast.
• Periphery: every vendored library file was fetched from its pinned upstream commit. OpenZeppelin and solmate are byte-identical. The seventeen forge-std and v4-core files that differ do so only by line wrapping, confirmed with whitespace stripped. The HookFlags helper the floor consumes aliases the v4 flags correctly.
• First Principles: no $factory gate on initialize is safe only because the factory deploys and initializes atomically. I recorded that as a documented assumption rather than a defect.

Not reached. The owners floor needs two toolchain helpers that were not supplied, so I could not execute it. By reading, the hook has no owner function and no remove-liquidity callbacks, so a zero-liquidity fee collect never calls it.

One note for the judge, not a finding. The brief asks to reuse an existing hook launch configuration. The README states no prior configuration was found and the minimal hook is a reconstruction. If the launch system does hold an earlier configuration with a different hook, this deliverable would replace rather than preserve it. That is a scope question for the operator, with no failing input I could name.

Review complete. The findings file is written at the repository root, every snippet matches the tree, the scratch directory is removed, and the working tree is clean apart from the findings file.

Outcome. The contracts are sound. The one real defect is in the vendored test dependency, not in the Solidity.

Findings kept (3), from 4 specialist entries:

1. Medium, merged from audit_flow. The vendored forge-std is pinned at release 1.9.7, which defines only the zero-argument fail(). The pinned hook floor calls fail(string) in two files, so compiling it inside this tree gives solc error 6160. I reproduced this by copying the floor into the tree and building. I also confirmed upstream: the pinned commit lacks the overload, and v1.10.0 and master have it. With the call shimmed to revert(, all 14 floor tests pass against the hook and token creation code, so the fix is only to vendor forge-std v1.10.0 or later and update dependencies.json. Impact is conditional on the verifier using the project's forge-std, which nothing in the tree rules out.
2. Info, from write_foundry_tests. The hook's beforeInitialize gates only on the PoolManager caller. That is what the floor requires, and the project tests show the pool cannot be opened before the hook has code. Kept as a note that the deploy-and-initialize ordering must stay atomic.
3. Info, merged from audit_permissions and the second tester note. The brief's "existing configuration" has no counterpart in the tree, so the hook is a documented reconstruction, and form support for the 12-character symbol plus cost cannot be checked here. The README's claim that no launch.json is supplied is now stale since the merge commit added one.

Dropped: nothing substantive. The two aderyn lows are style only.

Own pass. I diffed every vendored Solidity file against upstream at the pinned commits, ignoring whitespace. All are identical except formatting reflow in two v4-core files. OpenZeppelin is release v5.1.0, so the three token entry points are the standard implementation. The manifest matches the code on constructor arguments, permissions, supply, name, symbol, decimals, fee tier and note length.

Coverage. All three listed entry points are marked holds, plus five invariant rows covering the hook callback, constructor and flags, the manifest, floor compilation (finding 1) and dependency integrity.

The responses file is in place and is excluded from git by the harness's own exclude list, which is expected since it is read directly by the review pipeline rather than committed.

Outcome: the reopened finding reproduced and is fixed. The two advisory findings did not require code changes, and every finding is answered in .imd-responses.json.

What I reproduced and changed

• forge-std too old for the floor (medium, fixed). Copying the pinned hook floor into scratch and building failed with solc error 6160 at the one-argument fail( call, exactly as reported. The vendored forge-std at v1.9.7 only had the zero-argument form.
• Fix. Re-vendored lib/forge-std from the GitHub archive of release v1.17.0, keeping the same subset layout as before. The archive hash method matched the old entry, so dependencies.json now carries the new commit, archive SHA-256 and file count. The README's build section explains why the floor needs forge-std v1.10.0 or later. No source contract changed.
• Verification. With the unmodified Hook, Token and OwnToken floor files in scratch and the reviewer's environment values, all 14 floor tests pass against the built creation code. The Owners floor imports verifier-only helpers that are not in this tree, so it could not be compiled here, but it uses the same overload that now exists.

Advisory findings

• beforeInitialize only gates on the PoolManager is confirmed, intended behaviour. The existing tests already cover initialization being blocked before the hook has code, duplicate initialization, and forged-sender callbacks. Answered as disputed with no change.
• Missing existing configuration and the launch.json inconsistency does not reproduce in the accepted tree. The commits it cites belong to the rejected attempt, no launch.json exists here, and the README already documents the reconstruction and the open operator checks. Answered as not reproducible.

Final checks on the clean tree

Check	Result
forge build with solc 0.8.26	passes
forge test with the verifier fuzz seed	22 passed, 0 failed
forge fmt --check	passes
Python review-tool tests	15 passed

Nothing was paid, signed or broadcast. Form validation of the 12-character symbol and the total cost quote remain operator steps before confirmation, as the README states.

I didn't change anything: the launch.json already in the tree is correct, and the round listed no findings that would call for an edit. Nothing has been paid for or deployed, and no transactions were sent.

The manifest matches the code it describes:

• Kind: the first field is "kind": "univ4_hook".
• Token: ConditionalsToken, name Conditionals, symbol exactly CONDITIONALS (12 characters), 18 decimals. Its constructor takes no arguments, so constructorArgs is []. It mints a fixed 1,000,000,000 × 10^18 once to whoever deploys it, so totalSupply is "1000000000000000000000000000".
• Hook: ConditionalsHook, with constructorArgs of ["$poolManager"], which is its only constructor parameter. Its getHookPermissions turns on only beforeInitialize, so the manifest declares only that. The callback accepts calls only from the PoolManager, returns its selector, and doesn't block any fee tier.
• Pool: paired with 0x5f7bb59365ce557c26dbcaa4ee9d39a4b95b7127, fee 12500, tick spacing 60, initial price 79228162514264337593543950336.
• Notes: 1,086 characters, under the 4,000 limit.

Symbol conflict: the brief says the symbol must be exactly CONDITIONALS, but a later line says "Token symbol: CONDITIONAL". The manifest uses CONDITIONALS, and the notes say why.

forge test passed all 22 tests with the verifier's fuzz seed, including the invariant that supply and token metadata never change.

Before broadcasting: two things are still open:

• The launch system has not yet confirmed that it accepts a 12-character symbol.
• It has not yet quoted the total cost.

Once you've confirmed both and the launch is deployed, I can return the token address, hook address, pool ID and transaction links.

The review is complete and written to .imd-findings.json. The medium finding from the previous round is fixed, and the only item kept is one documentation note.

Prior medium finding (forge-std lacked fail(string)): fixed. The vendored library is now byte-identical to upstream forge-std at commit f3dae6e, release v1.17.0. The codeload archive hash matches the value recorded in dependencies.json, and StdAssertions now defines the string overload. Copying the pinned Hook, Token and OwnToken floor files into the tree unmodified, they compile and pass against the real creation code of ConditionalsHook and ConditionalsToken.

Suite	Result
Protected floor (hook, token, own token)	14 of 14 pass
Project Solidity suite	40 of 40 pass

Prior advisory on beforeInitialize gating: dropped. The behaviour is intended, the atomic deploy-and-initialize model is the protection, and the project tests cover it. No defect.

Prior advisory on unverifiable "existing configuration": one residual note kept as info. The author answered that launch.json did not exist in their tree. That was true of their node, but the combined tree under review now has launch.json at the root, so the README sentence saying none is supplied is out of date. The manifest itself is consistent with the code: constructor arguments, permissions, supply, name, symbol, decimals, paired currency, fee tier and tick spacing all match. The remaining points from that advisory are already documented in the README and the manifest notes and need no code change.

Specialist findings. The audit_flow finding was the same forge-std root cause and is settled by the fix. The audit_permissions info note is merged into the kept info finding. No specialist proof was attached, and nothing new reproduced.

Coverage. All three token entry points are marked holds. They are unmodified OpenZeppelin v5 ERC20 paths with no override, mint or admin surface in the token. The hook's constructor and callback, and both prior findings, have rows as well.