The review is complete. The findings file is written and validated, and no source, configuration or test file in the tree was changed.

Outcome. One medium defect and one informational note in src/multichain/StackReceiver.sol. Nothing critical or high. The receiver's trust model holds: only the endpoint may call lzCompose, only for composes the IMD token queued, the amount is written by the token, the sum check is exact, the approval is set once, reentrancy is guarded, and stray IMD is never spent.

Medium: the zero-share fallback cannot work. The contract, the manifest notes and the brief all promise that a deposit minting zero shares pays that trader plain IMD. The revert ZeroShares() on line 124 sits inside the try success block, which Solidity's catch does not cover, so the whole delivery reverts and every retry reverts the same way. All IMD in that message would stay in the receiver forever, since there is no owner or rescue. A second point matters for the fix: a Solady vault that rounds to zero shares has already pulled the assets, so moving the case into the plain-IMD path after the deposit pays IMD the receiver no longer has. I verified that on a patched copy, which failed with an insufficient-balance error. The decision must come before the deposit via previewDeposit. Reachability is honest in the report: with the live vault a bridged amount is at least one bridge step, so zero shares needs a share price about 1e18 times the initial one, and the owner is renounced so the pause fallback is dead code too. The proof test under test/scratch/StackReceiverZeroShares.t.sol fails on the current code with ZeroShares() and passes against a corrected copy.

Info: ETH sent with a compose is stuck. lzCompose is payable and the contract has no way to move ETH out. Only a third party calling the permissionless endpoint with value loses its own ETH, since the RemoteStacker's options request no compose value.

Coverage. I read StackReceiver.sol, LayerZero.sol, RemoteStacker.sol, the IStakedIMD interface and the Stacker's credit path, the test doubles, the receiver, mainnet-fork and deployment tests, the protected harness and launch.json. I checked the compose message layout and the executor option encoding against the LayerZero OFT and OptionsBuilder formats from memory, since no LayerZero source is vendored. Through a public RPC I confirmed the live facts the manifest depends on: the vault's asset is IMD, IMD's endpoint is the manifest's endpoint, the vault owner is zero and it is not paused. The manifest has only the schema keys, one contract, three string arguments in declaration order, and notes under the limit. The full offline suite passed with 270 tests and 22 skipped, the fork and manifest skips the brief describes. I did not run the mainnet fork tests, since no RPC environment variable is set on this machine, and I did not audit the ProjectRegistry or the live Stacker, which this launch does not touch.

Fixed both reproduced findings: zero-share fallback now previews before depositing, and compose calls reject attached ETH. Added regression tests and ADAPTATION.md.

Validation:

• forge build: passed.
• forge test: 277 passed, 23 skipped, no failures.
• Live mainnet receiver fork: all 5 tests passed.

Manifest and protected files remain unchanged. Deployment stays with IMD’s launch process; the README address awaits confirmed deployment.

Updated launch.json, preserving the sole StackReceiver deployment and all three approved mainnet addresses. Clarified notes against the accepted implementation.

Validation passed: manifest structure, constructor ABI, and forge build. forge test: 277 passed, 0 failed, 23 skipped.

Only launch.json changed.

The review is complete. The findings file is written and validated, the snippet matches the tree, the scratch test is removed, and the working tree is clean apart from the findings file.

Outcome. The StackReceiver's permission model holds on every path I traced, and the manifest wires it correctly. I found one low-severity defect, in the RemoteStacker rather than the contract this launch deploys.

Finding 1, low, RemoteStacker credit at line 136. The waiting clock is an amount-weighted average of arrival times, but the tip reader caps at 12 hours. Once an old balance has waited past the cap, a new credit merges to a clock that is still 12 hours or older, so the new IMD pays the full 2% tip the moment it arrives. With 1000 IMD waiting 24 hours and a fresh 1000 IMD credit, the flusher takes 40 IMD where the documented rule yields 20. I confirmed the numbers with a scratch Foundry test. The trader still keeps at least 98%, so impact is bounded, and the existing clock test never merges past the cap.

StackReceiver, my assigned area, holds. Specifically:

• Only the endpoint may call lzCompose, and only for a compose the IMD token itself queued, so the amount in the message is the amount minted.
• The list must sum exactly to that amount, so a sender can only pay out its own IMD. Stray IMD is never spent.
• No owner, no sweep, no initializer, no upgrade. The vault approval is spendable only through the receiver's own deposits.
• The endpoint refuses a second delivery of the same compose, and value-carrying calls are rejected without consuming the queue.
• One accepted asymmetry noted in coverage: the receiver lacks the InvalidTrader guard the Stacker and RemoteStacker have, so a direct OFT sender naming the receiver or vault as trader strands only its own IMD.

