Implemented the collection and vault, tests, vendored dependencies, ABIs, and integration documentation.

• forge build, forge test, and forge fmt --check pass.
• 43 local checks and 28 Ethereum-fork tests pass.
• IMD’s 18 decimals were verified onchain.

Mainnet deployment, GitHub publication, source-commit pinning, independent review, and Etherscan verification remain pending network release steps. No live issues or purchases were created.

See README and release handoff.

launch.json is written and is the only changed path in the tree.

What the manifest declares

• IMDDailyVault first, with an empty constructor argument list. The compiled ABI confirms it has no constructor parameters.
• IMDDaily second, with the single address argument $contract:IMDDailyVault. The compiled ABI confirms one parameter, address vault_.
• No owner argument appears because both contracts inherit a fixed authority. The publisher wallet from the brief and the existing IMD token are hardcoded constants, so neither the factory nor the launch wallet can hold any role.
• The notes field explains the collection, the fixed publisher and payment token, the 0.1 IMD price, the 24-hour window, the vault custody rules, and the empty-chain-safe constructor. It is well under the 4000 character limit.

Checks run

• A schema check on the file passed: only the keys kind, contracts and notes, string arguments, unique identifiers under 32 characters, and a backward-only contract reference.
• A clean offline build and the full test suite passed with the verifier's fuzz seed and an empty environment. The one skipped test is the mainnet fork suite, which skips itself by design when no fork is configured.
• The repository's own deployment rehearsal already exercises this exact two-step CREATE2 order from a single factory call and passed.

Release status, unchanged by this task

The contracts remain implemented and locally tested but not deployed. Source publication, attestation, review, factory deployment and Etherscan verification are later stages of the launch workflow, as the repository's release document already records.

I found no math defects in my area, and one low-severity custody issue outside it. The results are in .imd-findings.json at the repo root, with a coverage row for each of the six entry points (all holds) plus two invariant rows. The local suite passes (43 passed, 1 skipped); I ran the fork tests only through their saved output, not against the live chain.

What I checked (Math Precision, Boundary and Numerical Gap):

• Price: PRICE = 1e17 is exactly 0.1 IMD at 18 decimals. The saved onchain evidence shows decimals is 18 (0x12), and mint re-checks it every time. There is no division, so nothing rounds or loses precision.
• Cost calculation: quantity * PRICE uses Solidity's overflow-checked multiplication, so an oversized quantity reverts instead of wrapping. Zero quantity is rejected in both mint and quote.
• Mint window: I tested the boundary in a temporary Foundry test. A mint at publication time + 86399 seconds succeeds and one at + 86400 reverts with MintClosed. A mint in the same block as publication is allowed, and the editorial date has no effect on eligibility.
• Deadline: it is inclusive (a mint whose deadline equals the current time succeeds). It is checked separately from the window, so it can't extend it.
• Payment and withdrawal checks:
  • mint compares the vault's and the payer's IMD balances before and after the transfer.
  • withdraw does the same for the vault and the publisher.
  • Zero and over-balance withdrawals revert before any funds move.
  • Partial withdrawal works.
• Counters: vault balance + totalWithdrawn = totalCollected + donations to the vault. totalWithdrawn can exceed totalCollected once donations are withdrawn; the README documents this as intended, so I didn't report it.
• Supply: an issue's supply can't grow after its window closes. Transfers don't change supply, and real IMD supply rules out overflow.
• Static-analysis leads:
  • Slither's two timestamp warnings are the required time window, not defects.
  • Aderyn's "reentrancy" high is a false positive: its only external calls before state changes are reads to the fixed IMD token and the vault, and mint is nonReentrant.

Finding (low): IMD sent directly to the IMDDaily collection contract is locked forever. Collectors approve the collection, not the vault, so that's the address a mistaken transfer is most likely to hit. The collection has no function that moves IMD, and the publisher's vault.withdraw can't reach it (it reverts with InsufficientFunds(0, 1e18)). My temporary test confirmed this. A suggested fix is a publisher-only function that forwards the collection's IMD balance to the vault without counting it in totalCollected. I didn't attach a proof test because the format asks for those only on critical and high findings.

I deleted the temporary test afterwards; apart from .imd-findings.json, I changed no files.

The review is complete. The findings file is at the repository root and the working tree is otherwise unchanged.

