README.md lists python3 tools/check_launch.py as one of the four offline checks and says lib/dependencies.json records the exact SHA-256 of every vendored file. On the committed tree the script exits non-zero before printing its success line, because 16 files under lib/ were reformatted (forge fmt) after the hashes were recorded.

The recorded hashes are the pristine upstream ones (I fetched forge-std 3b20d60 StdAssertions.sol and v4-core 46c6834 PoolManager.sol from GitHub and they hash to exactly the recorded values), so the vendored copies are the ones that drifted.

I diffed every mismatching file against upstream: the differences are whitespace and line-wrapping only (no token, operator or literal changes), so the test stand-in for the PoolManager still reproduces upstream behaviour and the production ERC20.sol is byte-identical to OpenZeppelin 5.0.2.

Impact is on verification, not on the token: the project's own provenance gate is red, so a future semantic edit to lib/v4-core (which the launch-flow and fee tests run against) or lib/forge-std would be indistinguishable from this formatting drift.

Mismatching files: forge-std StdAssertions.sol, StdJson.sol, StdToml.sol, Vm.sol, console.sol, interfaces/IMulticall3.sol; v4-core PoolManager.sol, libraries/Hooks.sol, Pool.sol, SqrtPriceMath.sol, StateLibrary.sol, SwapMath.sol, TickBitmap.sol, types/Currency.sol, Slot0.sol.

Minimal fix: either re-record the hashes of the committed files in lib/dependencies.json (and note in README that lib/ is forge-fmt formatted) or restore the pristine upstream bytes so the recorded hashes hold. Do not change lib/ semantics.

The job narrative says the pool fee is fixed at 1.25% and asks for a test that the fee is 1.25%, while the mandatory build requirements say launch.json pool: ... fee 3000. The submission follows the mandatory value, documents the conflict in README.md, test/COVERAGE.md and launch.json notes, and its pool tests assert lpFee == 3000.

Economically the two values differ materially for LPs and traders: on a 1 IMD buy the pool keeps 0.003 IMD at 3000 versus 0.0125 IMD at 12500, and the sole LP position is the factory-seeded single-sided 90% supply, so the requester's share of trading revenue is about 4.2x lower under 3000.

This is not a code defect (the token has no fee logic either way, and 12500 is a valid static v4 fee below LPFeeLibrary.MAX_LP_FEE) and the mandatory requirement prevails, but the requester should explicitly confirm 3000 so a 1.25% expectation does not resurface at admission. Also note the narrative's unit is wrong on its own terms: 12500 in Uniswap v4 fee units is 125 basis points (1.25%), not 12500 basis points.

README.md (line 27) lists python3 tools/check_launch.py as a required offline check after forge build, and its docstring calls it the manifest/ABI/vendored-input regression check. On the committed tree it exits non-zero at the first vendored-file hash comparison.

Root cause: lib/dependencies.json records the upstream SHA-256 of each vendored file at the pinned commits (forge-std 3b20d60d, v4-core 46c68346); I fetched those upstream files and every recorded hash matches upstream exactly. But 15 files in lib/ were re-formatted after vendoring (forge-fmt style line re-wrapping, plus one if (...) return ...; turned into a braced block in v4-core/src/libraries/Hooks.sol), so their bytes differ from upstream and from the recorded hash.

The altered files are forge-std: StdAssertions.sol, StdJson.sol, StdToml.sol, Vm.sol, console.sol, interfaces/IMulticall3.sol; v4-core: PoolManager.sol, libraries/Hooks.sol, libraries/Pool.sol, libraries/SqrtPriceMath.sol, libraries/StateLibrary.sol, libraries/SwapMath.sol, libraries/TickBitmap.sol, types/Currency.sol, types/Slot0.sol.

I verified each altered file is whitespace-identical to upstream (Hooks.sol is identical after also removing the inserted braces), so the vendored AMM math exercised by test/LaunchFlow.t.sol is semantically upstream and forge build/forge test are unaffected.

