The NIGHTSHIFT token project is complete, verified, and committed on main.

What was built

• src/ShiftToken.sol: a self-contained ERC-20 named NIGHTSHIFT, symbol SHIFT, 18 decimals. The constructor mints the full 1,000,000,000 supply once to the deployer, takes no arguments, and makes no external calls. There is no owner, mint, burn, pause, blocklist, fee, or upgrade path, so every launch flow moves tokens whole.
• script/DeployShiftToken.s.sol: a reviewable deploy helper whose deploy() function tests call directly. It reads no environment variables.
• test/ShiftToken.t.sol and test/DeployShiftToken.t.sol: 38 tests covering metadata, supply, transfer and allowance success paths, every revert path with exact custom errors, event emission, rejection of common admin selectors from both a stranger and the deployer, an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and five fuzz tests for conservation and bounds.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", disables ffi and filesystem access.
• lib/forge-std/ holds forge-std v1.11.0 vendored as plain files, with no submodule.
• README.md documents behaviour, deployment parameters, the launch values, the empty "After launch" section, assumptions, operational responsibilities, and which security tools ran.

Verification

Check	Result
forge build	clean
forge test with the verifier's fuzz seed, empty environment, offline	38 passed, 0 failed
forge fmt --check	clean

A scratch test in test/scratch/ also reproduced the protected floor's non-pool checks (CREATE2 deployment from a factory-like contract, the swarm share flow, and the admin-call lists) and passed. The pool seed and swap checks need the verifier's v4-core harness and were not reproduced locally, but a token with no transfer rules has nothing that could fail them.

Slither and Mythril were not on this machine and did not run. The commit excludes the stray dotfiles and .claude/ directory in the workspace.

I found no defects in src/ShiftToken.sol. I wrote .imd-findings.json with an empty findings list and a coverage row for each of the three entry points, all marked holds. I read the code and traced it by hand. I didn't run any Foundry tests, and I didn't open the existing test files or the supplied protected tests.

• approve: it refuses the zero address as spender, sets the allowance to exactly the amount given, and emits Approval.
• transfer: the balance check comes before the subtraction that skips overflow checks, so it can't wrap. Sending tokens to yourself leaves your balance unchanged. The total of all balances always stays at the fixed supply.
• transferFrom: it spends the allowance before moving the tokens, and an allowance of the maximum value is never reduced. Any failure reverts the whole call. There is no fee or burn, so the launch transfers out of the factory, into the pool and to the distributor all arrive at their full amounts.
• Supply: the constructor mints 1,000,000,000 × 10^18 to the deployer once. There is no way to mint or burn after that, no owner role, and no delegatecall or selfdestruct.

The static analysis line about a large number at src/ShiftToken.sol:43 refers to the supply constant. It's correct and harmless, so I didn't report it.

One minor behaviour I didn't treat as a defect: anyone can call transferFrom with the zero address as the sender and an amount of 0. It succeeds and logs a zero-value transfer from the zero address. That moves no tokens and changes no balances.

I found no defects in my area, so .imd-findings.json holds an empty findings list and four coverage rows: all three entry points plus one invariant, each marked holds. I read the contract only; I wrote no test and ran no Foundry tests.

Access control: src/ShiftToken.sol has no owner and no roles. It also has no mint after the constructor, no burn, pause, blocklist or upgrade path, and no privileged functions at all. The constructor mints the fixed TOTAL_SUPPLY of 1,000,000,000 × 10¹⁸ once to msg.sender, which is the factory at launch.

Trust gap: a holder trusts nobody but themselves and the spenders they approve.

• transfer moves only the caller's own balance.
• transferFrom uses up the caller's allowance before moving anything. An allowance of type(uint256).max is treated as unlimited and is not reduced; any other allowance is checked and reduced. A failed check reverts the whole call.
• approve sets only the caller's own allowance and rejects the zero address as spender.

Asymmetry: there are no fees, exemptions or address-specific rules. The factory's payouts to the distributor and the pool, and trades through the PoolManager, move exactly the amount stated, so none of the launch transfers arrive short.

Static analysis: aderyn's "large numeric literal" at line 43 is just the supply constant, 1_000_000_000 * 10 ** uint256(DECIMALS). It is not a defect.

