Recovered and repaired the source package, including contracts, tests, manifest, ABIs and deployment instructions.

Validation passed: 142 tests, 11 protected checks, both-stage Sepolia fork rehearsal, forge build, and forge fmt --check.

UNLK is not deployed or active. No executable owner-signed stage-2 service was established, so stage 1 was not broadcast. Public deployment and GitHub publication remain pending.

Independent review remains required. The documented quiet-market manipulation scenario costs a payer approximately 0.65 ETH net over 56 hours.

See deployment handoff, validation, and security findings.

launch.json is written and verified. Only that file changed.

What the manifest describes

• Hook contract UnlkHook, constructor args in declaration order: $poolManager, $token, $factory, $owner. This matches src/UnlkHook.sol:131.
• Permissions: the eight callbacks the implementation enables at src/UnlkHook.sol:149 (beforeInitialize, afterInitialize, before/after add and remove liquidity, beforeSwap, afterSwap). No return-delta flags, flags 0x3fc0.
• Token UnlkToken, name UNLOCK, symbol UNLK, 18 decimals. Pool: native ETH, fee 12500, tickSpacing 60, initialPrice as the launch facts give it.
• Notes (3968 characters, under the cap) summarize the two-stage design, quota formula and tiers, oracle parameters, provenance of the restored bundles, the other-pool bypass and measured manipulation residual risk, and the current status.

Verification run

• forge build succeeds.
• forge test: 142 passed, 0 failed across 28 suites.
• The pinned protected admission tests, run from a scratch copy with the manifest's values: 11 passed, 0 failed, including the permissions-match-declared-flags and initialize-from-factory checks.
• git status shows only launch.json modified. No blocked file was written.

What this task did not do The brief also asks for a Sepolia broadcast. This assignment's write scope is the manifest only, so nothing was deployed. The tree's own release status records the fork rehearsal at block 11904506 without broadcast, and the notes state that stage 1 must not be sent until an owner-signed stage-2 route exists. Actual launch addresses, transactions and PoolId remain outputs of the deployer, not values in the manifest.

The review is complete. Findings and the coverage record are in .imd-findings.json at the repository root, and the scratch test I used was removed, so the tree is unchanged.

What I covered. I traced the Execution Trace, Periphery and First Principles guides across UnlkHook, UnlkSwapRouter, UnlkOracle, MerkleClaimEvidence, UnlkToken, the three small libraries, HookDeployer, and the verified LaunchFactory, PoolFees, LaunchRegistry and MerkleDistributor fixtures the hook binds to. The full non-invariant suite passes, and a scratch test confirmed the pinned reviewed creation-code hashes equal the current build, so stage 2 staging is executable.

Result: no critical or high defects. The swap path, quota accounting, two-stage activation checks, evidence adapter and oracle accumulator all held against the failure modes in the guides. Three substantiated lower-severity items are reported, each with a concrete input:

• Low, UnlkHook.sol:417. A Uniswap protocol-fee change on the official pool makes every swap revert forever. There is no admin, no substitute pool and no recovery. The docs disclose it as a trust assumption; I recorded the exact trigger so the judge can treat the liveness trade-off as a deliberate release decision.
• Low, UnlkHook.sol:600. Confirmation restarts only when an invalid feed interval is observed. One permissionless updateMilestone call during routine Chainlink lateness resets a 6-hour or 24-hour clock, while the same lateness unobserved does not. Rights are never revoked, so this is unlock liveness only, but the asymmetry is undocumented.
• Info, UnlkHook.sol:212. Staging is single-shot. If round 0 has more than 1024 recipients or any other immutable precondition fails after deployCompanions, activation is permanently impossible. The docs name this as a preflight failure; the row asks the judge to confirm the preflight is in the runbook.

Coverage. All 25 listed entry points have a row. 22 hold, three reference the findings above, and two invariant rows record the hash check and the quota derivation. One row is marked unreached: the Sepolia fork rehearsal and the Stage2 broadcast script, which were outside my guides and need fork access I did not have.

