Implemented MOON, MoonRewards, and MoonShop/Courier Companions, with vendored dependencies, ABI exports, and deployment/operations documentation.

Validation passed:

• forge build
• forge test: 70 passed, including offline with an empty environment
• All 9 supplied protected checks
• Formatting and ABI consistency checks

The owner must configure the game signer and fund rewards after deployment. Manifest creation, independent review, and deployment remain separate stages.

I found two economic defects; the more serious one I confirmed with a test. The results are in .imd-findings.json, and I changed no source files (the scratch test I used has been deleted).

1. Medium: the reward pool may never open (src/MoonRewards.sol:29).

• What happens: claims fail until the pool has held INITIAL_FUNDING = 700_000_000 ether at least once. That number assumes the factory gives the creator exactly 70% of the supply.
• Why that's uncertain: the README and docs/deployment.md assume a 70% creator split, but the source doesn't decide it. The launch policy row does, and the standard default is 80% of the supply to the pool, leaving the creator about 100M.
• What breaks: under the default split, the creator deposits their whole balance and every claim still fails with NotFunded. Closing the gap would mean buying about 600M MOON out of an 800M pool, which isn't realistic.
• Why it's permanent: deposits can't be withdrawn by design, so the creator's deposit and all shop recycling are locked forever while no player can ever be paid.
• Test: I gave the creator 100M, had them deposit it all, then made a properly signed claim. It failed with NotFunded and isFunded() stayed false. Because of this test the finding is confirmed rather than inferred from reading the code.
• Fix: either confirm before admission that this launch's policy really gives the creator 70%, or take the threshold as a constructor argument set from the policy.
• Why medium and not high: the harm depends on which policy is actually used, and I couldn't check that from here.

2. Low: the owner can pay the pool to themselves (src/MoonRewards.sol:85).

• The brief allows the owner to swap the voucher signer, but nothing limits who the new signer is.
• The owner could install their own key and sign vouchers for 50 wallets they control that have post offices. That pays out up to 1,000,000 MOON per day, against the rule that "nobody, including the creator, can redirect the reward pool."
• This is a trust assumption that should be stated in the README and on the site, not a bypass of the access checks.

Coverage: I wrote one row for each of the 16 entry points, plus one invariant row: "the pool never pays out more than it holds" holds. Three rows point to the findings: claim and fund to finding 1, setVoucherSigner to finding 2. The other 13 hold. In particular:

• The shop's 50/50 split always adds up to the exact cost, with any odd wei going to the pool.
• The shop keeps no MOON and the owner earns nothing from sales.
• The maximum price, supply and per-wallet limits are enforced.
• Permit failures are tolerated safely.
• Pausing never moves tokens.

Not checked in depth: whether a PostOffice contract actually exists at the hard-coded address on the launch chain, and the 2% / 8% swarm payouts and any rounding dust they leave. Both depend on the chain or the factory, not this code. There is no launch.json yet to review.

Created launch.json with MOON, ordered application dependencies, $owner references, and the required pool settings.

Manifest and compiled ABI checks passed. forge build succeeded with existing warnings; forge test passed all 70 tests.

Only launch.json is submitted.

The review is complete and the findings file is written and validated. The working tree is clean apart from the gitignored findings file.

Outcome: no exploitable permission defect found. Across the Access Control, Asymmetry and Trust Gap lenses, the three contracts hold. Both owners are explicit constructor parameters, never the factory or tx.origin. Every storage variable has a single guard shape across its writers. The only outgoing transfer from the reward pool is the verified claim payout, and the shop ends each purchase with zero balance and zero allowance. Build and the full suite pass with 70 tests, and the ABI exports match the compiler output.

Two entries are recorded in .imd-findings.json:

• Low, policy dependency. The immutable 700,000,000 MOON activation threshold assumes the launch policy gives the creator 70% of supply. If the pinned policy uses the default 80% pool share, the creator holds only 100,000,000 MOON and claims can never activate. A scratch test confirmed the permanent NotFunded path under that balance. The needed evidence is the policy row showing a 20% pool share before admission.
• Info, trust assumption. The owner can appoint any signer, including itself, and draw rewards within the daily caps. I verified the bound: 20,000 MOON per wallet per day, 1,000,000 MOON globally. This is the designed power the brief grants and is reported as a trust assumption, not a bypass.

Coverage. All 16 listed entry points have a row, 14 as holds and 2 pointing at the trust-assumption entry. Five extra rows cover invariants and the static-analysis leads, all of which turned out to be false positives or designed behaviour. The one unreached item is launch.json, which does not exist in the tree yet. When it is written, the reviewer should check that the owner arguments resolve to $owner rather than the literal address in the README, and that the shop references $contract:MoonRewards.