Result: no critical, high or medium defects in the assigned economic area. One low finding.

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Value flows. Mint pulls exactly quantity * 0.1 IMD from the caller into the vault with checked multiplication, verifies the exact vault credit and payer debit, and rolls back payment, counters and supply together on any failure. Withdrawal goes only to the hardcoded publisher, supports partial amounts, and rolls back its counter on failure.
• Invariants. Collected revenue always equals total supply times price, and vault balance plus withdrawals always equals revenue plus donations. The existing invariant campaign and my own probes could not break either. Supply freezes at the closing timestamp, and no selector can reopen, extend, reprice or free-mint.
• Flow gaps. Receiver callbacks run after payment settles and cannot re-enter mint or publish. A publisher smart wallet can withdraw inside its own receive hook, and a rejected mint undoes that withdrawal. A donation made mid-callback leaves counters honest. Copies cannot be sent to the collection, vault or token address.
• Token dependency. I ran the fork suite myself against real mainnet IMD at the pinned block, and all 28 tests pass. The token is a LayerZero OFT with plain OpenZeppelin transfer semantics, hardcoded 18 decimals, and no fee, pause or blacklist. The residual trust is the token owner's peer configuration, which affects IMD's value rather than these contracts' accounting.

The one finding (low): IMD transferred directly to the collection contract is stranded forever. Nothing in the collection's ABI can move it, and the vault only reads its own balance. It is self-inflicted and documented in the README, but the integration guide steers users to the collection address for approvals, which makes the approve-versus-transfer mistake plausible. A permissionless sweep from the collection to the vault, with no revenue accounting, would fix it within the brief's single-payout-destination rule.

Coverage: all six listed entry points hold, plus five invariant and dependency rows, with the stranding invariant pointing at the finding. Nothing in my area was left unreached.

The review is complete. The findings file is written and every snippet matches the tree. No tracked file was modified.

Outcome: no exploitable defect in the Access Control, Trust Gap or Asymmetry area. The permission model is two hardcoded constants and one modifier, with no initializer, role transfer, upgrade path, URI or price setter, owner mint or burn. I reported four info-level items, each a trust assumption or release hazard with a concrete reproduction, rather than a code bug.

What I verified:

• Local suite of 43 tests passes, including the invariant conservation and permanence checks.
• Fork suite of 28 tests passes against live Ethereum mainnet through publicnode. The pinned-block RPC error noted in the evidence did not recur at the latest block.
• IMD token at 0xd34a…63b7 is a non-proxy LayerZero OFT. Its 45 selectors are standard ERC20, Ownable and OFT. No pause, blocklist or fee logic exists, so the exact-balance assertions in mint and withdraw are safe against the token owner.
• Publisher wallet is not a plain EOA. It carries an EIP-7702 delegation to MetaMask's EIP7702StatelessDeleGator v1.3.0 with a DelegationManager. The delegate answers the ERC1155 receiver hook, so mints to the publisher work today.

Findings written to .imd-findings.json, all info severity:

1. Publisher authority is a smart account. Any path the MetaMask delegator authorizes, including EntryPoint userOps and redeemed delegations, satisfies the publisher check in createIssue and withdraw. The brief mandates the hardcoded authority, so this is documented, not fixed.
2. Publisher self-mints cost zero IMD. The publisher pays its own vault and withdraws it back, and those mints inflate totalCollected. Verified in a scratch test.
3. Wrong vault constructor argument is irreversible. The recipe forbids code checks in constructors, so a bad manifest argument other than the vault reference bricks mint forever. No launch.json exists yet. Verified in a scratch test.
4. No content-hash uniqueness. The publisher can republish an expired issue's exact files under a new ID, which is an economic reopening at the content level.

Coverage has ten rows: all six listed entry points plus four invariants. Three entry points hold outright and three carry the info findings above, with reasons per row.

Not reached within budget: the Pashov Boundary and Numerical Gap passes beyond what overlaps my three guides, and a full line-by-line read of the vendored OpenZeppelin ERC1155Supply override, which I treated as unmodified v5.4 per dependencies.json.

The review is complete and recorded in .imd-findings.json at the repository root. No repository file was changed.

Outcome: no funds-at-risk defect found in the assigned area. I traced every entry point through the Execution Trace, Periphery and First Principles checklists, re-ran the 43 local tests and the 128x48 invariant campaign (all pass), and cross-checked the periphery against upstream sources and the live mainnet token.

Findings written, ranked by severity:

• Low, dependency provenance. The vendored OpenZeppelin v5.4.0 and forge-std v1.9.7 files are not the bytes of the pinned archives. The project's own forge fmt rewrapped 10 OpenZeppelin and 19 forge-std files, yet dependencies.json calls them "Unmodified". A whitespace-stripped comparison is identical, so bytecode and behaviour are unaffected, but anyone verifying the base contracts against the archive hash gets a mismatch on exactly the files that implement mint, supply and payment.
• Info, known limitation. IMD transferred straight to the collection contract instead of through mint is unrecoverable. The author documents this already; a fix that keeps the single-authority design would be a permissionless sweep to the fixed vault.
• Info, trust assumption. The payment token is a LayerZero OFT with an active owner who can rename it and whose bridge peers can mint on Ethereum. It has no proxy, pause, blacklist or transfer hooks, so the contracts are sound against it. The one in-repo consequence is that the fork suite's setUp asserts the symbol, which that owner can change.

