Committed. All 48 project files are in the commit, the working tree is clean, and nothing further depends on another step.

Recap

Delivered a Foundry project for the IPO token, committed as 0d425d9 on main.

• Token at src/AIPepeArmyBillionDollarStartup0Staff.sol. It extends the vendored OpenZeppelin ERC20 and overrides the internal update hook. Ordinary transfers credit the recipient 99% and burn 1%, rounded down. The whole 1e27 minor-unit supply mints once to the constructor's caller. There is no owner, mint, pause, blocklist, burnFrom or upgrade path.
• Launch exemptions follow the custom-token floor. The constructor takes the factory, the PoolManager and the launch number. A transfer skips the burn when its caller, sender or recipient is the factory, the PoolManager, or the distributor returned by the factory's distributorOf lookup at transfer time. That lookup uses a tolerant staticcall, so a factory without code just means no distributor exemption.
• Tests: 35 pass under an empty environment, including a value-conservation fuzz that also held at 2000 runs. They cover metadata and supply, the burn math and rounding, allowance semantics, every exemption path, a late-set distributor, another launch's distributor not being exempt, overdraft and zero-address failures, absence of admin selectors, and a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT.
• One defect found and fixed during testing. An overdraft reverted with the burn leg's numbers rather than the gross amount. The token now checks the gross balance first and reports the caller's figures.
• Config: solc pinned at 0.8.26, bytecode_hash set to none, ffi off, no filesystem permissions. The compiled bytecode tail confirms no metadata hash is emitted.
• Dependencies are vendored as plain files with licences: forge-std v1.11.0 and a five-file OpenZeppelin v5.4.0 subset. No submodules exist.
• Docs in README.md cover behaviour, manifest constructor args order, assumptions, operational responsibilities, the security checklist walkthrough, and open items.

Not run: Slither and Mythril were unavailable here. The protected floor test needs the verifier's v4-core harness, so this repo tests the same flows with address-level stand-ins. Explorer verification and the manifest belong to later steps.

launch.json is written and is the only changed file. Build and all 35 existing tests pass. One blocker remains that I could not resolve within scope.

Blocker: the contract name is too long for the schema. The accepted contract in src/AIPepeArmyBillionDollarStartup0Staff.sol is named with 36 characters. The LaunchManifest schema's token.contract pattern allows at most 32. I kept the exact name because the deployer resolves creation code by it, and a shortened name would describe nothing in the accepted tree. Every other schema rule and refinement validates. Fixing this requires either a schema allowance or an accepted rename of the contract in src, both outside this assignment. The notes field records the conflict.

What the manifest says

• Token uses the exact name, symbol IPO, 18 decimals, constructorArgs $factory, $poolManager, $launchNumber in declaration order, matching the constructor signature. totalSupply is the constructor's single mint to msg.sender, in minor units.
• Contracts is empty. The accepted tree holds only the token, a dev deploy script, mocks and tests.
• Pool pairs with the job's pair token at the 0.3% tier with tick spacing 60. initialPrice is the sqrtPriceX96 of the cap divided by supply with the token as currency0. The notes give the inverse for the other sort order and state the deployer derives the real price from economics.
• Economics is the job's object copied verbatim.
• Notes describe the 1% burn, the factory, PoolManager and distributor exemptions, the absence of any privileged surface, and the name-length conflict.

Checks run

python jsonschema validation: 1 error (token.contract pattern), all other fields and refinements pass
forge build: Compiler run successful
forge test: 35 passed, 0 failed
git status: only launch.json added

I did not commit, since nothing asked for a commit and no dependencies were installed.

The math review is complete and .imd-findings.json is written. The tree is otherwise unchanged.

Result: no defects in the assigned area. The 1% burn arithmetic is sound across the whole input domain. Two info-level notes are recorded, each with an exact triggering input.

What I verified, by tracing and with a scratch Foundry suite that I ran and then deleted:

• Overflow intermediates. The gross balance check runs before the fee multiply, so the multiplied value is bounded by the 1e27 supply and cannot overflow. A whole-supply ordinary transfer works.
• Underflow and conservation. The recipient's share cannot underflow, and the sum of balances equals total supply after any mix of ordinary and exempt transfers. Fuzzed over the full supply range.
• Edges. Zero-value transfer and transferFrom, self-transfer of a whole balance, self-transfer overdraft, infinite allowance, and the 99/100/199/200 thresholds all behave as the README states.
• External boundary. The factory read tolerates no code, a revert, and short return data. Longer return data decodes the first word correctly.
• Launch flows. Factory, PoolManager and distributor legs move exact amounts. The distributor lookup selector matches the protected harness.

The two recorded notes:

1. Fee rounds down (info). A transfer of 99 minor units burns nothing. The guides prefer fees rounding up, but the README documents the current direction as intended and the economic effect is nil.
2. Dirty return word reverts transfers (info). If the factory ever answered distributorOf with a 32-byte word carrying non-zero upper bits, every ordinary transfer would revert. A Solidity factory with an address mapping cannot produce this, so it is a hardening note only.

