The review is complete. The findings file holds one low finding and three info notes; no critical, high or medium defect reproduced in the six genesis contracts.

What I read. All six in full: NftGate, ProjectVesting, the four schedule contracts in Vestings.sol, and YoloSplitter. For context I also read YoloToken.sol (the gate's only caller, launch 2), the genesis part of script/LaunchPlan.sol, the snapshot script, the token test suite, the starter mock, and the two protected tests. Not reachable: the live ProjectFactory source, floor/OwnerChecks.sol (not in the tree), and the fork rehearsal could not be run without a FORK_URL.

What I verified.

• Access control matches the stated design: writer-only record and seal, starter-only clock start, no owner, pause, upgrade or fee anywhere.
• The transient bindStarter guard works: it reverts BindingClosed outside the deployment transaction and after the splitter has bound. Confirmed by scratch test.
• Arithmetic: the four fixed shares sum to 527,777,777; the vested amount is monotone, rounds down and returns the full total at the end; left() cannot underflow because used never exceeds the allowance.
• No reentrancy surface: done[token] is set before transfers, YOLO is a plain OpenZeppelin ERC-20, and the gate makes no external calls.
• Compiled runtime of all seven contracts scanned: no DELEGATECALL, CALLCODE or SELFDESTRUCT, sizes under 2.2 KB.
• The existing suite for these contracts passes (34 tests), and my four scratch probes in test/scratch/GenesisEdges.t.sol pass.

Findings written to .imd-findings.json.

• Low: YoloSplitter.sol:96 silently skips the starter binding when a vesting address has no code. If the bind is ever missed, the vested parts of that vesting are locked forever with no recovery path, and launch 2 cannot be undone. The guard is operational only. Recommended for the adapter: check starter() equals the splitter on all four vestings after launch 0 and before launch 2.
• Info: the gate writer's pre-seal powers are unbounded on chain (any count, total above 2,000 NFTs, any snapshot block). This is the accepted trust assumption, recorded with concrete inputs so the panel sees it.
• Info: a mis-recorded wallet cannot be amended before the seal; the only remedy is a fresh gate before the token launch.
• Info: the coverage statement above, anchored to the splitter.

No proof files were needed since nothing reached high severity. Nothing outside .imd-findings.json and test/scratch/ was written.

I found no defects in the permissions of the six genesis contracts (NftGate, the four vestings and YoloSplitter). .imd-findings.json has an empty findings list and a coverage row for each of the 113 listed entry points, plus two invariant rows. No repository files changed: I deleted my scratch test and the working tree is clean.

What I checked, using the Access Control, Asymmetry and Trust Gap guides:

• NftGate:
  • Only the writer can call record or seal, and both revert for good after the seal.
  • consume is open to anyone, but it only books against the calling contract's own record. A stranger calling it leaves the token's allowance untouched, which I confirmed in a test.
  • The gate's "book only if it fits" check matches the token's revert check exactly.
• Vestings:
  • The YoloSplitter claims the starter role inside the deploy transaction, and any later bindStarter call reverts.
  • A stranger calling release while the vesting holds tokens does not start the clock.
  • release only ever pays the fixed beneficiary.
• YoloSplitter:
  • It pays only five fixed addresses, and the done flag is set before any transfer.
  • Calling split with a fake token can only start clocks for that fake token, never for $YOLO.
  • In the test, the first split paid the expected at-once amounts: 150M to the stabilizer, 62.5M from incentives and 74,074,074 from treasury.

Rejected leads:

• These two are already recorded in ADAPTATION.md (findings 1 and 2), so I didn't file them again:
  • A vesting with no code gets no clock.
  • The writer has unlimited power before the seal: it can record any counts and any snapshotBlock, and nothing on chain caps the total at 2,000 NFTs.
• These follow the documented rules, so they aren't findings:
  • A token the splitter never releases has only its at-once part free.
  • If the snapshot isn't sealed, nobody buys in minutes 0–30.
• None of the static-analysis items on these six turned into a reproducible defect.

Coverage:

• 39 holds:
  • The 13 genesis and $YOLO token functions, traced in full.
  • 20 privileged functions in the later launches. For these I only confirmed the guard is there (onlyDesk, only(vault/disputeDesk), onlyOwner, onlySafe, the dev check); I didn't trace their logic.
  • The 2 invariant rows.
• 76 unreached: the remaining later-launch functions, which are outside this genesis scope.

I didn't run the fork rehearsal because no FORK_URL is set here, so whether the live ProjectFactory binds the starter on all four vestings is only shown by the existing local-factory tests. The fork test checks it for the dev and treasury vestings only.

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

Outcome: no reproducible defect in the math of the six genesis contracts. I traced every division, subtraction, cast and boundary in NftGate, ProjectVesting (the four compiled schedules) and YoloSplitter against the Math Precision, Boundary and Numerical Gap guides, then fuzzed the invariants in a scratch test under test/scratch/ (vesting conservation and monotonicity under random arrivals and releases by anyone, gate booking bounds per caller, splitter share sums and the FIXED boundary, buy and sell tax identities). All probes pass, as do the 34 existing token, gate, vesting and splitter unit tests.

What holds, specifically:

• Vesting formula is monotone in both time and received total, so released never exceeds vested and release can never underflow or brick for a standard token. Rounding down in the stream loses nothing because the end returns the whole total. Pre-split dust releases by non-starters pay only the unlocked part and do not shift the at-once amount paid at the split.
• Gate books only if the amount fits and usedBefore can never exceed allowance, so the subtraction in consume and left cannot underflow. The token's reject condition is the exact complement of the gate's accept condition. The off-chain snapshot script's running hash and record calldata match the contract byte for byte.
• Splitter fixed shares sum exactly to 527,777,777 and the remainder of 750M leaves 222,222,223 for the treasury vesting, with later arrivals forwarded. The strict bal > FIXED guard is unreachable as a lock at launch.
• Launch text numbers (shares, at-once parts, durations, allowance per NFT, recipients) match the code.

One informational note was recorded: the buyTaxBps view truncates to whole basis points while the transfer path taxes at the exact fraction, a sub-1 bps quoting drift with no on-chain effect. The static-analysis leads in my area (strict equalities on zero sentinels, the lock hub's rounded-up weeks) were checked and are benign.

Coverage: 117 rows, one per listed entry point plus four invariant rows. The 23 in-area entry points (gate, five vesting contracts, splitter, the token's transfer paths and the two lock-hub leads) are marked holds with reasons. The rest are honestly marked unreached as outside the assigned area.

Review complete. The findings file is at .imd-findings.json with two info-level items and a coverage row for every listed entry point.

Outcome: no defect above informational in the six genesis contracts. I traced NftGate, ProjectVesting (all four schedules), and YoloSplitter through the Execution Trace, Periphery and First Principles checklists, and confirmed each claim with tests rather than by reading alone.

What I verified, with tests I wrote under test/scratch/ and the project's own suites:

• Launch handshake. The four vestings bind the YoloSplitter as their only starter inside the deployment transaction, a lone vesting cannot be bound later, and the fork rehearsal against the live ProjectFactory on mainnet passes with FORK_URL set, including the starter check and every share.
• Split. Shares are paid in the stated amounts with the rest to the treasury vesting, the splitter holds nothing after any call, a balance equal to the fixed sum reverts, later arrivals go to the treasury vesting, and a fake token sent by an attacker only starts that token's own clocks, never YOLO's.
• Vesting schedules. Dust sent before the split never starts a clock and cannot raise the at-once part above its cap. A fuzz over release times with a mid-stream top-up shows the beneficiary's balance always equals the vested amount, so nothing is over-paid or stranded. Release twice in one block pays zero the second time.
• Gate. Consume reverts until the seal, books only what fits per calling token, and the writer has no power after the seal. The snapshot script's running hash matches the gate's encoding, so the published hash can be recomputed.
• Token side. I traced the token's transfer hook for the gated window and both tax windows. Wallet-to-wallet transfers, including vesting payouts, are untouched.
• Suites. The full unit suite passes (691 tests), and the two fork rehearsal tests pass against the local mainnet endpoint.

The two informational findings, both inside the accepted trust in the snapshot writer, each with a confirmed reproduction:

1. seal accepts any block number, including zero or a future block. The value is never read on chain, so it only weakens the published reference. A one-line bound would catch a typo.
2. record accepts an NFT count large enough to overflow the allowance, which makes consume and left revert for that wallet all window. A cap at the collection size would fail it at write time.

Coverage: all 118 rows are answered. The 21 entry points of the genesis contracts and the token hold or carry one of the info findings; the 96 entry points of the later launches are marked unreached, since the assignment asked for depth in this area first and none of them touch the genesis flow. One handoff item is recorded in the token's row: the launch-2 manifest must give the real NftGate address, because a gate address without code silently removes the window.

I added 29 unit and fuzz tests and 6 invariant tests for the six genesis contracts, all in test/genesis/. I found no defect, so there is no .imd-findings.json.

Checks run: the full forge test with the verifier's fuzz seed gives 722 passed, 0 failed, 3 skipped. The 3 skipped are the fork tests, which need FORK_URL and an archive RPC this machine doesn't have. The mainnet rehearsal with live holders and routing was not run here and is still owed. forge build is clean and I changed no source file.

test/genesis/GenesisLaunch.t.sol

• Launch: all six contracts are deployed in one call through the repo's local stand-in for the factory, with the brief's exact constructor arguments written out. The tests check every address, schedule, share and FIXED, that all four vestings name the splitter as their starter, and that LaunchPlan.genesisLaunch produces the same code. The gate works even though the real NFT address has no code on the test chain, which shows it never reads the NFT.
• Failure paths:
  • Starter binding: bindStarter is refused after the launch transaction (even when called as the splitter), and a second bind inside the deployment transaction also fails.
  • Constructors: a zero address is rejected in every splitter position and as every vesting's beneficiary, and bad schedule lengths are rejected.
  • Split:
    • It reverts with NotArrived at 0 and at exactly 527,777,777, and succeeds one wei above.
    • A remainder a few wei short of 750M still splits.
    • Later arrivals go to the treasury vesting without restarting any clock.
    • A second token gets clocks of its own.
    • If a recipient refuses the transfer, the whole split reverts and nothing is left half-paid.
  • Vestings: tokens sent to a vesting before the split start no clock, release called by anyone pays only the beneficiary, and tokens arriving late follow the running schedule.
  • Gate:
    • Only the writer can record or seal, and a batch that fails keeps nothing.
    • consume reverts before the seal for every caller.
    • After the seal it books per calling token and only what fits.
    • Unlisted wallets and zero amounts book nothing.
    • The seal is final.
• With the real YoloToken: the split and the releases are never taxed, including during the taxed hour. A snapshot that is unsealed or sealed exactly at openAt makes the token refuse every buy in the window.
• Fuzz:
  • Any arrival above the fixed shares splits with nothing created or lost, and any amount at or below always reverts.
  • Each schedule stays between its at-once part and the straight line, never decreases, and is complete after its duration.
  • Releasing in many small steps pays exactly what one release at the end pays.
  • Gate bookings never exceed a wallet's allowance.

test/genesis/GenesisInvariant.t.sol (random call sequences, 256 runs)

• Splitter and vestings: the handler randomly sends tokens to the splitter, donates directly to vestings, splits, releases from random callers and moves time forward. The invariants:
  • Every token minted is somewhere it should be.
  • Each beneficiary holds exactly what its vesting released, never ahead of the schedule.
  • Clocks start only at the split, all four at the same second.
  • The fixed shares are paid exactly once, the rest goes to the treasury vesting, and a split above the fixed shares never fails.
• Gate: the totals, wallet count and snapshot hash match what was written; no caller books more than a wallet's allowance; the seal never reopens.

One observation, not reported as a defect: record has no upper limit on a wallet's NFT count. An absurd count (above about 2²⁵⁶ / 5×10²³) makes allowanceOf and consume fail for that wallet. Only the writer can cause this, and the brief accepts the writer's off-chain snapshot as a trust assumption, so I wrote no test that blesses or flags it.

One thing a future test author should know: with

The full test run was stopped by the ten-minute background limit before it produced a summary. No failure lines appeared in its output before the stop. Not enough time remains to rerun it, and no Solidity was changed, so the existing suite is not affected by this task.

Final state:

• launch.json is written, validated for schema shape, and matches the six constructors in the accepted source.
• The one-transaction deployment rehearsal and the two token suites covering NftGate, the four vestings and YoloSplitter passed with the verifier's fuzz seed.
• git status --porcelain shows only launch.json as new. ADAPTATION.md is unchanged because no finding required an adaptation.

The review is complete and .imd-findings.json is written with 3 info findings and 116 coverage rows (all 113 listed entry points plus 3 invariants).

Verdict on the audit. None of the four specialists found a defect in the six genesis contracts, and my own pass agrees. NftGate, the four ProjectVesting instances and YoloSplitter hold: the transient bindStarter flag is consumed once inside the launch transaction, only the splitter starts a clock, released is booked before every transfer, done is set before the split pays, used never exceeds a wallet's allowance, and no constructor needs code or address bits. The manifest matches the brief in every argument, reference and recipient.

Findings kept, all info, all reproduced in test/scratch/JudgeLeads.t.sol:

• NftGate.seal accepts any block value (merged from audit_flow and audit_economics, same root cause). The token never reads it, so nothing changes on chain. Within the accepted writer trust.
• NftGate.record accepts a count that overflows the allowance, which makes consume revert for that wallet after the seal. A writer typo of about 2.3e50 is required. Within the accepted writer trust.
• YoloToken.buyTaxBps rounds down while the transfer path taxes at the exact fraction. Drift of under 1 bps, no loss, and the token belongs to launch 2, not this one.

Dropped or settled: no specialist finding was dropped. The slither and aderyn lines touching the six contracts are flag tests and an uninitialized local that defaults to zero, not defects.

Checks run: the scratch suite (4 tests) passes, the genesis unit and invariant suites pass (31 tests). The full non-fork suite finished with exit code 0, but its filtered output was lost when the command was moved to the background, so I report it as exit code 0 rather than a counted pass. The fork rehearsal was not run, since no archive RPC is on this machine.

Coverage: the 14 genesis entry points, the token's three ERC-20 entry points and the smaller launch 2 and 4 contracts are marked holds with a one-line trace each. The 50 CaseDesk, DisputeDesk, TaskVault, HiddenList and YoloPredict entry points are marked unreached, since they belong to later launches and did not fit the budget.