Implemented Squeekchain.sol: 1 billion SQK, 18 decimals, minted once to the deployer.

Includes vendored dependencies, deployment documentation, and success/failure, fuzz, and invariant tests.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test: 27 passed using the required seed.
• forge fmt --check passed.

I found no math defects in squeekchain (SQK). I wrote the result to .imd-findings.json with an empty findings list and a coverage row for each of the three entry points, all marked holds. No other files were changed.

The token is src/Squeekchain.sol, a thin wrapper over the standard OpenZeppelin v5.0.2 ERC20. Its constructor mints 1_000_000_000 * 10**18 (1e27) once to the deployer. The vendored ERC20 file matches its recorded hash, so the library has not been altered.

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

• Precision: there is no division, fee, tax or rounding anywhere, so amounts move exactly as sent.
• Unchecked arithmetic: the balance subtraction only runs after fromBalance < value reverts. The additions can't overflow because the total supply is fixed at 1e27, far below 2^256.
• Allowance boundaries: _spendAllowance reverts when the allowance is too small and doesn't decrease an allowance of type(uint256).max, which is the standard "unlimited approval" behaviour.
• Edge inputs: transfers of zero, of exactly the whole balance, of the balance plus one, and to yourself all behave correctly. Zero addresses are rejected.
• Supply: the constant is computed at compile time, decimals() returns 18, and nothing can mint or burn after deployment.
• Static analysis: the one aderyn note (a large number written out at src/Squeekchain.sol:12) is about style only and isn't a defect.

The existing tests pass: 27 of 27, including the invariant that supply, balances and allowances stay consistent.

Some of the vendored test-library (forge-std) files don't match the hashes in DEPENDENCIES.lock.json. That only affects testing, not the deployed token, so I left it out of the findings; it's worth a look by whoever maintains the dependency list.

I found no defects in Squeekchain in my area (the Execution Trace, Periphery and First Principles guides). .imd-findings.json holds an empty findings list and a coverage record with a row for each of the 3 entry points, all marked holds, plus 3 invariant rows.

What the code is: src/Squeekchain.sol is 17 lines. It inherits the standard OpenZeppelin v5.0.2 ERC20 without changing it, and its constructor calls _mint(msg.sender, 1_000_000_000 * 10**18) once. It has no other functions, no owner, no fee and no hooks.

What I checked:

• Shared library code (Periphery): I downloaded the five vendored OpenZeppelin files from the upstream commit, and their SHA-256 hashes match the files in lib/ exactly. So the code everything relies on is unchanged upstream code, not just consistent with the repo's own lock file.
• approve, transfer, transferFrom (Execution Trace):
  • Mismatched inputs: none of the three functions has two inputs that could be made to disagree in a harmful way.
  • Special values: an allowance of the maximum uint256 only skips the allowance decrease; it skips no other check.
  • Zero address: transferFrom(address(0), x, 0) reverts with ERC20InvalidSender, so it can't be used to mint.
  • Failures: transferFrom spends the allowance before moving tokens, and a failure reverts everything, so nothing is left half-updated.
  • Leftover allowances and the usual race when changing an allowance with approve are standard ERC-20 behaviour and are documented in the README.
• Assumptions (First Principles):
  • The only way to mint is the constructor, because runtime calls can't reach the mint or burn path. The supply therefore stays at exactly 10^27.
  • Transfers have no fee or callback, so the factory → distributor → claimant and pool manager transfers arrive whole.
• Runtime bytecode: I scanned the deployed code using the protected test's reachability rule. No reachable DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE.
• Tests: forge test passes all 27 tests, including 6,000 fuzz cases and 256 invariant sequences with zero reverts.

What I didn't do:

• I didn't run the protected launch tests (Token.protected.t.sol, Owners.protected.t.sol). They need v4-core, the launch harness and environment settings that aren't in this repo.
• I didn't check the economics the README describes (10% swarm, 40% pool, 50% requester) against the job. They come from the job and aren't in the token code.
• The static-analysis lead (a "large numeric literal" at line 12) is just the supply constant, so it isn't a defect.