The defect is that the repository's own integrity gate cannot pass, so it no longer proves anything about the manifest, ABI or foundry.toml either: the script aborts before reaching those checks only if dependency checks ran first, and here the dependency loop is last, so the earlier checks do run but the command still reports failure. Anyone following the README will see the build as rejected.

Fix options for the author: restore the 15 files to their exact upstream bytes (ideal, keeps the recorded provenance true), or regenerate the hashes in lib/dependencies.json from the formatted files. Both touch lib/, which this task's rules forbid contributors from editing, so this needs the author or the integrator.

The assignment's narrative says the Uniswap v4 pool fee is fixed at 1.25% and its test item 5 says to verify 1.25%, but the mandatory build requirements say fee 3000, tickSpacing 60. The committed manifest, README.md and test/COVERAGE.md all resolve this toward 3000 and say so explicitly; test/LaunchFlow.t.sol asserts lpFee == 3000.

This is consistent with the mandatory requirement and with the admission rule that economics/pool fields are copied from the job verbatim, so it is not a code defect. It is recorded here because the two parts of the brief cannot both be satisfied: a launch admitted with fee 3000 opens a pool charging 0.30%, not 1.25%, and the requester's own acceptance test 5 as written would fail against it.

Note also that the narrative's unit is wrong: Uniswap v4 fee units are hundredths of a basis point, so 1.25% is 12500 pips (125 bps), not '12500 basis points'; if the requester truly wants 1.25%, the manifest value must be 12500 and the tick spacing re-chosen, which changes a mandatory field and is the requester's decision, not the contributor's.

Periphery / provenance. README.md:27 lists python3 tools/check_launch.py as one of the four offline acceptance commands, and README.md:119-121 and the 'Dependency provenance' section claim lib/dependencies.json records SHA-256 hashes of the vendored sources.

The hashes recorded there are the hashes of the pristine upstream files (verified against forge-std v1.9.6 at 3b20d60d and Uniswap v4-core at 46c6834698c4), but the files actually committed under lib/ are reformatted copies: 6 forge-std files (src/StdAssertions.sol, src/StdJson.sol, src/StdToml.sol, src/Vm.sol, src/console.sol, src/interfaces/IMulticall3.sol) and 9 v4-core files (src/PoolManager.sol, src/libraries/Hooks.sol, src/libraries/Pool.sol, src/libraries/SqrtPriceMath.sol, src/libraries/StateLibrary.sol, src/libraries/SwapMath.sol, src/libraries/TickBitmap.sol, src/types/Currency.sol, src/types/Slot0.sol) hash differently from their recorded value.

The divergence is present from the first commit (a45499d) onward; the working tree equals HEAD. I diffed every mismatched file against upstream: all differences are whitespace/line-wrapping only (Hooks.sol additionally gained braces around a one-statement if), so the vendored PoolManager used as the mainnet stand-in in test/LaunchFlow.t.sol is semantically the pinned upstream and the production token's OpenZeppelin 5.0.2 sources are byte-identical to upstream.

The defect is that the provenance record is wrong and the check that is supposed to prove the vendored code is untampered exits non-zero on the committed tree. Because tools/check_launch.py:86 raises SystemExit on the first mismatch, the nine v4-core mismatches are never even reported.

Fix (either): re-vendor the 15 files byte-for-byte from the pinned commits so the recorded hashes hold, or regenerate the hashes in lib/dependencies.json from the committed files and note the reformatting in the README. Plain forge build, forge test and forge fmt --check are unaffected.

Not a code defect; recorded so the judge sees the open specification conflict. The task narrative item 3 says 'The Uniswap v4 pool fee is fixed at 1.25% (12500 basis points)' and test item 5 says 'Verify that the Uniswap v4 pool fee is set at 1.25%', while the mandatory build requirements say 'launch.json pool: ... fee 3000, tickSpacing 60'.

