Implemented LaunchToken (TEYO) and JobZero, with vendored dependencies, ABI exports, and deployment/operations documentation.

Validation passed:

• forge build
• forge test: 44 tests, including 8,192 invariant calls
• forge fmt --check
• ABI consistency checks

After deployment, the owner must set the TEYO address once. Manifest generation, independent review, and deployment remain with the designated launch stages.

I found no defects in the access control, trust gap and asymmetry review. I wrote .imd-findings.json with an empty findings list and a coverage row for all 10 entry points (every one holds), plus one row for the "no hidden privileged role" check. No project files were changed. The full suite passes: 44 tests, 0 failed.

Access control

• Owner: owner is set once in the constructor, which rejects the zero address; the manifest fills it with $owner. It is only checked in setToken, which works once and locks the token for good. There is no withdraw, rescue, pause, upgrade, delegatecall or selfdestruct. The factory that deploys the contract and tx.origin get no powers.
• handoff: only the current worker can call it, before the deadline. The new worker can't be the zero address, the caller, or anyone who already held the job in this run.
• timeout: anyone can call it, but only at or after the deadline.
• claim: pays only on a closed run, only to someone who held the job, never to the failed worker, and only once per wallet. The claimed flag is set before the transfer, and every function uses the reentrancy guard.

Trust gaps (by design, already in the README)

• The owner chooses the token. The code only checks that the address has code and reports 18 decimals. If the owner never sets it, or sets the wrong one, there's no way to fix it.
• The current worker can hand off to any address that hasn't held the job, including one that can never act. That address then takes the failure. The brief's rules allow this.

Asymmetry and accounting

• Each handoff fee is split so the burned half plus the bounty half equals the fee exactly.
• At timeout, each share times the number of paid workers, plus the burned remainder, equals the bounty. So the contract's record of what it owes can't drop below zero.
• Handing off to your own second wallet loses money (net −500 TEYO on the first handoff), so it isn't profitable.
• At the exact deadline second, handoff reverts and timeout succeeds, so the two never overlap.

Static-analysis leads, both dismissed

• Slither "weak PRNG": the flagged line just divides the bounty and burns the leftover units; no randomness is involved.
• Aderyn "reentrancy" at line 131: this is the owner-only decimals() call, under the reentrancy guard, and nothing changes in state before it.

There is no launch.json yet, so I reviewed only the source and the README's owner wiring ($owner fills owner_).

README.md:31 gives the token split as 10% to the swarm, 88% to the pool and 2% to the paying wallet. The launch reference describes 80% to the pool and 10% to the requester's wallet by default. The requester may have chosen a different split, so I couldn't verify it and didn't report it.

I found no defects I could reproduce in JobZero or LaunchToken, so .imd-findings.json has an empty findings list. It also has a coverage row for all 10 entry points (each marked holds), plus two invariant rows. No source files were changed. The existing test suite passes: 44 tests, including the 128×64 invariant run.

What I checked, by guide:

• Execution Trace:
  • Payments: every payment is taken from the caller, and the contract checks the exact amount arrived. So no one else's leftover approval can be pulled, and a deducted fee can't be passed on at full value.
  • Deadline boundary: a handoff is allowed only before the deadline and a timeout only at or after it. Neither a gap nor an overlap exists.
  • Out-of-order calls: an expired run must be timed out before a new one can open. Every game function reverts until the token is set.
  • Run IDs: each run has its own queue and worker history, so nothing carries over from an old run.
• Periphery: the OpenZeppelin ERC20, SafeERC20 and ReentrancyGuard are used unmodified. The queue's linked-list insert and removal stay consistent, including removal of the newest entry. The paging views (getQueue, getAttempts) stay within bounds. docs/abi/*.json match the compiled ABIs exactly.
• First Principles:
  • Payout maths: a run's workers are always distinct, so the number paid is exactly attempts − 1. Shares plus the burned remainder add up to the bounty. A run with only the opener burns the whole bounty.
  • Liability tracking: totalLiability stays matched to the tokens the contract holds.
  • Fee growth: the fee would only overflow after about 4,000 handoffs. It passes the total token supply after about 470, so the run times out first.