The review is complete. The findings file is in place and valid, the scratch tests were removed, and the working tree holds nothing new beyond .imd-findings.json (which the repository already ignores) and the pinned .imd/ inputs.

Outcome

I audited the UNLK hook launch against the Pashov Economic Security, Invariant and Flow Gap guides, tracing the quota ledger, the fee split, the oracle and milestone cadence, the router settlement, and the claim-evidence path. Two defects were substantiated by local Foundry runs; the rest of the assigned area holds.

Findings written to .imd-findings.json

• Medium, activation tolerance. configureAndActivate in src/UnlkHook.sol only accepts a pool seed within 1e12 wei of exactly 870M tokens. The seed amount is a deployer input the factory accepts with far looser bounds. A liquidity value 1e9 units low seeds about 7 millionths of one token less and activation reverts forever, leaving a seeded Sepolia pool that can never trade. The deployer's own policy row names liquidityBps 8000, which fails the same way. Both cases were reproduced against the project fixture.
• Low, uncertifiable rounds. certifyRound in src/MerkleClaimEvidence.sol refuses rounds over 1024 leaves or with a repeated recipient. For any later treasury round in that shape, claimants receive tokens natively but can never be credited sell rights, so they cannot sell a single token on the official pool until the $5M unlock. Reproduced with a two-leaf duplicate-recipient round.

Coverage

All 25 listed entry points have a row, plus three invariant rows. Everything is holds except the two finding rows above. The disclosed sustained-manipulation cost was re-run from the project's own test and matches the documented numbers. No undisclosed cheaper path was found. I also probed whether quota-limited sellers can push the price out of the seed range to poison the oracle, and they cannot before full unlock, so that lead was dropped.

Not reached

Chain-specific coupling I could not verify offline: whether the IMD deployer's liquidity formula lands inside the 1e12-wei window, and whether its compiled token creation code matches the pinned ReviewedCode.TOKEN hash. Both are the same failure class as the first finding and belong in a deployer preflight.

The findings file is complete and valid. Here is the recap.

Scope covered. I audited the permission model, trust gaps and asymmetries across UnlkHook, UnlkSwapRouter, UnlkOracle, MerkleClaimEvidence and UnlkToken, plus the manifest and the vendored IMD factory, distributor and fee contracts the hook authenticates against. All 25 listed entry points have a coverage row, plus three invariant rows. Nothing in the permission model itself broke: every callback is manager-only with a sender check, the router only ever pulls from its caller, the setup authority can stage and seal exactly one reviewed bundle, and no admin, pause or withdrawal path exists.

Findings written to .imd-findings.json

• Medium, activation seals a dead oracle. configureAndActivate pins the oracle's 17 ETH depth constant but never checks that the actual seed reaches it. A seed opened about 2% under the 20 ETH cap, which only the IMD deployer controls, activates cleanly and is never liquid, so no tier can ever be confirmed and nothing signals it. Reproduced with the real factory logic at opening tick 177540, a 400 ETH buy and 30 checkpoints.
• Medium, stage 2 can die permanently. The 1e12 wei allocation tolerance is a relative precision of 1e-15. A deployer liquidity only 1e-14 below the exact value passes the factory and the single-shot deployCompanions, then configureAndActivate reverts forever with no re-stage path. Reproduced with liquidity reduced by 1e9 units.
• Info, trust assumption. The IMD treasury can open and fund later distributor rounds, and every attested native claim earns sell quota, so the treasury can manufacture quota for chosen wallets. This is within the brief's design but is not listed in the security review's trust section.

Dropped after tracing. Pushing the pool price past the seed range with a far price limit to poison the oracle requires draining all pool ETH, which aggregate quota cannot do once buys exceed roughly 1 ETH. The protocol-fee halt and the 1024-leaf certification cap are already disclosed in the docs. Static-analysis leads on the router's reentrancy and unchecked ETH recipient are false positives.

