Implemented NightshiftVault with CREATE2 forwarders, vendored dependencies, tests, and deployment documentation.

Validation passed: forge build, all 56 tests, and forge fmt --check, including stateful invariants and local Uniswap v4 integration.

Prepared for IdentityMD’s review and deployment step. No live transaction was broadcast.

Done. launch.json is written and validated, and the working tree contains no other changes.

What the manifest declares

• One application contract, NightshiftVault, with an empty constructor argument list.
• The accepted source at src/NightshiftVault.sol:188 has a no-argument constructor. The contract owner, initial role holder, asset addresses, fee splitter, BurnExecutor, dead address, pool key and default caps are all compile-time constants, so no $owner argument exists to fill. The hard-coded owner matches the launch owner stated in the brief.
• DepositForwarder is not listed. The vault deploys it on demand through CREATE2, and the README's deployment handoff says the same.
• Notes are explanatory only, well under the 4000 character limit.

Verification

• forge build compiles cleanly.
• forge test with the verifier's fuzz seed passed all 56 tests across 7 suites, including the deployment rehearsal that checks the fixed owner, predictable CREATE2 address and forbidden-opcode scan.
• Manifest checked for exact keys, kind, string arguments, identifier length and notes length.
• git status --porcelain shows only the new launch.json.

Added 18 regression tests and strengthened stateful invariants with independent account ledgers, ownership changes, donations, and unauthorized withdrawals.

forge build and all 77 tests pass with the required seed. Formatting and diff checks pass. Only test/ changed.

Live pool and hook verification remains outside the offline suite.

The review is complete. The findings file is written, validated against the tree, and the scratch tests are removed so no tracked file changed.

Outcome: no critical, high or medium defects found in the control-flow area. The file .imd-findings.json holds two low and two info findings plus a coverage row for all 27 entry points and two invariants.

What I checked

• Traced every state-changing entry point of NightshiftVault and DepositForwarder through its guards, state writes, external calls and failure paths, against the Execution Trace, Periphery and First Principles guides.
• Ran the existing suite: 56 tests pass, including the invariant suite with revert-on-failure enabled.
• Ran a mainnet fork probe: the hardcoded Uniswap v4 pool is initialised, the hook at the fixed address permits the vault's exact-input swap, the fee splitter accepts plain ETH plus IMD and SHIFT, and the IMD burn executor accepts IMD. The slither and aderyn leads (arbitrary ETH send, reentrancy in sweep and the callback, packed-encoding collision) all resolve to intended behaviour with guards in place.

Findings reported

1. Low. Owner and operator purchase signatures share one nonce in buyWithSig, so an operator-signed purchase relayed first invalidates an outstanding owner-signed one. Reproduced with a scratch test.
2. Low. setCaps replaces the whole pending change, so lowering only the per-game cap restarts the 24 h clock on a pending daily raise. Reproduced with a scratch test.
3. Info. Sweeping an empty deposit address emits a zero-amount Deposited event anyone can spam.
4. Info. The 5% fee is pushed to the external fee splitter inside settle. It accepts ETH today, but if it ever rejected ETH, winners could only be refunded. This is a trust assumption on an owned external contract, recorded for awareness.

Not reached. I did not reverse the hook's bytecode to confirm it has no sender allowlist that could later block the vault's burn swap. The fork run today succeeds, so this is only a forward-looking dependency note.

The review is complete and .imd-findings.json holds the result: two low findings, one info trust assumption, and a coverage row for all 27 entry points plus two invariants.

What I found in the assigned area (Access Control, Trust Gap, Asymmetry)

• Low, register at src/NightshiftVault.sol:285. Funds sent to a deposit address before that accountId is registered are outside every operator bound. A compromised operator co-signs a registration naming its own wallet, front-runs the player's pending registration for the same accountId, then sweeps and withdraws the whole balance. The daily cap only covers balances already credited to a registered account. Confirmed with a scratch test that takes 1 ETH against a 0.05 ETH cap.
• Low, invalidatePurchaseNonce at src/NightshiftVault.sol:555. The owner may set the purchase nonce to the maximum uint256, after which every relayed purchase reverts on the increment and the setter refuses any new value. The gasless purchase path is permanently dead for that account. Direct purchases still work, so no funds are lost.
• Info, postPrizes at src/NightshiftVault.sol:636. Recorded as the main trust assumption rather than a defect: the operator can post any root for the full pot and claim it to its own account in the same block. This matches the brief, so it is documented for the launch record with a suggested delay.

What held. Every other entry point traced clean for my area: the owner has only pause and 48-hour role rotation, every fund recipient is a constant, withdraw goes only to the account owner, caps and freeze cannot be accelerated, settle and refund are mutually exclusive, and the pool callback is bound to one in-flight keeper burn. I verified on-chain that the fee splitter accepts plain ETH, so settlement with a winner cannot be blocked by it. The existing suite of 56 tests passes.

Not fully reached. I did not verify the live SHIFT hook's trading-open flag or hook fee behaviour against the burn path. That sits outside my area and affects only whether burns revert, not custody.

Note on the static analysis leads. The slither and aderyn lines for sweep reentrancy, encodePacked collision, uninitialized _spending and timestamp use were each traced and none produced a reachable defect.

The review is complete and the findings file is written and validated.