Coverage record: all six listed entry points are holds, with reasons, plus six invariant and periphery rows. The mint path's reentrancy argument was confirmed against the vendored ERC1155 source, which settles balances and supply before the receiver callback. Static-analysis leads (timestamp comparisons, state change after external call) were checked and are the intended eligibility rule and guarded view calls, not defects.

Not reached: the launch manifest itself, since no launch.json exists yet at this stage, and the docs and metadata schema beyond cross-checking the call examples against the compiled ABI, which match.

I added two test files to the existing suite. forge build succeeds and forge test with the verifier's seed gives 60 passed, 0 failed, 1 skipped. The skip is the real-IMD fork suite, which only runs when you pass a fork URL.

New tests

• test/IMDDailyEdges.t.sol (16 tests, mostly failure paths):
  • Mint window: at any publication time, minting works one second before close and is refused at close, a day later, and ten years later.
  • Caller deadline: it counts up to and including the stated second, and it can never extend the 24-hour window.
  • Funds: a buyer one wei short on either balance or allowance is refused, and exact funds succeed. The largest quantity that doesn't overflow fails for lack of funds, and one more fails on the overflow.
  • Withdrawals: exactly the balance works, one wei more is refused, and a split withdrawal works.
  • Authority: only the publisher can publish or withdraw. Any other address is refused, including whoever deployed the contracts and the transaction sender.
  • Other cases: paying requires approving the collection (approving the vault isn't enough). Copies can't be sent to the vault, the collection or the zero address. No burn or free-mint function exists. Issues published in the same block get sequential IDs in their events, and a later issue never reopens an earlier one.
• test/DailyModelInvariant.t.sol: an invariant suite that makes random sequences of publish, fund, mint, time-jump, transfer, donate and withdraw calls. Many calls are deliberately invalid: unknown IDs, zero quantity, a zero, rejecting or re-entering recipient, a past deadline, not enough funds, or a caller who isn't the publisher. For each call it predicts from the brief whether it should succeed and checks the contract agrees. A failed call must not move any funds.
  • Invariants checked after every call: the vault holds exactly revenue plus donations minus withdrawals. Only the publisher ever receives IMD. Buyers lose exactly what they paid. Supply, publication times and closing times match the model.
  • It ran 256 sequences of 64 calls. My first version almost never minted successfully, so the test would have passed while checking nothing. I adjusted it and confirmed that successful mints now happen in every campaign.

Fork run: I ran the existing fork suite against Ethereum mainnet via https://ethereum-rpc.publicnode.com, and all 28 tests passed against the real IMD token. This was a local simulation only. Nothing was deployed or broadcast, and it is not deployment evidence.

Findings (in .imd-findings.json)

• Low: IMD sent straight to the collection contract, instead of the vault, is locked forever. It is correctly left out of revenue, but nobody can recover it. Possible fixes are a publisher-only sweep that sends only to the vault, or a clear warning in the integration guide. My tests check that this IMD isn't counted as revenue; they don't treat the lock as correct.
• Info: the default forge test run never touches real IMD, because the fork suite skips itself offline.

I found no defects in minting, payment, access control or the mint window. I haven't committed anything.

The review is complete and the findings file is written. The working tree is otherwise clean.

Outcome. No critical, high or medium defect in the two contracts. Every state-changing entry point holds. The six findings kept are two low provenance and usability issues plus four documented trust assumptions, all reproduced against the code.

What I verified myself

• Build and the full local suite pass (60 tests, two invariant suites with fail-on-revert).
• The fork suite against real mainnet IMD at today's chain head passes all 28 tests.
• The manifest in the tree is schema-valid, orders the vault before the collection, and passes the backward reference correctly. Both runtimes are well within EIP-170 and EIP-3860 limits with no forbidden opcodes.
• The aderyn reentrancy lead and the slither timestamp leads do not reproduce as defects. Mint settles payment and counters before the receiver callback under a reentrancy guard, and the timestamp window is the brief's design.

Findings kept, in order

1. Low. IMD sent directly to the collection contract is stranded forever. Four specialists reported this; merged into one. Reproduced with a scratch test.
2. Low. The dependency record claims the vendored OpenZeppelin and forge-std files are unmodified, but 29 of them were reformatted. I downloaded both pinned archives, confirmed their hashes, and showed every difference is whitespace only.
3. Info. The hardcoded publisher is an EIP-7702 delegated MetaMask smart account. Confirmed with a live code read.
4. Info. Publisher self-mints are net zero in IMD and counted as revenue. Reproduced.
5. Info. Identical content can be republished under a new ID after expiry. Reproduced.
6. Info. The fork suite asserts the IMD symbol, which the token owner can change. Confirmed the owner and the rename selector.

Dropped. The wrong-vault-argument hazard, because the manifest in the tree is correct. The fork-suite opt-in skip, because that is the right behavior for the offline verifier.

Remaining release blockers are unchanged from the evidence file: source publication, mainnet factory deployment and Etherscan verification have not happened. The release status file states this plainly and separates fork results from real deployment.