The deliverable is complete and verified. Nothing else is pending, so no further tool calls are needed.

Outcome: a Foundry project at the repository root implementing the Starknet (STARKNET) fixed-supply token. forge build, forge test (30 tests, all passing, also with an empty environment) and forge fmt --check all pass with solc 0.8.26 pinned.

What was built

• src/StarknetToken.sol: contract StarknetToken inheriting OpenZeppelin v5.1.0 ERC20. The constructor takes no arguments and mints 1,000,000,000 × 10^18 to msg.sender once. No owner, mint, burn, pause, blocklist, fee or upgrade path, so the supply is constant and no privileged hand can touch a holder.
• foundry.toml: solc 0.8.26, optimizer on, bytecode_hash = "none" and CBOR metadata off (I confirmed the artifact ends without a metadata marker), ffi off, no fs permissions.
• Dependencies vendored as plain files in lib/ (forge-std commit 0258fe8, and only the five OpenZeppelin files ERC20 imports). No submodules.
• script/DeployStarknetToken.s.sol with a deploy() function tested directly and a run() for local use. It reads no environment.
• Tests in test/: success paths (metadata, exact supply, mint event, CREATE2 deployment lands the supply on the creating contract and nothing on the EOA, transfers, approvals, infinite allowance), failure paths (insufficient balance and allowance with the ERC-6093 errors, zero-address receiver and spender, rejected ether and unknown selectors, every mint/admin/pause/blocklist/seize selector from the protected test failing from both a stranger and the deployer), an opcode scan for DELEGATECALL/CALLCODE/SELFDESTRUCT, fuzz tests, and a handler-driven invariant suite for supply conservation.
• README.md documenting assumptions, deployment parameters (no constructor arguments, contract name 13 chars), the launch's pool and economics values as the manifest step's responsibility, an "After launch" section (nothing to configure), and operational responsibilities.

Notes

• The protected test's seed and swap through Uniswap v4 could not be replicated locally because its harness sources (LaunchLiquidity, HookFlags, PoolInitializationGuard) are the verifier's and not in the reads. A plain OpenZeppelin ERC20 with no transfer hooks has no path to fail those flows, and every other check in that file is mirrored in my own tests.
• I did not write launch.json and did not commit, since .git/ is off limits. All deliverables are untracked files in the working tree, ready for the upload step.

Done. I wrote the manifest for the accepted Starknet token launch and verified the tree.

What the accepted tree contains

The only deployable contract is the token at src/StarknetToken.sol. It is a plain OpenZeppelin v5.1.0 ERC-20 with a no-argument constructor that mints the whole supply to msg.sender once. There are no application contracts, no owner, no mint or burn, and no transfer hooks, so there is nothing else to name in the manifest.

What launch.json says

• Kind is custom_token, with the token contract named StarknetToken, name Starknet, symbol STARKNET, 18 decimals and an empty constructorArgs list to match the parameterless constructor.
• totalSupply is the constructor's exact mint in minor units: 1,000,000,000 tokens times 10 to the 18.
• contracts is an empty list, since the accepted tree has no application contracts.
• pool and economics are copied verbatim from the launch terms: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's 8800 bps, 2,500 IMD cap and remainder address.
• notes describe only the token actually present and run 985 characters.

Verification

• The build compiles cleanly and the full suite passes 30 tests across 3 suites, invariants included.
• A JSON check confirmed the manifest uses only the schema's six top-level keys, the supply string equals the constructor's mint and economics matches the job's object exactly.
• Git shows launch.json as the only new or changed file. No configuration, library or source file was touched.

Review complete. No defects found in the assigned area. The findings file is written at the repository root with one informational entry and a full coverage record.

What I reviewed. The token at src/StarknetToken.sol is a 30-line OpenZeppelin v5.1.0 ERC-20 with no custom logic. It has no owner, no mint or burn, no fee, no hooks and no external calls. I checked it against the Economic Security, Invariant and Flow Gap guides in the Pashov reference, plus the protected launch floor test.

What I verified.

• The project's own 30 tests pass, including the handler-driven invariant suite with zero reverts.
• A scratch probe under test/scratch/ confirmed the launch legs move exact amounts. Factory to distributor, distributor to claimant, factory to pool and factory to remainder all arrive whole, and total supply stays constant.
• Allowance accounting decrements exactly, infinite allowance never decrements, and overspend reverts. Zero-address transfer and approve revert, self-transfer keeps the balance, and ETH sent to the contract reverts.
• The constants agree with the manifest. Decimals read 18 and the minted amount equals the declared supply.
• The aderyn "large numeric literal" lead is style only. Slither reported nothing.

