The deliverable is complete and verified from a clean copy of the tree.

What was built

• src/ADVNToken.sol: AIDIVN / ADVN, 18 decimals, 1,000,000,000 tokens minted once to msg.sender (the launch factory). Constructor takes $factory, $poolManager, $launchNumber, stores them and calls nothing. No owner, mint, pause, blocklist or upgrade.
• Every taxed transfer sends 0.5% to Jensen Huang's address and burns 1%. The recipient gets 98.5%. A TradeTaxed event records each split.
• Untaxed flows are exactly the launch flows: the factory sending, the launch's MerkleDistributor sending (resolved through distributorOf at transfer time, failure-tolerant), and anything sent into the Uniswap v4 PoolManager. Tokens leaving the PoolManager are taxed, so buys from the launch pool pay the fee and burn.

Key assumption, documented in README and REVIEW

Sells into the v4 pool cannot be taxed without a hook, because v4 settlement requires the PoolManager to receive exactly the declared amount. The brief's "1% burn of supply from every fee" is read as 1% of the transferred amount, with the alternative reading noted and one constant to change.

Verification

Check	Result
forge build --offline --sizes	ADVNToken 3,179 bytes runtime
forge test --offline	43 passed (unit, fuzz, 3 invariants, 6 real-PoolManager flow tests)
Verifier fuzz seed and a second seed with 1000 runs	all pass
forge fmt --check	clean
Slither, low excluded and high-only	0 results both ways
Clean-copy rebuild of only src, test, lib and config	identical results

Libraries are vendored as plain files under lib/ with no nested .git. README covers rules, interface, manifest constructor values, assumptions, operational responsibilities and offline build steps. REVIEW lists five low or informational findings with dispositions. No launch.json was written.

Created launch.json matching the accepted constructor, supply, required economics, and pool settings.

Only the manifest changed. forge build succeeded; all 43 tests passed with the supplied fuzz seed.

The permissions review is finished with one finding: medium severity, reproduced with a Foundry test that fails on the current code. It's written to .imd-findings.json with a coverage row for each of the three entry points and three invariant rows. No project files were changed. The scratch test I wrote under test/scratch/ is deleted, and its full source is in the finding's proof field.

Finding 1 (medium): any trader with their own contract can skip the 0.5% fee and the 1% burn (src/ADVNToken.sol:77)

• How it works: the token taxes a transfer only when ADVN actually leaves the Uniswap v4 pool, and it never taxes ADVN going in (line 77). But v4 lets a swapper keep what they bought as claim tokens held inside the pool, instead of withdrawing it, and pay for a sale with those claims. Neither step moves ADVN itself, so the token's tax code never runs.
• What that allows: a trader using their own contract, such as a bot or an aggregator, can buy, hold, pass claims to other wallets and sell back without paying anything to Jensen Huang's address or burning anything. Sells are already untaxed, so a buy-and-sell round trip done this way costs nothing.
• Who still pays: only people who eventually withdraw real ADVN from the pool, which is what ordinary routers do for retail buyers.
• Reproduced: a 1 ETH buy kept as claims and then sold back left the fee recipient with 0, where a normal buy would have sent them 4907965121486501 minor units (about 0.0049 ADVN). Total supply didn't drop either. The README's list of limits doesn't mention this.
• Fix: the token can't see claim-token movements, so enforcing the fee on these trades would need a v4 hook that charges on swaps. This launch type doesn't deploy one, so that's a scope decision for the requester. The alternative is to document the bypass in the README.

Coverage:

• approve holds: it's the standard OpenZeppelin version and doesn't touch the tax or the exemptions.
• transfer and transferFrom are marked as finding 1. The tax and its exemptions (the factory sending, the distributor sending, anything sent into the pool) otherwise behave correctly.
• There's no owner and no admin function, and the supply can't grow after the constructor. The launch flows move exact amounts. A taxed transfer splits correctly into 98.5% / 0.5% / 1%, and the burn lowers the total supply.

Left out:

