The deliverable is complete and verified. Nothing further depends on another result, so there is nothing more to request.

Outcome. The Nvidia (ADVN) custom token is implemented in src/NvidiaToken.sol as contract NvidiaToken, with a Foundry project at the repository root. forge build, forge test (38 tests, including fuzz and invariant suites run with the verifier's seed) and forge fmt --check all pass with solc 0.8.26 pinned and bytecode_hash = "none".

What the token does

• Mints 1,000,000,000 ADVN (18 decimals) once to msg.sender in the constructor. No mint, owner, pause, blacklist, fee setter or upgrade path exists.
• Every ordinary transfer sends 0.5% to Jensen Huang's wallet (a constant) and burns 1%, so the receiver gets 98.5%. Cuts round down; the sender pays the full amount and transferFrom spends the full allowance.
• Transfers from or to the factory, the PoolManager, and the launch's MerkleDistributor (looked up via distributorOf(launchNumber) on the factory, then cached) move exactly, so the swarm share, pool seed, claims and v4 swaps all settle whole. The lookup tolerates a factory with no code, a revert or a malformed answer.
• Constructor arguments are the three static launch values: $factory, $poolManager, $launchNumber. The constructor makes no external call.

Files

• foundry.toml, remappings.txt, .gitignore
• src/NvidiaToken.sol
• script/DeployNvidiaToken.s.sol (local-only helper; its deploy(Config) is tested directly)
• test/NvidiaToken.t.sol, test/NvidiaToken.invariant.t.sol, test/mocks/MockLaunchFactory.sol
• README.md with assumptions, deployment parameters, "After launch" (nothing to set), operational responsibilities, and security notes
• lib/forge-std (v1.9.7) and lib/openzeppelin-contracts (v5.7.0) vendored as plain files with no nested .git

Assumptions flagged for the requester (all documented in the README)

• "Trade" is read as any transfer, since an ERC-20 cannot distinguish trades. Swaps through the Uniswap v4 PoolManager are untaxed in both directions because the launch floor requires exact settlement there; trades on other venues are taxed.
• "1% burn of supply from every fee" is read as 1% of the transferred amount burned per taxed transfer, for a 1.5% total tax. If the requester meant 1% of the 0.5% tribute, BURN_BPS is the single constant to change.
• The tribute recipient address is fixed as a constant exactly as given, with no setter.

Not run. Slither is not available on this machine. I did not vendor v4-core to run a scratch swap against a real PoolManager; the PoolManager exemption makes those flows plain OpenZeppelin transfers, which the unit and fuzz tests cover.

Done. launch.json is written and is the only changed file.

What the manifest says

• Kind custom_token, token contract NvidiaToken, name Nvidia, symbol ADVN, 18 decimals.
• Constructor args $factory, $poolManager, $launchNumber, matching the accepted constructor (address, address, uint64) in declaration order.
• totalSupply is the constructor's single mint to msg.sender, 1,000,000,000 tokens in minor units.
• contracts is empty: the accepted tree deploys only the token, with no application contracts.
• pool and economics are copied exactly from the launch reference: native ETH, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object verbatim.
• notes describe the 0.5% tribute to Jensen Huang's wallet, the 1% burn, the untaxed launch flows via factory, PoolManager and the distributor lookup, and the absence of any admin path. They run to about 1,500 characters.

Verification

• A local schema check passed: only the allowed top-level keys, strings for uint256 and address values, numbers for fee, tickSpacing and decimals, lowercase addresses, economics equal to the job's copy.
• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 38 tests across both suites.
• git status shows only the new launch.json; nothing else was touched.

I found one medium-severity problem with access control and wrote it to .imd-findings.json. No source files were changed. I deleted my scratch test afterwards.

Finding 1 (medium): any holder can skip the tax by routing transfers through the Uniswap v4 PoolManager. At src/NvidiaToken.sol:133, every transfer to or from the PoolManager is fee-free, whoever starts it and for whatever reason. That address is shared, and v4 lets anyone send it tokens and have them paid out to another address without making a trade. Both steps touch the PoolManager, so neither is taxed.

• What happens: alice sends 100e18 to bob through a small relay contract. Bob receives the full 100e18, Jensen's wallet gets nothing and nothing is burned. The tax should have given bob 98.5e18, Jensen 0.5e18 and burned 1e18.
• Why it matters: the code comments and README promise that wallet-to-wallet transfers are taxed. Any other pool on the same PoolManager, such as an ADVN/USDC pool anyone creates, is untaxed too.
• How I checked it: a scratch Foundry test passed, but against a minimal stand-in for the PoolManager, not the real one. The repo doesn't include Uniswap v4, so I couldn't test against it, and there is no proof test in the finding.
• Fix: the launch rules require the PoolManager exemption, so it can't simply be removed. Either the README and launch notes should say the tax is optional for anyone who routes through the PoolManager, or you decide whether to add a v4 hook. The launch doesn't deploy one at the moment.

Disclosed tradeoff, not reported as a defect: trades in the launch pool itself are untaxed. Your brief says the fee comes "from every trade", but the README states this limit openly.

Coverage of the three entry points:

Entry point	Verdict	Why
NvidiaToken.transfer(address,uint256)	finding 1	Otherwise splits and burns as specified
NvidiaToken.transferFrom(address,address,uint256)	finding 1	Spends the full allowance, then follows the same path as transfer
NvidiaToken.approve(address,uint256)	holds	Unchanged OpenZeppelin approve

I also checked that the token has no owner, setter, pause, blacklist, extra minting or burnFrom. The factory, PoolManager and launch number can't be changed after deployment, and only the factory's answer can set the cached distributor address. The supply never grows after the constructor.

The two static-analysis leads were low-severity style notes with no security impact, so I didn't report them.

I found one defect, rated medium: any holder can skip the 0.5% tribute and the 1% burn by routing a transfer through the PoolManager. I wrote it to .imd-findings.json with a coverage row for each of the three entry points. The project's own suite passes (38 tests), and no tracked files were changed.

Finding 1 (medium): transfers out of the PoolManager are untaxed (src/NvidiaToken.sol:133)

if (from == factory || to == factory || from == poolManager || to == poolManager) return true;

• Bypass: any holder can send ADVN to any address tax-free by passing it through the PoolManager's escrow in one transaction: deposit the tokens, record the credit, then withdraw them to the recipient. Both legs touch the PoolManager, so neither is taxed. No pool, liquidity or swap fee is needed.
• Example: sending 1,000,000 ADVN this way, Bob receives the full 1,000,000 instead of 985,000. Jensen's wallet gets 0 instead of 5,000, and nothing is burned instead of 10,000.
• Buys: the same clause also makes every buy from the launch pool untaxed. The README says this is needed for exact settlement, but only tokens going into the PoolManager (sells and the seed) must arrive exact. The PoolManager never checks its own balance when paying out, and the launch floor only requires that a buy delivers something and that the full balance can be sold back.
• Fix: remove from == poolManager and keep to == poolManager. The seed is still exempt because it comes from the factory, and sells still settle exactly.
• Decision for the requester: this reverses the README's assumption that pool trades are untaxed, so pool buys would start paying the tax. Three of the project's own tests assume PoolManager payouts are untaxed and would need updating: test_poolManagerBothWaysIsUntaxed, the PoolManager-payout case of testFuzz_launchFlowsAreExact, and the invariant model.
• Proof: the attached Foundry test fails on the current code with tribute skipped: 0 != 5000000000000000000000. It uses a minimal stand-in for the PoolManager, because v4-core isn't in lib/. In a copy of the tree outside the repo, it passes with the fix applied.

Coverage

• transfer and transferFrom: finding 1. The rest of the path holds: the balance check, the three-way split, rounding, the distributor cache and the handling of a factory that can't be reached. transferFrom spends the full allowance before the same path runs.
• approve: holds. It is the standard OpenZeppelin version with no tax logic.
• I also checked and recorded these invariants: supply never grows, the launch transfers (factory, distributor, seed, sells) move exact amounts, and a failed factory lookup never blocks transfers.

Not reported

• Amounts under 200 wei pay no tribute. The README already discloses this and splitting transfers that small costs more in gas than it saves.
• I could not run the protected floor tests here, because they depend on harness files that aren't in this tree.
• I deleted the scratch test and the temporary copy afterwards.

The review is written to .imd-findings.json: four findings and fourteen coverage rows, with no tracked file changed. The split arithmetic itself holds; the one finding that matters is outside the math area.

Findings

1. Medium — the tax can be skipped on any transfer (src/NvidiaToken.sol:133). The exemption applies when either side is the PoolManager, and anyone can pay tokens into the PoolManager and take them out to another address without swapping. Against the real mainnet PoolManager bytecode, 1,000 ADVN moved from Alice to Bob with tribute 0 and burn 0, for about the gas of a normal transfer. This is outside my area, and it cannot be closed in the token while the launch floor requires exact PoolManager flows, so it is a decision for the requester.

2. Low — the factory lookup is not as failure-tolerant as documented (src/NvidiaToken.sol:148). Three factory answers break ordinary transfers until a distributor is cached:

   • a 32-byte answer that is not an address reverts transfer, transferFrom and isExempt;
   • a factory that burns its gas makes a transfer fail at up to 4,000,000 gas;
   • a 600,000-byte answer makes a transfer fail at up to 1,000,000 gas.

   None of these happens with a factory that returns a clean address, as the floor's stand-in does. The finding carries a proof test that fails on the current code and passes on a patched copy (gas-capped call, decode as uint256, reject words above 160 bits).

3. Info — splitTransfer panics above type(uint256).max / 100 (src/NvidiaToken.sol:94). The README says it answers for any amount; no transfer can reach this, because the balance check comes first.

4. Info — the local deploy script truncates the launch number (script/DeployNvidiaToken.s.sol:30). ADVN_LAUNCH_NUMBER = 2^64 + 5 deploys with launch number 5. The script is local-only.

Coverage

• Entry points: approve holds. transfer and transferFrom are marked as findings (reference 1, with finding 2 noted in the reason), though their arithmetic is exact.
• Math Precision: net + tribute + burned equals the value on every taxed transfer, and nothing overflows below the supply. Amounts of 99 wei or less pay nothing and 100–199 wei pay 1 wei of burn only; this is documented and worth under 2 wei per transfer, so I recorded it as a coverage row rather than a finding.
• Boundary: the only external call is the factory lookup (finding 2). Zero-value, self and tribute-recipient transfers conserve balances.
• Numerical Gap: supply only ever falls by the burned amount, and the views match what the write path does.
• Not run: the protected floor suite, because its v4-core harness is not vendored here. I traced the launch flows against it by reading only.

The repository's own 38 tests pass. My scratch tests under test/scratch/ are deleted.

The review is complete. The findings file is valid, all four cited snippets match the tree, and all three entry points plus six invariants have coverage rows. No source or config files were changed; the only new files are the findings file and one scratch test.

Outcome: one medium, one low, two info findings on the economics of NvidiaToken. No critical or high defect.

The token's arithmetic, conservation and launch flows hold. Supply is minted once, the three-way split sums exactly to the amount after a whole-amount balance check, totalSupply only shrinks by the burn, and the factory, PoolManager and distributor flows move exactly what they say. All 38 repository tests pass.

Findings written to .imd-findings.json:

• Medium. The tax is optional. The exemption keys on the PoolManager address, and Uniswap v4's PoolManager is permissionless. Any holder can unlock it, transfer ADVN in, settle, and take to any address, so a wallet-to-wallet transfer, exchange deposit or OTC settlement pays no tribute and burns nothing. ERC-6909 claims on the manager are an untaxed wrapped ADVN, and every v4 pool trades untaxed, not just the launch pool. I demonstrated this with a scratch test: the same sender, receiver and amount yield 985 to the receiver, 5 tribute and 10 burned directly, and 1000, 0 and 0 when routed through the manager. The token cannot fix this without failing the launch floor's exact swap checks, so it is a design limitation the requester must accept and the README must disclose.
• Low. The tribute address has never been used. On mainnet it has no code, zero balance and nonce zero. The code copies the brief exactly, but there is no evidence anyone controls the key, and the constant has no setter. Proof of control should be obtained before admission.
• Info. Brief versus implementation. Fees are stated as "from every trade", yet launch-pool trades are necessarily untaxed, and "1% burn of supply from every fee" is read as 1% of the amount. Both are disclosed assumptions that need the requester's written confirmation.
• Info. README v3 guidance is wrong. Uniswap v3 has no fee-on-transfer swap path, so selling ADVN into any v3 pool reverts. Only buying works.

Coverage: all three entry points answered, with transfer and transferFrom pointing at finding 1 and approve holding. Passes I could not complete: no test against the real v4-core PoolManager, since it is not vendored and a submitted proof may import only the project and forge-std, so the pass-through is shown with a minimal manager that mirrors v4's sync, settle and take accounting. No proof field was attached because no finding is high or critical.

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

forge build and forge test pass with the required seed: 78 passed, 0 failed. The new invariant campaign exercised 16,384 calls.

Reported two low-severity defects with failing proofs in .imd-findings.json: malformed distributor responses blocking transfers, and overflow on large splitTransfer inputs.

The review is complete and .imd-findings.json holds the result. No repository file was changed; the scratch tests are removed.

Outcome. The twelve specialist findings collapse to seven, all reproduced against the code. The existing suite of 78 tests passes, and all four attached proofs fail on this tree for the stated reasons.

Findings kept

1. Medium, PoolManager two-way exemption at src/NvidiaToken.sol:133. Four specialists reported the same root cause, merged into one. Anyone can route a wallet-to-wallet transfer through the v4 PoolManager's sync, settle and take, paying no tribute and no burn. The attached proof fails here with "tribute skipped". I also verified the minimal fix in a scratch copy of the token: dropping the outbound exemption makes the proof pass and still satisfies the launch floor, since only tokens entering the PoolManager need to arrive whole. The economics specialist's claim that nothing can be done at the token level was wrong for the outbound leg. This is a requester decision, because it would also tax pool buys.
2. Low, distributor lookup hardening at line 148. Merged from the math specialist and the tester. A 32-byte non-address answer from the factory reverts every transfer and isExempt. I also confirmed the gas-burning and oversized-return variants: a 1e18 transfer needs about 6M gas against an INVALID-returning factory. Needs a misbehaving factory, so low.
3. Low, splitTransfer overflow at line 94. Merged. The quote helper panics above type(uint256).max / 100 although the README promises any amount. Boundary confirmed.
4. Info, script truncates the launch number to 64 bits. Verified with vm.setEnv: 2^64 + 5 deploys with launchNumber 5.
5. Info, brief interpretation to confirm in writing: pool swaps untaxed and the 1% burn read as 1% of the amount.
6. Info, README v3 guidance is wrong: v3 has no fee-on-transfer swap, so sells into a v3 pool revert on the IIA check.
7. Info, tribute recipient is an unverified constant. Confirmed on mainnet today: no code, zero balance, nonce 0.

Coverage. All three entry points are answered, approve holds and transfer and transferFrom carry finding 1, plus four invariant rows including the manifest shape. My own pass found nothing beyond the specialists' leads: supply, exempt flows, rounding, self-transfer, allowance and reentrancy all hold.

I fixed the main finding (the PoolManager tax bypass) and the two low ones. The reviewer's proof now passes, and forge build, forge test (45 tests, run with the verifier's fuzz seed) and forge fmt --check all pass. Nothing is committed.

