Taylor, the HI token is built, tested, documented, and committed on main as a442a04.

What was delivered

• src/HIToken.sol: OpenZeppelin ERC20, 1,000,000,000 HI with 18 decimals, minted once to the deployer in the constructor. No owner, mint, pause, blocklist, or upgrade path.
• Transfer rule: 1% of every ordinary transfer is burned, so the recipient receives 99%. The factory, the Uniswap v4 PoolManager, and the launch's MerkleDistributor are exempt in both directions. The distributor is read live from the factory at transfer time, so the swarm share, claims, seed, and both swap directions move whole.
• script/DeployHI.s.sol: local deploy script whose config function the tests call directly. The real launch deploys through the factory.
• Tests: 29 passing across unit, fuzz with value conservation, failure paths, a sweep of admin selectors from a stranger and from the factory, and an opcode scan for DELEGATECALL, CALLCODE, and SELFDESTRUCT. A scratch rehearsal deploying via CREATE2 from a probe etched at the factory address also passed.
• Dependencies vendored as plain files under lib/ with no submodules. A clean build and the full suite passed with the network off.
• README.md documents assumptions, constructor arguments, trust on the factory, operational responsibilities, and which security tools ran.

Checks

Assumptions to confirm

• The brief's "1%" is read as a 1% fee burned on peer-to-peer transfers. No fee recipient was named, so burning avoided adding a privileged address. If a treasury was intended, the fee destination is one line in the contract's update hook.
• Pool trades clear through the exempt PoolManager and are not taxed. The 1% applies to direct wallet-to-wallet movement.
• Slither and Mythril were not available and did not run. Explorer verification after deployment is an open item for the network deployer.

Created launch.json matching HIToken’s constructor, supply, and required economics. Only this file changed.

Manifest constraints and constructor ABI checks passed. forge build succeeded; forge test passed all 29 tests.

The review is complete. The findings file is in place and valid, the scratch tests are removed, and the tree is clean apart from the harness-excluded output file.

Result: no critical, high, medium or low defects in the token's math. The 1% burn in src/HIToken.sol is arithmetically sound under every Math Precision, Boundary and Numerical Gap check I could reach, and the existing suite plus my own probes confirm it.

What I verified

• Overflow is unreachable through transfers. The insufficient-balance pre-check runs before the fee multiply, so the largest reachable operand is the whole supply, far below the overflow threshold. The public helper reverts on absurd input but is view-only.
• Conservation holds exactly. Sender loses the full amount, recipient gains amount minus burn, supply drops by the burn. A multi-holder fuzz over random transfers never drifted.
• Recipient always receives between 99% and 100% of the amount. Zero-amount and exact-balance transfers behave.
• Launch flows are exempt as the floor requires. Factory and PoolManager checks short-circuit before the external call, the recorded distributor is exempt both ways, a zero or foreign-launch distributor exempts nothing.
• Allowance accounting spends the full pre-fee amount, consistent with the sender paying the full amount.

Two info-level items recorded, each with a concrete input

1. The fee rounds down, so transfers under 100 minor units burn nothing and ten transfers of 99 wei deliver 990 with zero burn. The README documents this as intended, and the gas cost makes it economically meaningless at 18 decimals. The guide prefers fees that round up, so I noted the one-line change and its tradeoff.
2. Every ordinary transfer depends on the factory answering the distributor lookup. A factory that reverts or returns malformed data blocks wallet-to-wallet transfers while exempt flows still work. This is what the launch specification requires and the README states it as a trust assumption. I reproduced both failure shapes.

Coverage. All three entry points are marked holds, with additional rows for the overflow boundary, conservation, recipient-share bounds, exempt-flow exactness, the factory-call boundary, the "1%" interpretation, and the aderyn literal lead. No proof files were needed since nothing reached high severity.

One point for the requester outside the math: the brief's "Transfer rules: 1%" was read as a burn with no treasury. If a fee recipient or a per-transfer cap was intended, that is a scope decision rather than a defect.

The review is complete. The findings file is written, the scratch test is removed, and no tracked file changed.

Outcome. The permission model of src/HIToken.sol is small and mostly sound: no owner, no roles, no initializer, no supply growth path, and the factory-as-caller exemption cannot skip the allowance check. I report one medium defect, one low, and two informational trust notes, all reproduced locally with a scratch Foundry test before being written up.

• Medium, fee bypass through the PoolManager rail. Both to == poolManager and from == poolManager are exempt, and the v4 PoolManager is permissionless. Any holder can transfer in, call settle, then take to any recipient, or mint ERC-6909 claims, moving HI peer-to-peer with zero burn. The README's claim that transfers through other contracts are taxed is false for this one. The exemption is required by the launch floor, so the fix is a disclosure or a design decision, not a one-line patch.
• Low, constructor does not bind the factory role to the minter. A wrong $factory argument produces a token whose supply holder is taxed and whose distributor lookup hits the wrong contract. The floor would catch it after deployment, but the constructor could refuse it.
• Info, factory controls the exempt set post-launch. Whoever writes distributorOf for this launch number can make any address fee-free, or halt all ordinary transfers by reverting. Documented as a trust assumption, with the exemption-grant case missing from the README.
• Info, isExempt is caller-dependent. Queried by the factory it reports exempt for pairs that are taxed on an actual transfer.