• I didn't report that sells are untaxed, because the README already documents it.
• Swaps through routers that withdraw to themselves before forwarding to the user would be taxed twice. That's in the economics area, not mine, so I didn't reproduce it.
• The static-analysis tool's large-number-literal note isn't a defect.

The review is complete and the findings file is written and validated.

Outcome: one substantiated finding, severity medium, with a Foundry proof that fails on the current code. The token's accounting is otherwise sound in my area.

Finding 1 (medium): the trade tax can be skipped on every Uniswap v4 trade. The tax lives only in ERC-20 _update, and anything sent to the PoolManager is exempt. Uniswap v4 lets any unlocker settle a buy as ERC-6909 claims with mint instead of take, and pay a sell by burning claims. No ERC-20 transfer from the PoolManager happens, so the 0.5% fee to Jensen Huang and the 1% burn never fire. I reproduced it against the vendored real PoolManager with the same seed as the project's own launch tests:

1 ETH buy settled as claims: gross output 981593024297300372 ADVN
expected fee to Jensen        4907965121486501   observed 0
expected supply decrease      9815930242973003   observed 0

The same trader then sold the claims back for ETH and handed claims to another wallet, both untaxed. Anyone can also wrap ERC-20 ADVN into claims untaxed, since the transfer into the PoolManager is exempt. The practical effect is that the fee stream and the burn fall only on users of plain take/transfer flows, while bots and routers using claim settlement avoid them. The README statement that buys are taxed because the PoolManager pays with a plain transfer is not a guarantee v4 gives. The token cannot fix this alone. The requester must either accept and document it, or ask for a v4 hook, which is a scope decision outside this launch kind.

What holds, with the reasoning recorded in the coverage rows:

• Sum of balances equals total supply, and supply only shrinks through burns. The sender is always debited the full amount.
• Launch flows move exactly what they say. Seed, swarm share, distributor claim and sells into the pool settle exactly.
• Pool solvency is intact. A take of X reduces the PoolManager's balance by exactly X.
• Preview matches execution. Fee and burn round down, so dust under 200 units escapes the fee, which is documented and not worth a separate finding.
• Fee recipient and rates match the brief. No owner, minter, setter or pause exists.

Files: findings and nine coverage rows are in .imd-findings.json, and the proof test is at test/scratch/ClaimBypass.t.sol. No source, test or configuration file was changed. The existing suite of 43 tests still passes.

The review is complete. The findings file is written and validated, every cited snippet matches its line in the tree, and no tracked file was changed (test/scratch/ holds my reproduction tests only).

Outcome: the control-flow area of ADVNToken holds. No critical, high or medium defect. The three entry points were traced through OpenZeppelin's _transfer/_update into the overridden tax path, and the launch flows were confirmed against a real Uniswap v4 PoolManager by the existing test suite, which passes in full.

Findings written to .imd-findings.json:

• Low. The factory lookup decodes the answer with abi.decode(data, (address)). A 32-byte word with non-zero upper bits reverts, and that revert propagates into every taxed transfer and transferFrom. The README promises the lookup never reverts a transfer. The real factory returns a clean mapping value, so this is a robustness and documentation gap, not a live loss. Reproduced in test/scratch/Leads.t.sol.
• Info. Holders can wrap ADVN into ERC-6909 claims inside the PoolManager and move claims between each other with no fee and no burn. Tax is paid only once on exit. The README says every non-launch venue is taxed both ways, which this venue is not. Reproduced against a real PoolManager.
• Info. Sells into the pool are untaxed, so roughly half of trading volume pays nothing. This is forced by v4 exact settlement and the protected floor's whole-balance sell check. The author already documents it; reported so the requester decides on it explicitly.
• Info. The brief's "1% burn of supply from every fee" is read as 1% of the transferred amount. The alternative reading differs by a factor of 200. The author flagged this too.

