Implemented Bankers (BANKERS): 1,000,000,000 tokens with 18 decimals, minted once to the deployer. Dependencies are vendored, and deployment parameters and operational responsibilities are documented in README.md.

Verified with Solidity 0.8.26:

• forge build — passed
• forge test — 39 passed
• forge fmt --check — passed

A clean copy also passed offline with an empty environment. No deployment was performed.

Created launch.json with Bankers’ exact supply, empty constructor arguments, and the required pool and economics values.

Manifest checks passed. forge build succeeded offline; forge test passed all 39 tests. Only launch.json is changed for submission.

The review is complete and .imd-findings.json holds the result. No math defects were found in the Bankers token.

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

• Supply constant. The literal on line 10 of src/Bankers.sol evaluates to exactly 1e27, which is the manifest supply. The aderyn large-literal lead is correct code, not a defect.
• Arithmetic paths. The token adds nothing to OpenZeppelin v5.0.2. Every unchecked add or subtract in the inherited _update and _spendAllowance sits behind an explicit guard, and every balance is bounded by the fixed supply. I probed 0, 1 wei, exact balance, balance plus one, whole supply, max uint, max minus one allowance, and self transfers in a scratch test. All nine probes passed, and I then removed the scratch file.
• Launch split. Ten, eighty-eight and two percent of 1e27 divide with no remainder and sum back to the supply exactly.
• Pool limits. The supply is far below the int128 and uint128 limits Uniswap v4 uses, so no downcast saturates during the seed or a swap.
• Boundaries. There are no external calls, no payable paths, no bytes decoding and no fee or rounding branch. The only sentinel branches are the zero-address reverts and the unlimited-allowance skip, both traced.
• Vendored code. All six OpenZeppelin files match their recorded hashes and the pinned upstream commit.

One info-level finding. Six forge-std files under lib/ differ from the hashes in dependencies.lock.json. The diff against upstream is only forge fmt line-wrapping in test-only files, so there is no effect on the deployed token. I reported it because the lock file claims the files are unmodified, and a verifier re-hashing the tree will flag it.

Coverage. All three entry points are recorded as holds, plus six invariant rows covering the constructor, launch split, pool limits, balance conservation, boundary surface and metadata. Nothing in my area was left unreached.

The review is complete. No defects were found in the Bankers token, and the findings file holds an empty findings list with nine coverage rows.

What was reviewed. The token at src/Bankers.sol is OpenZeppelin 5.0.2 ERC-20 plus a constructor that mints the full supply to the deployer. I verified the vendored OpenZeppelin files against the lock file hashes, then checked the three entry points against the Senior Auditor's Mindset and the Economic Security, Invariant and Flow Gap guides.

Results by area.

• Economic security. No external dependencies, oracles, fee formulas or price logic exist. The zero address is rejected as sender, recipient and spender. Native ETH to the contract reverts.
• Invariants. Total supply is fixed at 1e27. The only mint is in the constructor, and no public path reaches a burn. Sum of balances equals supply across the project's invariant suite and a wider scratch fuzz that included the token address and a code-bearing recipient.
• Flow gaps. The 10%/88%/2% split, distributor claims, pool-manager settlement by direct transfer and router-style transferFrom all deliver exact amounts, down to 1 wei and full balances. A trader can buy and sell back to zero.

Checks run. The project suite passed with 39 tests, including the 128-run invariant campaign. A scratch suite of five additional tests passed and was removed afterwards. The aderyn large-literal lead evaluates to exactly 1e27 and is a style note only.

One observation, not a finding. Six vendored forge-std files in this checkout differ from the hashes in dependencies.lock.json. The lock matches upstream v1.9.6, so the difference is in this working copy, affects tests only, and does not touch deployable bytecode.

Trust assumptions. The approve replace-allowance race is inherent to ERC-20 and documented in the README. There is no owner, pause, or admin power to document.

The review is complete. The Bankers token has no defects in the Execution Trace, Periphery or First Principles areas, and the findings file records a clean result with full coverage.

What the token is. A single contract that inherits the vendored OpenZeppelin v5.0.2 ERC20 and adds only a constant supply and a constructor mint to msg.sender. It has no owner, minter, hooks, fees, exemptions, receive or fallback.

What I verified.

