Boundary x invariant seam. The invariant the vault relies on is 'excluded addresses have shares == 0, every other address has shares == balanceOf'. The token only re-derives shares inside _update, using whatever factory.distributorOf(launchNumber) returns at that instant (launchDistributor(), src/IMDIVIDENDS.sol:70-77, which also resolves to zero on any staticcall failure).

If the swarm's 10% is moved to the MerkleDistributor before the registry answers with its address, the transfer is still tax-exempt (msg.sender == factory) but setShares(to) stores balanceOf(distributor) = 100,000,000e18 as eligible shares. Nothing re-evaluates the exclusion until the distributor itself is the from of a transfer, i.e. the first contributor claim.

Until then the distributor owns the large majority of totalShares, every stream pays it proportionally, and because claimFor(address) is permissionless and always pays the account itself, anyone can push those rewards to the MerkleDistributor address where no code can retrieve them. Even unclaimed, they sit in accrued[distributor] forever and are never redistributed.

The code cannot verify the factory's ordering and offers no permissionless way to resync an address whose exclusion status changed. The README states the ordering requirement, but a stale-exclusion window is also reachable if the factory's getter transiently fails (not the function signature, or more than 30,000 gas) at the moment of the transfer.

Suggested minimal fix that preserves the design: add a permissionless syncShares(address account) on the token that calls dividendVault.setShares(account, _excluded(account, launchDistributor()) ? 0 : balanceOf(account)), and/or have the factory-sender path in _update treat a zero distributor as a reason to re-sync to on its next interaction.

Exclusion of the distributor is evaluated only at transfer time through factory.distributorOf(launchNumber). If the swarm's 10% arrives at the distributor before the factory's registry answers for this launch, the distributor is recorded with shares equal to its full balance and totalShares includes them. Nothing re-evaluates that until the distributor itself transfers.

Meanwhile every stream pays the distributor pro rata, diluting real holders, and anyone can call claimFor(distributor) to push those reward tokens into the MerkleDistributor contract, where they are unrecoverable. The README states the ordering assumption but the code does not enforce it and the factory's actual order (deploy token, deploy distributor, register, transfer) is not visible from this repository.

Minimal fix: expose a permissionless syncShares(address) on the token that re-reads exclusion and balance and calls dividendVault.setShares, so a mis-recorded excluded account can be zeroed by anyone; otherwise record 'registry answers before the swarm transfer' as a verified launch precondition.

rewardToken is a static constructor word. The protected admission test (Token.protected.t.sol) deploys the attested creation code in a fresh EVM with no fork: only the factory, pool manager and (for ERC-20 pairs) the paired token address are given code.

If the job pairs with native ETH, the README instructs to pass the chain's wrapped ETH as rewardToken; that address has no code in the harness, the vault constructor reverts, LaunchProbe.deploy fails with 'constructor failed', setUp aborts and the launch is refused. For an IMD-paired launch the paired address does have code (PairTokenProbe) and the check passes.

The author should either drop the code-length check (SafeERC20 already fails cleanly on a codeless token at fund time, and the existing balance-delta checks reject non-standard tokens) or make the reward token the paired currency and document that native-ETH pairing is unsupported.

Invariant / Flow Gap (execution x periphery). Exclusion is evaluated only at transfer time, from the factory's distributorOf(launchNumber) registry. If the factory forwards the swarm share to the MerkleDistributor before the registry answers (or the registry is unavailable within 30,000 gas at that moment), the transfer is still untaxed (msg.sender == factory) but setShares(to) records the full 10% of supply as eligible shares for the distributor.

Those shares are not revisited when the registry later resolves: the invariant 'excluded addresses hold zero shares' is broken until the distributor's first outgoing transfer, and every stream in between allocates rewards to the distributor in proportion to 10% of supply, diluting real holders.

When the first contributor claim finally zeroes the distributor's shares, _accrue has already credited the rewards to accrued[distributor]; anyone can then call claimFor(distributor) and the reward tokens land in a contract with no function to move them.

The protected harness happens to register before moving, and the README states the registry 'must be registered before the distributor receives tokens', so the precondition lies in launch-infrastructure ordering outside this tree; it is reported because the code could enforce the invariant cheaply.

Minimal fix: in _update, after resolving distributor, if distributor != address(0) && dividendVault.shares(distributor) != 0 call dividendVault.setShares(distributor, 0) (and optionally the same for any address that becomes excluded), so a late registration self-heals on the next transfer and no further rewards accrue to it; rewards already accrued remain a one-time loss bounded by the pre-registration window.