Coverage: all three entry points answered. approve holds. transfer and transferFrom reference finding 1. Five invariant rows hold (fixed supply, exact launch flows, empty-chain constructor, no forbidden opcodes, periphery). One row is honestly unreached: the real ProjectFactory's distributorOf behaviour, since its source is not in this tree.

The review is complete. The findings file is valid JSON, every snippet matches the tree line for line, and no source or configuration file was changed.

Outcome: the math in ADVNToken holds. I found no defect in the Math Precision, Boundary or Numerical Gap areas that loses funds or breaks a guarantee. The findings file carries one low and three informational items, each with a reproduction I ran.

What I checked in the assigned area, all against src/ADVNToken.sol:

• Overflow. The explicit balance check runs before the two basis-point multiplications, so the operand is bounded by the 1e27 supply and amount * 100 cannot overflow. A transfer of the maximum uint256 reverts with the standard insufficient-balance error, not a panic.
• Conservation. Fee plus burn plus received equals the value exactly, the sender is debited exactly the value, and the sum of balances plus burns equals the initial supply. Confirmed by a 2000-run fuzz and the project's own invariant suite.
• Edges. Zero, whole-balance, balance-plus-one, self-transfer, transfers to and from the fee recipient, and the gross-allowance semantics of transferFrom all behave as intended.
• External boundary. The factory lookup degrades to "not exempt" on no code, revert and short return.

Findings written to .imd-findings.json:

1. Low. A Uniswap v4 trade settled as ERC-6909 claims never calls the token, so a buy-then-sell entirely in claims pays no fee and burns nothing. Reproduced against a real PoolManager. This is outside the math area and cannot be fixed inside the token, so it is reported as a design limitation for the judge.
2. Info. Fee and burn round down. Transfers under 200 wei pay no fee and under 100 wei pay nothing. Not economically exploitable at 18 decimals.
3. Info. The amount-only preview function reports a tax for flows that are actually exempt.
4. Info. The distributor lookup panics on a 32-byte word that is not a clean address, which would block all taxed transfers. Unreachable with the real factory.

Coverage records all three ABI entry points as holds, plus four invariant and flow rows. The two scratch test files under test/scratch/ hold the reproductions and are not part of the submission.

Added failure-path, fuzz, swap rollback, and stateful invariant tests.

Offline build and full suite pass with the required seed: 74 passed, 0 failed. The new invariant campaign exercised 16,384 calls.

Recorded two low-severity findings with reproduced proofs in .imd-findings.json: malformed factory responses blocking transfers, and preview overflow for amounts far above supply.

The review is complete. The findings file is written and validated against the tree, with every snippet matching its cited line.

Outcome: four findings kept from the eleven specialist reports, none above medium, and the three entry points all answered.

• Medium, line 77 of src/ADVNToken.sol. The trade tax only fires on ERC-20 transfers leaving the PoolManager. A Uniswap v4 trader who settles with ERC-6909 claims (mint instead of take, burn instead of transfer in) buys, sells and moves ADVN with no fee to Jensen Huang and no burn. Sells are exempt by design and documented, but the claim bypass is not. I merged five reports from economics, permissions, math and flow into this one. Both specialist proofs fail on the code as stated, with 0 paid against an expected 4907965121486501 wei of fee on a 1 ETH buy. No proof is attached because no token-only change can fix it; the requester must choose between a v4 hook (outside this launch kind) and correcting the README and manifest notes.
• Low, line 71. If the factory ever answers distributorOf with a 32-byte word that is not a clean address, abi.decode reverts and every taxed transfer and every buy reverts with it, contrary to the README's "never reverts" promise. Three reports merged. The real factory is a mapping getter, so this is a robustness gap only. The tester's proof is attached and fails here.
• Info, line 85. previewTransfer overflows for amounts of 2^256/100 and above even though the results fit. Unreachable from any transfer. Proof attached.
• Info, line 31. The burn is 1% of the transferred amount; the brief's wording also admits 1% of the fee. Documented by the author, but the requester should confirm since the constant is immutable.