The one known weakness is the standard ERC-20 approve race: changing a non-zero allowance to another value lets the spender use both the old and new amounts. The code's own comment documents it, and it is not specific to this token, so I did not report it.

I found no math defects in src/ShiftToken.sol. .imd-findings.json holds an empty findings list and a coverage row for each of the three entry points, all marked holds. I changed no files; the project's 38 tests pass.

What I checked under the Math Precision, Boundary and Numerical Gap guides:

• Supply: 1_000_000_000 * 10 ** 18 comes out to exactly 1e27, which fits easily in a uint256. Aderyn's "large numeric literal" warning at line 43 is a style note, not a calculation error. The whole supply is minted once in the constructor, and there is no way to mint or burn afterwards, so all balances always add up to 1e27.
• transfer / transferFrom: the balance subtraction skips Solidity's overflow checks, but it only runs after the code checks that the sender holds at least the amount. The addition also skips them and still can't overflow, because no balance can exceed 1e27. These cases all behave correctly:
  • a transfer to yourself writes back the original balance;
  • a transfer of 0 works;
  • moving an entire balance works.
• Allowances: the allowance subtraction also skips the overflow checks, but only after checking the allowance is large enough. A maximum (type(uint256).max) allowance is never reduced. Spending exactly the allowance leaves 0, and spending 1 more than the allowance reverts.
• approve: it just stores the amount, so there is no arithmetic to go wrong. It rejects the zero address as spender.
• Rounding and precision: there is no division, fee, percentage or cast anywhere in the contract, so those failure modes from the guides don't apply.

One quirk I left out of the report because it does no harm: transferFrom(address(0), to, 0) succeeds and emits a Transfer event from the zero address for 0 tokens. That looks like a mint of nothing and moves no value.

I covered my whole assigned area and left nothing unreached.

Done. launch.json is written and is the only changed file.

What the manifest says

• Kind is custom_token. The token contract is ShiftToken, name NIGHTSHIFT, symbol SHIFT, 18 decimals.
• Constructor args are empty, matching the accepted no-argument constructor that mints the whole supply to msg.sender.
• totalSupply is the constructor's constant in minor units, 1e27.
• No application contracts exist in the accepted tree, so the contracts list is empty.
• Pool and economics are copied exactly from the launch reference: IMD pair, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object verbatim.
• Notes describe only the token's actual behavior, well under the 4000-character cap.

Checks run

• JSON parsed with only the schema's top-level keys and all strings and numbers typed as the schema expects.
• forge build succeeded.
• forge test with the verifier's fuzz seed passed all 38 tests.
• Git status shows only the new launch.json.

The review is complete. The findings file is written at the repository root, the scratch tests are removed, and no tracked file changed.

Result: one info-level finding, nothing in the economic, invariant or flow-gap area that moves or freezes value.

src/ShiftToken.sol is a 165-line fixed-supply ERC-20 with no owner, no external calls, no hooks and a pure constant totalSupply(). Most failure modes in the three assigned guides are structurally absent, and I confirmed the rest by execution rather than by reading:

• Conservation invariant holds. A stateful fuzz over transfer, approve and transferFrom, including self-transfers and unlimited allowances, kept the sum of balances equal to the supply and the zero address at zero balance. The unchecked block is guarded by the prior balance check and the supply bound, and self-transfer re-reads storage so it cannot double a balance.
• Launch flows arrive whole. Factory to distributor, distributor to claimant, factory to pool and pool to trader all move exactly the amount requested. There is no fee, burn, rebase, pause or blocklist, and every mutating function returns true, so Uniswap v4's sync/settle balance deltas are exact.
• Supply cannot grow and nothing is privileged. The compiled ABI has only the three listed state-changing entry points, no receive or fallback. A scan of the runtime bytecode found no CALL, DELEGATECALL, CALLCODE, STATICCALL, CREATE, CREATE2 or SELFDESTRUCT.
• The one defect (info). _transfer validates to but never from, so any account can call transferFrom(address(0), BOB, 0) and get a successful call that emits a mint-shaped Transfer(0x0, BOB, 0) and an Approval(0x0, caller, 0). No value moves and the supply is a constant, so only off-chain indexers that treat a zero-address sender as a mint are affected. OpenZeppelin's ERC20 rejects this sender. A fail-now/pass-when-fixed Foundry proof is attached, and the fix is one line at the top of _transfer.