The review is complete. The findings file is written, the scratch tests are removed, and the working tree shows no tracked changes.

Outcome: no math, boundary or numerical-gap defect in the contracts. One informational boundary note was recorded.

What I checked, in my area:

• Every division and product in value paths. The only divisions are the 50/50 purchase split and the UTC day index. The split partitions cost exactly, with the odd wei going to rewards, confirmed at 1-wei and 2-wei costs. Price times quantity is checked arithmetic, so overflow reverts rather than producing free items.
• Every cap and threshold at its edge. Wallet cap allows exactly 20,000 MOON and rejects 1 wei over without consuming the nonce. The day rolls at the exact UTC second and resets caps. Activation triggers at exactly 700,000,000 MOON and not at one wei below. Payout requires balance at least the amount, strictly.
• Every external boundary. Signatures of 64 bytes, empty, v=0 and high-s all fail. PostOffice responses of 2, 64 bytes, or no code all fail closed. The shop's allowance to rewards is zero after each purchase. Royalty floors at 5 percent to the owner.
• The three slither leads and four aderyn leads. None is a defect: the ignored ECDSA return is the error argument after the error enum is checked, the permit reentrancy is guarded, and timestamp use is the specified UTC day.

The one note: the activation threshold is pinned to exactly 700,000,000 MOON. If the creator wallet holds even one wei less when it makes its single prescribed deposit, claims stay disabled until anyone tops up the difference. Recovery is trivial and no funds are at risk, so it is informational. The README should state the exact balance precondition.

Coverage: all sixteen listed entry points are marked holds, plus three invariant rows. The launch manifest row is unreached because no launch.json exists in the tree yet.

The review is complete. The findings file is written and no tracked file changed.

Outcome: one critical defect, one low configuration risk, 19 coverage rows.

Critical: every claim reverts on the real chain. The _requirePostOffice check in src/MoonRewards.sol demands that the PostOffice offices(address) call return exactly one 32-byte word. The live PostOffice at the pinned constant address on Robinhood Chain is a verified contract whose offices is a public mapping to a nine-field struct. Its first field is bool open, followed by tier, duty, route, timestamp, referrer and three accounting words. I confirmed this against the chain with cast: the requester's own wallet returns 288 bytes starting with 1, and an address without an office returns nine zero words. The brief's phrase "returns true first" means the first returned field, which the implementer read as a bare bool. Because the response is never 32 bytes, the check reverts with PostOfficeUnavailable for everyone, before nonces, caps or balance are considered. The PostOffice address is a constant by requirement and deposits are irreversible by requirement, so after launch the creator's 700 million MOON deposit and all shop recycling would be locked forever. The existing suite passes only because its mock is a plain bool mapping.

The attached proof under test/scratch etches a mock with the verified struct shape at the constant address. Both of its tests fail on the current source. I rebuilt a scratch copy of MoonRewards that accepts a response of at least 32 bytes and reads the first word, and both tests pass on it. The same wrong shape is in the IPostOffice interface, the exported ABI and the README, so those need the same correction.

Low: the activation threshold depends on the launch policy. INITIAL_FUNDING hard-codes 700 million MOON, which only reaches the creator if the policy seeds the pool with 20% rather than the default 80%. Nothing in this tree proves which split is pinned. If the default applies, the creator holds 100 million, activation is unreachable and claims revert NotFunded forever. The needed evidence is the pinned policy's pool share.

Everything else in my area holds. I traced the full claim ordering, both funding routes, the shop purchase path with its 50/50 split and recycling, the permit front-running handling, reentrancy guards, cap and nonce accounting, the owner powers, the constructor role wiring, and the vendored OpenZeppelin 5.4.0 code. The ABI exports match the compiler output, formatting passes, and all 70 project tests pass. No launch.json exists yet, so there was no manifest to check beyond the documented constructor mapping, which matches the source.

Sources used for the chain lookup: chainid.network chain list, QuickNode Robinhood Chain RPC guide, Sourcify verified PostOffice.

Added 22 tests under test/ covering failure paths, rollback, fuzzed boundaries, and stateful accounting.

• forge build: passed.
• forge test: 95 passed, no failures or skips.
• New invariant campaign: 32,768 calls, no unexpected reverts.

No implementation defects reproduced. Live PostOffice integration remains unverified.