The only file I created in the repository is .imd-findings.json, and it is gitignored. git status shows a clean tree.

Created launch.json matching Squeekchain’s constructor, exact supply, and required pool/economics values. No application contracts are listed.

forge build succeeded; all 27 tests passed with the supplied fuzz seed. Only launch.json changed.

The review is complete. No defects were found in my area, and the findings file is written with an empty findings list and a full coverage record. No tracked file was changed.

What I reviewed. The token at src/Squeekchain.sol is a 17-line contract that inherits the vendored OpenZeppelin v5.0.2 ERC-20 unchanged and mints the whole supply to the constructor's caller. I checked it against the Access Control, Trust Gap and Asymmetry guides in the Pashov reference, plus the protected launch floor tests.

What held.

• Permission model. There are no roles, modifiers, owner, initializer, mint, burn, pause or blacklist. The three state-changing entry points each act only on the caller's own balance or allowance. The factory, as deployer, has no privilege over any later holder.
• Trust-gap seams. With no privileged actor and no paired pricing or fee formula, none of the four seams in the guide has anything to attach to.
• Asymmetry pairs. Approve and spend mirror each other, including the unlimited-allowance case. Transfer and transferFrom share one update path. Revert paths roll back fully, which the existing fuzz tests confirm.
• Hidden surface. The compiled ABI exposes only the standard ERC-20 functions, with no receive or fallback. The runtime bytecode has no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT. All six vendored OpenZeppelin files match their lockfile SHA-256 hashes.
• Supply. The constant evaluates to exactly 10^27 base units, minted once. The project's 27 tests pass with the README's fuzz seed, including the 256-run invariant suite with zero reverts.

Leads dismissed. The aderyn large-numeric-literal note is style only. The ERC-20 approve race is a standard property, already documented in the README, not a defect in this code.

Coverage record. The three listed entry points are marked holds, with three extra rows for the constructor's role handout, the hidden-entry-point invariant and the fixed-supply invariant. Nothing was left unreached, and no scratch test was needed since no finding carries a proof.

The review is complete with no defects found. The findings file holds an empty list and eight coverage rows, and the working tree is untouched apart from that file.

What was checked in the assigned area

• Economic Security. The token is OpenZeppelin v5.0.2 ERC20 with a single constructor mint and nothing else. There is no fee, rebase, pause, blacklist, hook, callback, fallback, or external call, so nothing can short a launch flow or strand funds. The five vendored library files are byte-identical to the upstream commit named in the lock file, which I confirmed by fetching them. The supply constant evaluates to exactly 10^27 base units, which dismisses the aderyn large-literal lead.
• Invariant. Total supply equals the sum of balances and stays at 10^27 for life. Only the constructor reaches the internal mint, and no burn or administrative selector exists. The project's own invariant suite and 24 unit tests pass locally with the documented seed.
• Flow Gap. Every flow the protected launch test exercises moves exactly the stated amount: the swarm share to the distributor, claims out of it, the single-sided seed into the PoolManager, and a trader's buy and sell. No seam between execution, periphery and intent exists because the token overrides nothing.

One lead outside the area, dismissed. The runtime is compiled for Cancun and contains PUSH0 and MCOPY, and chain 4663's block headers lack the usual post-Shanghai fields. I simulated the creation code through eth_call on chains 1, 4663 and 8453. All three returned the full runtime, and chain 4663 identifies as Arbitrum Nitro v3.12, which supports those opcodes. No finding.

Coverage. All three listed entry points hold, each with a one-line reason, plus rows for supply conservation, exact constructor mint, launch-flow exactness, dependency integrity and opcode compatibility. Slither and Mythril were not run beyond the verifier's supplied output. The standard ERC-20 approve overwrite race was checked and is a design property of the standard, already documented in the README, not a defect in this code.

