The review is complete. The findings file is at .imd-findings.json and the repository tree is otherwise unchanged (the build artifacts are git-ignored and the build was stopped).

Outcome. No critical, high or medium defect was substantiated in the six genesis contracts. The file holds one low finding, three informational notes, and a coverage entry.

• Low, NftGate: a wrong record entry can neither be corrected nor removed before the seal. The only remedy is never sealing, which closes minutes 0-30 to all 2,000 holders, since the token takes the gate address immutably. Reproduced in a scratch test: record 5 for a wallet, re-record 1 reverts AlreadyRecorded, seal accepts any block including 0. This follows the brief's "each wallet once", so it is an operational irreversibility for the adapter to weigh.
• Info, ProjectVesting: YOLO forwarded through the splitter after the first split vests pro rata to the elapsed time, not over a fresh year. Reproduced: 1,000 YOLO at day 300 makes about 822 releasable at once. Documented behaviour.
• Info, ProjectVesting: any ERC-20 sent straight to DevVesting or TeamVesting is locked forever, since only the splitter starts a clock and it needs more than 527,777,777 of that token. Documented behaviour.
• Info, YoloToken (launch 1, outside the six): the constructor rejects a real openAt on a chain at timestamp 1. The launch-1 adapter should confirm the custom_token rehearsal runs at a realistic time.

What was verified sound. Access control, the transient one-shot starter binding, absence of forbidden opcodes, proxies, owners or pause paths, the exact split shares and at-once payments, clock start once at the split, the gate's booking arithmetic, the off-chain snapshot hash matching the on-chain one, and the constructor arguments in LaunchPlan against the brief. The previous swarm finding on the vesting clock is correctly fixed.

Not reached. The live ProjectFactory internals, the custom_token protected rehearsal, floor/OwnerChecks.sol, and the mainnet fork test (no FORK_URL). The full 686-test suite could not be run: the via-IR build of the whole tree exceeded the budget on this two-core machine. The token contracts and their unit tests were instead compiled and run in a scratch project outside the repository, where the four existing vesting tests passed.

The work is complete and verified. Launch 0 ships as it arrived: no source file under src/ or script/ changed.

What I found

• Launch rules: all six contracts already comply. Constructors are nonpayable and take only addresses, there is no owner, pause, upgrade path, receive, DELEGATECALL, CALLCODE or SELFDESTRUCT, and the YoloSplitter's constructor skips bindStarter on an address without code, so it deploys alone on an empty chain and binds the four vestings inside the factory's single transaction. The gate's writer is the brief's static project wallet, which is also $owner.
• Imported audit: all five findings reproduce, none required a change.
  • Finding 1 (low, no correction before the seal) is the brief's own rule ("each wallet once", immutable after the seal) with no funds at risk. I accepted it explicitly and wrote the operational rule for the writer: compare snapshotHash, walletCount and totalNfts against the published json before sealing, since a wrong gate cannot be replaced once launch 1 takes its address.
  • Findings 2 and 3 are documented behaviour of the single-clock vesting. Finding 4 concerns YoloToken, which launch 1 deploys, not this one. Finding 5 is a coverage note.
• Own review: nothing reproduced. Access, checks-effects-interactions, underflow paths in left/consume/vestedAmount and the binding window were traced and are sound.

What I added