Dropped: the preview-versus-exempt-flow note (the view is documented as the taxed preview) and the dust rounding note (documented, at most 2 wei per transfer). The aderyn large-literal line is style only.

My own pass found nothing further. I checked self-transfers, fee-recipient sends, allowance accounting, zero-value and zero-receiver transfers, the distributor exemption boundaries, a factory with no code, the distributorOf(uint64) selector against the floor's probe, and contract sizes. The full project suite passes with 74 tests. Coverage rows mark approve as holds and transfer and transferFrom as finding 1, with four invariant rows all holding.

The revision is complete. All four findings are answered in .imd-responses.json, the build, tests and formatter pass, and the token's exemption rule and tax logic are unchanged.

What I reproduced

• The ERC-6909 claims bypass: a buy settled with the PoolManager's mint paid no fee and burned nothing against a real v4 PoolManager. A claim-paid sell and a claim-to-claim move were untaxed too.
• The malformed factory answer: a 32-byte word with a high bit set made every ordinary transfer revert inside the address decode.
• The preview overflow: amounts of 2^256/100 and above panicked.
• The burn-base reading: the behaviour matches the documented 1%-of-amount choice. The finding itself says this is not a code defect.

What changed

• src/ADVNToken.sol: the distributor lookup decodes the factory's answer as a word and treats anything above 160 bits as no distributor, so it can never revert a transfer. The preview divides by the exact reciprocals (200 and 100), which gives identical results everywhere the old formula was defined and is defined for every input. NatSpec now states the ERC-6909 limit.
• Tests: a MalformedAnswerFactory mock with a transfer test, two preview tests covering the full range, and four v4 flow tests with a claims-settling router that pin the documented behaviour, including that redeeming claims as ERC-20 is taxed.
• README.md and REVIEW.md: the "Limits" section now says the tax reaches only ERC-20 transfers out of the PoolManager and ordinary ERC-20 transfers, that claims-settled buys, sells, round trips and holder moves are untaxed, and that taxing all pool trades needs a v4 hook as a separate launch. The burn-base confirmation is flagged for the requester.

Verdicts filed

• Claims bypass: fixed via the finding's option (b). No token-only change can tax a path that never calls the token, and taxing transfers into the PoolManager breaks every sell against the floor.
• Malformed lookup: fixed.
• Preview overflow: fixed.
• Burn base: disputed as not a defect, with the requester confirmation made explicit in the docs.

Checks run

Check	Result
forge build --offline	clean
forge test --offline with the verifier's fuzz seed	50 passed, 0 failed
forge test --offline --fuzz-seed 0x1234 --fuzz-runs 1000	50 passed, 0 failed
forge fmt --check	clean

Slither is not installed on this machine, so it was not run for this revision. The changes touch none of the six refusal detectors. Two decisions remain the requester's and are listed in the README and REVIEW open items: whether to order a v4 hook launch so claims-settled pool trades also pay the fee and burn, and whether the burn base is 1% of the amount as built.

I updated launch.json. The only change is one sentence in notes; nothing else in the repository was touched. I left the change uncommitted.

What changed: The old notes said buys and liquidity withdrawals from the PoolManager are always taxed. That is no longer accurate: the accepted revision of src/ADVNToken.sol (finding 6 in REVIEW.md) shows that trades settled as Uniswap v4 ERC-6909 claims skip the tax. The fee and the burn only apply once those claims are turned back into ordinary tokens. The notes now say that taxing those trades would need a v4 hook, which this launch does not deploy. They are 1,344 characters, under the 4,000 limit.

Already correct and left as they were:

• Token: contract ADVNToken, name AIDIVN, symbol ADVN, 18 decimals.
• Constructor arguments: ["$factory","$poolManager","$launchNumber"], matching the constructor's (address, address, uint64) in order.
• Total supply: "1000000000000000000000000000", which is exactly what the constructor mints to the deployer (1_000_000_000 * 1e18).
• Contracts: an empty list, because the accepted tree has no application contracts.
• Pool: native ETH (the zero address), fee 12500, tick spacing 60, initial price 79228162514264337593543950336.
• Economics: copied verbatim from the job.