Documented privileged powers recorded as trust assumptions, not permission bypasses (the requester asked that only the owner change fees and vault operation). (a) convertFees enforces only rewardAmount != 0: the owner may take the entire collected 7% fee inventory for a single base unit of the reward token, so the conversion of taxes into dividends has no minimum rate and depends entirely on the owner.

(b) configureVault(duration, false) stops distribute() while fund()/convertFees deposits already queued (including third-party donations) remain in the vault; if ownership is then renounced (Ownable.renounceOwnership is inherited and reachable), distributions can never be re-enabled and queuedRewards is stranded forever, since there is no sweep. (c) setFeeBps may be raised to 1,000 bps immediately, with no delay, so a pending ordinary transfer may pay up to 10% instead of 7%.

No unprivileged amplifier exists for any of these; they are reported so the judge and requester can weigh an operational multisig and the documented 'avoid renunciation while fee conversion is needed' guidance. No code change is required if the trust model is accepted; a timelock or a minimum reward-per-token floor on convertFees would narrow (a), and refusing renounceOwnership while distributionsEnabled == false or queuedRewards != 0 would narrow (b).

The brief says the 7% tax exists to 'distribute dividends to the holders'. The only path from collected fees (held at the token contract) to holder dividends is convertFees, which is onlyOwner and whose only economic constraint is rewardAmount != 0.

The guard is correct in isolation (only the owner may call) and the accounting is correct in isolation (what is pulled is queued exactly), but together they let the permitted actor set the exchange rate to anything, including 1 base unit of the reward token for 100% of the fee inventory, with recipient = the owner. There is no minimum rate, no reference to a pool price, no timelock and no cap on tokenAmount per call.

The README documents this as an accepted trust assumption ('a dishonest owner can acquire collected fees cheaply'), so this is reported as a trust assumption with material impact, not as a permission bypass: the owner cannot touch holder balances or already-funded rewards, only the fee pool.

The requester should decide whether this is acceptable; if not, the minimal design-preserving mitigations are an owner-set but publicly visible minimum reward-per-token rate with a delay before it lowers, or a per-call cap on tokenAmount as a fraction of inventory, both of which keep the owner-funded conversion model.

distribute() checks distributionsEnabled (line 96: if (!distributionsEnabled) revert DistributionsDisabled();) but _fund does not. Donations from anyone via the public fund() are therefore accepted into queuedRewards even when the owner has switched new periods off, and the vault has no sweep or refund. Two actors are treated differently: the owner alone can re-enable, while donors have no recourse.

If the owner then renounces ownership (an inherited, one-way call that the README recommends against but does not block), configureVault is unreachable forever and the queued tokens are permanently locked in the vault. Even without renunciation, a donor cannot tell from the fund() call that their tokens will not be scheduled.

Minimal fix that preserves the design: make _fund revert with DistributionsDisabled when !distributionsEnabled (so the asymmetry between the two entry points disappears), or additionally have renounceOwnership revert while distributions are disabled or queuedRewards != 0.

Exclusion from dividend shares is evaluated per transfer from a live staticcall to the factory's registry (line 89: address distributor = launchDistributor();). The factory, PoolManager, token and vault are immutable exclusions, but the distributor is the one exclusion whose status can be stale: shares are only rewritten when a transfer touches the address.

If the factory transfers the 10% swarm share to the MerkleDistributor before distributorOf(launchNumber) returns that address (the README states this ordering as a requirement on the factory, but the token cannot enforce it), the distributor is recorded with shares equal to 10% of supply and participates in every stream until some transfer touches it.

Rewards accrued to it in that window are credited to accrued[distributor], an address that never claims, so they are lost to holders and sit in the vault forever; totalShares is also inflated for all holders during that window. The same staleness applies if the registry later changes.

This cannot be fixed inside the token without the factory, so it is an infrastructure-ordering dependency that the deployer must verify against the real ProjectFactory.launchCustom; a code-level mitigation would be to let anyone call a permissionless syncShares(address) that re-evaluates exclusion, which at least stops further accrual without needing a transfer (a zero-value transfer to the distributor already does this today, but that is not documented as an operator step).

Merged from audit_permissions, audit_economics, audit_math and audit_flow (same root cause). Shares are re-derived only inside _update, from whatever factory.distributorOf(launchNumber) returns at that instant (launchDistributor() also resolves to zero on any staticcall failure).

If the factory forwards the 10% swarm share to the MerkleDistributor before the registry answers with its address, the transfer is still untaxed (msg.sender == factory) but setShares(to) records 100,000,000e18 eligible shares for the distributor. Nothing re-evaluates that until the distributor itself is the from of a transfer (the first contributor claim).

In the meantime every stream pays the distributor pro rata, diluting real holders, and because claimFor(address) is permissionless anyone can push those reward tokens into the MerkleDistributor address, which has no code to move them; unclaimed, they sit in accrued[distributor] forever and are never redistributed.