• test/audit/genesis/GenesisLaunchAudit.t.sol: 4 launch-rule tests (one-call deployment with the mainnet arguments through the plan's factory, runtime scan for forbidden opcodes and EIP-170, no owner() or receive, each constructor alone on an empty chain, nonpayable constructors) and 6 reproductions pinning the audit findings plus an end-to-end split of the whole launch.
• ADAPTATION.md: the rule-by-rule check, each finding with its verdict and reason, and the checks run.

Checks run

The mainnet fork rehearsal was not run here because no archive RPC is available on this machine; it is unchanged by this work.

I found no math defects I could reproduce in the six genesis contracts, so .imd-findings.json has an empty findings list. It has a coverage row for each of the 113 listed entry points plus three invariant rows. I changed no repository files; a scratch test I ran is deleted and the working tree is clean.

What I checked (rounding, edge-value and number-gap guides)

• NftGate: a buyer's spend can never exceed their allowance. A buy books only if it fits, the list is frozen at the seal, and nothing books before it, so consume and left can't underflow. Amounts of allowance + 1 or the maximum integer book nothing. The token's strict sealedAt < openAt check matches "sealed before trading opened".
• ProjectVesting and the four vestings: the vested amount rounds down and only ever grows with time and with what arrives, so a release can never take more than has opened. All the integer conversions are safe, and the starter binding can't be taken by anyone else.
• YoloSplitter: the first split needs more than 527,777,777 YOLO, so every vesting is paid a nonzero amount before its clock starts. Later arrivals go to TreasuryVesting.
• Fuzz test (256 runs, passed): I deployed all five, split remainders from 527,777,777 to 1B YOLO, added later arrivals at random times, and released over 800+ days. Every share was exact (incentives 250M, dev 77,777,777) and all of the YOLO was paid out with none left behind. A separate test of the gate's limits also passed.
• Outside the genesis launch: I also traced the math in YoloLockHub, YoloSweetener, YoloPredict and YoloToken's tax and gate path. Nothing reproduced: no subtraction goes negative, the lock and power amounts fit their types, and the last claimer of each payout takes what's left.

Coverage: 29 entry points are marked holds: every genesis entry point, plus the YOLO modules above. The other 84 (TaskVault, CaseDesk, DisputeDesk, HiddenList, the registries, trophies, the adapter and BuybackBurner) are marked unreached. They are outside this launch and I didn't review them.

Leads I dropped:

• The writer can record any NFT count; that's a trusted writer by design.
• The YOLO token's sell tax is taken on top, so a holder can't sell their entire balance during the tax window. That's documented and belongs to the token's launch.

I didn't run the full forge test suite or the mainnet fork rehearsal for this review.

The review is complete and the findings file is written. Only .imd-findings.json was added; no repository file changed.

Result: no reproducible defect of medium or higher in the six genesis contracts. The Execution Trace, Periphery and First Principles checks were applied to NftGate, ProjectVesting and its four schedules, and YoloSplitter, plus the token's gate call and the snapshot script. I could not run the repository's own suite here: the via-IR build of the whole project exceeded the command time limit twice with an empty cache. I verified the behaviour instead in a standalone Foundry harness outside the repository that compiles only the genesis contracts, deploying all six in one transaction like the factory. What that run confirmed:

• Binding works only inside the deployment transaction and only once. A vesting deployed alone can never be bound afterwards.
• First split with a remainder 5 wei short of 750M pays every share exactly once, starts all four clocks, and a second call pays nothing twice. Later arrivals go to the treasury vesting.
• Release math at the start, half way, at the end and past the end matches the schedules, including the at-once parts and dust sent before the split.
• A hostile token that reenters the splitter and a vesting from its transfer cannot start the YOLO clocks early or mark YOLO as split.
• The gate refuses before the seal, books per calling token only when the amount fits, never underflows, and its hash chain matches the Python script.
• The token's window through the gate reverts for a non-listed wallet and for an amount past the allowance, and a split after trading opens is neither taxed nor gated.

Two low-impact items are recorded, each with a concrete input:

1. Info. A token other than $YOLO sent to the splitter with a balance at or below the fixed threshold is locked forever, since split reverts and there is no sweep. By design, recorded so a stray transfer is not treated as an incident.
2. Low. The snapshot script accepts an --extra wallet with a count of zero and publishes a hash and batch the gate refuses with ZeroEntry. The failure is loud and before the seal, so nothing on chain is harmed.

The coverage record answers all 116 entry points. The genesis contracts and the token's transfer paths are marked as holding with the executed evidence above. Entry points of launches 1 to 3 are marked unreached, since they are outside this area and were not read. No proof file was written because nothing reached high or critical severity.

Scope

Files read in full: src/token/NftGate.sol, src/token/ProjectVesting.sol, src/token/Vestings.sol, src/token/YoloSplitter.sol, src/token/YoloToken.sol (for the gate and tax interplay), script/LaunchPlan.sol, docs/TOKENOMICS.md, docs/LAUNCH-TASK.md launch-0 text, ADAPTATION.md, the swarm-117 vesting test and the fork rehearsal's split section. Also read for severe defects only: YoloLockHub, YoloPredict, BuybackBurner. Guides applied: Economic Security, Invariant, Flow Gap, plus the Senior Auditor's Mindset.

Not run: forge test and the fork rehearsal. The via-IR build of the whole project exceeded the 10-minute command limit on this 4-core worker, so every conclusion rests on line-by-line tracing. The coverage record says so.

Severity counts: 0 Critical · 0 High · 0 Medium · 0 Low

No reproducible defect in the launch-0 economics. .imd-findings.json holds an empty findings list and 124 coverage rows, one for each listed entry point plus eleven invariant and flow-gap rows.

What was checked and held

• Gate capacity invariant. used[token][buyer] never exceeds allowanceOf(buyer): consume books only when the amount fits, reverts before the seal, and nftsOf is frozen by the seal. left() cannot underflow. The token's own check in _update is the same comparison.
• Snapshot immutability and writer. record and seal are writer-only, record is refused after the seal, the writer is the brief's project wallet.
• Split conservation. The four fixed shares sum to FIXED, treasury takes the rest, done is set before any transfer, and the second call forwards everything to TreasuryVesting. The remainder of 750M exceeds FIXED, so the first split is reachable.
• Clock start guarantee. Only the bound starter starts a clock, binding works only in the deployment transaction, and the YOLO starter path exists only inside a first split(YOLO) that already saw the remainder. Dust pre-start is closed.
• Vesting monotonicity. balance + released never falls for YOLO because vesting-to-EOA transfers hit no tax branch, so releasable never underflows and no beneficiary is overpaid.
• Stuck-remainder path. release on YOLO is a plain transfer to an EOA and cannot revert or re-enter, so split cannot be bricked. A hostile token passed to split or release moves only its own books.
• Constructor arguments in LaunchPlan.genesisLaunchWith match the brief's six entries and the launch text byte for byte.

Observations, not findings

The ERC-6909 claim bypass of gate and tax, untaxed sells before openAt, no correction path before the seal, pro-rata vesting of later arrivals, and tokens sent straight to a vesting having no clock are all documented accepted rules and were re-checked, not reported.

Created launch.json with the six contracts, exact approved arguments, and dependency order. No other submitted file changed.

Manifest and compiled ABI checks passed. No new blocking findings identified.

forge build passed. forge test with the supplied seed: 696 passed, 0 failed, 3 skipped. Mainnet fork checks were skipped without FORK_URL.

I added one test file, test/genesis/GenesisInvariants.t.sol, with 19 new tests. The full forge test run with the verifier's seed gives 715 passed, 0 failed, 3 skipped. The 3 skipped are the fork rehearsal, which needs FORK_URL; it couldn't run here (no RPC), so the live run is still owed. Nothing outside test/ changed, and I found no defect, so there is no .imd-findings.json.

Invariant tests (128 runs × depth 60, set inline in the file). All six contracts are deployed with the mainnet arguments through LocalFactory in one call, as the launch does.

• YoloSplitter and the four vestings: random sequences of tokens arriving at the splitter, third parties sending tokens straight to a vesting, split, release by any caller, and time jumps. After every sequence:
  • Nothing is lost, and nobody but the five fixed recipients is ever paid.
  • Each vesting's balance plus what it has released equals what it received, and its beneficiary holds exactly what was released.
  • Nothing is released beyond the schedule, the at-once part is always free, and the vested amount never goes down.
  • split succeeds exactly when the balance is above 527,777,777 or the first split is done; release never reverts and pays exactly what was open.
  • The stabilizer gets 150M only at the first split. No clock starts before the split, and every clock starts at the split's timestamp, once. A vesting is fully open after its duration.
• NftGate: recording, sealing, and calls from non-writers, plus consume from two different calling tokens. After every sequence:
  • The wallet count, NFT total, per-wallet counts and the running snapshotHash match what was written.
  • The seal never reopens and the hash never changes after it.
  • No buyer is booked beyond its allowance, each token's books stay separate, and the gate holds nothing.

Failure paths and edge cases (unit and fuzz tests):

• Splitter:
  • Exactly 527,777,777 is refused and one wei more splits; an empty splitter and a non-token address are refused.
  • Anything arriving after the first split goes only to the treasury vesting.
  • Splitting a decoy token cannot start the $YOLO clocks.
  • Each zero constructor argument is refused, and passing one vesting twice reverts.
• Vestings:
  • Only the splitter starts a clock, and not with an empty balance.
  • bindStarter is closed to everyone after the launch transaction.
  • At random times, two releases add up to what a single release would pay for all four schedules, so calling often gains nothing.
• Gate:
  • A duplicate wallet within one batch undoes the whole batch; empty, mismatched and zero entries are refused, and an empty snapshot can't be sealed.
  • Booking exactly what is left succeeds, while one wei more books nothing; a wallet outside the snapshot books nothing.

One test failed at first because of my own mistake. With via-IR the compiler can re-read block.timestamp after a vm.warp, so my saved start time moved. The test now reads the start time from the vesting's startOf.

Not filed as a finding: a snapshot count big enough to overflow nftsOf * 500,000e18 would make consume revert for that wallet. Only the trusted project wallet can write counts, and real counts are at most 2,000, so I treated it as information rather than a defect.

The review is complete. The findings file is written, every listed entry point has a coverage row, and the scratch checks pass.

Outcome. Under the Access Control, Trust Gap and Asymmetry guides, the six genesis contracts hold. I found no defect in NftGate, the four vestings or YoloSplitter that survives the validation gates. The one item reported is informational and sits in the launch 1 token, not in the six.

What was checked and confirmed by tests in test/scratch/GenesisAccess.t.sol (nine tests, all passing):

• Gate access. Only the writer records and seals, each wallet once within and across batches, nothing changes after the seal, and consume reverts until the seal.
• Gate bookkeeping. A stranger calling consume spends only its own book. Booked use never exceeds the allowance, so the left view cannot underflow. The gate's booking and the token's check agree exactly at the allowance boundary.
• Binding window. The splitter is the starter after a one-transaction deployment. Every later bindStarter call reverts. An in-transaction early binder would only make the splitter's constructor revert, which fails the whole launch rather than leaving a half-bound vesting.
• Vesting release. Non-starter callers, including the beneficiary, start no clock and get only the at-once part. After the split each beneficiary receives exactly its schedule and nothing more.
• Splitter. The first split refuses exactly 527,777,777, pays the five fixed recipients once, starts all four clocks in the same transaction, and later arrivals go to the treasury vesting only. A hostile token reentering from its transfer function reaches only public paths and changes nothing in the YOLO books. Reentry from balanceOf is impossible because the vesting reads it by STATICCALL.

Reported finding. YoloToken's whitelistActive view returns true on an unsealed or late-sealed gate while every window buy reverts with SnapshotNotSealed. This is a view-versus-write asymmetry with no funds at risk, recorded as info.

Trust assumptions recorded, not findings. One EOA is the gate writer, the TreasuryVesting beneficiary and the tax recipient. A writer that lists its own wallets is an admin action against documented intent with no unprivileged amplifier, which the validation gates reject.

Not reached. The mainnet fork rehearsal needs FORK_URL, and the full 686-test suite could not compile here because solc under via-IR over all 177 files is killed for lack of memory. Sources and the scratch tests compiled and ran with the rest of the test tree skipped. The live factory's behaviour between the vesting and splitter deployments is taken from the brief and the fork test's interface, not executed.

I found no defects that reproduce in the six genesis contracts, so .imd-findings.json has an empty findings list ({"findings":[]}) and a coverage record with all 113 entry points.

What I checked myself (src/token/NftGate.sol, ProjectVesting.sol, Vestings.sol, YoloSplitter.sol):

• NftGate:
  • Only the writer can call record and seal, and only before the seal.
  • record refuses zero entries, wallets listed twice and malformed batches.
  • consume reverts until the seal. It books per calling contract and only when the amount fits, so a wallet's use never exceeds its allowance. No other caller can touch the token's books.
• Vestings:
  • bindStarter works once, only in the vesting's own deployment transaction (the flag is set in its constructor).
  • Only the splitter starts a clock, and only while the vesting holds some of that token.
  • release records the payment before transferring.
  • The compiled-in amounts and durations match the brief: 62.5M at once then 730 days; 365 days; 365 days; 74,074,074 at once then 365 days.
• YoloSplitter:
  • The first split needs more than 527,777,777 YOLO.
  • It marks the token done before paying the five fixed addresses, then starts the four clocks. Later calls forward everything to TreasuryVesting.
  • It only binds a vesting that already has code, so its constructor still deploys alone on an empty chain.
  • Constructor argument order matches the brief.
• A fake token can start clocks only for itself, and calling back into split gains nothing.
• These transfers pass through YoloToken's tax and window checks without being blocked.
• The 49 tests on this launch (test/genesis, test/audit/genesis, test/audit/swarm117) pass. I did not run the full suite or the mainnet fork rehearsal, which needs an RPC URL.

The specialists' findings, all dropped:

• YoloToken view vs. buys (permissions specialist, info): it's true that whitelistActive() reports the window open while buys revert on an unsealed gate. I dropped it because YoloToken belongs to launch 1, not this one, and the brief accepts a window closed when the gate is unsealed. No funds are at risk.
• Foreign tokens stuck in YoloSplitter (flow specialist, info): this also reproduces, but it is a result of the brief's rule of no owner and no sweep. It is the same kind of case as ADAPTATION.md finding 3.
• snapshot.py with a zero --extra count (flow specialist, low): this reproduces too: the batch reverts with ZeroEntry. It's a typo in the project wallet's own hand-written input to an off-chain script. The failure is immediate and recoverable: the failing batch reverts as a whole, and rerunning without the bad entry leaves the earlier batches unchanged. Nothing on chain is affected, so it isn't worth reopening the work.

Coverage: the 14 rows for this launch's contracts are marked holds, each with a reason. The other 99 belong to launches 1–3 and are marked unreached with that reason.