The bypass (medium). I reproduced it first: on the starting code the reviewer's proof failed with "tribute skipped". Anyone could send ADVN to the PoolManager and have it paid out to another wallet in one call, untaxed. The fix in src/NvidiaToken.sol:

• Into the PoolManager: still untaxed. This covers the launch seed and sells, which must arrive exact or they revert.
• Out of the PoolManager: now taxed. This covers buys, liquidity withdrawals and any payout. The tax comes out of the PoolManager's own balance, so its accounting still balances, and the receiver gets 98.5%.
• isExempt(poolManager) now returns false, because the PoolManager is only exempt as a receiver. I updated the tests that assumed the old two-way exemption and added a test of the pass-through route.

The two low findings:

• Factory lookup: it now runs on a 50,000-gas budget and treats any answer that isn't a valid address as "not known yet". New tests with a factory that returns a non-address value, burns all its gas, or returns a huge answer show transfers still go through, correctly taxed and cheaply.
• splitTransfer: it now divides by 200 and 100 directly. That gives the same results as before and can't overflow, even at the largest possible amount.

The info findings:

• Deploy script: it now rejects a launch number too big to fit.
• Uniswap v3: the README now says ADVN can't be sold into a v3 pool, because v3 has no fee-on-transfer swap functions. A v3 pool would be buy-only.
• Tribute address: I disputed this as a code defect. The address matches the brief and the brief asked for no admin, so there is deliberately no way to change it. The README records that the address showed no on-chain activity as of 2026-11-12 and asks the requester for proof they control it.

