The brief says '1% on each transfer'. _isExempt waives the burn whenever the recipient is the PoolManager (to == poolManager) and whenever the PoolManager is the caller or sender (msg.sender/from == poolManager). In Uniswap v4 anyone can call unlock() and, inside the callback, sync(AINSEM), send AINSEM to the PoolManager, settle() and then take(AINSEM, anyRecipient, amount).

The pay-in leg is exempt because to == poolManager, and the take leg is exempt because msg.sender == poolManager. So any holder, or a public router contract, can move any amount to any address with no burn. Swaps through the launch pool are also never taxed.

The README documents this as a design choice ('the token does not enforce a universal economic tax'), and the launch floor requires PoolManager flows to move exact amounts. Taxing either leg would short a pool settlement or a buy, so this cannot be fixed inside the token without breaking the launch floor. It is reported so the requester knows the 1% applies only to direct holder-to-holder transfers, and that any integration can route around it at gas cost only.

Fixing it means relaxing the brief, for example taxing only direct EOA/contract transfers, or accepting the bypass explicitly; changing the code alone does not fix it. Severity is info because no funds are lost and the behavior is documented.

Area: Trust Gap (access x asymmetry x economics), with the Asymmetry guide's branch diff. The exemption predicate treats the pool manager asymmetrically from every other counterparty: a transfer is exempt whenever the recipient is the pool manager (to == poolManager) and whenever the sender is the pool manager (from == poolManager), with no condition on who initiated the call.

The Uniswap v4 PoolManager is a permissionless singleton whose custody primitives (unlock, sync, settle, take, and ERC-6909 mint/burn) are callable by anyone and do not require a swap. Chaining the two exempt legs in one unlock therefore gives every holder a tax-free transfer to any recipient: deposit via sync + transfer(poolManager, X) + settle (exempt by to == poolManager), then take(token, recipient, X) (exempt by from == poolManager).

Net effect: sender debited X, recipient credited X, supply unchanged, so the requester's stated rule ('1% on each transfer') is enforceable only against holders who do not know this route, and the deflation the rule promises can be avoided at the cost of gas. The same bypass applies to ERC-6909 claim tokens: mint claims to oneself, transfer the claims inside the PoolManager (no AINSEM transfer occurs), and let the counterparty burn + take.

Trust framing: the README discloses that pool-routed transfers are untaxed, and the protected launch floor requires an ordinary trader to be able to sell exactly into the pool (v4 settle credits the balance delta, so a taxed inbound leg would leave a non-zero delta and revert the swap).

The to == poolManager and from == poolManager legs are therefore required by the agreed design, and this is a design consequence to be accepted explicitly rather than a bug with a drop-in fix.

Options if the requester wants a stronger guarantee: (a) accept and document that the 1% burn applies only to transfers that do not touch the launch pool infrastructure (current state); or (b) narrow the outbound leg, e.g. keep to == poolManager exempt but tax from == poolManager transfers only when the recipient is not the current locker, which v4 does not expose, so (b) is not implementable from the token alone.

No concrete victim loses funds; the harm is that the economic rule is weaker than stated.

Guard gap: the distributor and factory exemptions are keyed on msg.sender/from identity of a trusted contract that only moves tokens on launch flows; the pool manager exemption is keyed on a permissionless custody contract that moves tokens on behalf of any caller.

Numerical Gap seam: boundary x invariant. The invariant 'a claim leaves the distributor whole' is enforced only when the registry STATICCALL succeeds inside a fixed numeric bound (DISTRIBUTOR_LOOKUP_GAS = 30_000, line 16).

At the edge of that bound _distributor() returns address(0) (line 84), _isExempt() returns false, and the claim falls through to the ordinary path: the distributor is debited the full amount, the claimant receives amount - amount/100, and amount/100 is burned. Nothing reverts, so a Merkle claim is marked paid while it arrived 1% short, which is the 'launch flow that arrives short' the launch floor refuses.

The cap is an unverified assumption about the real ProjectFactory.distributorOf, whose source is not in this tree; only the test mock (a single mapping read, about 3,100 gas measured cold from the caller) is exercised.

Measured cliff: a correct getter that costs up to ~28,300 gas keeps claims exact; at ~30,600 gas (one mapping read plus 12 further cold SLOADs) every claim is taxed. The same happens for any reverting or malformed read (README line 31 says claims 'must not be executed while the registry is unhealthy', but the token cannot enforce that and claims are normally permissionless).

What I ruled out, so the precondition is limited to the registry's own cost/health: (a) an outside caller cannot starve the lookup with a tuned gas limit - EIP-150 leaves the token at most 1/64 of what the lookup needed (<476 gas for any getter under the cap), far below the two balance writes that follow; a sweep of every gas limit from 5,000 to 120,000 on a claim produced 0 taxed successes, also with a 28k-gas getter; (b) the 1024 call-depth route needs ~(64/63)^1022 = ~1e7 times the gas of the claim, above any block limit; (c) failing closed means 'taxed', so no holder can use a failed lookup to avoid the burn.

Fix options that keep the design: obtain evidence that the real factory getter costs well below 30,000 gas cold and record it with the launch; or remember the last successfully resolved non-zero distributor and use it when a later lookup fails (tradeoff: a registry failure then no longer ends the exemption; a successful read returning address(0) still can), or make a transfer whose msg.sender/from could be the distributor revert on a failed lookup instead of taxing it.

Math Precision: zero-rounding and fee rounding direction. burnAmount = floor(amount/100), so the effective rate is below 1% whenever amount % 100 != 0 and is 0% below 100 base units. Splitting defeats the burn entirely in principle. The leak is bounded at 99 base units (9.9e-17 AINSEM) per transfer, so with 18 decimals it is economically irrelevant: avoiding the burn on 1 AINSEM needs about 1.01e16 transfers of 99 base units.

