The IMD PUMP launch is implemented, tested, documented and committed on main as commit f385196. A fresh clone builds and passes offline with an empty environment.

What was built

• src/IMDPumpToken.sol: the token. Name "IMD PUMP", symbol "IMDPUMP", 18 decimals, 1,000,000,000 minted once to msg.sender (the factory). No taxes, no owner, no mint, no pause, no blacklist, no burnFrom. Holders can burn their own tokens.
• src/IMDPumpRevenueSplitter.sol: the application contract carrying the brief's allocation model. Revenue arrives in IMD and is split 20% burn, 15% developer, 25% treasury, 20% operations, 20% NFT workers (35% IMD-directed). Anyone can call distribute. Owner (the requester, a constructor argument) can re-point the four recipients, set the burn sink, and adjust the allocation for the three-month review, all through event-emitting setters. It rejects ETH, uses SafeERC20 and a reentrancy guard, and lets the owner recover stray non-IMD tokens.
• script/Deploy.s.sol: a reference deployment whose deploy(Config) function the tests call directly.
• README.md: assumptions, constructor arguments, after-launch settings, operational responsibilities and trust notes.
• lib/: OpenZeppelin Contracts v5.7.0 and forge-std v1.17.0 vendored as plain files, no submodules.

One design decision worth knowing

The IMD token on mainnet has no burn function. I checked its deployed bytecode: it has transfer, transferFrom, owner, but no burn or burnFrom. So a "verified burn" is a transfer to a burn address that only the IMD project can name. The splitter keeps that as an owner-set burnSink. Until it is set, the 20% burn share accrues in pendingBurn and every other share pays out normally. The owner should call setBurnSink soon after launch. This is listed in the README under "After launch".

Checks run

Slither was not available on this machine, so it did not run. The code avoids the six rejected detectors by construction: no selfdestruct, transferFrom only from msg.sender, no proxies or initializers, no shifts, no abi.encodePacked.

Open items for the requester or launch

• Set the burn sink after launch to the IMD project's recognised burn address.
• The splitter's owner_ constructor argument should be filled with the requester's owner address, and payout_ with 0x83027AD9d0D5374335086c539dADD1db983441B0, revenueToken_ with the IMD address.
• An independent adversarial review is still expected before release.

Created launch.json with the exact supply, constructor arguments, pool settings and economics. Notes document the pending burn configuration.

Manifest and compiled ABI checks passed. forge build succeeded; all 56 local tests passed with the supplied fuzz seed.

Only launch.json is changed for submission.

The review is complete. The findings file is written at the repository root and validated.

Result: no defects in the math area. The findings list is empty and the coverage record answers all 17 entry points plus four invariant and boundary rows, every one holds.

What I checked against the Math Precision, Boundary and Numerical Gap guides:

• Split arithmetic. Four shares floor-divide by 10,000 basis points and the treasury takes the remainder, so the five shares always sum exactly to the revenue. The remainder never underflows because the allocation is forced to sum to 10,000. Confirmed by fuzzing up to the full mainnet IMD supply and under random allocations.
• Zero-rounding. With 4 wei of revenue the burn, developer, operations and worker shares are all zero and the treasury gets everything. The loss is under 1 wei per bucket per distribution and does not compound. The code documents this, and the auditor checklist treats dust-level non-compounding loss as not reportable.
• Overflow. The largest intermediate is revenue times 2,500, which only overflows above roughly 4.6e73 wei. IMD's supply is 4.23e24, so this is unreachable.
• Casts and sums. The allocation setter sums in uint256, so five maxed uint16 inputs are rejected rather than wrapped. The combined IMD-directed share stays at most 10,000, so its uint16 addition cannot revert.
• Balance invariant. After every distribution the splitter's IMD balance equals the pending burn exactly, and the burn drains it to zero. A second distribute with nothing new reverts as intended.
• External boundary. I read the real IMD token's bytecode and metadata from a public Ethereum RPC. It is a LayerZero OFT with plain OpenZeppelin ERC-20 transfer semantics, 18 decimals, no pause, blacklist or burn function. SafeERC20's assumptions hold for it, and any non-zero burn sink accepts transfers.
• Token. Supply constant is exactly 1e27 minted once to the deployer. Self-burn reverts above balance. The vendored OpenZeppelin v5.7.0 ERC-20 is unchanged.

One trust note recorded in coverage rather than as a finding: if the owner renounces ownership before setting the burn sink, future burn shares accumulate forever since IMD cannot be recovered. That requires an owner action and has no unprivileged trigger.

The project's own 56 tests pass. My scratch tests were removed, and no repository file was changed apart from creating the findings file.

The economics audit is complete. The findings file at the repository root holds two substantiated findings and a coverage row for every one of the 17 listed entry points plus four invariant and dependency rows. No source file was changed.