The protected harness registers before moving and the README states the ordering as a requirement, so the precondition lies in launch-infrastructure ordering outside this tree; it is kept at low because the code could enforce its own invariant cheaply and cannot verify the factory's order.

Minimal design-preserving fix: add a permissionless syncShares(address account) on the token that calls dividendVault.setShares(account, _excluded(account, launchDistributor()) ? 0 : balanceOf(account)), and/or in _update zero the resolved distributor's shares if they are nonzero. Rewards already accrued before the fix remain a one-time loss bounded by the pre-registration window.

Merged from audit_permissions (two items) and audit_economics (b). distribute() checks distributionsEnabled (line 96) but _fund does not, so public donations and owner conversions are accepted into queuedRewards after the owner has switched new periods off, and the vault has no sweep or refund. Only the owner can re-enable, so a donor has no recourse and cannot tell from the fund() call that their tokens will not be scheduled.

If the owner then calls the inherited, un-overridden Ownable.renounceOwnership() (deliberately or by mistake), configureVault is unreachable forever and the queued tokens are locked in the vault permanently; renouncing also permanently disables convertFees and setFeeBps, so the 7% tax keeps accumulating at the token contract with no way out and no way to turn it off. The README documents renunciation as discouraged but the code does not block it.

Low: loss requires an owner action, but the asymmetry between fund() and distribute() is a code-level gap. Minimal fixes preserving the design: make _fund revert with DistributionsDisabled when !distributionsEnabled, and/or override renounceOwnership to revert while distributionsEnabled == false, queuedRewards != 0, feeBps != 0 or balanceOf(address(this)) != 0.

Merged from audit_permissions (three items), audit_economics (a, c) and audit_flow. Recorded as documented trust assumptions, not permission bypasses: the brief says only the owner changes fees and vault operation, and the README states each power.

(a) convertFees enforces only rewardAmount != 0 and tokenAmount <= inventory: the owner may take the entire collected 7% inventory for a single base unit of the reward token, to an owner-chosen recipient, so the conversion of taxes into dividends has no minimum rate and depends entirely on the owner's good faith. Combined with finding 1, the dividend flow depends on the owner plus on holders choosing to pay the tax.

(b) setFeeBps applies immediately, so a pending ordinary transfer can be front-run with setFeeBps(1000) and pay 10% instead of 7% (bounded by MAX_FEE_BPS). (c) renounceOwnership() is reachable and one-way (see finding 3). None of these affect holder balances or already-funded rewards.

If the requester wants them narrowed without changing the owner-funded model: an owner-set, publicly visible minimum reward-per-token rate that only lowers after a delay, or a per-call cap on tokenAmount; a short delay on fee increases; and a guarded renounceOwnership.

Merged from audit_economics (medium), audit_flow (low) and audit_permissions (info); recalibrated to info because it has no impact on this launch.

The reproduction holds: deploying with a codeless rewardToken reverts InvalidRewardToken (Proof_95666fc26dac fails on this tree).

But launch.json pairs with the ERC-20 at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 and passes the same address as rewardToken, and the protected harness etches PairTokenProbe code at IMD_PAIRED_CURRENCY before it deploys the token (Token.protected.t.sol lines 177-180), so the constructor succeeds in admission and on-chain where the pair token exists. The check would only break a future native-ETH-paired launch, where WETH has no code in the harness.

If that portability matters, drop the code-length check (SafeERC20 and fund's balance-delta check already reject a non-token at first use) and keep the rewardToken == msg.sender guard.

Non-blocking. The guard added in this revision (fixing b3ec3120...) makes renounceOwnership revert while the token contract holds any DIVIDENDS. Transfers to address(this) are exempt endpoints (README: 'Direct DIVIDENDS transfers to the token contract join its convertible fee inventory'), so any holder can deposit 1 base unit at any time and the owner's renounceOwnership() reverts with UnsafeRenunciation.

The owner can clear the inventory only through convertFees (which needs at least 1 reward base unit and enabled distributions), and a griefer can re-deposit dust before the owner's next renounce transaction, so a separate-transaction renounce can be blocked for as long as the griefer pays gas. Impact is limited to an optional and discouraged owner action: no funds move, no holder is affected, and ownership and every other owner power remain intact.

A multisig owner can defeat it by batching convertFees and renounceOwnership in one transaction. Recorded so the author knows what the fix introduced; no code change is required if the operational note is accepted. If a change is wanted, replace the exact inventory == 0 condition with 'convert what is there inside renounceOwnership' or allow renunciation when inventory is below a small dust threshold.