The review is complete. The findings file holds three judged findings and a full coverage record, and the tree is otherwise unchanged.

Outcome

• Critical, kept with proof. The audit_flow finding reproduces live and locally. The pinned PostOffice contract on Robinhood Chain returns a nine-word struct (288 bytes) from offices(address), which I confirmed with a cast call against the chain's RPC. MoonRewards line 193 requires exactly 32 bytes, so every claim reverts PostOfficeUnavailable and the irreversible pool could never pay. The attached proof fails on this tree for that reason and passes against a scratch copy with the two-line fix, so I carried it on the finding.
• Medium, merged from four specialists. The 700,000,000 MOON activation constant assumes a 70% creator allocation that nothing in the source, ABI or manifest can guarantee. Under the default 80% pool share the creator holds 100,000,000 MOON, claims revert NotFunded forever and all deposits are locked. I reproduced the lock, the one-wei boundary and the top-up recovery in a scratch test. It is a policy/constructor conflict for admission to confirm against the pinned policy row.
• Info, merged from two specialists. The owner may install any signer, including its own key, and draw rewards up to the daily caps. This is the designed owner power, so it is recorded as a bounded trust assumption rather than a defect.

Dropped leads. The slither unused-return line does not reproduce: OpenZeppelin's tryRecover rejects high-s values internally and claim rejects any recover error. Shop, token and manifest entry points traced clean, exported ABIs match the compiled ones, and contract sizes and constructors are compatible with CREATE2 factory deployment.

Coverage. All 16 entry points are answered, plus three invariant rows for the manifest, deployability and ABI parity. The existing suite passes 92 of 92 tests.

The revision is complete and verified. All three findings are answered in .imd-responses.json.

Critical finding (PostOffice return shape): fixed. The reviewer's proof reproduced on the starting tree, failing both tests with PostOfficeUnavailable. The post office check in src/MoonRewards.sol now requires at least one returned word and reads the first word as the open flag, keeping the canonical 0/1 check, so it works against the live nine-field struct getter and a one-word bool alike. The IPostOffice interface now declares the real nine-field return tuple and its ABI export was regenerated. The test mock returns the live 288-byte shape so every existing PostOffice test and the invariant handler now exercise it, and two new tests cover the struct shape, a closed office, a non-canonical first word, and the legacy one-word shape. The proof passes 2/2 on the result. I could not repeat the live RPC call myself because this machine has no network, and the docs say so.

Medium finding (700,000,000 MOON threshold): disputed. The behaviour reproduces, but it is what the brief and this launch's terms require. The assignment's launch facts state the split as swarm 10%, pool 20%, creator 70%, which is the evidence the finding asked for, and the brief says the pool must hold at least the creator allocation and forbids requesting a different split. The code is unchanged. I added an explicit pre-admission check to the deployment doc and a README paragraph explaining the constant, that any depositor's MOON counts toward it, and that the policy must pay the creator 700,000,000 MOON.

Info finding (owner-chosen signer): fixed in documentation only. The README and validation notes now state the exact bound of the owner's power through the signer, within the per-wallet and global daily caps, with no code change, as the reviewer proposed.

Checks on the result:

If the admission stage finds the pinned policy pays the creator anything other than 70%, the threshold constant needs a further revision before deployment, since it cannot change afterwards.

The launch.json is already present and correct. I've verified it builds and all tests pass.

The manifest describes the three contracts in dependency order:

1. LaunchToken - MOON token with 1 billion supply at 18 decimals, no constructor arguments
2. MoonRewards - takes $token and $owner, the permanent reward pool that pays verified mission claims
3. MoonShop - takes $token, $contract:MoonRewards, and $owner, implements the Courier Companions ERC-1155 collection and recycles half of shop payments into MoonRewards

The pool configuration matches the requirements: paired with IMD at 0x5f7bb59365ce557c26dbcaa4ee9d39a4b95b7127, fee 12500 (1.25%), tickSpacing 60, initialPrice at 1:1.

Build completed successfully with only linter warnings about reentrancy patterns and block.timestamp usage (all expected for this design). All 72 tests passed including the 30 MoonRewards tests covering solvency, daily caps, voucher validation, and the post office requirement, plus 29 MoonShop tests verifying the 50/50 burn/recycle split and the invariant tests confirming the entire economy across 12,288 fuzzed sequences.

No changes needed. The manifest is ready for submission.

forge build and forge test both pass now: 96 tests in 8 suites, none failing or skipped.