What I found

• Low: allocation and recipient setters race the permissionless distribute(). Revenue already delivered is split by whatever allocation and recipients are current when distribute runs, not those in force when it arrived. A recipient about to lose share can front-run setAllocation or a re-point and lock in the old split, and the reverse ordering pays a new recipient revenue earned by the old one. Reproduction: 1,000 IMD waiting, owner cuts the developer from 15% to 5%, developer calls distribute first and takes 150 instead of 50. The fix is to settle waiting revenue inside the five setters. Proof test attached.
• Low: renounceOwnership is inherited unguarded. Renouncing while the burn sink is unset locks the 20% burn share of every past and future distribution in the splitter forever, since nobody can set the sink, burnPending reverts, and recoverToken refuses IMD. No BurnExecuted record is ever produced. Fix is to refuse renouncing while burnSink is zero. Proof test attached.

Both proof tests fail on the current code and pass on a patched copy I built outside the repository, so they hold the author to the stated fixes.

What holds

• Revenue conservation, rounding dust to treasury, the balance-equals-pendingBurn coupling, and the lifetime totals all hold under the launch split and arbitrary allocations, including 1 wei inputs.
• depositAndDistribute splits the measured balance rather than the argument, so a short delivery cannot over-pay.
• I fetched the real IMD token's mainnet bytecode. It is a LayerZero OFT on OpenZeppelin ERC-20 with no pause, blacklist, fee or burn selector, so IMD behaviour cannot block or distort distribution.
• The token is a plain fixed-supply ERC-20 that satisfies every launch-floor flow.
• Both static-analysis leads are false positives and are recorded as such in the coverage.

Trust assumptions, not defects: the burn sink is any non-zero, non-self address the owner chooses, and the owner can re-point all five buckets and change the split. Both are documented in the README and are the requested design.

Not reached: nothing within the assigned area. No launch.json exists yet, so manifest constructor arguments for the splitter were not reviewed.

Review complete. The findings file is written at .imd-findings.json with 2 findings and 21 coverage rows, and no repository file was changed.

What I checked. I traced both contracts against the Execution Trace, Periphery and First Principles guides, ran the project's 56 tests (all pass), and inspected the splitter's one external dependency, the mainnet IMD token. Its runtime holds only OpenZeppelin ERC20 and LayerZero OFT selectors, with no tax, limit, pause or blacklist, and no proxy slot. A mainnet fork test confirmed the splitter pays exactly 80% to the payout address and burns exactly 20% to a dead address with the real token.

Findings.

• Low: the inherited renounceOwnership() is unconditional. If the owner renounces before setting the burn sink, the accumulated 20% burn share can never leave the contract, since both burn paths require a sink, the setter is now unreachable, and recoverToken refuses IMD. It also freezes the allocation and recipients, which conflicts with the planned three-month review. Reproduced with a Foundry test. Fix: override it to revert, or require the sink to be set and the pending burn to be zero.
• Info: distribute() is permissionless by design, so a third party can lock in the current recipients for IMD already sitting in the contract before the owner reconfigures, and can inflate the lifetime counters by sending dust. Mitigation is operational: use depositAndDistribute so configuration always precedes money.

What holds. All 17 entry points received a row. The share math sums exactly to revenue with dust to the treasury and cannot underflow. Balance-based accounting keeps the splitter's IMD balance at or above pendingBurn on every path. Both static-analysis leads are benign. The token is an unmodified OpenZeppelin ERC20 with a self-only burn, meeting the launch floor.

For the manifest step: the splitter's owner_ must be $requester, never $factory, or the Owners floor rejects it.

The review is complete. Findings are in .imd-findings.json with every snippet verified against the tree and all 17 entry points answered.

What I found (permissions area: Access Control, Trust Gap, Asymmetry)

• Medium: setBurnSink is a retroactive sweep. It refuses only the zero address and the splitter itself. Every distribute() before the sink is set publicly accounts 20% as burn share in pendingBurn, totalDistributed and the RevenueDistributed event. The owner's first setBurnSink then decides where all of that goes, and burnPending() records the transfer as BurnExecuted/totalBurned. Reproduced: two distributions of 1,000 IMD, setBurnSink(owner), burnPending() puts 400 IMD in the owner's wallet with totalBurned == 400e18. Fix options: constrain the sink to a canonical dead address, or fix it at construction.
• Medium: inherited renounceOwnership has no guard. Every other path refuses the zero address, but renouncing before the sink is set makes it unsettable forever. Reproduced: pendingBurn of 200 IMD becomes unreachable, and each later distribute() strands another 20%. Fix: override to revert, or require burnSink != 0 first.
• Low: permissionless distribute() races owner setters. Revenue sent by plain transfer and not yet distributed is split under whatever is in storage when distribute() runs. A recipient whose share is being cut can front-run setAllocation and lock in the old split. Reproduced with a developer taking 150,000 instead of 50,000 IMD on 1,000,000 waiting.