Static-analysis leads, all false positives:

• slither weak-prng (timeout, line 215): the % only computes the leftover dust that gets burned; nothing random depends on it.
• aderyn reentrancy (setToken, line 131): the function is owner-only and guarded. While the token is unset, every game function reverts anyway.
• aderyn uninitialized local (line 311): a loop counter that correctly starts at 0.
• slither timestamp warnings: these comparisons are the 24-hour rule the brief asks for.

Trust assumptions, not defects:

• Owner token choice: the owner can set any contract with code and 18 decimals as the token. The README already documents this, and the brief asks for the owner to set it once.
• Brief-approved rules: handing the job to someone who didn't ask for it, and one person playing as many addresses, both follow from the approved rules.

Not covered: launch.json doesn't exist yet, so I didn't review the manifest. I also left out the README's split of the token supply (88% to the pool, 2% to the paying wallet), because I can't check what the requester chose.

Created launch.json with Teyo/TEYO, JobZero(["$owner"]), and the required pool values. Only the manifest changed.

Validation passed: manifest checks, compiled ABI matching, forge build, and forge test—44 tests passed, none failed.

The math review is complete and found no defects. The report is written to .imd-findings.json with an empty findings list and 14 coverage rows.

What I checked, in the Math Precision, Boundary and Numerical Gap areas

• Fee growth and split in handoff. Burn is floor(fee/2), the odd unit stays in the bounty, and the next fee is floor-compounded at 3%. I traced 348 consecutive handoffs against an independent model until the token supply ran out. The multiplication cannot overflow since that would need about 4,367 steps and the fee exceeds the whole supply after 468.
• Settlement rounding in timeout and claim. Share is bounty divided by earlier workers, the remainder is burned, and liability is reduced by exactly that dust. After every claim the liability and the contract balance both reach zero. The slither weak-PRNG lead on the modulo is a false positive. It computes dust, not randomness.
• Deadline boundaries. Handoff and goOnline require a timestamp strictly below the deadline, timeout requires at or above it. At deadline minus one second the former succeed and timeout reverts, at the deadline the inverse holds. There is no gap and no double-eligible second.
• Queue list and pagination. A 200-step random join and leave model with offset paging matched the contract's newest-first order and size exactly.
• Record math. The longest-run record uses the deadline, so a late timeout caller cannot inflate it, and ties keep the earlier run.
• Static-analysis leads. The aderyn reentrancy lead on setToken is an owner-only, once-only read guarded by the reentrancy guard. The timestamp leads are the requested deadline logic.

Coverage. All ten listed entry points are marked holds, with three invariant rows added. The one unreached row is the launch manifest, since no launch.json exists in the tree yet. When it is written it needs only JobZero with the single argument $owner.

The project's own suite of 44 tests and the invariant run pass, and the ABI export check matches. My scratch tests under test/scratch/ were removed, so the working tree is unchanged apart from the findings file.

The review is complete. The findings file is written, validated, and the tree is otherwise untouched (git status shows only the ignored findings file).

Outcome: no fund-loss or invariant-breaking defect found in the Economic Security, Invariant and Flow Gap areas. Two items reported, neither critical or high, so no proof tests were attached.

What I checked

• Traced every state-changing entry point for conservation of totalLiability against the contract's token balance, fee split and compounding, share computation and dust burn, claim once-only, and the handoff/timeout deadline boundary. All hold, and the project's own 8,192-call invariant suite asserts the same equalities.
• Traced the queue linked list for size, ordering and stale-pointer reuse. Holds.
• Checked the slither and aderyn leads. The weak-PRNG line is a modulus for dust, not randomness. The reentrancy lead in setToken is owner-only, guarded and unexploitable. None became findings.
• Build, the full 44-test suite and the ABI export check all pass.