What broke: after my last round, MoonRewards was changed to work with the real PostOffice contract. That contract returns a whole nine-field record (288 bytes) for offices(player), not a single true/false value. The contract now reads only the first field (open) and accepts any response at least one word (32 bytes) long. One of my old tests, testFuzz_postOfficeRejectsShortAndOversizedReturnData, still required the reply to be exactly 32 bytes, so it failed on 95 bytes. The new code's behaviour is correct, so I replaced the test rather than reporting it as a defect.

Changes in test/MoonRewardsEdges.t.sol:

• testFuzz_postOfficeRejectsResponsesShorterThanOneWord: every reply of 0–31 bytes is refused with PostOfficeUnavailable. Nothing is paid and the voucher stays unused.
• testFuzz_postOfficeDecidesOnlyOnTheFirstWordWhateverFollows: adds 0–299 random bytes after the first word, including partial words. A first word of 1 pays, 0 fails with PostOfficeRequired, and anything else (2, the top bit, the maximum) fails with PostOfficeUnavailable. The extra bytes never change the outcome.
• test_postOfficeLiveStructWithOpenButOtherwiseEmptyFieldsIsAccepted: a full 288-byte record where open is true and every other field is zero still lets the player claim.

I also updated the two lines in test/README.md that described the old exact-32-byte rule.

I found no defect in the implementation, so there is no .imd-findings.json.

These tests only use a local stand-in at the PostOffice address. The 288-byte reply shape comes from a reviewer's earlier check against the live chain; I couldn't confirm it from this machine, so a check against the real contract on Robinhood Chain is still needed.

All three findings from last round are settled, and I found nothing new. .imd-findings.json has an empty findings list and a coverage row for each of the 16 entry points (all holds), plus one row closing out the activation threshold. The working tree is clean; the scratch copies are deleted.

Critical: the post office check rejected the live response — fixed.

• _requirePostOffice (src/MoonRewards.sol:189-198) now accepts any successful response of at least 32 bytes. It reads the first word as the open flag and still fails closed: 0 reverts PostOfficeRequired, anything above 1 or a short or reverted response reverts PostOfficeUnavailable.
• I ran the live call again: cast call 0x26D8…5D82 'offices(address)' 0x7221…d566 on the Robinhood Chain RPC returns 288 bytes with first word 1. The fixed check therefore lets that wallet's claims through.
• Both attached proofs (Proof_f77592622387, Proof_8ba6921257ee) now pass 2/2, run from a copy under test/scratch/.
• The full suite passes: 100 tests, including the invariant runs.
• The IPostOffice interface now returns the nine fields; the function selector is unchanged.

Medium: the 700,000,000 MOON activation threshold — dropped.

• The behaviour reproduces, but it is what the brief asks for. The brief calls the creator's deposit "the 70% allocation", requires that no claim succeed until the pool holds it, and says "Do not request a different split."
• If the creator's balance comes up short by a little dust, anyone can fund the difference.
• Whether the pinned launch policy actually pays the creator 70% is for the admission stage to check, and the author added that check to docs/deployment.md and the README.
• One caveat: I saw only the brief's "70% allocation" wording. The "This launch" facts the author quotes for the 10/20/70 split were not in my inputs, so I couldn't confirm the policy's pool share myself.

Advisory: the owner can install any voucher signer — accepted as documented. This is the owner power the brief grants. The README and docs/validation.md now state its exact limit: 20,000 MOON per wallet and 1,000,000 MOON in total per UTC day, with pause giving no protection against it.

Other checks

• The slither lead about ignoring part of tryRecover's return is harmless: the code checks both the error and the recovered address.
• Contract sizes are well under the deploy limits (MoonShop is the largest at about 10 KB deployed).
• launch.json matches the constructors: $token, $owner for MoonRewards and $token, $contract:MoonRewards, $owner for MoonShop, in dependency order.
• I couldn't run the protected launch tests: they need the IMD_PROJECT_FACTORY environment variable, which this machine doesn't set.

Committed. The full bundle is 1.86 MB, well under the 8 MiB limit, with a clean working tree.

Delivered

• web/: Vite, React 19, TypeScript, Tailwind 4, wagmi and viem source with lockfile and web/.gitignore for node_modules.
• dist/: committed static export with relative base, bundled Bungee and Patrick Hand fonts, favicon, share image, and dist/imd-deployment.json.
• docs/frontend-validation.md, docs/frontend-screenshots/, probe and browser reports, web/README.md, web/DESIGN.md.

Runtime configuration

