Implemented Proof House (PH) with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. No further minting or administrative powers.

Dependencies are vendored for offline builds. README documents deployment parameters, assumptions, and responsibilities.

Validation passed with Solidity 0.8.26:

• forge build
• forge test — 32 local tests passed using the required seed
• forge fmt --check

I found no math defects in Proof House (PH). .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all marked holds.

What's in scope: src/ProofHouse.sol has 17 lines. It sets one constant, INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18, and its constructor mints that amount once to whoever deploys it. All transfer and approval logic comes from the copy of OpenZeppelin v5.0.2 in lib/. I downloaded the five upstream files and compared hashes: they are byte-for-byte identical, so nothing was changed in the inherited code.

Checked against the three guides:

• Math Precision:
  • The supply constant is worked out once when the contract is compiled and comes to exactly 10^27. Nothing in the contract divides, rounds, converts to a smaller number type or uses a fixed-point scale.
  • The only shortcuts that skip overflow checks are in the inherited transfer and allowance code. Each one runs only after a check that the balance or allowance is large enough. When tokens are added to a recipient, the total can't overflow because all balances together always equal the fixed 10^27.
• Boundary:
  • Sending 10^27 + 1 or the largest possible number (2^256 − 1) reverts with an insufficient-balance error.
  • Zero-amount transfers and transfers to yourself leave balances unchanged.
  • An allowance of max − 1 goes down when spent. An allowance of exactly the maximum counts as unlimited and stays the same.
  • A delegated transfer for the maximum amount, made under an unlimited allowance, reverts on the balance check and leaves the allowance as it was.
  • The contract makes no external calls and has no payable functions or address special cases.
• Numerical Gap: I found no rounding or edge case that breaks an invariant. In 1,024 random runs over balance, allowance and amount values, total supply always stayed at 10^27, every balance added up, and allowances were updated exactly.
• Launch amounts: 80% of the supply (8e26) and 10% (1e26) both come out exact with no remainder.

Static-analysis leads: Aderyn flagged the large number at src/ProofHouse.sol:10. That is a style note only; the value is correct. Slither reported nothing.

How I checked it: the existing suite passes (32 tests: unit, fuzz and invariant). I also wrote a temporary set of four boundary and fuzz tests under test/scratch/, which passed, and then deleted it. No other files in the repository were changed.

Not covered: the full factory and Uniswap launch test setup isn't in this repository, so I couldn't run the protected launch tests themselves.

Created launch.json matching ProofHouse, its constructor, exact supply, and required pool/economics values. Only the manifest is changed.

Validation passed: manifest checks, forge build, and all 32 tests with the supplied fuzz seed.

Review complete. No defects found in the assigned area, and the findings file records that with full coverage.

Outcome. The findings file at the repository root holds an empty findings list and seven coverage rows, one per listed entry point plus the constructor and three invariants. Every row is holds. No source files were changed, and the scratch test I used was removed.

What was reviewed. The production surface is a single 17-line contract. The token inherits the vendored OpenZeppelin ERC20 and adds only a constant and a constructor that mints the full supply once to msg.sender. I read ERC20.sol and Context.sol in full and they match upstream v5.0.2 with no edits. The compiled ABI exposes only the standard ERC-20 functions plus a view for the supply constant.

Access Control guide. There is no role, modifier, owner, initializer, proxy, delegatecall, or callback in the token. The three state-changing entry points each act only on msg.sender's balance or allowance. The factory, as deployer, holds no privilege after the constructor returns and has no allowance over any holder.

Asymmetry and Trust Gap guides. No paired function or branch treats any caller class differently. There is no fee, burn, tax, exemption list, or admin variant, so the launch flows (factory to distributor, distributor to claimant, pool seed, swaps both ways) move exact amounts for every actor. With no privileged actor and no economic formula, no seam between access, economics and asymmetry exists.

Evidence gathered.

• The existing suite passes: 32 tests including fuzz and invariant runs.
• A scratch Foundry test tried 24 privileged-looking selectors from a stranger and from the deployer. All reverted with supply and holder balance unchanged.
• The same test confirmed ETH sends and unknown calldata revert, and a reachable-opcode scan of the runtime found no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• A fuzz probe confirmed transfer and transferFrom move identical amounts and that unapproved spenders cannot pull funds.

Static analysis leads. Slither reported nothing. Aderyn's low note on the large numeric literal at line 10 is the intentional supply constant, written with underscore separators, and is not a defect.

Not covered. No launch manifest exists yet, which is expected at this stage. The token has no constructor arguments, so its manifest entry will need an empty constructorArgs list and totalSupply of 1000000000000000000000000000.

The review is complete. The findings file is written and valid, and the working tree shows no tracked changes.

Outcome: no defects found. The findings list is empty and all three entry points plus six invariant rows are recorded as holds in .imd-findings.json.

What was checked