What holds. The token is an unmodified OpenZeppelin ERC-20 with self-only burn, no owner and no exemption logic. Two-step ownership, all recipient setters, recoverToken and depositAndDistribute have correct guards. I diffed every vendored OpenZeppelin file the contracts inherit against the upstream v5.7.0 tag and they are byte-identical. The IMD mainnet token is a LayerZero OFT with no pause, blacklist or burn, so the IMD owner cannot freeze distributions.

Static-analysis leads. The Slither strict-equality on revenue == 0 and the Aderyn storage-to-memory struct copy at the preview function are both benign and were not reported.

Not reached. launch.json is not in the tree, so the actual owner_ constructor argument the manifest will pass could not be checked. Only the three permission guides were applied in depth. The scratch test directory was removed, so no repository file is changed.

Added failure-path, fuzz, wallet-gas, and invariant tests under test/.

Verification passed with the specified seed: 109 tests, including 65,536 invariant calls. forge build also passes.

No confirmed implementation defects found. Production contracts and configuration remain unchanged.

Review complete. The findings file is written and valid, no source files were changed, and only test/scratch/ holds my reproductions.

Outcome: 3 findings kept from 7 specialist reports, 17 of 17 entry points answered, plus 5 invariant and manifest rows.

Findings written to .imd-findings.json:

1. Medium: unguarded renounceOwnership(). Merged from three specialists reporting the same root cause. The inherited one-step renounce has no guard, so renouncing while the burn sink is unset strands the burn share forever and freezes every setting. Reproduced with the economics specialist's proof, which fails on the current code for exactly the stated reason. Attached as proof.

2. Low: in-flight revenue is split by whatever allocation and recipients are current at distribute() time. Merged from three specialists. A recipient about to lose share can front-run the owner's setter. I replaced the specialist's proof with a fix-agnostic one that passes whether the author settles first or rejects setters while revenue waits. Verified failing on the current code.

3. Low: setBurnSink retroactively redirects already-accounted burn share and records it as a verified burn. Downgraded from the permissions specialist's medium. The actor is the owner, who already controls all future flows, so it is a misdocumented privileged power rather than a bypass. Reproduced with a passing demonstration test.

Dropped: the slither strict-equality lead (a plain zero check), the aderyn storage-array lead (a storage-to-memory copy), the counter-pollution note (documented behaviour), and centralization and literal-size notes.

Own pass found nothing new. I verified the real IMD token on mainnet is a LayerZero OFT standard ERC20 with no burn, pause, blacklist, fee or proxy, so the splitter's dependency assumptions hold. The manifest matches the constructors and supply, and the existing suite passes with 109 tests.

All three findings are answered and the work is verified.

Reproduced and fixed (medium, the proof): renounceOwnership() succeeded with the burn sink unset, stranding the 20% share forever. The splitter now overrides it to revert with a RenounceDisabled error, so ownership moves only by two-step transfer. The reviewer's proof passes on the result, and three new tests cover the disabled call, the sink still being settable afterwards, and the stranger path.

Reproduced and fixed (low, setter race): revenue waiting in the contract was split by whatever allocation and recipients were in storage when a permissionless distribute() ran, so an owner setter and a recipient could race over it. Every setter now settles waiting revenue under the old terms before writing, and is reentrancy-guarded since it now makes transfers. I chose settling over refusing while revenue waits, because the latter lets anyone block every setter with a 1 wei transfer. I confirmed from IMD's verified source that it is a LayerZero OFT with plain ERC-20 transfers, so a settle inside a setter cannot deadlock a re-point. Eight new tests cover the report's exact 150/650 scenario, each setter, the no-revenue case, reentrancy, and a rejected allocation.

Reproduced, fixed by documentation (low, burn sink): the owner can name any sink and the first one receives the already-accrued pending burn, which the header and README had misdescribed as owner-proof verification. The code is unchanged for this finding. The header, the setter docstring and the README now state plainly that the record attests a transfer to an owner-chosen sink, and that verification means checking that sink against the IMD project's burn address.

Results on this tree, with the verifier's fuzz seed:

Changed files: src/IMDPumpRevenueSplitter.sol, test/IMDPumpRevenueSplitter.t.sol, README.md, plus .imd-responses.json at the repository root with the three verdicts. Nothing was committed, as the brief did not ask for it.

The accepted manifest is correct and needs no revision. No findings were attached to this round, and every check passes.

What I verified