For the requester to confirm before launch (marked in the README):

• "From every trade": in the launch pool, buys now pay the 1.5% tax and sells don't. Taxing sells as well would need a Uniswap v4 hook, which this launch doesn't deploy.
• The burn: it is implemented as 1% of each transfer amount, not 1% of the 0.5% fee.

My answers to each finding are in .imd-responses.json.

Several files I didn't create appeared untracked in the repo root (.bashrc, .gitmodules, .claude/, .vscode and others). I left them alone, but they shouldn't be submitted, so check them before upload.

I fixed the notes in launch.json. They described an older version of the token, where transfers both into and out of the Uniswap v4 PoolManager were tax-free and pool trades were untaxed. The accepted src/NvidiaToken.sol only exempts transfers into the PoolManager (the pool seed and sells). Transfers out of it (buys, liquidity withdrawals, take) pay the full 1.5%, which also stops people routing wallet-to-wallet payments through the PoolManager to dodge the tax.

The notes now say this, and also mention the gas-capped lookup of the token's distributor, the constructor's zero-address check, and the two readings the README leaves for the requester to confirm. They're 1,910 characters, under the 4,000 limit. This is the only change in the diff; no other file was touched.

The rest of the manifest already matched the source, so I left it as it was:

• Token: contract NvidiaToken, name Nvidia, symbol ADVN, 18 decimals.
• Constructor arguments: [$factory, $poolManager, $launchNumber], which matches the constructor (address, address, uint64).
• Supply: totalSupply is "1000000000000000000000000000", which equals INITIAL_SUPPLY, minted once to msg.sender.
• Contracts: none, since the token is the only contract in the accepted tree.
• Pool: ETH as the paired currency, fee 12500, tick spacing 60, initial price at one to one.
• Economics: the requester's object, copied exactly.