README lines 10 and 15 document this as intended, and rounding up instead would make a 1-base-unit transfer deliver nothing, so I am not asking for a change; it is recorded so the judge has the numbers.

Related check: the public constant BURN_BPS = 100 (line 15) is not used by the calculation, which hard-codes '/ 100'; the two agree today because floor(amount*100/10000) == floor(amount/100) for every amount, and dividing first cannot overflow, but a later edit to one would not move the other. No overflow, underflow, downcast or scale-mixing path exists: amount <= balance <= 1e27, burnAmount <= amount, divisor is a literal.

The requested rule is '1% on each transfer'. _isExempt waives the burn whenever the recipient is the PoolManager, regardless of who the caller is, and whenever the sender is the PoolManager. Uniswap v4 lets any unprivileged account drive both legs inside PoolManager.unlock: sync(token) -> token.transfer(poolManager, X) -> settle() credits X to the caller -> take(token, recipient, X) pays X out from the PoolManager to any address.

Each leg is exempt, so an A->B value movement completes with zero burn. The same credit can instead be minted as ERC-6909 claim tokens, which are transferable with no AINSEM burn at all. Cost to the bypasser is only gas; nobody loses funds directly, but the token's single economic mechanism (deflation benefiting all holders) becomes optional for any sophisticated transferor, router or aggregator.

The README discloses this ('the token does not enforce a universal economic tax'), and the to == poolManager exemption is forced by the launch floor: an exact-input sell settles exactly bought tokens into the PoolManager and would revert with CurrencyNotSettled if taxed. Reported so the requester decides consciously; it cannot be removed without failing the protected swap test.

Economic lens: Legitimate features turned against the protocol / Flow Gap seam periphery x first-principles.

The distributor exemption is resolved by a bounded STATICCALL to factory.distributorOf(launchNumber); on any failure (revert, out-of-gas within the 30,000 allowance, malformed return) the token treats the launch as having no distributor and applies the 1% burn.

This design correctly protects ordinary holders from a broken registry, but it means a claim executed while the real ProjectFactory's getter costs more than 30,000 gas (for example a factory behind a beacon proxy plus extra reads, or a getter that derives the distributor address) does not revert: the claim succeeds and the claimant receives 99% while the MerkleDistributor's last claimant is shorted.

The verifier's probe is a plain mapping getter (well under the budget), and the README documents the requirement, so this holds for the attested deployment path; it is recorded as the one state in which the 'claims arrive whole' guarantee degrades silently rather than loudly.

I also checked that gas starvation of the outer call cannot cause this: either the lookup receives its full 30,000 or the outer transfer itself runs out of gas (test_lowGasClaimEitherRevertsOrArrivesWhole, gas limits 20k..120k).

Three specialists reported the same root cause at the same line; merged into one finding at low. _isExempt waives the burn whenever the recipient is the PoolManager (to == poolManager) and whenever the PoolManager is the caller or sender. Uniswap v4's PoolManager is a permissionless singleton: any account can unlock(), sync(token), pay tokens in, settle() for a credit, and take(token, anyRecipient, amount).

The pay-in leg is exempt (to == poolManager) and the pay-out leg is exempt (msg.sender == poolManager), so an A -> B transfer of any size completes with zero burn at gas cost only; the credit can also be minted as ERC-6909 claims and moved inside the PoolManager with no AINSEM transfer at all. Reproduced locally with a model of v4 flash accounting (v4-core is not vendored and lib/ may not be changed).

Impact: no holder loses funds and supply never grows; the stated rule '1% on each transfer' in practice applies only to direct holder-to-holder transfers and can be routed around by any router or sophisticated holder.

Recalibration: the to == poolManager and msg.sender == poolManager legs are required by the protected launch floor (an exact-input sell settles exactly bought into the PoolManager and a buy pays out from it; taxing either leg leaves a non-zero delta and reverts the swap), and README lines 29 and 86 disclose that the token does not enforce a universal tax. This is therefore a design consequence the requester should accept explicitly, not a bug with a drop-in fix.

Fix options: (a) accept and document, as now; or (b) change the brief (e.g. tax only direct transfers) - the token alone cannot distinguish a swap settlement from a bridged transfer.

Two specialists reported the same mechanism; merged at low. The distributor exemption depends on a STATICCALL to factory.distributorOf(launchNumber) capped at DISTRIBUTOR_LOOKUP_GAS = 30_000 (line 16). On revert, out-of-gas inside that cap, or a non-32-byte return, _distributor() returns address(0), _isExempt() is false, and the claim falls through to the ordinary path: the distributor is debited the full amount, the claimant receives amount - amount/100 and the rest is burned.

Nothing reverts, so a Merkle claim is recorded as paid while it arrived 1% short, which shorts the last claimant - the 'launch flow that arrives short' the floor refuses. Fail-open is the right choice for ordinary holders (a dead registry must not freeze transfers), but the precondition is an unverified assumption about the real ProjectFactory's getter, whose source is not in this tree; the protected harness probe is a plain mapping getter (~2.6k gas) and passes.

I confirmed the ruled-out paths: an outside caller cannot starve the lookup by tuning the outer gas limit (EIP-150 leaves the token at most 1/64 of what the lookup needed, below the two balance writes that follow), and a failed lookup never lets a holder avoid the burn.

Fix options that keep the design: record evidence of the production getter's cold gas cost well under 30,000 with the launch; or raise the cap; or revert instead of taxing when the lookup fails and from == a previously resolved distributor.