• Execution trace. ProofHouse adds nothing to OpenZeppelin ERC20 except a constructor that mints the constant supply to msg.sender. I traced approve, transfer and transferFrom through _approve, _spendAllowance, _transfer and _update: zero-address reverts, exact-amount delivery, allowance spent before the balance move, max allowance left untouched, and full state rollback on every revert path. A scratch test confirmed residual-allowance behaviour at the uint256 max boundary.
• Periphery. The five vendored OpenZeppelin files were fetched from the upstream v5.0.2 tag and compared byte for byte. All are identical, and Context._msgSender is plain msg.sender, so no meta-transaction or forwarder path exists.
• First principles. The supply constant equals exactly 10^27 base units. A CREATE2 deployment from a probe contract gives the probe the whole supply and the calling EOA nothing, which matches the launch floor's requirement that the factory receives everything. The compiled ABI exposes only ERC-20 functions and the public constant. 22 mint, pause, freeze, burnFrom, seize and ownership selectors revert from both deployer and stranger. The contract has no receive or fallback, rejects ETH, and an opcode walk of the runtime found no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Static analysis lead. The aderyn large-numeric-literal note on line 10 is style only. The literal is a compile-time constant with the right value.

Not reachable locally. The protected floor's Uniswap v4 seed and swap test depends on floor contracts that are not in this tree. Because the token has no transfer override, every launch flow moves exactly the stated amount, but the actual pool initialization was not executed here.

The project's own 32 tests and format check pass. The scratch test under test/scratch/ is review scaffolding and is not part of the submission.

The review is complete. No defects were found, and the findings file records that with full coverage.

Outcome. .imd-findings.json holds an empty findings list and eight coverage rows: all three listed entry points hold, plus five invariant and economics rows that also hold. No file in the tree was changed. The scratch test lives in the ignored test/scratch directory.

What was checked, against the Economic Security, Invariant and Flow Gap guides:

• Source and dependencies. The token is a 17-line contract that inherits OpenZeppelin ERC-20 and mints the supply once in the constructor. The five vendored OpenZeppelin files hash-match upstream v5.0.2 byte for byte, so the library behaviour is the audited upstream behaviour.
• Entry points. The compiled ABI is exactly the ERC-20 surface plus the supply constant getter. No mint, burn, pause, blacklist, owner, receive or fallback exists. Twenty-two common admin selectors revert when called from both the factory and a stranger, and the factory cannot pull a holder's tokens without approval.
• Invariants. Sum of balances equals total supply equals the manifest supply at all times. The only mint is in the constructor and nothing can call the internal mint or burn afterwards. The existing fuzz and invariant suites pass with zero reverts, and my own fuzz over transfer, approve and transferFrom agrees.
• Launch flows. Deployed through CREATE2 from a factory stub, the whole supply lands at the factory and nothing at the caller. Swarm share, pool share and remainder move exactly, claims arrive whole, and a trader can move tokens to and from the pool manager with no shortfall. There is no tax or exemption logic, so there is no exemption list to get wrong.
• Economics of the opening. The supply of one billion tokens against a 4500 IMD opening cap gives a price, tick and liquidity well inside Uniswap v4's representable range. That derivation is the deployer's job and is noted as such.
• Bytecode floor. A reachable-opcode walk of the runtime, the same walk the protected floor uses, finds no DELEGATECALL, CALLCODE, SELFDESTRUCT, CREATE or CALL. Runtime is well under the EIP-170 limit.
• Static analysis leads. Slither reported nothing. Aderyn's large-literal note points at the compile-time supply constant, which evaluates to the manifest value and is not a defect.

Not covered. The README's claim that the launch chain is Ethereum chain 1 and that IMD lives at the quoted address was not verified against any network. Those are documentation and manifest matters outside the token code and this area.

Added 13 adversarial unit/fuzz tests and expanded invariants to cover failed calls, approval revocation, balance conservation, and continued transferability.

Offline forge build and forge test passed with the required seed: 45 tests, including 24,576 invariant calls.

Only test/ changed. No implementation defects reproduced.

The review is complete. The Proof House token has no defects, and the findings file records a clean result with full coverage.

What the code is. src/ProofHouse.sol is a 17-line contract that inherits OpenZeppelin's ERC20 and mints one billion tokens with 18 decimals to the deployer in its constructor. It adds no other functions. The compiled ABI exposes only the standard ERC-20 methods plus the supply constant.

What I checked.

• All four specialists and the independent tester reported no findings, so nothing needed reproducing or merging.
• I traced the three state-changing entry points against the inherited code and ran a scratch test covering the zero-address, insufficient-balance, insufficient-allowance, unlimited-allowance and self-transfer paths. All behaved as the standard requires. The project's own 45 tests, including the 24,576-call invariant suite, also pass.
• I downloaded the OpenZeppelin v5.0.2 release archive and compared the five vendored files byte for byte. They are identical to upstream, so no hidden behavior was introduced through the library.
• The manifest matches the contract: an empty constructor argument list for the no-parameter constructor, a total supply equal to what the constructor mints, 18 decimals, and a valid contract identifier.
• The one static-analysis lead, a large numeric literal on line 10, is a style note on an expression that evaluates correctly. I dropped it.

Output. .imd-findings.json holds an empty findings list and seven coverage rows, all marked holds, covering the three entry points plus the constructor, dependency integrity, manifest, and specialist input. The scratch test was removed and the tree is unchanged apart from the findings file.