Residuals. Both medium findings hinge on deployer inputs the tree cannot prove, since the Sepolia rehearsal used the project's own exact seed formula rather than the IMD deployer's. The scratch test under test/scratch/ reproduces both and is not part of the submission.

The review is complete and .imd-findings.json holds two substantiated findings plus a coverage row for all 25 entry points and three checked invariants.

What I covered (Math Precision, Boundary, Numerical Gap guides):

• Quota arithmetic in afterSwap and remainingQuota: floor(E·p/10000) minus S matches the brief, int128 sign handling is safe, and the router makes a zero token delta impossible.
• Oracle math: the depth formula seedTokens·2^192/rangeUpper² loses about 1e-23 relative precision, the TWAP floor-division for negative ticks is correct, the binary search returns the last observation at or before the window start, and the FDV scale chain (wei/token to USD18 to FDV18, 512-bit branch above 2^128) has no overflow or decimal mismatch.
• Milestone cadence: the 4-minute minimum, 10-minute maximum gap, 6h/24h durations and array indices (qualifyingSince[0..5], percentages[0..6]) are all in bounds. A try/catch gas-griefing reset is not feasible because fdvUsd costs far less than 63× the catch body.
• Router settlement: native and ERC-20 branches reconcile pre and post balances, the batch value sum cannot overflow, exact output must fill fully, and withdrawals zero state before the call.
• Merkle certification: n in [1,1024], the single-leaf edge, heap reconstruction and uniqueness via heapsort hold.

Findings (both medium, both reproduced by scratch tests under test/scratch/):

1. Seed tolerance is 1e12 wei. Activation requires the pool's initial allocation to be within 0.000001 UNLK of exactly 870M, but the factory accepts any seed up to that share and the off-chain deployer chooses the liquidity. A seed short by 0.001 UNLK launches normally and can never activate, leaving a live pool with no stage-2 path. Reproduced in SeedTolerance.t.sol.
2. No seed-capacity check before sealing. The oracle's fixed 17 ETH capacity test needs an opening FDV of at least 19.54 ETH, a 2.3% margin under a policy value the hook cannot read. Activation verifies the constant but never evaluates it against the real position, so an opening 5.4% under the cap activates and then every milestone stays dead forever while trading continues. Reproduced in SeedCapacity.t.sol.

Not reached: economic manipulation cost modelling, the Sepolia rehearsal script and script/Stage2.s.sol are outside my area and were not traced. Static-analysis leads in my area (divide-before-multiply in the depth formula, strict equalities in checkpoint and twapTick, the uninitialized fdv local) were checked and are not defects.

Added adversarial batch tests and two stateful invariant suites. Changes are confined to test/.

Validation passed: clean build, 151 tests, and all 11 protected checks—including 2,000 fuzz cases and 36,864 randomized invariant calls.

No new defect reproduced. No deployment performed.

The review is complete. .imd-findings.json holds 6 judged findings and a 27-row coverage record (all 25 entry points answered, plus two invariants). The tree is unchanged apart from that file and the scratch tests under test/scratch/.

What I verified first. The project builds, and all 151 existing tests pass. The manifest matches the implementation: four constructor words in declaration order, the eight permissions equal getHookPermissions, fee 12500 with spacing 60 on an ETH pair, notes under the 4,000-character cap, and the hook runtime is 22,388 bytes.

Findings kept, all reproduced in scratch tests I ran:

