SwarmPegHook takes maintenancePot_ as a literal constructor address, and every fee is minted as ERC-6909 claims to it forever (afterSwap: poolManager.mint(maintenancePot, ...)). The pot (SwarmMaintenance(IPoolManager manager_, IERC20 token_), src/SwarmMaintenance.sol:74) must be constructed with the launch token's address.

In the IMD flow the launch factory creates the token ($token) and deploys the hook and initializes the pool in a single transaction; the manifest has only hook and token contracts and placeholders $poolManager/$token/$owner/$factory. There is no placeholder or deployment step for a third contract, and the token address is not known before the launch transaction (so it cannot be written by hand either).

The constructor args the hook needs therefore cannot be written: ["$poolManager","$token",<pot>,"$factory"] where must be a contract that already exists with votingToken == $token. README/OPERATIONS step 3 ('Deploy SwarmPeg ... then SwarmMaintenance(manager, token), then SwarmPegHook') describes an ordering the factory does not perform.

Either the launch is blocked, or the hook is deployed with a pot wired to some other token/address, and since the field is immutable all 2% fees go to the wrong place for good (claims minted to an address that cannot redeem or vote them).

SwarmPegHook's constructor (src/SwarmPegHook.sol:61) takes address maintenancePot_ and stores it with no check beyond nonzero: it never verifies that the address has code, is a SwarmMaintenance, or is bound to the same PoolManager and token (SwarmMaintenance.poolManager(), votingToken()). README.md line 31 states this explicitly: 'Constructors make no calls to these dependencies and do not require deployed code.'

Every swap fee is then minted as an ERC-6909 claim to that address (src/SwarmPegHook.sol:155 poolManager.mint(maintenancePot, uint256(uint160(PAIRED_ASSET)), fee)). A claim can only be burned by its holder (PoolManager.burn requires msg.sender == from or an operator/allowance the holder set) inside an unlock callback, so a codeless or mis-wired recipient can never redeem, and 100% of the hook fee is unrecoverable with no owner or rescue path.

This is a trust gap at the deployment seam, not a hypothetical: the launch flow cannot supply a correct value. The manifest resolves only $poolManager, $token, $owner and $factory; the pot has no placeholder and must be a literal (a stand-in is refused).

SwarmMaintenance's constructor needs the launch token address, but $token is deployed by the factory in the same transaction that deploys the hook, so no correctly wired pot can exist when launch.json is written. docs/OPERATIONS.md step 3 asks 'the network' to deploy the pot between the token and the hook, which the factory does not do. Whatever literal is written, the hook constructor will accept it.

Fix: remove the argument and have the hook deploy its own pot in the constructor (maintenancePot = address(new SwarmMaintenance(manager_, token_));), so constructorArgs become [$poolManager, $token, $factory] and wiring is enforced by construction; or, at minimum, require maintenancePot_.code.length != 0 && SwarmMaintenance(maintenancePot_).poolManager() == manager_ && SwarmMaintenance(maintenancePot_).votingToken() == token_ in the constructor.

The maintenance pot's own constructor has the mirror gap (src/SwarmMaintenance.sol:74) and would be covered by the same change.

Trust gap across access, economics and asymmetry.

Access: proposePayment is open to anyone who can escrow PROPOSAL_STAKE (1,000,000 SWARMPEG, 0.1% of supply, src/SwarmMaintenance.sol:20), and closeJob is open to anyone once voteEnd passes.

Economics: the stake is fully refundable through withdrawVote the moment voteEnd is reached, whether the job passed or not, so a junk proposal costs only gas and a 7-day lock of about 2.5 IMD worth of tokens at the 2,500 IMD opening cap.

Asymmetry: only one job may exist (activeJob != 0 reverts every other proposer for the full VOTING_PERIOD), and the slot is handed to whoever calls proposePayment first after a close. A griefer bundles closeJob(old) + withdrawVote(old) + proposePayment(self, 1, x) in one transaction at the first eligible second, every 7 days, forever; honest proposals (renderer work, keeper pay) can never be opened and the entire fee stream is frozen in the pot.

If the griefer also reaches quorum (see finding 3) and names a recipient that cannot receive IMD, closeJob is additionally blocked during the 2-day delay plus 14-day window (src/SwarmMaintenance.sol:169), stretching each cycle to 23 days. README.md line 106 discloses this as a cost 'wealthy holders' bear, but the actual requirement is 0.1% of supply with full refund.

Fix options that keep the ownerless design: allow several concurrent proposals with the sum of open amounts bounded by managedAssets(); or forfeit (burn or keep in the pot) the stake of a proposal that fails to reach quorum; or let a proposal with more yes votes supersede the active one.

Access x economics seam. passed() needs only job.yes >= QUORUM (10,000,000 SWARMPEG, 1% of supply, src/SwarmMaintenance.sol:21) and yes > no; there is no minimum turnout relative to circulating supply, no cap on amount relative to the pot, no veto or guardian, and the proposer may name themselves as recipient (proposePayment only rejects address(0) and the pot).