Coverage. All 13 listed entry points have rows, plus rows for the manifest, the conservation invariant and the trust assumptions. The eight ProjectRegistry entry points are marked holds on the ground that this launch does not touch the live registry, and the row says they were not re-traced here. Trust assumptions recorded rather than reported: the IMD OFT owner's token-level powers, LayerZero executor liveness, and the vault's one-block hold stamped on each delivered trader.

Checks run. The offline suite passed with 277 tests and 23 skipped. Fork tests did not run because no RPC URLs are set in this environment.

The review is complete and .imd-findings.json is written with one substantiated finding and 17 coverage rows (every listed entry point plus the invariants and manifest I checked).

Result of the math audit of the StackReceiver launch

The deployed contract, StackReceiver, holds on every item in the Math Precision, Boundary and Numerical Gap guides that I could apply:

• Compose decoding slices the amount, source eid and payload at the same offsets as LayerZero's codec, so the amount the receiver pays out is the one IMD's own lzReceive minted.
• Sum check uses checked arithmetic and must equal that amount exactly. Zero entries are skipped. A sender who lies can only strand its own IMD.
• Vault rounding is gated by previewDeposit, so a zero-share deposit never consumes assets. Against the live vault totals read from mainnet today, even a 1 wei entry previews about 125,000 shares, so the plain-IMD fallback is unreachable in practice.
• Decimal step and uint64 cap: both IMDs convert at 1e12, and the live IMD supply is about 4.17 million tokens, far below the OFT's shared-decimal ceiling, so list sums always match on arrival.
• Manifest: three address words in constructor order, matching the brief.

One finding, low severity, in the RemoteStacker (the sender side, not deployed in this launch). The flush tip is computed on the whole waiting balance, but the delivered amount is rounded down to the bridge step, so the sub-step dust stays waiting and is tipped again on the next flush. With two credits of 1.03e12 wei, total tips reach 41.388e9 wei against a 2% ceiling of 41.2e9, and the trader ends at 97.99% instead of the documented 98%. The absolute loss is bounded at 2% of one bridge step per flush, so nobody profits from it, but the stated guarantee breaks. The proof test under test/scratch/ fails on the current code with exactly those numbers. A minimal fix is to compute the tip only on the step-rounded deliverable amount.

Coverage limits: the ProjectRegistry rows are scan-level reads of its timestamp and rate arithmetic, which is bounded by its constants; it is outside my area and not part of this launch. The 20 fork tests could not run here because no RPC environment variables are set, so the gas budget numbers rest on the figures in the brief and the fork test's assertions.

The review is complete. The findings file is written and valid, no source files were changed, and the scratch test lives under test/scratch as permitted.

Result: no economic defect in the StackReceiver. The amount check binds every payout to the IMD the token itself minted, so a sender can only lose its own funds. The per-trader fallback keeps one trader from blocking a delivery, and a failed compose stays queued at the endpoint where anyone can retry it.

What I verified

• Live facts read on chain through a public RPC at block 26,181,910. The sIMD asset is IMD, its owner is renounced and it is not paused. Both IMD OFTs have 18 decimals, a 1e12 step, are peered, and have no inspector or enforced send-and-call options.
• The mainnet fork tests pass live. Compose delivery uses 228k, 713k and 3.22M gas for 1, 10 and 50 traders, inside the 280k, 1.0M and 4.2M budgets.
• A zero-share deposit is unreachable on the live vault, since one bridge step of IMD previews to about 1.25e17 shares.
• The RemoteStacker's amount-weighted waiting clock keeps a flusher's absolute tip unchanged when a trader front-runs a flush with a self-credit, so the free-bridge grief I tested for does not work.
• The full offline suite passes with 277 tests, and the manifest's three constructor arguments match the brief in declaration order.

Two informational notes were recorded

1. The receiver deposits for any listed address, including itself, the vault and the zero address. A hostile sender can strand sIMD shares that way, which breaks the suite's "receiver holds no sIMD" invariant, but only at the sender's own cost. The Stacker guards against the same addresses, so this is an asymmetry worth closing.
2. The IMD token's owner is not renounced. That owner can un-peer the chains or install a message inspector and stall the route. This is a trust assumption the brief does not name, not a defect.