Findings written to .imd-findings.json

1. Low, queue join consumed for the whole run. After goOffline, goOnline reverts with AlreadyJoined for the rest of that run, even though the wallet never held the job. The brief's "one entry per wallet per run" is ambiguous and the README documents this reading, so the judge decides whether it matches intent. Reproduced in a scratch test.
2. Info, free failure sanction. Any holder can end the run profitably by handing to a burner address. With A opening and handing to B, B handing to a burner, and timeout after 24 hours, B nets +4,477.5 TEYO and A nets -5,492.5 TEYO while the burner pays nothing. This is an accepted consequence of the brief's rules, reported so the requester accepts it knowingly.

Coverage record: 14 rows, all 10 listed entry points answered (9 holds, 1 finding), plus 3 invariant rows and one unreached row for launch.json, which does not exist in the tree yet.

The scratch test directory was removed, so the submission changes no repository files.

Added payment-failure, rollback, token-boundary, and expanded stateful invariant tests. All changes are under test/.

Validation passed:

• forge build
• forge test: 66 passed, 0 failed, 0 skipped
• Two invariant suites: 49,152 randomized calls total

No reproducible contract defects found.

Review complete. The findings file is written at .imd-findings.json, both snippets match the tree, and the working tree is otherwise unchanged.

Outcome: no critical, high or medium defects. The code holds on every entry point I traced. Two findings are kept, both merged from the economics specialist and reproduced in a scratch Foundry test before I removed it.

• Low, queue re-join lockout. A wallet that calls goOffline can never call goOnline again in that run, because the join flag at src/JobZero.sol:243 is never cleared. The README documents this as the chosen reading of "one entry per wallet per run". I kept it as low so the requester settles the interpretation knowingly, since the other natural reading is one active entry at a time and a run can last days.
• Info, free failure sanction. A holder can end the run by handing to a burner address they control, then share in the bounty after timeout. The brief explicitly allows handing to any typed address, so this is a design consequence for the requester to accept, not a defect.

What I checked and dropped:

• Permissions, flow, math and tester reported nothing, and I confirmed that independently: the handoff and timeout deadline boundaries complement each other, fee growth and the burn split match the brief, liability accounting balances on every path, and the queue's linked list stays consistent across head and middle removals.
• All three static-analysis leads are false positives. The weak-PRNG line is the dust modulo in timeout, the reentrancy line in setToken is owner-only and guarded while every gameplay path still reverts on an unset token, and the uninitialized local is a zero-defaulted loop counter.
• The manifest is schema-valid, names the owner via $owner, and the JobZero constructor calls no outside contract. Initcode and runtime sizes are within the factory's limits.

Verification run: build succeeded, the full suite passed with 66 tests, and the ABI export check matched both contracts.

One note outside the findings: the README states an 88% pool and 2% wallet split, while the reference default is 80% to the pool. I could not verify the launch facts, so I left it out of the findings.

Built the frontend, static export, and documentation.

• Build, typecheck, 20 unit/integrity tests, and 38 browser interaction checks passed.
• Export: 680 KB, with verified deployment manifest and ABI hashes.
• Design documentation is in docs/DESIGN.md to respect the write scope.
• Live reads show owner setup pending and insufficient sell-side liquidity. No transactions were broadcast.

Git staging/commit was blocked because .git is read-only. All deliverables remain ready in the workspace.

Saved one verified finding to .imd-findings.json. Website and contract files remain unchanged.

High — bug: growing handoff fees hide the mobile approval button behind the live bar. At 390×844, after 15 handoffs, the approval button ends at 836.59px while the fixed bar starts at 805px, covering its bottom 31.59px. Chromium and WebKit reproduce this. Change the button label to “Approve TEYO,” retain the exact fee above it, and reduce mobile assignment spacing from 10px to 6px. A browser-only trial places the complete button above the bar. The report contains exact inputs, measurements, and the source snippet at App.tsx:173.

