Implemented LaunchToken and ownerless HongbaoBox, with tests, ABI exports, offline dependencies, and deployment/security documentation.

All checks pass:

• forge build
• forge test: 51 passed using the specified fuzz seed
• forge fmt --check
• ABI consistency checks

Manifest generation, independent review, and deployment remain subsequent workflow stages.

Created launch.json matching the accepted token, HongbaoBox constructor, and required pool settings.

Validation passed: forge build and all 51 tests with the specified fuzz seed. Only launch.json changed.

The review is complete. .imd-findings.json holds one informational finding and a coverage row for all nine entry points plus three checked invariants. The scratch probe was removed and the tree is unchanged apart from the findings file.

Result: no defect in the math, boundary or numerical-gap area. The arithmetic in HongbaoBox traces clean against every failure mode in the three guides:

• Burn and minimum. net = amount - floor(amount/200) with net >= slots * 0.01 IMD means the burn is never zero and no transfer of zero is ever attempted. The documented smallest-gross formula was brute-forced for every net up to 300,000 and for all 200 slot counts on chain, with one wei less reverting each time.
• Equal split. Each non-final grab pays floor(net/slots), the final slot takes the remainder, the running liability never underflows, and the parts sum exactly to the net amount.
• Lucky draw. The proportional payout uses full-precision mulDiv. The reserve cap keeps rest >= 0.01 IMD × remaining slots inductively, so the draw range is never zero, every share lands in [0.01 IMD, upper], the last grabber takes the rest, and payout plus refund equals the net amount exactly. The rejection-sampling threshold is the correct 2^256 mod range.
• Timing boundaries. Grab closes at expiry, reveal and refund open at expiry, settle opens at filledAt + 24h or expiry + 24h, with no overlapping windows and filledAt always set in the filling grab.
• Fuzz evidence. Beyond the shipped suite, a reviewer fuzz over gross amounts up to 2^255, 1 to 200 slots and 0 to all slots grabbed, through reveal, settle and equal paths, held every invariant for 1,500 runs each. The ABI exports match the compiled artifacts exactly.

The single informational note records that the implemented draw cap is narrower than the brief's literal "2 × remaining / remaining slots" range. The two sentences in the brief conflict for small packets, the implementation picks the only resolution that keeps the 0.01 IMD minimum, and the integration document states this. No fix is proposed.

Static-analysis leads in my area did not reproduce. The balance reads around transferFrom sit inside the shared reentrancy guard, the loops are bounded at 200 recipients, and the flagged "uninitialized" variable is a loop counter.

One item I could not verify from this machine and left as a service responsibility: the live IMD token's transfer behaviour and the per-transaction gas budget on Robinhood Chain for a 200-recipient reveal, which measured about 11.7 million gas with the mock token.

Added failure-path tests, full-width arithmetic fuzzing, and two invariant campaigns covering escrow, payouts, token supply, and allowances. All additions are under test/.

forge build and forge test with the required seed pass: 63 passed, 0 failed, 0 skipped.

Live IMD integration remains unverified; tests run offline.

Review complete. The findings file is written and parses, with one substantiated finding and a 13-row coverage record.

What I found

• Medium: a single blocklisted IMD address permanently strands a whole packet. The live IMD token on Robinhood Chain is an owner-controlled LayerZero OFT with a blocked(address) list. I confirmed by simulation against the public RPC that a transfer to a blocked recipient reverts with "BridgedFP: blocked". Because reveal, settle and refund push every payout atomically through _pay in src/HongbaoBox.sol:284 and :205, one blocked grabber or a blocked creator makes every terminal path revert forever. That breaks the brief's guarantee that the contract never holds IMD nobody can withdraw, and it turns settle from an unconditional fallback into one that can be griefed by any passphrase holder grabbing for a known-blocked address. The builder noted this as an external risk, but the dependency behavior is now confirmed on the real token. The suggested fix is a best-effort payout that credits failed shares to a claimable mapping rather than reverting the batch. The proof test under test/scratch fails on current code for both the lucky and the equal-packet variants.

What holds