Outcome. The economics of NightshiftVault hold up well. I traced the conservation invariant (player funds + pot + reserved prizes + burn reserve never exceed holdings) through every state-changing path and found no leak. Purchase splits are exact, the 5% fee rounds dust to the winner, the rolling cap check matches its view function, cap raises and unfreezes cannot be shortened, and the Uniswap v4 callback's delta decoding and exact-input check are correct for the hook's permissions. The existing 54 unit tests pass. I also verified the hardcoded mainnet dependencies over RPC: the ETH/SHIFT pool under that exact key is initialised, IMD and SHIFT are plain 18-decimal ERC-20s with no tax, and the fee splitter accepts a raw ETH call.

One finding, rated low, with a failing Foundry proof under test/scratch/PreRegistrationForwarder.t.sol:

• Pre-registration deposits escape the compromised-operator cap model. A deposit address is computable before registration, and register binds any unused id to whichever owner the operator key plus any owner key names. A compromised operator can register a funded but unregistered id to its own wallet, front-running the player's own registration, then sweep and withdraw the whole balance. The test shows 1 ETH extracted against a 0.05 ETH daily cap. The honest-operator variant is a liveness gap: funds sent to a never-registered id stay in the forwarder with no other recovery. The suggested fix derives the required account id from the owner's address so a forwarder can only ever be credited to the wallet it was generated for.

Coverage. All 27 listed entry points have a row: 26 hold, register carries the finding. Two invariant rows were added. Not reached within budget: a full fuzz run of the invariant suite and a live-fork execution of burnReserve against the real hook. Static analysis leads (reentrancy in sweep, arbitrary ETH send, uninitialized _spending, encodePacked collision) were each checked and dismissed as false positives given the reentrancy guard, fixed recipients, mapping semantics and fixed-length encoding.

Review complete. The findings file is written and validated, and no source file was changed.

Outcome. The math in NightshiftVault holds up under the Math Precision, Boundary and Numerical Gap checklists. I found no critical, high or medium defect in that area, so no proof tests were attached. The report in .imd-findings.json carries one low finding, three informational notes and a coverage row for every one of the 27 entry points plus three invariants.

Findings recorded:

• Low. The owner can set the purchase nonce to the maximum value with no upper bound, after which every relayed purchase for that account panics on the checked increment forever. Direct purchases still work, so no funds are at risk.
• Info. The 5% settlement fee rounds down, which means zero fee for pots under 20 wei and at most 1 wei short otherwise. Conservation still holds.
• Info. Sweeping an empty forwarder succeeds and emits a zero-amount Deposited event that anyone can trigger.
• Info. All purchase paths reject odd raw amounts to keep the half-and-half split exact, so off-chain prices must be even.

What I verified beyond reading. The project's 56 tests pass, including the invariant suite. Four scratch tests in the gitignored scratch directory confirmed each reported edge. Against live mainnet state, I overlaid the vault bytecode with a funded reserve and simulated a real burn of 0.001 ETH through the production pool and hook, which returned about 37,464 SHIFT, so the swap, delta unpacking and hook interaction work in production. I also confirmed the fee splitter accepts a plain ETH push, the pool key is initialized with the expected fee, and IMD and SHIFT transfers to their burn destinations return true from a live holder.

Coverage. Every entry point is answered as holds or finding. No row is unreached. Areas I touched only lightly because they belong to other specialists: the operator trust model around registering accounts for pre-funded forwarder addresses, and the hook's ability to take output fees, which the keeper's minimum-output parameter already bounds.

The review is complete and .imd-findings.json holds 10 substantiated findings plus a 29-row coverage record answering all 27 entry points.

Outcome. No critical or high defects. The contract matches the brief on every rule I traced: custody, caps, delays, settlement, splits, prizes, roles and pause scope. All 77 project tests pass, and I ran burnReserve on a mainnet fork against the live PoolManager, hook and SHIFT token. The swap executed and every SHIFT went to the dead address, so the one external dependency the specialists could not exercise now has evidence.

Findings kept, after reproduction and merging:

• Low, merged from permissions and economics: funds parked at a deposit address before registration follow whichever owner the operator registers first, so a compromised operator can take them without any cap. The attached proof fails on this tree as stated.
• Low, new: the vendored OpenZeppelin 5.1.0 signature checker sends any signer with code to ERC-1271 only. An EIP-7702 delegated wallet without that interface cannot register, be made owner, or relay purchases. I hit this live on the fork and reproduced it offline.
• Low, merged from math and permissions: setting the purchase nonce to the maximum value bricks relayed purchases for that account permanently.
• Low: owner and operator relayed purchases share one nonce, so either side cancels the other's outstanding signature.
• Low: calling setCaps to lower one cap restarts the 24 h delay of the other cap's pending raise.
• Info: zero-amount sweep events, fee rounding on tiny pots, even-amount requirement, the push dependency on the fee splitter, and the operator's unconstrained prize root as a trust assumption.

Dropped or downgraded. Nothing from the specialists failed to reproduce. All static-analysis leads were false positives: the ETH recipients are the owner or fixed beneficiaries, the reentrancy lines sit under the outer guard, the hash-collision line uses fixed-size inputs, and the "uninitialized" state is a mapping.

Manifest. The launch file has only the schema keys, one contract with no constructor parameters, and the owner and all roles are compile-time constants rather than the factory. Runtime and creation sizes are within limits.