The app fetches imd-deployment.json at load and builds its chain, transports, addresses and ABIs from it. No second table exists. The manifest script copies launch id, chain id, source commit, attestation hash, contracts, pool key, network and walletAddChain from the handoff and chain table, re-hashes each ABI with canonical keccak against the handoff, and lists SHA-256 for all 13 other exported files. The manifest has exactly the ten allowed top-level keys.

Controls on the page

• Claim: paste voucher JSON, preflight checks, simulated claim.
• Shop: item cards with price, remaining supply, per-wallet limit, approve then buy with the half-burned, half-recycled wording.
• Trade: quoter via simulateContract, slippage, approve to Permit2, Permit2 approve, router execute with the six-field tuple for Robinhood Chain.
• Fund: approve then permanent deposit.
• Owner panel for the connected owner: set signer, pause or resume, configure item.
• Wallet: connect, single "Switch to Robinhood Chain" control, wallet_addEthereumChain on 4902.

Validation results

The two remaining probe items are brief-driven: the literal NOT FUNDED badge and the ink-outline plus offset shadow on paper cards. Live reads confirmed the pool holds 0 MOON, the creator wallet still holds 700,000,000 MOON, and no signer or items are set.

Limitations

No real transaction was broadcast. WebKit, screen reader and physical device checks were not run. DESIGN.md sits at web/DESIGN.md because the repository root is outside this assignment's write scope. The shop discovers items by probing ids 0 to 63 plus a manual lookup, since both public RPCs refuse wide log scans.

The review is written to .imd-findings.json with five findings, none high. The site is working and close to the brief. The findings are three medium bugs and two low ones.

Requirements, one line each

• "MoonRewards balance, paid today against the daily cap, total paid, total burned and recycled, the creator wallet's current MOON balance" are all met. The reward pool card reads them live from the chain, no wallet needed.
• "the funding transaction link" is met by a live link to the pool's token transfers on the explorer. The deposit itself has not happened (creator wallet still holds 700,000,000 MOON), so the specific hash needs the requester.
• "the website shows NOT FUNDED" is met by the badge on the pool card. The probe's casing failure is overridden by this quote.
• "Show the reward pool, paid today, total burned, your MOON and your companions" are met. Your MOON and your companions appear once a wallet is connected.
• "Shop cards show price and what's left, with a clear Buy button that says half the MOON is burned and half returns to the pool" is met by the item card and its "Buy: half burned, half to pool" button. The catalog on chain is empty today, so the empty state is what a visitor sees.
• "Big 'Play Courier World' button" is partly met. The button exists and is gold, but renders at the same 44px and 16px as the secondary links because the cascade cancels its size class. Reported as a medium fidelity finding.
• "Watching needs no wallet" is met. Every public read goes through the configured public RPCs.
• "Home page says: 'MOON is earned by playing Courier World...'" is met word for word under the headline.
• "No guaranteed token value or profit claims" is met. The trade card closes with a plain disclaimer.
• "cel-shaded grey moon, deep indigo starry sky, warm gold, ink outlines, paper cards, Bungee and Patrick Hand fonts" is met. Both fonts are bundled and confirmed loaded. The border plus hard shadow on paper cards is this system, so the probe's chrome failure is not a finding.
• "React/TypeScript, shadcn/ui, Tailwind" is met for React, TypeScript and Tailwind. The builder documented using hand-written components in the shadcn style rather than the package, which the validation record states openly.
• "Mobile-first, reduced-motion support" is met. No horizontal scroll at 320, 390 or 1440, and the star twinkle stops under reduced motion.
• "ABI/address config with the EIP-712 voucher types" is met. The voucher types file is exported and linked from the footer.
• "static site and share image" is met by the export and og.png.
• Wallet connection, wrong-network switching, swap controls, claim, fund and owner controls are met. Each has disabled, pending, error and success states. Sending transactions needs a wallet and cannot be judged here.
• Deployment configuration is met. The manifest's contracts, addresses, ABI hashes, poolKey, network and walletAddChain match the handoff exactly, every asset hash verifies, and every exported file is listed. ABIs are byte-equivalent to the pinned source commit.
• Source publishing, IPFS hosting and the site name are after review.
• The game server signer, shop items and the creator's funding deposit need the requester.

The idea in one sentence. A paper ledger pinned over a cel-shaded moon in an indigo night sky, where ink outlines and hard gold shadows carry the game's look into a verifiable reward-pool dashboard.

Findings

• Bug, medium. Fund and Trade step buttons read "1. Approved", "1. Permit2 approved" and "2. Router allowed" to a visitor with no wallet and no amount. The done label is shown whenever the needs flag is false, including w