• All three listed entry points were traced through the OpenZeppelin internals. Allowance is spent before the balance move, so a reverting transferFrom leaves allowance untouched. Zero sender, zero recipient and zero spender are rejected. The unlimited allowance is never decremented.
• The constructor mints exactly 10^27 base units to the direct deployer, which is the factory under CREATE2, and not to the transaction origin.
• The compiled ABI contains only the standard ERC-20 surface plus the supply constant. The deployed bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE, CALL or ORIGIN opcodes.
• The five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag and to the lock file. Six vendored forge-std files have lock-hash mismatches, but they are identical to the pinned v1.9.6 commit apart from formatter whitespace, and forge-std is test-only code.
• The full project suite passed, including the invariant suite, with 39 tests and no failures.

What I could not reach. The protected launch test depends on v4-core and launch library sources that this tree does not vendor, so it could not be executed here. It is marked unreached in the coverage record. The project's own tests cover the token-side equivalent of that flow.

Leads from static analysis. The aderyn large-literal note points at the supply constant. Its value evaluates to 10^27 as the brief requires, so it is a style note and not a defect.

The findings file holds zero findings and ten coverage rows, one for each entry point plus invariant and periphery rows. No repository files were changed.

Review complete. The findings file is written and the tree is otherwise untouched.

Result: the Bankers token holds across the Access Control, Trust Gap and Asymmetry guides. It is the unmodified OpenZeppelin v5.0.2 ERC20 with a single constructor mint of exactly 10^27 base units to msg.sender. One low-severity provenance defect was found outside the token itself.

What I verified

• The compiled ABI exposes exactly three state-changing functions, approve, transfer and transferFrom. There is no owner, initializer, pause, blacklist, mint, burn, permit, receive or fallback, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Each entry point acts only on the caller's own balance or allowance. The deployer or factory keeps no power after construction and needs an allowance like anyone else. A scratch fuzz test confirmed transfer and transferFrom move identical amounts under identical checks.
• All five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 commit, and their lock-file hashes are correct.
• The existing 39 tests pass, including the launch-flow settlement test and the 128-run invariant suite. The static analysis lead about the large numeric literal is correct arithmetic, not a defect.

Finding reported (low): six vendored forge-std files were reformatted, so the SHA-256 hashes recorded in the lock file do not match the files in the tree. The differences are whitespace-only against upstream, so the test harness behaves correctly, but the README's claims that the files are unmodified and that the lock records exact hashes are false for them. The reproduction and fix are in the findings file.

Coverage: all three verifier-listed entry points are marked holds, plus rows for the constructor mint, the no-privileged-entry-point invariant, supply conservation, the factory-holds-supply trust assumption, and dependency integrity, which carries the finding. No proof test was needed since nothing reached high or critical.

Added 15 boundary, failure-path, and fuzz tests; strengthened four stateful invariants with independent balance and allowance tracking.

forge build and forge test passed offline: 54 tests, including 32,768 invariant handler calls. No confirmed defects found. Changes are confined to test/.

The review is complete and .imd-findings.json holds the result. Nothing in the tracked tree was changed. The findings file is ignored by git, so the working tree stays clean.

Outcome: one low finding kept, everything else holds.

• Kept, merged, reproduced: both audit_permissions and audit_math reported the same root cause, so they are one finding at low. Six vendored forge-std files hash differently from what dependencies.lock.json records. I recomputed every hash in the lock, fetched the six upstream files at the pinned commit, and confirmed the lock values are the upstream hashes while the vendored copies differ only by line re-wrapping. The OpenZeppelin ERC20 the token inherits is byte-identical to upstream, so the deployed code is unaffected. This is a provenance defect in test-only material, which is why it stays low rather than info.
• Dropped: nothing else was reported by the specialists. The aderyn large-literal lead is the supply constant, which equals the manifest's total supply exactly, so it is not a defect.

My own pass found no defects. The token is a bare OpenZeppelin v5.0.2 ERC20 with a constant supply minted to the deployer. All three entry points trace cleanly through the standard checks and revert paths. The compiled ABI exposes no mint, burn, owner, pause or blacklist. Creation and runtime bytecode are well under the size limits, and a PUSH-aware scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT. The manifest uses only schema keys, with no constructor arguments matching the no-argument constructor, lowercase addresses, and a supply of 10^27 matching the code.

Checks run:

Check	Result
forge build, solc 0.8.26	success
forge test	54 passed, 0 failed
Lock file hashes	26 of 32 match

The protected launch test could not be run here because it imports v4-core and launch libraries this repository does not vendor. I verified each of its assertions by tracing instead: exact-amount transfers for the factory, distributor and pool-manager flows, no supply growth, no privileged freeze or seizure, and clean opcodes.

The coverage record answers all three listed entry points as holds, plus three invariant rows for the constructor and supply, deployability and manifest, and the project test suites.