At the 2,500 IMD opening market cap, 1% of supply costs about 25 IMD plus price impact, while the pot accumulates 2% of all volume indefinitely. Once managedAssets() exceeds the cost of 10M tokens, any holder or buyer can propose proposePayment(self, managedAssets(), anyHash), vote the remaining 9M from a second address, wait 7 + 2 days, call executePayment and withdraw all 10M tokens afterwards, keeping the full pot.

The only defense is other holders locking more than 10M tokens in a 'no' vote within 7 days, and combined with finding 2 the attacker can repeat the proposal every 7 days at no cost, so defenders must win every round forever while the attacker needs to win once. The requester's 2% (20M) can block a single round only if it is watching.

README.md line 104 and docs/SECURITY.md describe capture 'with economically acquired tokens' as a disclosed governance risk; this finding records the concrete break-even so the author can decide whether a 25 IMD attack budget against an unbounded pot is acceptable.

Fixes that keep the design: cap each job at a fraction of managedAssets() per period; require yes votes >= a share of circulating (non-pool) supply; add a short objection window in which a larger stake can veto; or let a proposal be superseded by one with more support.

Economic Security: the pot receives 100% of the 2% hook fee and grows without bound, but the only gate on paying it out is passed(id) (line 146): yes >= QUORUM (10,000,000 SWARMPEG, 1% of supply) and yes > no, after 7 days. The quorum is fixed in tokens, not tied to the amount requested or to the pot's size.

At the launch policy's 2,500-IMD whole-supply valuation, 10M SWARMPEG costs about 25 IMD to buy from the pool (plus ~3.25% LP+hook fee each way and price impact, roughly 2-3 IMD round trip), and every voting token is refundable through withdrawVote as soon as voting ends, before execution.

So the cost to take the entire pot is a fixed ~2-3 IMD plus gas, while the prize is everything the pot has ever accrued; the attack is profitable as soon as the pot exceeds a few IMD (about 150 IMD of traded volume). The one-vote-per-address rule does not raise the cost: the 1M proposal stake and the 9M vote simply come from two keys of the same actor, as the proof shows.

Defence requires other holders to lock more than the attacker's tokens as no within 7 days on every attempt, and the attacker can re-propose immediately after each failure (only one job at a time, but closing and proposing can be bundled in one transaction).

Note also that the requester's 2% allocation (20M) and the contributors' 10% (100M) each exceed the quorum on their own, so either can pay out the pot unilaterally; the README calls threshold capture a disclosed governance risk, but at these numbers the pot's funds are effectively claimable by anyone, which contradicts the brief's purpose of a pot that funds swarm jobs.

Minimal fix that keeps the ownerless design: make the threshold scale with the request (e.g. yes votes must be at least a share of circulating supply proportional to amount/managedAssets, or cap a single job at a small fraction of managedAssets per period), and/or require a supermajority of votes cast with a minimum turnout that excludes the proposer's own stake.

Flow Gap (execution x first principles): every fee is minted as an ERC-6909 IMD claim to maintenancePot (line 155, poolManager.mint(maintenancePot, uint256(uint160(PAIRED_ASSET)), fee)), and only SwarmMaintenance.unlockCallback on that same manager, driven by a vote of votingToken holders, can ever turn the claims into IMD. The constructor accepts any nonzero maintenancePot_ without reading SwarmMaintenance(pot).votingToken() or .poolManager().

The launch flow makes a wiring mistake likely rather than hypothetical: the factory creates the launch token ($token) inside the launch transaction, the hook's maintenancePot_ can only be written in launch.json as a literal address of an already-deployed contract, and that pot's constructor needs the launch token's address, which must therefore be predicted off-chain before the token exists (README: 'deploy SwarmPeg ... then SwarmMaintenance(manager, token), then SwarmPegHook').

If the prediction is off by one nonce, or the pot is built against another chain's manager, the hook still deploys, the pool still opens, trading works, and 100% of fees are minted to a pot whose voters hold a token nobody owns (or whose claims live on a different manager and whose managedAssets() is 0 so proposePayment always reverts with InvalidJob).

There is no owner, rescue or re-pointing path, so all fees are permanently lost; the README states 'bad deployment wiring cannot be repaired by an owner' but relies on an off-chain validateDeployedDependencies call that nothing in the launch enforces.

Minimal fix: in the constructor require SwarmMaintenance(maintenancePot_).votingToken() == token_ and .poolManager() == manager_ (the token probe exists before the hook is built in the verifier's floor tests, and the pot must exist to be named).

Better: let the hook deploy the pot itself (maintenancePot = address(new SwarmMaintenance(manager_, token_))) so launch.json carries only $poolManager, $token, $factory and no hand-written address at all.