Checks: The file parses as JSON. forge build compiles cleanly, and forge test with the verifier's fuzz seed passed all 50 tests in 3 suites. Nothing I can run here validates the manifest against the schema, so I checked its keys and formats by reading it.

Still open for you: The review also leaves an open question about the burn. It is built as 1% of the amount transferred; your wording could also mean 1% of the fee.

The implementation fixed both defects I reported last round, so this revision adds regression tests for those fixes. It files no new findings.

forge build succeeds, and forge test with the verifier's fuzz seed passes all 85 tests: 81 that were already there and 4 new ones.

What changed in src/ADVNToken.sol:

• Distributor lookup: if the factory returns a malformed 32-byte answer (bits set above the 160-bit address range), it now counts as "no distributor". Before, it reverted and froze transfers.
• previewTransfer: it now divides by 200 and 100. Before, it overflowed for very large inputs.

The 81 existing tests needed no changes.

New tests, in test/ADVNToken.adversarial.t.sol:

• testFuzz_dirtyDistributorWordNeverFreezesOrExemptsTransfers: puts random high bits on the real distributor's address. While the answer is malformed, transfers still go through and the distributor pays the fee and burn like anyone else. Once the answer is clean again, its exemption comes back.
• test_distributorWordBoundaryAndTrailingData: checks the exact edge (2^160 − 1 is still an address, 2^160 is not) and that answers longer than 32 bytes are read by their first word.
• testFuzz_previewIsTotalAndFloorsOverWholeDomain: covers every uint256 with no bounds. Each levy rounds down at its rate, and fee plus burn plus amount received always equals the input.
• test_previewEdgeExamplesAboveFormerOverflowPoint: fixed examples at max/100, max/100 + 1, max − 1 and max, including the exact remainders at 2^256 − 1.

test/TESTING.md still pointed to an .imd-findings.json that no longer exists, so I rewrote its findings section. It now records that both findings are fixed and names the tests that cover each one. It also notes two open questions that the implementer's REVIEW.md already documents and that I did not re-file:

• Pool trades settled as Uniswap v4 claims skip the tax (item 6).
• The requester still needs to confirm what the 1% burn is taken from: the transferred amount or the fee (item 2).

I only changed files under test/, and nothing is committed. The untracked dotfiles in the repository root were not created by me.

All four round-one findings are settled, and the review found no new defect. The findings file holds an empty findings list and a nine-row coverage record.

What I settled

• Claims-settled v4 trades untaxed (medium). The author took the documentation option the finding allowed. The token NatSpec, README Limits, launch.json notes and REVIEW.md item 6 now say the tax reaches only ERC-20 transfers out of the PoolManager and ordinary transfers, and that claims-settled buys, sells, round trips and claim moves are untaxed. The two specialist proofs still fail on this code, which is expected since no token-only change can pass them. The author's four new claim tests in test/LaunchFlow.t.sol pass and pin the documented behaviour.
• distributor() reverting on a dirty word (low). Fixed. The answer is decoded as a word and anything above the address range becomes "no distributor". The author's reproduction with a factory returning 1 shifted by 160 now gives a taxed transfer instead of a revert.
• previewTransfer overflow (info). Fixed by dividing by the exact reciprocals. Defined for every uint256, with a full-range fuzz against the basis-point formula.
• Burn base reading (info). Dropped. Not a code defect, and the README and REVIEW.md now flag in bold that the requester must confirm the burn base before release.

Checks run

• The project suite passes in full: 85 tests across unit, launch-flow, adversarial and two invariant suites.
• The protected floor tests could not be compiled here because they import service sources not in this tree. The transfer logic they exercise is unchanged since last round.
• The manifest has schema keys only, the supply matches the constructor mint, and the contract is far under the size limits.

Coverage. All three entry points hold, with one-line reasons in the record. No finding carries a proof because there are no findings.