Independent validation passed: build, typecheck, 20 unit/integrity tests, and 38 supplied browser cases. The rebuilt export matches the submitted bytes. Both ABIs match the pinned commit; all eight asset hashes verify. No real transactions were sent.

The visual idea is clear: an onchain handoff game presented as a corrupted IMD explorer, using black records and a red failure stamp. The brief’s “white monospace text” and “uppercase labels” justify two probe flags; the third misidentifies the brand and metric labels as decorative headings.

The inventory below groups related clauses and counts duplicated brief text once. Contract items reflect inherited source and test evidence, not a new Solidity audit.

Reproduced and fixed the overlap. “Approve TEYO” and tighter mobile spacing keep the full button above the live bar; exact fees remain visible.

Passed: 42 browser cases, 20 unit/integrity tests, typecheck, build and manifest verification.

Rebuilt dist/, recorded .imd-responses.json, and added evidence in docs/frontend-revision.md. Files are ready for submission; Git metadata is read-only.

The one high finding is fixed and the findings file holds an empty list.

Settling the finding. I reproduced the author's repair on the committed export, not on a rebuild. Serving dist/ with the configured RPC intercepted, connected as the current worker with zero allowance, with integer-generated fees after 7 and 15 handoffs, at 390 by 844 and scrollY 0 in Chromium 141:

The button is 44px high, reads "Approve TEYO", and the screenshot shows it wholly above the bar. The full fee still appears unrounded in the alert sentence and the next handoff metric, the full bounty in the bounty metric, and the 320, 390 and 1440 overflow checks pass. The approval calldata still carries the exact fee to the JobZero spender, and the following handoff goes through. The source change is the label at web/src/App.tsx line 173 and the 6px mobile gap at web/src/styles.css line 253, nothing else in the transaction path. The export was rebuilt from that source, and all eight manifest hashes match the files.

WebKit did not run on this machine this round. The cached WebKit build needs over a hundred missing system libraries, there is no sudo, and the earlier extracted dependency tree is gone. The author's WebKit 27.2 run records the same 796.59375px bottom for both cases against a manifest with the same SHA-256 as the committed one, and the fix is a text label plus a 4px gap with no engine-specific CSS, so I accept it rather than restate the finding.

Requirements, one line each:

• "Black background, white monospace text, thin borders, uppercase labels, glitch artifacts, red error highlights, flickering VERIFICATION FAILED stamps": met, hero stamp and tokens in web/src/styles.css.
• "A live status bar fixed at the bottom: workers online, attempts this run, TEYO burned": met, the fixed live bar.
• "Mobile first": met, the job card and connect button on the first 390 screen, no overflow at 320, 390, 1440.
• Hero line and JOB #0 record with status, worker, countdown, bounty, attempts, next fee: met, the job record card.
• Worker red alert panel with fee, approve and hand off: met, now fully visible at 390 with full-precision fees.
• Go online, online rows with one-tap hand off, manual address with held-before warning: met, harness cases pass.
• Share on X post with countdown and link: met, share link in the queue section.
• Attempts log newest first with HANDED OFF tags: met.
• Force timeout after deadline: met, expired case.
• Bounties with Claim buttons, once per wallet: met.
• Failed workers wall and records: met.
• Docs in four steps, footer with Etherscan links: met.
• Owner one-time Set TEYO panel: met.
• Wallet connection, wrong network, swap controls via Uniswap v4, manifest-driven ABIs and addresses: met, chain 1 and the two handoff addresses in dist/imd-deployment.json.
• IPFS hosting, GitHub publishing: after review. A live run, a configured token on chain, and real swaps: needs the requester.

The three probe failures are the brief's choices. Uppercase labels, monospace prose and the metric labels above values follow "white monospace text, uppercase labels", so none is a finding.

The idea. A corrupted IMD explorer record for one job that can never clear, carried by the red glitch underline and the stamped "VERIFICATION FAILED" over an otherwise plain terminal page.