Implemented NIGHTSHIFT (SHIFT): 1 billion tokens with 18 decimals, minted once to the deployer. No admin powers or further minting.

Included vendored dependencies, tests, and deployment/operational documentation in README.md.

Verified with Solidity 0.8.26:

• forge build passed.
• All 25 tests passed, including fuzz tests with the supplied seed.
• forge fmt --check passed.

Done. I wrote launch.json for the NIGHTSHIFT (SHIFT) custom token launch, and it is the only changed file.

What the manifest describes:

• Token: contract Nightshift, name NIGHTSHIFT, symbol SHIFT, 18 decimals, empty constructorArgs since the accepted constructor takes no parameters, and totalSupply of 10^27 minor units, exactly what the constructor mints to msg.sender.
• Contracts: an empty list. The accepted tree holds only the token, so no application contracts are named.
• Pool and economics: copied verbatim from the launch reference, with IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object unchanged.
• Notes: a 1081-character description of the token's behavior and why the launch flows move exactly what they say.

Checks run:

• A script confirmed the manifest parses, uses only schema keys, has the exact supply and economics, and keeps notes under the limit.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 25 tests.
• git status shows launch.json as the only new or changed file.

I found nothing to report in my area (access control, trust gap and asymmetry). .imd-findings.json holds an empty findings list and five coverage rows, and the JSON parses. I changed no other file.

What I checked

• The contract: src/Nightshift.sol is 15 lines. Nightshift is ERC20, and its constructor runs _mint(msg.sender, INITIAL_SUPPLY) with INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18. It overrides nothing and adds no functions of its own.
• The library code: I read the bundled OpenZeppelin ERC20.sol and Context.sol in lib/ instead of trusting their labels. Their code matches the standard OpenZeppelin v5.1 code, with no hidden hook, exemption, fee or owner.
• Access Control: there are no roles, modifiers, initializer, proxy, delegatecall or self-destruct. _mint can only run from the constructor, so the supply can't grow after deployment. Nobody can pause, blacklist, freeze, seize or burn a holder's tokens.
• Asymmetry: the paired actions behave consistently.
  • transfer and transferFrom both deliver the exact amount.
  • transferFrom spends the allowance first, then moves the tokens. If either step fails, the whole call reverts.
  • Only approve and the allowance-spending step write allowances, and both are tied to the caller.
• Trust Gap: with no privileged actor and no fee or price formula, there is no overlap between who is allowed, who profits and who is treated differently.

Coverage rows

• approve, transfer and transferFrom: all three marked holds.
• Two extra invariants: "no privileged role or supply change after construction" and "the library code is unmodified standard code", both holds.

Static analysis: aderyn's one low note ("large numeric literal" at line 10) is the supply constant written out in full. It is correct and not a defect. Slither reported nothing.

Tests: the project's own suite passes, 25 of 25. I didn't run the protected launch tests, because the PoolManager and factory code they need isn't in this tree. Their checks on supply, decimals, exact launch transfers and the absence of privileged powers match what I read in the code.

One known ERC-20 trait is left out of the findings on purpose: someone with an allowance can front-run a change to it and spend both the old and new amounts. That is standard, documented OpenZeppelin behavior, not a defect in this token.

The review is complete and found no defects in the Economic Security, Invariant or Flow Gap areas. .imd-findings.json holds an empty findings list and seven coverage rows, and no tracked file was changed.

What the token is. src/Nightshift.sol is a 15-line contract inheriting unmodified OpenZeppelin v5.1.0 ERC20. The constructor mints 1e27 base units to msg.sender and nothing else exists: no owner, mint, burn, fee, pause, blacklist, hook or external call.

What I verified

• Economic Security. No external dependencies, oracles or callbacks. Transfers deliver the exact requested amount, so the factory's transfer to the distributor, claims, the single-sided seed and swaps through the PoolManager all arrive whole. The vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 release.
• Invariants. Total supply is fixed at 1e27 and equals the supply constant. The only balance writer is the OpenZeppelin update function, which is conservative. The compiled ABI exposes only approve, transfer, transferFrom and views. The project's 25 tests, including fuzzed conservation sequences, pass.
• Flow Gap. The constructor takes no arguments and mints to msg.sender, so a CREATE2 from the factory leaves the factory holding the whole supply. Decimals are the default 18. The runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE, CALL or ORIGIN opcodes.
• Static-analysis lead. The aderyn large-numeric-literal note is stylistic only. The literal evaluates to exactly 10^27.