Coverage. All three listed entry points have rows, plus the constructor, the burn-branch invariants, and the privileged-surface check. Every Access Control, Trust Gap and Asymmetry item in the Pashov guide was checked against this code. Nothing in my area was left unreached. No critical or high finding exists, so no proof test is attached.

The review is complete and .imd-findings.json holds the result. No source files were changed; only the findings file and my scratch tests under the ignored test/scratch/ directory were written.

Outcome: no critical, high or medium defects. The token's economics hold on a correct deployment. The 1% burn conserves value (balances always sum to totalSupply), the supply can only shrink, and every launch hop (factory to distributor, distributor claims, pool seed, remainder forwarding, and v4 buy and sell through the PoolManager) moves the full amount because one side of each is an exempt address. The burn cannot be used to tax or untax anyone else's transfer, and the only bypass routes are the pool itself (intended) and sub-100-wei dust chunks (gas dwarfs the saving).

Findings reported, all substantiated with scratch tests or the project's own tests:

1. Low, permanent dependency on the factory lookup. Every non-exempt transfer makes a live staticcall to distributorOf(uint64) on an immutable factory. A codeless factory, a reverting one, or one whose function takes uint256 instead of uint64 bricks all peer-to-peer transfers forever while pool and factory flows keep working. The protected floor cannot catch the selector case because its probe defines the same uint64 mapping. The real ProjectFactory ABI is not in the tree, so I listed it as needed evidence.
2. Low, constructor does not require the factory argument to equal the deployer. The supply goes to one address while a different one is exempt, so a mismatched deployment taxes the supply holder or reverts outright. Fix is a one-line check, with a small tradeoff for the review-only deploy script.
3. Info, view/write divergence. The public isExempt folds in the caller's identity, so the factory sees every pair as exempt while everyone else sees the pair-only answer for the same transfer.
4. Info, interpretation of the brief. "Transfer rules: 1%" was read as a burn. The fee is destroyed rather than paid to the requester, and with no admin the destination cannot change after deployment. Flagged for the judge to confirm the reading.

Coverage: all three entry points (approve, transfer, transferFrom) are recorded as holds, plus rows for the conservation and supply-ceiling invariants, the full launch flow, and burn-bypass economics. One row is marked unreached: confirming the deployed factory's distributorOf signature, which only the chain or the factory source can answer.

Added failure-path, boundary, fuzz, and seven-actor invariant tests.

Offline verification passed: 50 tests, including 256 invariant sequences / 16,384 calls.

Reported one low-severity defect in .imd-findings.json: burnFor(uint256.max) overflows. The report includes a reproduced failing proof; the input exceeds the entire token supply.

Nothing further is needed — the file validates, both snippets match the tree byte-for-byte, all three listed entry points have rows, and no tracked file changed. The review is complete.

Summary

Scope covered: Execution Trace, Periphery and First Principles against src/HIToken.sol, its interface, the vendored base contracts, and the deployment script. Build and all 29 existing tests pass. Findings are in .imd-findings.json (2 findings, 18 coverage rows, 100% of listed entry points answered).

Finding 1 — medium — the 1% burn is optional (src/HIToken.sol:57). isExempt exempts any transfer with the PoolManager on either end. Uniswap v4's PoolManager is a public singleton with flash accounting, so inside unlock() anyone can sync → transfer in → settle → take(to: anyone) with no pool for HI and no swap. Both legs hit the exemption, so the burn never runs. I verified this against real v4-core (commit 46c6834, built outside the repo since v4-core isn't vendored): BOB receives 1,000e18 with supply unchanged, versus 990e18 and a 10e18 burn on a direct transfer. It costs 79.4k gas versus 48.8k — about 30k gas replaces a 1% burn of any size. An ERC-6909 variant (settle + mint claims, trade claims, burn + take) yields a permanently tax-free wrapped HI. The README's claims at lines 13, 49–51 ("transfers through routers or other contracts, are taxed") are false. I was explicit that this is inherent and spec-mandated: the token can't tell settle/take from sell/buy, so narrowing the exemption breaks swaps and fails the floor. The honest fix is a requester decision — document the 1% as a default, or move the fee to a v4 hook (a design change). No proof file: no test can fail now and pass after a code fix without breaking the floor, so one would mislead.

Finding 2 — low — silent uint64 truncation (script/DeployHI.s.sol:24). HI_LAUNCH_NUMBER = 2^64+7 deploys with launchNumber == 7 instead of reverting. Review-only path, hence low; reproduced in a scratch test.

Verified clean: supply minted exactly once to the factory and can't grow; balance/supply conservation; all five launch flows (swarm share, claim, seed, buy, sell) move whole against the real PoolManager; no privileged selectors; no DELEGATECALL/CALLCODE/SELFDESTRUCT; vendored OZ v5.1.0 and forge-std v1.9.7 are byte-identical to upstream at their pinned commits. I dropped one lead after inversion (the msg.sender-dependent isExempt view is self-consistent with the asker's own transfer).

Unreached: the production ProjectFactory.distributorOf and MerkleDistributor sources aren't in the tree; the protected probe's getter matches the interface, and I recorded that as a trust assumption rather than a verified fact.

Scratch artifacts: test/scratch/ScriptTruncation.t.sol (gitignored, yours to discard) and the v4 harness at /tmp/v4repro.

Wrote .imd-findings.json with three low-severity findings, concrete reproductions, and coverage of all three entry points.

All 50 existing tests passed. Two targeted defect checks failed as expected. Full protected launch integration was unavailable locally.