What I reported. One info-level entry documents the inherent ERC-20 approve race, since OZ v5 dropped increaseAllowance. It is a trust assumption, not a defect, and I said no change to the agreed design is needed. The judge can drop it.

Coverage. All three listed entry points are marked holds, with four extra rows for the supply invariant, the decimals and constant equality, constructor deployment behaviour, and the receive/rescue surface. Nothing was left unreached.

Not done. The scratch test file is left under test/scratch/, which the task says is discarded. No other file was changed.

The review is complete and found no defects in the permission model. The findings file is written with an empty list and a full coverage record, and the working tree is unchanged apart from that file.

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

• Permission map. The token has no owner, admin, minter, pauser or blocklist. The constructor's only effect is minting the full supply to the creator, which is the factory in production. A CREATE2 deployment lands everything on the factory and nothing on the transaction origin.
• Entry points. The compiled ABI exposes exactly three state-changing functions: approve, transfer and transferFrom. There is no fallback, no receive, and the runtime contains zero CALL, DELEGATECALL, CALLCODE, STATICCALL, SELFDESTRUCT, CREATE or ORIGIN opcodes.
• Inherited code. All five vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 tag, so no backdoor is hidden in the base contract or in the sender resolution.
• Guards and asymmetry. Every storage slot has a single guard shape. The approve and spend paths write the same allowance slot with matching bounds, mint is reachable only from the constructor, and burn is unreachable. The decimals constant and the inherited decimals function agree.
• Trust gap. With no privileged actor, no economic formula and no caller-class branch inside the token, none of the guide's seams can be constructed.

Verification run

• The existing suite builds and passes: 30 tests including the invariant run with supply conservation.
• A scratch suite I wrote and then deleted fuzzed arbitrary callers and the deployer against a holder's balance, fuzzed allowance spending, fuzzed unknown selectors with value, and a factory-style CREATE2 deployment. All four passed at 512 runs.
• Static analysis leads: slither reported nothing. aderyn's large-literal note is style only, and the literal evaluates to the exact manifest supply.

Noted but not reported as defects

• The standard ERC-20 approve overwrite race is inherited unchanged and already documented in the README. It is recorded in the coverage file as a trust assumption for integrators, not as a finding.

All three listed entry points are marked as holding, with ten further rows covering the constructor, the ABI surface, the vendored library, each guide, the supply invariant and the launch flows.

The review is complete and the findings file is written. No source files were changed. Only test/scratch/ (mine, not kept) and .imd-findings.json were created.

Outcome: no math defects found. The token is an unmodified OpenZeppelin v5.1.0 ERC20 with a single constructor mint, and nothing in the Math Precision, Boundary or Numerical Gap guides applies to a defect here.

What I verified

• Vendored library integrity. All five OpenZeppelin files under lib/ match the upstream v5.1.0 release byte for byte by SHA-256. Context returns plain msg.sender. So the arithmetic in _update and _spendAllowance is the audited upstream code.
• Supply constant. The expression at src/StarknetToken.sol:22 evaluates to exactly 1e27 at compile time, fits uint128 (relevant to the v4 seed), and equals 1,000,000,000 times 10 to the decimals() power. The aderyn "large numeric literal" lead is a readability lint only.
• Launch split. 10% swarm, 88% pool and 2% remainder in basis points of 1e27 divide with no remainder and sum exactly to the supply. No intermediate overflow.
• Entry-point boundaries. Scratch tests exercised max-uint transfer, exact-allowance boundary, infinite allowance over the whole supply, self transferFrom of the full balance, zero-value calls with zero allowance, and both burn paths through the zero address. All behave as the OZ contract documents. The existing 30 project tests, including the 64-run invariant suite, also pass.
• No boundary surface. The token has no external calls, no payable or fallback functions, no sentinel branches, no bytes decoding, and the ABI holds only approve, transfer and transferFrom as state-changing functions.

One informational note, not a defect. DECIMALS at line 19 scales TOTAL_SUPPLY, but decimals() is OpenZeppelin's literal 18 and is not overridden to return the constant. They agree today. If DECIMALS were ever edited, the supply and reported decimals would drift apart. Overriding decimals() to return DECIMALS closes the gap.