forge build succeeds, and forge test with the verifier's fuzz seed passes all 43 tests. I couldn't run the protected launch-floor test (Token.protected.t.sol) here: it imports contracts and v4-core sources this repository doesn't have and needs the verifier's environment variables.

I've updated my tests for the revised token. All 98 tests now pass with the verifier's fuzz seed and with a second seed, and they also pass on a fresh copy of the tree with test/scratch left out. I found no new defects, so I didn't write .imd-findings.json.

Why my tests were failing: after my last round, the token was changed so that only transfers into the Uniswap v4 PoolManager are free. Transfers out of it (buys, liquidity withdrawals, take) now pay the 1.5% fee. My earlier tests still treated the pool as free both ways, so three of them failed on the new code: the stateful invariant suite, its scripted sequence, and one fuzz test.

What I changed:

• The stateful model (test/handlers/NvidiaTokenStateHandler.sol): it now uses the new rule. Transfers to the pool are untaxed, transfers out of it are taxed, and the pool no longer counts as exempt. It also tracks the extra factory lookup that a transfer out of the pool now makes, and counts taxed payouts from the pool so the run can't pass without any happening.
• test/NvidiaToken.stateful.t.sol: the scripted sequence now does a sell into the pool (arrives whole), then pays out the pool's whole balance (taxed). It checks the pool ends at zero, so the pool loses exactly the amount sent.
• test/NvidiaToken.discovery.t.sol: the allowance fuzz test only treats the pool as exempt when it is receiving.
• New test/NvidiaToken.pool.t.sol (15 tests):
  • Fee amounts are checked against an independent calculation of 0.5% and 1% of the full amount, not against the token's own function.
  • Payouts from the pool are taxed, both directly and via transferFrom (which spends the full allowance).
  • A sell followed by a buy-back loses exactly the fee.
  • Pool to factory is exact; pool to distributor is taxed until the factory names the distributor, then exact.
  • Overspending and too-small allowances revert with nothing changed, and the right events are emitted.