• Medium, merged from four specialists. Activation requires the factory seed within 1e12 wei of exactly 870M tokens, while the factory only enforces "at most 87%" and staging runs once without checking these preconditions. A liquidity word 1e9 units low seeds 7e12 wei short and leaves the stage-1 pool permanently unactivatable. Reproduced: the factory accepts the launch and configureAndActivate reverts with InvalidEvidence forever.
• Medium, merged from two specialists. Activation pins the oracle's 17 ETH depth constant but never evaluates it against the real seed. A seed opened 2.3% or more under the 20 ETH cap activates and seals, and the oracle is never liquid, so no tier can ever confirm. Reproduced at tick -177840: activation succeeds, 80 milestone calls over 6h40m all fail, tier stays 0.
• Low. A Uniswap protocol-fee change halts official trading and milestones permanently. Documented as a trust assumption; kept as an explicit release decision.
• Low. Confirmation restart depends on whether a call observed the stale feed. Reproduced both runs: the same one-minute stale interval keeps the clock when unobserved and discards six hours when one permissionless call lands inside it.
• Low. Rounds over 1024 leaves or with duplicate recipients can never be certified, so later-round claimants get tokens but zero sell quota.
• Info. The treasury can manufacture quota through later distributor rounds. Already disclosed in the security review; recorded as a trust assumption.

Dropped after checking. I traced a lead of my own where a sell past the seed boundary would push the pool price above the range and invalidate the TWAP for two hours. At any FDV where tiers matter, draining the pool's ETH needs more quota than the supply allows, so it is not reachable. Every slither and aderyn line was a false positive or already covered.

No finding reached high or critical, so no proof files were attached. Residual risks the author should keep disclosed: other-pool bypass, keeper dependence of the 10-minute confirmation cadence, and the funded sustained-manipulation path already modeled in the economics results.

All checks pass and every finding is answered. Here is the recap.

Outcome. Both reopened medium findings reproduced and are fixed in code, with regression tests that replay the reviewer's exact scenarios. Two of the four advisory findings are fixed as well. The remaining two are answered as documented decisions in .imd-responses.json. Build, 154 tests, format check, lint, and the reviewed-code hash check all pass offline.

What changed, by finding

• Seed tolerance stranding stage 1 (a4b5f9a2), fixed. The 1e12-wei dust tolerance became policy bands: the pool must hold 99 to 100 percent of its 870M share, the remainder wallet at least 30M, the distributor exactly 100M, and the three must sum to the supply. The remainder wallet is still credited exactly 30M. All stage-1 preconditions moved into one helper that staging runs before deploying anything, so nothing can be staged for a launch that cannot activate. Staging may now repeat until activation, and an out-of-band seed reverts the launch transaction itself.
• Unchecked 17 ETH capacity floor (d8778e80), fixed. A new internal library holds the single capacity formula used by the oracle, the seed callback, staging and activation. A seed below the floor now reverts inside the factory's launch transaction, and both stage-2 calls recompute it from the live position. The threshold and its 19.54 ETH minimum opening FDV are documented rather than hidden.
• Confirmation restart depended on call timing (66b99dca), fixed. The interrupted flag is gone. Invalid samples never confirm and never advance the cadence clock. Restart depends only on the gap between valid samples, so observed and unobserved outages behave identically. A snapshot-based test proves both runs agree.
• 1024-leaf certification cap (153c7ae8), fixed. Added per-submitter chunked certification with cross-chunk recipient uniqueness, tested at 1500 leaves. Duplicate-recipient roots stay uncertifiable by design.
• Protocol fee halt (d0e68f0c) and treasury quota power (0147f1a4), disputed. Both reproduce and both are intentional. The security review now states each as an explicit release decision or trust assumption with the finding id.

Files to look at

• src/UnlkHook.sol, src/libraries/SeedDepth.sol, src/MerkleClaimEvidence.sol, src/UnlkOracle.sol
• test/ActivationRobustness.t.sol for the new regression and chunked certification tests
• docs/SECURITY_REVIEW.md for the revision table and the two release decisions

Things worth knowing