Coverage rows answer all 13 entry points plus four invariants. Registry and Stacker entry points are marked as holding because they are live contracts outside this launch's value flows.

Review complete. The findings file is at .imd-findings.json with one finding and seventeen coverage rows. Nothing in src/ was changed; the only files I created are the findings file and one scratch test under test/scratch/.

Outcome. The StackReceiver's control flow holds. I traced lzCompose against the live, verified sources of the LayerZero endpoint, the IMD OFT token (BridgedFP) and the sIMD vault, not just the repository's copies:

• The endpoint only delivers a compose whose hash was queued under composeQueue[from][to][guid][index], marks it received before the call, and so from == IMD means the IMD token itself queued it, once.
• IMD's _lzReceive mints exactly amountReceivedLD to the recipient and writes that same number into the compose, so the receiver's exact-sum check binds the list to the IMD that arrived. The compose codec offsets in LayerZero.sol match the live OFTComposeMsgCodec.
• The live vault is byte for byte the test copy apart from name and symbol; Solady's deposit mints exactly previewDeposit, so the ZeroShares revert is unreachable, and the paused path cannot happen with ownership renounced.
• Executor gas griefing of the try/catch is not exploitable: the fallback path needs more than a sixty-fourth of what a deposit needs.
• On the sender side, minAmountLD == plan.imd guarantees the OFT cannot emit a message whose amount differs from the list sum. The option encoding is accepted by the live Robinhood endpoint. The live Robinhood IMD is peered to the Ethereum IMD with no enforced compose options.

All offline tests pass, as do the mainnet and Robinhood fork suites run against public RPCs. The manifest has the three checksummed addresses in constructor order and only the schema's keys.

The one finding (low, test coverage). The fork test's gas-margin assertion is inverted. It checks the delivered gas times ten twelfths against the budget, which passes whenever the budget is up to about 17% below what a delivery needs. A scratch fork test shows a 3.0M budget runs out of gas for fifty traders while that assertion still accepts it. The live constants are fine today with at least 23% margin; the test just cannot catch a regression. The fix is to compare the budget against the measured gas times twelve tenths.

Trust assumption, not a finding. The IMD token's owner and endpoint delegate on both chains can change peers, options and receive configuration. That is bridge-level trust in the IMD operator, outside this repository.

Added tests under test/ for failure paths, replay/retry, reentrancy, exact deployment, and conservation across 16,384 random calls.

Validation passed:

• forge build
• forge test: 296 passed, 0 failed, 23 skipped.

Skipped checks comprise 21 fork tests awaiting RPC configuration and 2 legacy manifest checks. No reproducible defect found.

The review is complete. The findings file is written at the repository root and the scratch tests are removed, so the tree holds only the new .imd-findings.json.

Outcome: no blocking defects in the contract this launch deploys. The StackReceiver's entry point holds on every path I traced, and the manifest matches the brief exactly. I kept five findings, all low or informational, each reproduced against the code.

• Low, RemoteStacker dust retipped. Sub-step dust left waiting after a flush is tipped again on the next flush, so across two flushes the trader lands at 97.99% instead of the documented 98%. The specialist's proof fails on this tree for exactly that reason and is attached.
• Low, RemoteStacker capped clock. A credit merged into a balance that already waited past 12 hours pays the full 2% tip after waiting zero seconds. My proof fails on this tree and is attached. Both RemoteStacker findings concern the later Robinhood Chain launch, not the receiver deployed here.
• Low, inverted fork gas assertion. The mainnet fork test's margin check accepts a compose budget up to 17% below measured gas. Current constants still pass a corrected check, so no live impact today.
• Info, no invalid-trader guard in the receiver. A hostile sender can mint vault shares to the receiver, the vault or the zero address. Only the sender's own IMD is lost, which is the brief's stated design.
• Info, trust assumption. IMD's OFT owner can stall the route by changing peers, the message inspector or enforced options. The specialist's on-chain reading is reported as theirs, since no RPC was available here.

Dropped or rejected: every static-analysis lead. The divide-before-multiply is intentional step rounding, the locked-ether lines have no ETH path, and the reentrancy lines are guarded.

Coverage: all 13 listed entry points have rows. Twelve are answered as holds or finding. The registry's oracle-result callback is marked unreached because its attestation library was not traced within budget. The registry and Stacker are live contracts this launch does not touch.

The offline suite passed with 296 tests, and 23 skipped for lack of fork RPC variables. The README's mainnet table still needs the receiver's address once it is live, as the brief already states.