• The two defects I reported last round are fixed and now have regression tests:
  • A malformed factory answer is ignored rather than breaking transfers, and a later valid answer is still accepted.
  • splitTransfer gives the right split for every possible amount, including the maximum.
• A griefing check: someone submits a distributor's first payout with a deliberately low gas limit, hoping the distributor lookup fails and the payout gets taxed. A fuzz test checks the payout either arrives in full or reverts. A full sweep of gas limits from 5,000 to 120,000 (in steps of 7) gave 8,605 full payouts, 7,824 reverts and none that arrived short.
• test/TESTING.md: rewritten to describe the new pool rule and to say both earlier findings are fixed.

The new rule also means buyers in the launch pool receive 98.5% of the quoted amount. The token's README already says this, and the supplied protected launch test (which buys and then sells back what was bought) still allows it.

There are some untracked files at the repo root that were there before I started (.bashrc, .gitconfig, .idea, .claude/ and similar). I didn't touch them.

All prior findings are settled as fixed, and I found no new reproducible defect. The findings file is written with an empty findings list and nine coverage rows.

What I verified on the revised tree

• Medium, PoolManager two-way exemption (e644f2a3): fixed. _isLaunchFlow at src/NvidiaToken.sol:144 now exempts only transfers into the PoolManager. Both attached bypass proofs pass on this tree, the escrow-route test and the invariant model agree, and a scratch v4-style manager ends with zero balance and zero delta after a taxed take, so flash accounting stays consistent. The launch floor's flows (seed from the factory, sells into the manager, sell-back of the trader's whole balance) are unaffected by tracing. The floor file itself cannot compile here because v4-core is not vendored.
• Low, lookup not failure-tolerant (4b5ec26b): fixed. The call is capped at 50,000 gas, decodes as uint256 and rejects words above uint160. The attached proof passes. For the slither return-bomb lead I measured the largest answer a 50k-gas callee can produce: the transfer still succeeds and costs under 200k gas, so the lead is bounded, not a defect.
• Low, splitTransfer overflow (891acc0d): fixed by dividing by the reduced denominators. Max-amount test and full-range fuzz pass.
• Info, deploy script truncation (9568c57a): fixed. A scratch run with 2^64+5 reverts with LaunchNumberTooLarge.
• Info, documentation items (db100ab3, 1bba8dd9): README assumptions 2 and 3 are rewritten and marked for requester confirmation. The v3 note is corrected.
• Info, tribute recipient control (1d2fed14, disputed): not a code defect, and I did not restate it. The README now records the mainnet observation and asks for proof of control. This remains an open operational item for admission, not a finding.

Suite status: 96 tests across six suites pass with the verifier's fuzz seed, including the invariant suite. Aderyn's two lines (large literal, unused public isExempt) are style noise, not defects.

Open for the requester before admission: written confirmation of the two brief readings (tax on every non-launch transfer with pool buys taxed and sells exact, and a 1%-of-amount burn), and proof of control of the tribute address.