• Create, grab, and recoverSurplus accounting: the remaining and totalEscrow coupling, the exact-delta checks, the 0.5% burn, and the equal-share remainder handling all trace cleanly. The slither reentrancy and unused-return leads do not survive verification because the guard covers every mutator and the ECDSA error is checked.
• Lucky draw math: the reserve cap keeps every share at or above 0.01 IMD, shares sum exactly to the payout, and the rejection-sampling threshold is correct.
• LaunchToken is a plain fixed-supply OpenZeppelin ERC-20.

Not reached

• No launch.json exists in the tree yet, so the manifest row is marked unreached with the constraints it must satisfy. Whether the IMD owner can switch transfersEnabled back off is noted as a lead, not a finding.

Sources for the chain lookup: chainid.network, GetBlock Robinhood docs, QuickNode Robinhood RPC guide.

Review complete. The findings file .imd-findings.json holds 2 findings and 12 coverage rows (all 9 listed entry points plus 3 invariant/trust rows). No source, test or config file was modified; only test/scratch/ and the findings file were written.

What I found

• Medium: one blocklisted grabber freezes a whole lucky packet. The live IMD token on Robinhood Chain is an owner-controlled ERC-20 with blocked(address) and transfersEnabled(). On a fork, a blocked recipient makes transfers revert with "BridgedFP: blocked". Lucky grabs pay nothing, so grab accepts any such address, and afterwards both reveal and settle revert forever, locking every honest grabber's share and the creator's refund. Equal packets isolate the failure to the blocked recipient's own grab, so this is an asymmetry between the two payout branches that anyone holding the shared passphrase can weaponise. The attached proof test fails on current code and asserts that honest grabbers can still be paid. Suggested fix: record failed shares as claimable instead of reverting the batch.
• Info: creator can grind the lucky draw. The creator knows the secret and holds the passphrase, so by choosing the last recipient address offline they pick the outcome. In the demonstration the honest grabber got 0.67% of a 200 IMD pot after 90 candidate addresses. This is inherent in the specified seed and is partly documented, so it is reported as a trust assumption for the author to document more plainly.

What holds

• No owner, initializer, msg.sender or tx.origin privilege anywhere; the only constructor argument is the IMD token address from the brief.
• Signature binding, one grab per recipient, escrow accounting, recoverSurplus isolation and the reveal/settle mirror writes all traced and consistent.
• Against the real IMD bytecode on a chain-4663 fork, a 200-grabber reveal costs about 12.1M gas with exact balances. Note that the IMD bytecode needs the Cancun EVM, so fork tests of it must pass --evm-version cancun; this does not affect deploying the Paris-compiled HongbaoBox.

Not reached: no launch.json exists yet, so manifest contents could not be compared; the ABI exports were verified with the project's own check script.

Review complete. The findings file is written and validated against the tree, the scratch directory is removed, and the working tree is otherwise unchanged.

Outcome: no exploitable defect in the control flow of HongbaoBox or LaunchToken. Two documentation-level findings were recorded, both low or informational.

What I checked in my area (Execution Trace, Periphery, First Principles)

• Execution flow of every mutator. Traced create, grab, reveal, settle, refund and recoverSurplus from guards through state writes to transfers. Every outbound payment is preceded by the escrow decrement and terminal state write, and the reentrancy guard covers the only transient surplus windows.
• Share arithmetic. Proved by induction that the capped double-average draw keeps every lucky share at or above 0.01 IMD and sums exactly to the scaled payout. Equal packets give the last slot the rounding dust as specified.
• Periphery libraries. Hashed all 18 vendored OpenZeppelin files against the upstream v5.0.2 tag. Four differ only by forge formatting and hex literal underscores, so the libraries are semantically upstream.
• Live IMD token. The brief's IMD address on chain 4663 is an Ownable LayerZero OFT over a standard OpenZeppelin ERC20 with no pause, blocklist, fee or hook selectors. I ran the real HongbaoBox against it on a local fork: create, burn, grab, reveal and refund all succeed. A 200-grabber reveal costs about 12.1M gas, within Arbitrum's 32M per-transaction limit.
• Static analysis leads. The slither and aderyn reentrancy and unchecked-address lines are false positives here: the guard shares one lock across all mutators, IMD has no callbacks, and the flagged "ETH send" is an ERC20 transfer to msg.sender.