Coverage: all three entry points have rows (approve and transfer hold, transferFrom carries the info finding), plus four invariant rows for conservation, non-growing supply, the constructor mint and the economic-security checklist. Nothing in the assigned area was left unreached.

I added invariant tests and more edge-case tests for NIGHTSHIFT (SHIFT). With the verifier's fuzz seed, forge build succeeds and forge test passes all 56 tests (38 existing, 18 new). I found no defects, so I didn't write .imd-findings.json.

The token in src/ShiftToken.sol is a plain fixed-supply ERC-20 with no owner and no functions for minting, pausing, blocking addresses or fees. Its name, symbol, 18 decimals and 1,000,000,000 × 10¹⁸ supply minted to the deployer all match the brief. The earlier tests already covered metadata, the main transfer and approval paths, and the absence of admin functions. What was missing was invariant tests, which the criteria require because the token keeps balances.

test/ShiftToken.invariant.t.sol (256 runs × 64 calls, set in the file itself):

• Handler: a handler contract makes random calls across five accounts, including the deployer. Each call is a transfer, a transfer to the zero address, an approval, a spend from someone else's allowance, or a spend by an outsider with no allowance.
• Amounts: they are picked to hit the edges often: zero, exactly the balance or allowance, one over it, and the largest possible value.
• Checks on every call: the handler keeps its own record of every balance and allowance and predicts whether each call should succeed. It checks the exact error when a call fails, and that a failed call changes nothing.
• Invariants after each sequence:
  • the total supply never changes;
  • the five accounts' balances always add up to the full supply;
  • nothing ever lands at the zero address, the handler or the token itself;
  • every balance and allowance matches the handler's record.
• Guard: a final check that each run actually called the token, so the suite can't pass without testing anything.

test/ShiftToken.edges.t.sol (17 tests, 4 of them fuzzed at 1,000 runs):

• Zero amounts: a transferFrom of 0 with no allowance succeeds and emits both events.
• Allowance boundaries:
  • spending exactly the allowance leaves zero, and the next wei fails;
  • an allowance of the maximum value minus one still goes down when spent;
  • an unlimited allowance emits no Approval when spent and is still limited by the owner's balance.
• Self cases:
  • an owner needs an allowance from themselves to use transferFrom on their own tokens;
  • sending from an owner back to the same owner still uses up the allowance.
• Failed calls:
  • a failed call leaves balances and allowances untouched;
  • when both the allowance and the balance are too low, the allowance error is the one reported;
  • spending from the zero address fails, and sending to it keeps the allowance.
• Calls and return values: each function returns exactly true; an unknown function or a call with no data fails.

I didn't commit anything: the two new files are untracked in test/.

Review complete. .imd-findings.json is written with one finding and a full coverage record. The scratch tests were removed, so the tree is unchanged apart from the findings file.

Outcome. The token is a plain, correct fixed-supply ERC-20. Of the four specialists, only audit_economics reported anything, and that single informational finding reproduces. Nothing else surfaced in my own pass.

Finding kept (info). _transfer in src/ShiftToken.sol:137 never validates the sender. Calling transferFrom with the zero address as sender and a zero amount succeeds and emits a mint-shaped Transfer event from the zero address. I re-ran the specialist's proof and it fails on the current code as stated. No value moves, the zero address can never hold a balance, and a nonzero amount reverts on the allowance check. Impact is limited to off-chain indexers and strict OpenZeppelin-style conformance, so severity stays informational. The one-line fix is to reject a zero sender in _transfer.

Dropped or merged. There were no duplicates to merge. The aderyn large-literal lead is the supply constant, which evaluates correctly to 1e27 and is confirmed by the existing tests.

Coverage. All three entry points are answered.

Entry point	Verdict
approve	holds
transfer	holds
transferFrom	finding 1 (info)

I also recorded three invariant rows as holding: fixed supply with no privileged surface, launch flows arriving whole, and deployability against the manifest. The existing suite passes with 56 tests. My own scratch checks confirmed self-transfer, infinite allowance passthrough, allowance decrement, zero-address rejections, the missing receive function and the constant supply. Creation and runtime bytecode are far under the protocol limits, and the manifest's empty constructor arguments match the argument-less constructor.