Coverage record. All three entry points are marked holds, with four additional rows for the supply and minting invariants, dependency integrity, and the static-analysis lead.

Not reported, by design. The standard ERC-20 approve-overwrite race and tokens stranded by transfers to the contract address are inherent to the requested standard token and documented in the README. The README states Ethereum mainnet as the intended chain while the launch policy decides the chain, but the token has no chain-specific logic, so this is a documentation note rather than a defect.

The findings file is in place and the harness deliberately excludes it from git, so the tree is otherwise untouched. The review is complete.

Result: no defects found. .imd-findings.json holds an empty findings list and a seven-row coverage record, with holds for all three entry points plus four invariant rows.

What I checked, in the three assigned guides:

• Execution Trace. Traced approve, transfer and transferFrom through OpenZeppelin's _approve, _spendAllowance, _transfer and _update. Every guard fires before any write, the debit and credit sit in one block with no external call between them, and a late revert rolls back the allowance decrement. A scratch Foundry test modelled the launch: CREATE2 deploy from a factory, the ten percent to a distributor, a claim, a pool-manager-style pull by transferFrom, the remainder to the requester, and a buy and sell. Every leg moved the exact amount and total supply never drifted.
• Periphery. Diffed the five vendored OpenZeppelin files and the LICENSE byte-for-byte against upstream v5.1.0. All identical. Context._msgSender is plain msg.sender, so there is no forwarder path.
• First Principles. The supply constant evaluates to exactly 10^27, minted once to msg.sender with no constructor arguments. The compiled ABI exposes only the three state-changing functions and views. There is no receive or fallback, no mint, burn, owner or pause. The runtime passes the protected test's opcode walk and the metadata trailer confirms no IPFS hash.

The one static-analysis lead, the large numeric literal on line 10, is a style note. The compile-time value is correct, so I did not report it. The standard ERC-20 approve front-run is noted in the transferFrom coverage row as inherent to the design the README specifies, not as a finding.

The scratch test directory was removed after use. Nothing else in the tree was changed.

Review complete. The findings file is written with an empty findings list and a full coverage record.

Result: no defects found in the Math Precision, Boundary or Numerical Gap areas. The token in src/Nightshift.sol is a 14-line wrapper around unmodified OpenZeppelin v5.1.0 ERC20 with one constructor mint. It contains no division, no scaling, no downcasts and no external calls, so most failure modes in the three guides have no surface here.

What I verified, with scratch Foundry tests that all passed and were then removed:

• Supply constant equals exactly 1e27 and the manifest's totalSupply string, with 18 decimals. The aderyn "large numeric literal" lead is correct arithmetic, not a defect.
• transfer at 0, 1 wei, exact balance, balance plus one, max uint256, and self-transfer at full balance. The checked compare precedes every unchecked subtraction, and the fixed supply bounds every addition.
• transferFrom at the allowance sentinel edges. Max is untouched, max minus one decrements, an exact allowance goes to zero, and an infinite allowance is still bounded by balance.
• approve stores 0, 1, max minus one and max exactly, rejects a zero spender, and self-approval is spent normally.
• Conservation of sum of balances equals total supply across fuzzed mixed transfer and transferFrom sequences, and the 10 / 80 / 10 percent launch split has zero dust.
• Vendored library read line by line and matches upstream v5.1.0. Runtime bytecode contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. The ABI has only the three listed state-changing entry points and no receive or fallback.

One limitation: the byte-hash comparison of the vendored OpenZeppelin files against GitHub could not run because the sandbox denied outbound access to raw.githubusercontent.com. I verified the files by reading them instead, and recorded that in the coverage row.

The coverage record answers all three listed entry points as holds, plus five invariant rows. Nothing in the tree was modified apart from .imd-findings.json.