Coverage. All three listed entry points are marked holds, plus rows for the constructor, the supply-conservation invariant, the launch split, the decimals coupling (ref finding 1), the absent boundary surface, and the static-analysis lead. Nothing in my area was left unreached.

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

Result: no defects found. .imd-findings.json holds an empty findings list and ten coverage rows, every one holds. All three listed entry points are covered.

What I checked, for the Execution Trace, Periphery and First Principles guides

• Token body. src/StarknetToken.sol is two constants and a constructor over OpenZeppelin v5.1.0 ERC20. The supply constant equals 10^27, minted once to the constructor's caller with no arguments and no external calls, so a CREATE2 factory receives all of it.
• Entry points. I traced approve, transfer and transferFrom with concrete values in a scratch Foundry probe: zero and max allowances, max-minus-one decrementing, from equal to to, zero amount without allowance, zero sender and receiver, and the full launch flow in miniature (factory to distributor to claimant, factory to pool, factory to remainder). Every amount arrived whole and the supply stayed constant. The scratch file has been removed.
• Surface. The compiled ABI exposes exactly three nonpayable functions and no receive, fallback, payable or admin selector. The repo's own opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT passes.
• Periphery. All five vendored OpenZeppelin files are sha256-identical to the upstream v5.1.0 tag, so the inherited library is untampered.
• Repo health. The full suite passes (30 tests plus a 64-run invariant campaign), forge fmt --check is clean, and the runtime is well within EIP-170.

Observations that are not defects

• The standard ERC-20 approve race exists, as in every OpenZeppelin token. The README documents the overwrite semantics, so I did not report it.
• decimals() is OpenZeppelin's default rather than returning the DECIMALS constant. Both are compile-time 18, so no deployed state can diverge. Recorded as a coverage row.
• The protected launch floor test was read but could not be run here, since it needs v4-core sources and environment the repo lacks. Every flow it drives is a plain transfer with no exemptions required, which the probe replayed.

Not reached: nothing within my area. Tooling run was forge build, forge test and forge fmt; Slither and Aderyn output supplied to me contained no medium-or-higher leads.

The failing check is repaired. The suite now passes on the recorded seed and on two further seeds, with the build clean.

What was wrong. The fuzz test testFuzz_approveSetsExactlyTheLastValue in test/StarknetToken.edges.t.sol asserted that the reverse-direction allowance stays zero after the deployer approves a spender. The fuzzer chose a spender seed that resolved to the deployer's own address. In that case the "reverse" allowance is the very same storage slot, so it legitimately equals the approved value. This was a harness assumption error, not a token defect. The token's approve is not symmetric, and the owner-as-own-spender case is already pinned by a separate unit test.

What I changed. One line in that test now steers the fuzzed spender off the deployer address, so the reverse-slot assertion always inspects a distinct slot. No other test or file was touched.

Verification.

Check	Result
forge build	clean, no changes needed
forge test with the failing seed	1000 runs pass
forge test full suite, default seed	67 passed, 0 failed
forge test with two extra seeds	67 passed each

No new defects were found in the token, so no .imd-findings.json was written. The only modified path is test/StarknetToken.edges.t.sol, inside the allowed scope.

The review is complete. The findings file is valid JSON, the git tree is unchanged, and the only files I created are the ignored findings file and a scratch test.

Outcome: no defects. The token is an unmodified OpenZeppelin v5.1.0 ERC20 with a parameterless constructor that mints 1e27 to the deployer. Nothing a specialist reported is a defect, and my own pass found nothing either.

What I verified

• All 67 existing tests pass, including the invariant suites and the opcode scan.
• Deploying through a CREATE2 factory mints the full supply to the factory, with name, symbol and 18 decimals matching the manifest. Creation and runtime bytecode are far under the protocol size limits.
• Transfers to the zero address revert, ETH sent to the token reverts, and there is no mint, burn, owner, pause or blocklist selector in the ABI.
• The manifest keys, lowercase addresses, empty constructor arguments and supply string all match the code.

Specialist findings, judged

• The approve overwrite race from the economics specialist reproduces exactly as stated. Spender ends with 150 after allowances of 100 then 50. It is standard ERC-20 behaviour, so I kept it as an info trust assumption.
• The decimals coupling note from the math specialist also reproduces as stated: both declarations return 18 and nothing fails today. Kept as info, with the optional one-line override recorded for the author.
• The permissions and flow specialists and the test writer reported nothing, and my traces agree.

Coverage. All three entry points hold, plus three invariant rows covering supply, privileged surface and deployability. No row is unreached.