Findings recorded

1. Low. The README states an 88% pool / 2% wallet HONGBAO split that contradicts the approved launch rules (80% pool by default, remainder to the requester's wallet) with no recorded requester choice. Documentation only.
2. Info. The on-chain token name is "HONGBAO" while the brief's narrative says "IMD Hongbao". The manifest's token.name must match the compiled contract, and no protected test cross-checks that field.

Coverage. All nine listed entry points are marked holds with reasons, plus rows for the escrow invariant, the vendored libraries, the live IMD token, and the ABI/manifest inputs. No launch.json exists yet in this tree, so the manifest check is limited to the constructor and ABI evidence: HongbaoBox takes exactly one address argument (the IMD address) and LaunchToken takes none.

The review is complete and written to .imd-findings.json. The working tree is otherwise untouched.

Outcome. The code is solid: all 63 project tests pass, the contracts fit the factory's size and constructor constraints, and launch.json matches the compiled token and the brief's IMD address. One real defect survives, plus one documentation error and one informational trust assumption.

Findings kept, after reproduction:

1. Medium, merged from economics and permissions. One IMD-blocklisted recipient strands a whole packet. The lucky payout loop at src/HongbaoBox.sol:284 and the creator refund push revert the entire transaction on any failed transfer, so reveal, settle and refund all fail forever once a grabber or creator is blocked. I confirmed the dependency behaviour on the live token itself: an eth_call of transfer against the real bytecode on chain 4663, with only the recipient's blocklist slot overridden, reverts with "BridgedFP: blocked". Both specialist proofs fail on the current code for that reason. The economics proof is attached since it covers both the lucky and equal cases. The brief's "never holds IMD no one can withdraw" guarantee is broken under this condition, and any passphrase holder can plant a blocked recipient in a lucky packet. Suggested fix is a per-recipient claimable credit on transfer failure, kept inside escrow.
2. Low. The README states an 88% pool / 2% wallet split of the launch token that nothing in the tree or the approved rules supports.
3. Info. The creator can grind the last grabber address to steer the lucky draw. My own scratch test confirmed it: after 745 offline attempts the honest grabber received 0.045 IMD of a 200 IMD packet. It is a property of the specified seed formula, so it is a documentation item for the site, not a code defect.

Dropped: the math specialist's note on the brief's self-contradictory range, since the implementation is the only one that satisfies the minimum share and the docs say so, and the token-name ambiguity, since launch.json already uses HONGBAO and matches the contract.

Coverage. All nine entry points are answered, with reveal, settle and refund pointing at finding 1 and the rest holding. Four extra rows record the escrow and share-sum invariants, the manifest, and factory deployability.

The revision is complete and verified.

The medium finding reproduced and is fixed. The reviewer's proof failed on both of its tests against the starting tree and passes on the result. In src/HongbaoBox.sol, settle and refund now pay each recipient through a best-effort path. A transfer that IMD refuses (revert, false return, or nothing moved) is credited to a new public claimable mapping, kept inside totalEscrow so recoverSurplus can never take it, and emitted as PayoutDeferred. The packet still reaches its terminal state and everyone else is paid in that call. A transfer that moves balances by the wrong amount still reverts the whole call, as before. A new claim(recipient, to) releases credits: anyone may push one to its recipient, and only the recipient may redirect it elsewhere, which is how a blocklisted address still withdraws. The creator's reveal stays atomic and reverts on a refused recipient, which is what the proof asserts and what the brief's "pays every grabber in the same transaction" says, so a planted blocked address can at worst force the equal fallback.

Tests. Seven new tests in test/HongbaoFailures.t.sol cover the blocked grabber and blocked creator under settle and refund, claim authority and failure modes, credits versus surplus recovery, false and no-op versus fee tokens, and reentry through claim. The invariant handler now models the IMD blocklist and claims, counts credits in liabilities, and drains them at teardown. Two tests that asserted the old revert-forever behaviour were rewritten.

Advisory findings. The README supply split is answered as disputed: this launch's own terms state 10% swarm, 88% pool, 2% paying wallet, and the generic 80% default the reviewer cites is overridden by them. The README now cites that source and tells the manifest and site contributors to take the figures from the launch terms. The creator-steering finding is answered as fixed by documentation only. README, the integration guide and the review notes now say plainly that a creator who holds the passphrase can grind the last grabber address to choose the outcome, and that the site must not present the lucky split as a fair draw.

All three answers are in .imd-responses.json. No launch.json or .imd-blocked.json was written. Nothing was committed, since the harness submits the working tree.

The build succeeds and all 56 tests pass with the verifier's fuzz seed. The manifest is complete and correct, so I left it unchanged.

Outcome: launch.json already describes the accepted tree exactly, and no review findings accompanied this revision, so nothing needed to change. The working tree is clean.

What I verified against the accepted source and launch facts:

• Token names LaunchToken with name and symbol HONGBAO and 18 decimals, matching the constructor in src/LaunchToken.sol.
• Contracts lists only HongbaoBox, whose single constructor parameter is an address. The manifest passes the IMD token address the brief names, in lowercase, as the ABI export confirms. The contract is ownerless, so no owner argument exists and nothing resolves to a privileged wallet.
• Pool uses the launch's pair token address, fee 12500, tick spacing 60 and the one-to-one initial price exactly as the launch facts give them.
• Schema contains only kind, token, contracts, pool and notes. Notes are one string of 440 characters, with no supply, allocation or chain fields.

Checks run:

forge build   -> ok (lint warnings only, in accepted source)
forge test    -> 7 suites, 56 passed, 0 failed (FOUNDRY_FUZZ_SEED set as the verifier uses)

No file other than launch.json is in my write scope, and no file was modified.

I updated my tests for the revised HongbaoBox, and the full suite now passes: 68 of 68 tests across 11 suites, run with the verifier's fuzz seed.

What broke: the revised contract (commit a3dc55b) changed how settle and refund handle a transfer the token refuses (it returns false, or reports success without moving anything). Instead of reverting, they now finish the packet and record what was owed as a claimable credit, which the recipient collects later through claim. My test testAllOutboundModesRollbackAndRetryEveryPayoutPath in test/HongbaoAtomicity.t.sol still expected a revert there, so it failed.

What I changed:

• test/HongbaoAtomicity.t.sol:
  • For settle and refund with a refused transfer, the test now checks the new behaviour:
    • No tokens move.
    • The packet reaches its final state.
    • The credits add up to exactly what the packet owed.
    • A second settle or refund reverts with PacketClosed.
    • Surplus recovery can't take the credits.
    • Each person gets their full amount through claim once the token works again.
  • I added claim to the test, so it now runs six payout paths against four token faults (24 cases). On claim, every fault reverts and leaves all state unchanged, and retrying after the fault clears succeeds.
  • The snapshot taken before each failed call now includes the claimable balances.
  • The other paths (grab, reveal, surplus recovery), and settle/refund when the token moves the wrong amount, keep their original revert-and-roll-back checks.
• test/README.md: the description of that file now matches the new behaviour.

I found no defects in the revised contract, so there is no .imd-findings.json.

One limitation remains: everything runs against a local stand-in token, so the behaviour of the real IMD token on Robinhood Chain is still untested.

The two changed files are not committed.

The review is complete. The findings file holds no open findings and a coverage record for all ten entry points plus two invariants. The working tree is clean apart from that file.

Settled from the previous round

• Medium, blocked recipient strands a packet: fixed. Both attached proofs pass on the revised code. Settle and refund now route each payout through a best-effort transfer that credits a refused recipient in claimable and keeps the credit inside the escrow total. I confirmed with my own scratch test that a 200-grabber lucky packet with every grabber and the creator blocked still reaches Settled, that surplus recovery cannot take the credits, that a third-party claim to a still-blocked address reverts without losing the credit, and that the recipient can redirect it. A globally disabled IMD transfer switch also no longer freezes the packet. Reveal keeps the brief's atomic payout and a refused recipient only forces the equal fallback.
• Low, README supply split: dropped. The author cites the launch terms for the 10/88/2 figures. Those terms are not among my inputs, so I cannot substantiate the objection a second time. The README now attributes the figures and tells downstream contributors to take them from the launch terms.
• Info, creator can steer the lucky draw: fixed as documentation. README, the integration guide and the review notes now state it plainly.

Checks run

• Full suite: 71 passed, 0 failed.
• Token and Project protected tests could not run here because they need the verifier's factory environment variable. The Owners protected test imports a floor file not present in this tree.
• Static-analysis leads traced and not kept: the reentrancy lines are all behind nonReentrant against the immutable IMD token, the strict equality is the intended exact-delta check, and the unused-return lead is wrong since the recovery error is checked.

Nothing new reproduced. The one remaining trust assumption, that IMD blocking the box itself as sender holds all payouts until the IMD owner lifts it, is documented in README and review item 5 and is outside the contract's control.

Implemented the bilingual frontend and 859 KB static export with verified deployment manifest.

• Build/typecheck passed.
• 10 unit, 20 browser and 16 design checks passed.
• Snapshot bundle: 1.61 MB, below 8 MiB.
• No live transactions sent; reverse swap quotes currently report insufficient liquidity.

Validation and limitations · Design

Files are ready for the publisher’s commit; workspace Git metadata is read-only.

Saved two verified findings in .imd-findings.json. Website files remain unchanged.

• High — fidelity: English mobile layout hides the primary action. At 390×844, the button starts at y=829 in Chromium and y=874 in WebKit. Compact the mobile header text and remove the decorative heading icon; the tested adjustment brings the complete button onscreen. Source: web/src/styles.css:1039.
• Medium — accessibility: “Skip to content” changes the route. From a packet, activating the link changes #/p/1 to #main, opens Send, and discards the current form. Prevent hash navigation and focus the existing main element. Reproduced in Chromium and WebKit. Source: web/src/App.tsx:116.

The build reproduces the export byte for byte; typechecking and all 10 unit tests pass. Chromium’s English first-screen assertion fails; the remaining scenarios pass when continued. Mocked transaction flows were also exercised in WebKit. Both public RPCs returned chain 4663 and deployed contract code. No mainnet transactions were signed.

Duplicate workflow text is consolidated below. Contract entries reflect existing source and test evidence, not a new Solidity audit or Foundry run.

Fixed both reproduced defects: the English mobile action stays visible, and the skip link preserves the current route and form.

Rebuilt the export and manifest; recorded both responses in .imd-responses.json. Build, typecheck, 10 unit tests, 35 browser checks, and 16 design checks pass. Bundle: 1.76 MB.

Changes are ready for the publisher to commit; workspace Git metadata is read-only.

Both previous findings are fixed. No new reproducible defect was found. .imd-findings.json contains {"findings":[]}. Website files remain unchanged.

• 439779a… — mobile header: At 390×844, fresh storage, no wallet, English and scrollY=0, the header measures 76px. The complete 48px action ends at 804.72px in Chromium and 812.72px in WebKit. The fix in styles.css holds.
• 5c53e63… — skip navigation: Keyboard activation preserves the hash, history and entered values on Send, Grab, packet, Swap and Funds in both engines. Focus reaches main. The original disconnected #/grab reproduction also passes without RPC access: ID 123 remains. The handler in App.tsx holds.

Independent checks passed: production build/typecheck, 10 unit tests, 20 interaction scenarios, 15 revision checks, and four additional wallet-prompt/offline-navigation checks. Axe reported zero violations in the tested view. The disposable rebuild exactly matches the submitted export. Transactions used fixtures; no live transaction or renewed contract security audit is claimed.

The requirement ledger below consolidates duplicated wording in the workflow. Contract-stage requirements marked “met, preserved” refer to the unchanged accepted implementation and its existing evidence.