Done. The full suite passes with the verifier's fuzz seed, and I found no defect to report, so there is no findings file.

What I added (two new files under test/, the existing suite untouched):

• test/Nightshift.invariant.t.sol holds a handler and a forge invariant suite. The handler drives five actors through twelve bounded entry points: valid transfers, zero transfers, transfers into the token contract, approvals over the full uint256 range, delegated spends, plus the failure paths (overdraw, zero receiver, zero spender, spend above a finite allowance, spend above balance on an unlimited allowance, admin calls like mint/burn/pause from any actor, and ether sent to the token). Expected reverts are caught and their revert data compared byte for byte against the ERC-6093 error, so a failure path that succeeds or fails for the wrong reason is counted. Seven invariants check fixed supply, conservation across actors plus the stranded balance, balances and allowances against a simple ghost model, zero unexpected outcomes, immutable metadata, and no ether held. Runs at 256 runs by 64 depth with fail-on-revert enabled via inline config, and a plain test exercises every handler path once so the run cannot be vacuous.
• test/Nightshift.edge.t.sol holds 31 unit and fuzz tests at 1000 runs: the exact external surface (any selector outside the nine ERC-20 functions and the supply constant reverts with no effect), empty calldata and ether refused, the finite/unlimited allowance boundary at max minus one, allowance checked before balance, owner needing a self-allowance for transferFrom, pair-isolated allowances, the zero address refused as sender, exact-balance and one-unit boundaries, recipient contracts that refuse ether, independent supplies per deployment, and event shapes (one mint event, no Approval emitted on transferFrom).

Verification. The existing suite avoids forge-std and I cannot add a lib, so both files use a minimal cheatcode interface and expose targetContracts and targetSelectors by ABI, which forge 1.8 reads directly. I grounded the harness with a scratch mutant that mis-tracked balances: the model invariant failed on it with a one-call shrunk sequence, and it passed again on the real code. The vendored OpenZeppelin files are byte-identical to upstream v5.1.0. The one failure I hit during development was a harness slip (fuzzing the zero address as a sender), which is now an explicit expectation rather than an exclusion.

Results with the verifier seed:

Suite	Tests	Result
Nightshift.t.sol (existing)	25	pass
Nightshift.edge.t.sol	31	pass
Nightshift.invariant.t.sol	7 invariants + 1	pass

Only the two new test files are untracked changes. I did not commit, since the harness makes its own commits.

The review is complete and the record is written to .imd-findings.json. The file is valid JSON with an empty findings list and eight coverage rows. I changed no other file.

Verdict: no defects. All four specialists and the independent tester reported nothing, and nothing survived my own pass either.

What I checked:

• The token itself. src/Nightshift.sol is fifteen lines: a stock OpenZeppelin v5.1.0 ERC20 with a no-argument constructor that mints exactly 10^27 minor units to the deployer. There is no owner, mint, burn, pause, fee or upgrade path. The three state-changing entry points, approve, transfer and transferFrom, are the unmodified library functions and behave as the standard says.
• Vendored library integrity. I diffed every file under lib/openzeppelin-contracts against the local OpenZeppelin mirror. The only differences are header comments, pragma ranges and import order between v5.1.0 and the mirror's v5.5.0. The executable code is identical, so there is no tampering.
• Launch deployability. The build and all 58 tests pass offline. Runtime is well under the EIP-170 limit and initcode well under EIP-3860. The contract name is ten characters, the constructor calls nothing external, and the bytecode is plain OpenZeppelin with no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The manifest. The committed launch.json has the right kind, matching contract name, name, symbol and decimals, an empty constructor argument list that matches the constructor, a total supply equal to the minted amount, lowercase even-length addresses, correct field types and a notes string under the length cap.
• Static analysis leads. Slither reported nothing. The aderyn low about a large numeric literal is a compile-time constant that evaluates exactly to the manifest supply, so it is a style note rather than a defect and I dropped it.

One procedural note: git status could not run inside the sandbox because the shell cannot read the user's git configuration. That did not affect the review, since the only file I wrote is the findings record the task asks for.