The narrative is also internally inconsistent: in Uniswap v4 units 12500 is 1.25% (hundredths of a bip), while '12500 basis points' would be 125%. The accepted implementation follows the mandatory block (launch.json fee 3000, README.md 'Launch parameters and the fee conflict', test/COVERAGE.md 'Scope and conflicting requirements', and test/LaunchFlow.t.sol asserts lpFee == 3000).

The token itself has no fee logic either way, so nothing in src/ changes if the requester picks 12500; only launch.json, README.md and the LaunchFlow fixtures would. Needed from the requester: a one-line confirmation of which fee the pool opens with.

README.md lists python3 tools/check_launch.py as one of the four offline build-and-check steps and states that lib/dependencies.json records the SHA-256 hashes of every vendored file. On the committed tree (HEAD deb877b, clean working copy) that check exits non-zero before it reaches its success message: 15 of the hashes in lib/dependencies.json do not match the files on disk.

I fetched each of the 15 files from the pinned upstream commits (foundry-rs/forge-std@3b20d60d, Uniswap/v4-core@46c68346): the recorded hashes are the genuine upstream hashes, and every committed file differs from upstream only by forge fmt reformatting (line wrapping, and in v4-core/src/libraries/Hooks.sol braces added around a one-line if).

Whitespace-stripped content is identical for 14 files and the Hooks.sol difference is brace-only, so no vendored dependency carries a semantic change, and the six OpenZeppelin files the production token inherits match upstream byte-for-byte. forge fmt --check passes, confirming the tree is in the formatted state.

The defect is in the verification tooling and its provenance claim, not in the token: the check the README tells a verifier to run is red on the author's own tree, so it cannot distinguish a tampered dependency from the shipped one, and lib/dependencies.json line 21 onward records hashes of files that are not what is committed.

Mismatched files: forge-std src/StdAssertions.sol, src/StdJson.sol, src/StdToml.sol, src/Vm.sol, src/console.sol, src/interfaces/IMulticall3.sol; v4-core src/PoolManager.sol, src/libraries/Hooks.sol, src/libraries/Pool.sol, src/libraries/SqrtPriceMath.sol, src/libraries/StateLibrary.sol, src/libraries/SwapMath.sol, src/libraries/TickBitmap.sol, src/types/Currency.sol, src/types/Slot0.sol.

Fix options that preserve intent: either re-record the hashes of the committed (formatted) files in lib/dependencies.json and state in README that the vendored copies are upstream content passed through forge fmt, or restore the upstream byte-exact files and exclude lib/ from formatting. The remainder of check_launch.py (manifest fields, foundry.toml settings, ABI surface, provenance price) passes once the hash loop is reached with correct data.

The job text describes the pool fee as 'fixed at 1.25% (12500 basis points)' and lists as acceptance test 5 'Verify that the Uniswap v4 pool fee is set at 1.25% with paired currency IMD'. The mandatory build requirements in the same job fix launch.json pool.fee at 3000 with tickSpacing 60.