• The token contract takes no constructor arguments and mints the whole supply to the deployer, so an empty constructorArgs list and a totalSupply of one billion in minor units match the source.
• The splitter constructor takes owner, payout and revenue token, in that order. The manifest passes the requester twice and the IMD address, which matches the accepted implementation.
• The pool and economics objects are byte-for-byte the launch's values, with lowercase addresses.
• Only the six schema keys are present, every contract name is unique and within 32 characters, and notes are well under the 4,000 character limit.
• The build compiles cleanly and the full test suite passes with the verifier's fuzz seed, 67 tests across 3 suites.

What changed

Nothing. The working tree is clean, and launch.json is left as accepted. Rewriting a verified manifest with no finding against it would only give the reviewer a different file to read for no gain.

The revised splitter had broken five of my existing tests. I updated them to the new behaviour, added tests for it, and reported one defect I couldn't test around. With the verifier's fuzz seed, forge build succeeds and forge test passes all 125 tests in my test paths. The only failure is the proof test for the defect, which is meant to fail and lives in test/scratch/, so it isn't submitted.

Why the tests broke. The other contributor's last change made two behaviour changes:

• Setters pay out first: every owner setter now pays out any revenue already sitting in the contract under the old settings before applying the new one.
• No renouncing: renounceOwnership is disabled.

The changes:

• test/IMDPumpRevenueProperties.t.sol
  • Fixed three tests that assumed setting the burn address wouldn't trigger a payout.
  • Replaced the renounce test with one checking the call is refused for the owner and the nominee, and that ownership and pending ownership are unchanged.
  • New tests:
    • All six setters pay waiting revenue to the old recipients, even when the value doesn't change. With nothing waiting, they only emit their own event.
    • A rejected setter call pays nothing out.
    • Someone front-running a recipient change with a 1-wei donation can't redirect it: the old recipient gets the dust.
    • The token can't re-enter the contract during a setter's payout, including re-entering a setter.
• test/invariant/IMDPumpRevenueInvariant.t.sol: the random-sequence handler now checks each setter's payout against the old rates, recipients and burn address. It also tries owner renounces, which must revert. All five invariants hold over 256 runs × 128 calls.
• test/IMDPumpWalletGas.t.sol: added a check, using the supplied helper, that setTreasury, setBurnSink and setAllocation behave the same at a wallet's gas limit as with gas to spare when revenue is waiting.
• test/TESTING.md: updated to match.

Reported defect (low), in .imd-findings.json with a runnable proof test. Because every setter pays out waiting revenue first, the owner can't replace a recipient or burn address whose incoming transfer reverts while any revenue is waiting. distribute() is blocked by the same failing transfer, and anyone can keep revenue waiting by sending 1 unit of IMD. IMD then can't leave the contract at all.

According to the README, the real IMD token uses plain transfers that don't revert for normal addresses, so today's deployment isn't exposed. That's why I rated it low. My tests don't treat this behaviour as correct.

I didn't commit anything.

The review is written to .imd-findings.json. All three findings from my earlier round are settled as fixed, and nothing new blocks the launch.

Settled findings

• renounceOwnership strands the burn share (medium). Fixed. The function is overridden to revert with a new error, so ownership moves only through the two-step transfer. My attached proof passes both tests on the revised code.
• Setter versus distribute() mempool race (low). Fixed. All six owner setters now settle any waiting revenue under the old terms before writing. My proof and the economics specialist's proof both pass, and the author's eight new tests covering this pass.
• setBurnSink retroactively directs pendingBurn (low). Settled as a documentation fix, as the author answered. The header, the setter docstring and the README now say the burn record attests a transfer to the owner-chosen sink, not that the sink is a burn address. The code behaviour is an owner power, recorded as a trust assumption.

The tester's new finding

The independent tester reported that the settle-first setters cannot re-point a recipient the revenue token refuses while revenue is waiting. The proof does fail on this code, with a mock token that rejects one address. I kept it as info only, because the precondition is unreachable with the token the splitter binds. I checked the IMD token on Ethereum mainnet directly. It is not a proxy, and its selector set is a LayerZero OFT with plain OpenZeppelin ERC-20 transfers and no pause or blocklist function. A transfer to any non-zero address cannot revert, and the setters already refuse the zero address and the splitter itself. The finding states explicitly that no change is required for this launch.

Other checks

• The full test suite passes on this tree, 131 tests, with only the tester's mock-token proof failing as described.
• Both static-analysis leads are false positives. The strict equality is a revert guard on a computed difference, and the memory copy of the allocation struct feeds a pure function.
• The protected floor tests could not run here because they import the verifier's harness, which is not in this tree. The verifier runs them.
• All sixteen entry points are answered in the coverage record, plus rows for the three settled findings, the two static leads and the deployment inputs.

Nothing under test/scratch/ is kept, and no project file was changed.