Implemented Tithe Demo (TDEMO): 1 billion tokens, 18 decimals, minted once entirely to the deployer.

Added vendored dependencies, success/failure tests, fuzz tests, stateful invariants, and deployment documentation.

Verified with Solidity 0.8.26:

• forge build passed
• forge test: 32 passed
• forge fmt --check passed
• Clean-copy checks passed offline with an empty environment

Created launch.json matching TitheDemo’s parameterless constructor, exact supply, and required pool and economics values.

Manifest checks and forge build passed. forge test passed all 32 tests. Only launch.json is changed for submission.

The review is complete. The findings file at the repository root holds an empty findings list and seven coverage rows, and no source, test, or configuration file was changed.

Result: no defects found in the Math Precision, Boundary, or Numerical Gap areas. TDEMO at src/TitheDemo.sol is a sixteen-line wrapper over the vendored OpenZeppelin 5.0.2 ERC-20. Its only arithmetic is the supply constant, which is a compile-time expression equal to exactly 10^27. Every value-moving path is OpenZeppelin's unmodified transfer and allowance logic.

What I checked against each guide:

• Math Precision. No divisions, no fixed-point scales, no downcasts, no unchecked subtraction that is not preceded by a bound check. The supply fits comfortably under the 128-bit limits Uniswap v4 uses for amounts and liquidity.
• Boundary. The token makes no external calls, has no payable, receive or fallback function, no sentinel-address branch, and decodes no bytes. The compiled ABI exposes exactly the three state-changing functions the verifier listed. Edge inputs probed: a transfer of the maximum uint256 reverts cleanly, a transfer of exactly the holder's balance succeeds and one wei more reverts, an allowance of max minus one is consumed while max is not, a full-balance self-transfer through transferFrom leaves the balance intact, and an allowance above balance binds on balance with the allowance preserved on revert.
• Numerical Gap. The launch split of ten, eighty-eight and two percent of 10^27 produces no rounding dust and sums exactly to the supply, so the protected harness's "arrives whole" checks cannot be shorted by arithmetic. The supply and sum-of-balances invariants held across the project's invariant suite and my own round-trip fuzz.

The aderyn large-numeric-literal lead on line 11 is stylistic and carries no numerical defect. The vendored ERC-20 matches upstream 5.0.x content. Slither reported nothing.

I substantiated the coverage rows with a temporary scratch test of ten cases that all passed and then removed it, so the working tree is as it was received.

The findings file is in place at the repository root, excluded from git by the harness as intended, and nothing in the tree was changed.

Outcome: no defects found. The review covered the Execution Trace, Periphery and First Principles guides against the token, and every one of the three state-changing entry points holds.

What the token is. src/TitheDemo.sol is sixteen lines: it inherits OpenZeppelin ERC20 and mints 10^27 units to the deployer in the constructor. It has no owner, no mint or burn path after construction, no hooks, no receive or fallback, and no constructor arguments.

What I verified.

• The five vendored OpenZeppelin files hash byte-for-byte to upstream v5.0.2, and they are ordinary files with no submodule.
• Traced approve, transfer and transferFrom through the OZ internals: zero-address guards, balance and allowance checks, atomic revert with no partial allowance consumption, exact delivery with no fee or callback.
• The compiled ABI exposes exactly ten methods, the three state-changing ones plus seven views. Unknown selectors and ETH revert. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The project suite passes: 32 tests including two stateful invariants over 256 runs. My scratch probes covered the launch flow shape (10% to distributor, 88% to pool custody, 2% remainder, claim, transfer and transferFrom through a pool-manager stand-in), self-transferFrom needing allowance, reentrant receivers, the approve overwrite race, infinite-allowance persistence, and a fuzz over arbitrary recipients. All passed and the scratch directory is removed.
• Both static analysis leads were checked. Slither had none. Aderyn's large-literal note is the supply constant, which evaluates to exactly 10^27.

Trust notes, not defects. The approve overwrite race and the undecremented max allowance are standard ERC-20 semantics, and the README documents both. Transfers from an account by itself via transferFrom need an allowance, which the README also states.

Not reached. The protected harness's real Uniswap v4 seed and swap were not executed locally because v4-core is not vendored. The token has no transfer logic that could behave differently under the PoolManager, so I recorded this as a limitation in the coverage row rather than a gap in verdict.

The review is complete. No defects were found in the economics, invariants or launch flows of TitheDemo, and .imd-findings.json holds an empty findings list with nine coverage rows.

What I checked