The delivered manifest, README (section 'Launch parameters and the fee conflict'), test/COVERAGE.md and test/LaunchFlow.t.sol all follow the mandatory 3000 value and say so explicitly, and launch.json notes records that 3000 supersedes the 1.25% description. This is the correct resolution under the rules given (economics and pool parameters are copied from the job's mandatory block verbatim), and it is not a defect in the token or the manifest.

It is recorded here because the requester's own test 5 as written cannot pass against this manifest, and 12500 in Uniswap fee units is 1.25% whereas '12500 basis points' would be 125%; the requester should confirm 0.30% is the intended LP fee before admission, since a static v4 LP fee cannot be changed after the pool is initialized (LaunchFlow.t.sol test_PoolFeeCannotBeDynamicallyChanged shows updateDynamicLPFee reverting on this pool key). No code change is proposed.

Merged from all four specialist areas (audit_flow, audit_economics, audit_math, audit_permissions), which reported the same root cause. README.md line 27 lists python3 tools/check_launch.py as one of the four offline acceptance commands, and the 'Dependency provenance' section says lib/dependencies.json records the SHA-256 of every vendored file.

On the committed tree (HEAD deb877b, clean working copy) that command exits 1 at tools/check_launch.py line 86 (check(actual == expected, f"Vendored source changed: {library}/{filename}")) on the first vendored file it compares, and never prints its success line.

I reproduced it and then hashed every entry in lib/dependencies.json: 15 files mismatch, 6 in forge-std (src/StdAssertions.sol, src/StdJson.sol, src/StdToml.sol, src/Vm.sol, src/console.sol, src/interfaces/IMulticall3.sol) and 9 in v4-core (src/PoolManager.sol, src/libraries/Hooks.sol, src/libraries/Pool.sol, src/libraries/SqrtPriceMath.sol, src/libraries/StateLibrary.sol, src/libraries/SwapMath.sol, src/libraries/TickBitmap.sol, src/types/Currency.sol, src/types/Slot0.sol).

I fetched each of the 15 files from the pinned upstream commits (foundry-rs/forge-std@3b20d60d, Uniswap/v4-core@46c68346): every recorded hash equals the upstream file's hash, so the record is of pristine upstream and the committed copies are what drifted.

Comparing whitespace-stripped bytes, 14 of the 15 are identical to upstream and Hooks.sol differs only by braces added around a one-statement if; forge fmt --check passes, so the drift is forge fmt reformatting of lib/. The six OpenZeppelin 5.0.2 files that the production token inherits are byte-identical to upstream (cmp against dbb6104c), so src/IMDTToken.sol's compiled behaviour is unaffected, and forge build / forge test (35 tests) pass.

The defect is confined to verification: the repository's own integrity gate is red on the author's own tree, so it cannot distinguish a tampered vendored file from the shipped one, and the README's instruction to run it reports the build as rejected. Note also that .gitignore line 4 lists lib/dependencies.json even though the file is tracked; this is harmless today (tracked files are not ignored) but it signals the file was not meant to be committed as-is.

Minimal fix, either: (a) restore the 15 files to their exact upstream bytes and exclude lib/ from forge fmt, keeping the recorded hashes true; or (b) regenerate the hashes in lib/dependencies.json from the committed files and state in README.md that lib/ holds upstream content passed through forge fmt. Do not change lib/ semantics. Both options touch lib/, which contributors are forbidden to edit, so this needs the author or integrator.

Merged from all four specialist areas. Not a code defect; recorded so the open specification conflict is visible before admission. The job narrative item 3 says 'The Uniswap v4 pool fee is fixed at 1.25% (12500 basis points)' and test item 5 says 'Verify that the Uniswap v4 pool fee is set at 1.25% with paired currency IMD', while the mandatory build requirements in the same job say 'launch.json pool: ... fee 3000, tickSpacing 60'.

The committed manifest follows the mandatory block (launch.json line 14 fee 3000), README.md section 'Launch parameters and the fee conflict', test/COVERAGE.md 'Scope and conflicting requirements' and launch.json notes all state this explicitly, and test/LaunchFlow.t.sol asserts lpFee == 3000 at lines 91 and 155.

That is the correct resolution under the rules given (pool and economics fields are copied from the job's mandatory block verbatim), and the token itself has no fee logic either way, so nothing in src/ changes whichever value the requester picks. The narrative is also internally inconsistent: Uniswap v4 fee units are hundredths of a basis point, so 12500 is 125 bps (1.25%), not '12500 basis points'.

A static v4 LP fee cannot be changed after the pool is initialized (test_PoolFeeCannotBeDynamicallyChanged shows updateDynamicLPFee reverting with UnauthorizedDynamicLPFeeUpdate), so the requester should confirm 0.30% before admission.

Needed: a one-line requester confirmation of the intended fee; if 12500 is intended, launch.json pool.fee and tickSpacing, README.md and the LaunchFlow fixtures change, and that is the requester's decision, not the contributor's.