I added two test files. The full suite passes: 47 tests, run with the verifier's fuzz seed (0x26fc…2da2) under forge 1.8.3, and forge build is clean. I found no defects, so I didn't write .imd-findings.json. The contract is a plain OpenZeppelin ERC20 that mints the whole 1,000,000,000 × 10¹⁸ supply to the deployer, with no admin, mint or burn functions.

The earlier contributors' 27 tests were already thorough and I left them untouched. I added to the parts they didn't reach:

test/SqueekchainAdversarialInvariant.t.sol: invariant tests where random call sequences mix successful calls with calls that must fail.

• Actors: five accounts with very uneven starting balances: almost the whole supply, 1,000 tokens, 1 wei, an empty account, and an outsider. This makes overdrafts from zero and from one wei reachable. The earlier handler only ever made calls that succeed, and every actor started with tokens.
• Failing calls: sending more than you hold, sending to the zero address, approving the zero address, spending past an allowance, and spending within an allowance but past the balance. A stranger with no allowance trying to pull funds is also included. Each must revert with the exact OpenZeppelin error and leave nothing behind.
• Invariants: every balance and allowance matches an independent model, the actors together hold the whole supply, the supply never changes, and no tokens end up at the zero address, the token itself, the handler or the test contract.
• Not vacuous: a check at the end of each run fails it if no failing call was ever made. Over 256 runs × 64 calls, each of the 9 actions ran about 1,800 times.

test/SqueekchainEdges.t.sol: 19 unit and fuzz tests for edge cases:

• No ETH: the token rejects plain ETH and ETH sent along with a transfer. Any function selector outside the ERC-20 interface (fuzzed), or an empty call, reverts.
• Bytecode scan: the deployed code has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, checked the same way the launch's protected test checks it.
• One-call launch: a helper contract deploys the token and distributes it in a single call, as a factory would; handing out one wei more than the supply reverts the whole deployment.
• Allowance edges: only exactly type(uint256).max counts as infinite (one below it is spent down normally); an allowance equal to the supply drops to zero once spent; an allowance can't overdraw after the balance is gone; allowances are separate for each owner–spender pair; approving doesn't require holding a balance.
• Fuzzed: a stranger can't pull without an allowance, two-step transfers conserve the supply, and spending any amount within an allowance leaves the right remainder.

I haven't committed the two new files; they're untracked in test/.

I found no defects in this audit, and .imd-findings.json holds an empty findings list plus a coverage record.

What I checked

• The contract: src/Squeekchain.sol is a plain OpenZeppelin v5.0.0 ERC20 with nothing overridden. Its constructor takes no arguments and mints 1_000_000_000 * 10 ** 18 once to msg.sender, which is the factory. It has no owner, no mint or burn callable from outside, no fees and no pause. Nothing can increase the supply after launch.
• The OpenZeppelin library: I read its transfer, transferFrom, approve, _spendAllowance and _update, and they behave as standard. Every launch transfer (factory to distributor, the pool seed, swaps) moves exactly the amount it says. The library has no delegatecall or selfdestruct.
• The manifest: launch.json matches the code. constructorArgs is empty, matching the constructor; the name, symbol and 18 decimals match; totalSupply is 1000000000000000000000000000. The contract name is under 32 characters and addresses are lowercase.
• Deployability: the contract is 1,752 bytes deployed and 2,639 bytes at creation, far below the 24,576 and 49,152 limits. It needs no particular address bits, so the factory can deploy it.
• Tests: all 47 project tests pass, including the invariant suites.

The other inputs

• Specialists: none of the four specialists or the tester reported anything, so there was nothing to reproduce or merge.
• Static analysis: Slither reported nothing. Aderyn flagged the large number at line 12, but that is the intended supply constant, not a defect.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds. I added two more rows for the fixed-supply rule and for the manifest matching the code.

I changed no repository files.