• Source and dependencies. src/TitheDemo.sol is a 16-line wrapper over OpenZeppelin ERC20 that mints a constant to the constructor caller. I diffed all five vendored OpenZeppelin files against upstream v5.0.2 and they are byte-identical.
• Economic Security guide. The token has no external calls, oracles, callbacks, fees, rebasing or exemption lists. Transfers and approvals to the zero address revert instead of silently succeeding. The ABI exposes only approve, transfer and transferFrom as state changers, with no owner, pause, blacklist, proxy, delegatecall or selfdestruct.
• Invariant guide. Sum of balances equals total supply and the supply cannot grow after construction. Mint, burn and internal-update selectors revert from the factory, the deployer and a stranger. The existing suite's 256 invariant sequences and my own fuzz probe conserve the sum.
• Flow Gap guide. A CREATE2 factory deployment leaves the whole supply with the factory and nothing with its caller. The 10/88/2 split of the supply has no rounding residue, claims from the distributor arrive whole down to the last wei, and a trader round trip through pool custody using transfer and transferFrom is exact. The constructor takes no arguments, so a manifest with empty constructor arguments is consistent.
• Static leads. The aderyn large-literal note resolves to a compile-time constant equal to exactly 10^27. Slither reported nothing.

Verification. The project's 32 tests pass, formatting is clean, and my temporary probe of five economic tests under test/scratch passed and was removed afterwards. The working tree is unchanged apart from the findings file.

Not reached. Pool pricing, the sqrtPriceX96 derivation and the real Uniswap v4 seed are owned by the launch system and are not exercised by this repository, so they are covered only by the separate protected harness.

The findings file is in place at the repository root, excluded from git by the workspace's own exclude rule, and the tree is otherwise unchanged. The review is complete.

Result: no defects found in the assigned area. The findings list is empty and the coverage record answers all three entry points as holds, plus six invariant rows.

What the token is. TitheDemo in src/TitheDemo.sol is a 16-line contract that inherits OpenZeppelin ERC20 and mints the full supply to the constructor caller. It adds no functions, overrides, modifiers, roles, hooks or external calls.

What I verified for Access Control, Trust Gap and Asymmetry:

• The compiled ABI has exactly the nine standard ERC-20 selectors plus one constant getter. There is no receive, fallback, payable function, owner, initializer, mint, burn, pause, blacklist, proxy or delegatecall surface.
• All five vendored OpenZeppelin files are byte-identical to upstream tag v5.0.2 by SHA-256, so the inherited logic is the audited library, not a modified copy. The sender resolution is plain msg.sender with no trusted forwarder.
• Balances are written only through _update, reached by transfer (debits the caller only) and transferFrom (allowance-gated on the caller). The deployer or factory cannot move a holder's balance without approval. I confirmed this with scratch tests.
• Allowances are written by approve (caller's own row only) and _spendAllowance (decrease only, caller as spender). The pair is symmetric in validation and slot. No weaker writer exists.
• Supply is minted once to the constructor caller, which is the factory under the launch's CREATE2 path. Nothing can grow it afterwards. Launch flows to the distributor, pool and remainder move exact amounts because there is no fee or exemption logic at all.

Why the one reproducible behavior is not reported. The ERC-20 approve front-running window is real and I reproduced it: a holder lowering an allowance from 10 to 5 can have 15 spent if the spender's transaction lands first. It is a property of the required ERC-20 interface, involves no privileged actor, and the README already documents the zero-then-set mitigation. It is recorded as a holds coverage row with the reproduction, not as a code defect.

Tooling run. The build, the 32 existing unit, fuzz and invariant tests, and my scratch probes all passed. Slither and aderyn output supplied with the task contained nothing above a cosmetic literal-formatting note, which matched my reading. The scratch tests were removed after use.

Added 18 tests and strengthened four invariants covering failure paths, exact balances, and allowances.

forge build and forge test pass: 10,000 fuzz cases and 32,768 stateful calls. Only test/ changed. No implementation defects found.

Protected launch integration requires platform contracts and inputs absent locally.

The review is complete and the findings file is written with no defects.

Outcome. The token at src/TitheDemo.sol is a 16-line wrapper over the vendored OpenZeppelin 5.0.2 ERC20 that mints 10^27 units to msg.sender in the constructor and adds nothing else. All four specialists and the test writer reported no findings, and my own pass confirmed that. The findings file holds an empty list and seven coverage rows, one for each of the three listed entry points plus four invariants I checked.

What I verified.

• Each entry point traces to unmodified OpenZeppelin code: approve replaces the allowance, transfer moves the exact amount or reverts, transferFrom spends allowance before moving. A scratch test deployed the token via CREATE2 from a factory contract and confirmed the 10% distributor flow arrives whole, allowance decrements correctly, and the deployer cannot move a holder's balance without allowance.
• The five vendored OpenZeppelin files hash identically to the upstream v5.0.2 raw files. There are no git submodules. The build and all 50 project tests pass with solc 0.8.26 and no network.
• The compiled runtime is 1,752 bytes, contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or CALL-family opcodes, and exposes no payable or admin function.
• The manifest uses only schema keys, names the contract by its Solidity identifier, has empty constructor arguments matching the parameterless constructor, and states the supply and decimals exactly as the constructor mints them.

Leads dropped. The aderyn low-severity note about a large numeric literal is a style remark on the supply constant, whose value is correct, so it is not a defect. The scratch test directory was removed and the working tree is unchanged apart from the findings file.