The coverage record answers all three listed entry points as holds, plus five invariant and boundary rows. Build and all 35 existing tests pass. The aderyn large-literal lead is style only. The constant equals 1e27 as specified.

launch.json is written, but it will not validate, and no manifest written within this assignment can: the accepted token contract's name is too long for the manifest.

The blocker. token.contract must be 32 characters or fewer (the validator's rule is ^[A-Za-z_][A-Za-z0-9_]{0,31}$, "a contract name fitting bytes32"). The only token contract in the accepted tree is AIPepeArmyBillionDollarStartup0Staff in src/AIPepeArmyBillionDollarStartup0Staff.sol, which is 36 characters. This is the same fault that rejected the previous attempt, and it sits in the source, which I am not allowed to change.

What I left in place. launch.json names the real 36-character contract, so it describes the tree truthfully and fails validation on that one field only. I did not invent a shorter name: no such contract exists in the tree, so the manifest would name something that isn't there. The blocker is also stated at the top of the manifest's notes.

What unblocks it. An implementation assignment needs to rename the Solidity contract to 32 characters or fewer. The on-chain name() string can stay as it is, since token.name allows 64 characters. After that, only token.contract (and the blocker sentence in notes) needs changing.

Everything else in the manifest:

• Token: symbol IPO, 18 decimals, constructorArgs ["$factory", "$poolManager", "$launchNumber"] matching the constructor's declaration order, totalSupply 1000000000000000000000000000 (what the constructor mints to msg.sender).
• Economics: copied verbatim from the job.
• Contracts: empty; the tree has no application contracts.
• Pool: paired with 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 3000 with tick spacing 60. The job did not name a tier; I chose 0.3% because wallet transfers already carry the 1% burn.
• Initial price: 125270724187523965593206900, computed for the token sorting below the pair token and an 18-decimal pair token. The notes give the value for the other ordering.

Checks run. forge build succeeds and forge test passes 35 of 35. Against the canonical schema, the only error is token.contract. I did not run the protected floor test: it imports v4-core and factory sources that are not in this tree. No file other than launch.json is changed.

Review complete. The findings file is written at the repository root with four findings and eight coverage rows, and no source files were changed. The scratch tests under test/scratch/ all pass, which confirms each reproduction.

What I found, in my area (Access Control, Trust Gap, Asymmetry):

• Medium: the 1% burn is bypassable by anyone through the PoolManager. Transfers to the PoolManager and from the PoolManager are both exempt, and Uniswap v4 lets any caller perform exactly that pair inside an unlock with sync, transfer, settle and take, without swapping. A holder relays the gross amount to any recipient for gas cost only. README lines 113 to 115 claim this is not a practical bypass, which is incorrect. The exemption is inherent to the launch floor, so the fix is disclosure and a requester decision, not an address check.
• Low: a factory answer that is not a clean address bricks ordinary transfers. No-code and reverting factories degrade gracefully, but a successful call returning a word with high bits set makes abi.decode revert at line 63. Factory and PoolManager flows keep working, so wallet transfers and claims alone fail. A masked decode closes it.
• Low: the constructor accepts a factory argument that is not the deployer. A wrong manifest value leaves the real supply holder un-exempt, so the swarm share arrives 1% short. The floor test would catch it before deployment. A one-line msg.sender check closes it.
• Info: trust assumption on the factory. The third exemption is a live read of distributorOf, so whoever controls that mapping can grant or revoke burn exemption after launch. A gas-burning factory also forces about 64 times the normal gas on ordinary transfers.

Coverage: approve holds. transfer and transferFrom carry finding 1. I also traced the mint-once supply, the absence of any privileged balance movement, value conservation in the ordinary path, exact launch flows, and the degraded-factory branches. No critical or high finding, so no proof files were attached. Static analysis leads were benign: the large literal is the correct 1e27 supply.

Review complete. Findings are in .imd-findings.json at the repository root, with one finding and eight coverage rows. No tracked files were changed.

Finding (medium): the 1% burn can be bypassed by anyone through the Uniswap v4 PoolManager. The token exempts any transfer whose sender or recipient is the PoolManager, at src/AIPepeArmyBillionDollarStartup0Staff.sol:70. Inside a v4 unlock, any caller can sync, transfer tokens in, call settle to get full credit, and then take to any recipient, with no pool or swap involved. Both legs are exempt, so holder A delivers the full amount to holder B with the supply unchanged. The same works across transactions by minting ERC-6909 claims to the recipient, who redeems them whole later. I reproduced both routes against a copy of the real v4 PoolManager in a scratch test, and both fail with the recipient receiving the whole amount instead of 99%.

Why medium, not higher: no one loses funds directly. The broken guarantee is the commissioned "1% burn on any transfer" rule and the README's claim that the PoolManager exemption is not a practical bypass. The to == PoolManager exemption is required for sells to settle, and the launch guide prescribes exempting the PoolManager as caller, so the only token-side mitigation is to burn on the PoolManager-to-recipient leg. That taxes every buy and deviates from the prescribed exemption set, so I flagged it as a design decision for the requester rather than proposing it as the fix.

What held: approve is unmodified OpenZeppelin. Burn math, overdraft ordering, self-transfer, zero-value and dust rounding behave as documented. Sum of balances equals total supply after every path. All five launch flows move exact amounts, and the distributor lookup selector matches the protected harness. There is no mint, owner, pause, blocklist, delegatecall or selfdestruct. The sub-100-unit rounding evasion is real but costs far more gas than it saves, so I recorded it as a coverage note, not a finding.

Scratch material: test/scratch/PoolManagerBypass.t.sol plus a trimmed v4-core copy with solmate's Owned.sol inlined, so the full suite builds with a plain forge test. The project's 35 tests still pass. Nothing in test/scratch/ is kept.

The work is complete and verified. Build and test both pass with 75 tests across 4 suites, and only files under test/ plus the findings record were touched.

What I added

• test/AIPepeArmyBillionDollarStartup0Staff.invariants.t.sol is the invariant suite the acceptance criteria required and the existing work lacked. A handler drives five ordinary actors plus the factory, PoolManager and distributor through 16 bounded actions: transfers, transferFrom, exempt flows in each direction, the factory forgetting and re-learning the distributor, dust and whole-balance stress, self-transfers, and three failure-path handlers that expect the exact revert. Each call asserts its own postcondition against an oracle that decides exemption independently of the token. Nine invariants then hold after every sequence: supply equals the initial mint minus the expected burns, the closed holder set sums to the supply, supply never grows, the aggregate burn is 1% rounded down per transfer, the exemption view matches the oracle, the distributor is read live from the factory, the zero address holds nothing, no holder exceeds supply, and metadata and launch parameters are fixed. It runs 256 sequences of depth 64 with fail-on-revert set by inline config.
• test/AIPepeArmyBillionDollarStartup0Staff.edges.t.sol adds 39 edge and failure tests: one wei, 99, 100 and 199 wei boundaries, the whole supply in one transfer, event counts for zero-value and dust transfers, overflow being unreachable through transfer, infinite and exact allowances with ordinary and exempt operators, the zero address as sender, exempt addresses not drainable without allowance, factories that answer with no data, short data or extra words, the maximum launch number, and fuzzed exemption and allowance accounting at 1000 runs.

Grounding

I ran the invariant suite against two deliberately broken scratch copies of the token, one rounding the burn up and one dropping the recipient-side distributor exemption. Both were caught on the first failing call, so the properties are not vacuous.

Finding reported, not tested around

The findings record holds one low and one informational entry. The low one: when the factory answers distributorOf with a successful 32-byte word that is not a clean address, the token's abi.decode reverts, so distributor() and every holder-to-holder transfer revert permanently. The contract and README promise this case degrades to "no distributor" instead. It needs a buggy or replaced factory to trigger, hence low, but the factory address is immutable and there is no recovery. The proof test fails on the current code as EvmError: Revert and includes the suggested fix. The info entry records the documented sub-100-wei zero-burn rounding so a reviewer does not rediscover it as a surprise.

The review is complete. Findings are written to .imd-findings.json with coverage for all three entry points. No tracked file changed.

What I found

• Medium, line 70. The 1% burn can be avoided by anyone who routes a transfer through the Uniswap v4 PoolManager. Transferring into the manager is exempt because the recipient is the manager, and take is exempt because the manager is the caller. Settle-then-take inside one unlock moves the full amount to any recipient with no burn and unchanged supply. This is the SETTLE plus TAKE action pair that Uniswap's own routers expose, so no custom contract is needed. The README's claim that the recipient exemption "is not a practical bypass" only considers transfers made outside an unlock. I reproduced it against a minimal flash-accounting model in test/scratch. The exemption cannot be removed without breaking the floor's sell flow, so the recommended fix is to document the limitation honestly or treat a universal burn as a redesign decision. No proof file attached, since a test cannot bind a documentation fix.
• Low, lines 62 to 63. distributor() handles a reverting or codeless factory but not a successful 32-byte answer with non-zero upper bits. ABI decoding reverts on the dirty padding and every ordinary transfer reverts, while factory and PoolManager paths keep working. Reaching it needs a factory bug or an upgrade changing the getter's return type, hence low. The attached proof fails on the current code and passes against a patched copy that range-checks the word.
• Info, line 55. The constructor mints to the deployer but takes the exempt factory as a free argument, so the two can diverge. The floor test catches this and the README acknowledges it. Hardening only.

What I checked and found sound

• Supply can never grow after construction, no privileged call moves or freezes balances, burn arithmetic cannot overflow, and the launch flows arrive whole given a factory getter with the distributorOf(uint64) selector the floor's probe also uses.
• The vendored OpenZeppelin files hash-match upstream v5.4.0. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT. It does use MCOPY, which the v4 PoolManager's transient storage already requires of the chain.
• Static analysis leads (the aderyn numeric-literal note) were cosmetic and dropped.

Not reached

The ProjectFactory, MerkleDistributor and LaunchLiquidity sources are not in the tree. The bypass was verified against a model of v4's documented sync, settle and take semantics rather than the real PoolManager, and that is recorded in the coverage.