• The oracle and claim-evidence bytecode changed, so the reviewed creation hashes were regenerated and all ABIs, artifact digests, and recorded check outputs were refreshed.
• The hook runtime now sits 248 bytes under the EIP-170 limit. The off-chain HookDeployer helper embeds the hook's init code and exceeds that limit on purpose; the artifact script exempts it.
• The fork rehearsal against recorded Sepolia state was not re-run here because this machine's verification profile runs without network access. Its code paths are unchanged in signature, but a re-run before stage 1 is still part of the documented deployment checklist.

Done. The suite is green and only test paths changed.

What I found on arrival. The build was broken: the other contributor's newer accepted work removed the hook's confirmationInterrupted flag, and my previous round's batch-settlement test still read it. The implementation also gained a seed-depth gate, repeatable staging and chunked Merkle certification since my tests were written.

What I changed.

• Removed the one stale line from test/BatchSettlementProperties.t.sol. Nothing else in the three earlier files moved.
• Added test/RevisionProperties.t.sol with four suites aimed at the changed code:
  • Fuzz over 51 opening boundaries and the 98 to 100 percent liquidity band. A seed launches if and only if it clears the capacity floor and pool-share band, every launched seed is classed liquid and priced within 0.2 percent of its boundary FDV, and the remainder wallet is never over-credited.
  • Fuzz over chunked certification with random chunk sizes and reduce counts. It certifies exactly when the single-shot path would, a corrupted parallel session never certifies or interferes, and abandoned sessions are inert.
  • A fail-on-revert invariant campaign that samples milestones under six feed corruptions and price swings, with an independent ghost chain of valid samples. No tier advances on invalid data, below threshold, by more than one step, or before the required unbroken confirmation. Nothing relocks.
  • A re-staging test: mixed bundles are refused, attestations on abandoned evidence create no rights, and the abandoned router and oracle are inert.
• Documented the revision in test/ADDITIONAL_COVERAGE.md.

Results. Full run: 170 tests passed across 37 suites, zero failed or skipped. No implementation defect was reproduced, so no findings file was written. The two failures hit during development were harness bugs in my own tests, since the distributor's contributor lock blocks early claims and forge-std's bound wraps rather than clamps.

Left as is. Changes are uncommitted in the working tree, matching how prior rounds were committed by the pipeline. The package's recorded deployment status and disclosed manipulation risks are unchanged by this tests-only revision.

The review is complete and .imd-findings.json is written at the repository root.

Outcome: all four code findings from the prior round are fixed and verified; nothing new reproduces. The revised tree builds and passes all 170 tests.

What I settled, each against my own re-run of the original reproduction:

• Seed tolerance (medium, a4b5f9a2): fixed. The exact prior scenario, with the pool short of 870M by about 7e12 wei, now launches, stages, activates and trades. The 1e12 tolerance became a 99% band, every stage-1 precondition now runs inside the staging call, staging can repeat until activation, and a superseded bundle cannot activate. A seed below the band reverts the launch transaction itself.
• Seed capacity (medium, d8778e80): fixed. Launching at tick -177840 now reverts inside the factory's seed callback, so no pool with a permanently dead oracle can exist. Hook, oracle and activation share one capacity formula and the live position is re-read at staging and activation.
• Confirmation asymmetry (low, 66b99dca): fixed. An invalid sample no longer writes anything, so observed and unobserved feed lateness produce the same outcome. The author's snapshot-based test proves it.
• Leaf cap (low, 153c7ae8): fixed. Chunked certification certifies a 1500-leaf round and the claimants' credits sync.

Two items the author disputed are kept as info entries only, with no change requested. The protocol-fee halt and the treasury's power to create quota through later rounds both still reproduce and are now written up as explicit release decisions in the security review document.

I also confirmed the pinned Sepolia service code hashes against the live chain on two public RPCs. All five match. One residual stays documented as a preflight rather than a finding: a round-0 root with a duplicate recipient could never be certified, and that root is known before stage 1 is broadcast.

The coverage record answers all 28 entry points, plus rows for each settled finding, the manifest, and the Sepolia pins. My scratch tests were removed and no repository file was changed.