The guard protects other backers from a completing call that already made an Intake request in the same transaction, because the swarm serves only the first request of a transaction (imd.fun/docs, Pay on chain > Limits: "A transaction with several is recorded, and only the first is served", read 2026-10-13).

It checks msg.sender == tx.origin, which a contract cannot satisfy (verified: a plain contract completer reverts CompleterMustBeEOA), but an EOA with EIP-7702 delegated code, live on Ethereum mainnet since Pectra, satisfies it while executing a batch. The attacker's batch sends intake.request(...) for a question of their own and then mine.back(id, left, body) on a question holding other backers' IMD.

The mine's request is the second in the transaction and is never served: the backers' IMD is spent, the question stays Asked and mines nothing. The attacker pays the Intake price for their own answer plus the completing backing (at least 0.01 IMD), so this is griefing at a cost at least equal to the damage, and docs/SECURITY.md lists it as a known limitation.

Reported so the adapter and the next panel see the acknowledged residual: the mine has no on-chain way to tell whether the Intake was already asked in this transaction (the Intake's nonce is public, but a pre-call snapshot is not available to the mine).

The mine writes the oracle body itself from Spec, which is the right defence against body injection, but the body it writes has no definitions and no allowAmbiguous. The swarm's wording screen refuses a question with more than one reasonable reading (status 1, body_refused), and the reference says to pin the reading in definitions.

Against the live free check (POST https://api.imd.fun/requests/check, action oracle.request, 2026-10-13) two plain factual questions were both refused as ambiguous_question: "Did the IMD token at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 have more than one Transfer event on Ethereum mainnet in the window" and "How many HMM were transferred on Ethereum mainnet in the window".

On chain the same body is paid for, then onOracleFailure(status 1, body_refused) reaches fail: the question becomes Failed, the IMD is gone, and refund refuses (status != Open). A proposer who does not run the site's pre-check, or whose backers join a question that was never checked, loses the full price.

Every other body field the mine writes was verified valid against the paid schema (v, window.hours, quorum, validForSeconds, toleranceBps for uint256, and the five chain ids match the swarm's live list exactly). This is a product limitation rather than a code error, reported so the adapter can decide whether Spec should carry a bounded definitions map (keys <= 64, values <= 512 characters, same character rules as question).

forward is the only way tokens leave the forwarder, and it always ends by calling start(), which reverts AlreadyStarted after the first call. So once the launch's reserve has been forwarded, any HMM transferred to 0x876c2fb3eaa91d32ef03186853bb82433b949a71 (by mistake, or by a holder who believes sending HMM there grows the mine) is locked forever: forward(n) reverts at start(), there is no sweep, and the contract is immutable.

The same applies to HMM sent straight to the mine after start (documented at line 254: never emitted), so there is no address in the system that can accept HMM later.

Low: no attacker gains, but a deployed, permissionless contract with a well-known address is a plausible destination for mistaken transfers. A fix that keeps the design is to let forward transfer and skip start() when started() is already true, so late arrivals at least reach the mine, or to refuse the transfer when the mine has started.

The adapter has no constructor binding (removed because the launch checker refuses zero-address arguments). bind() is public and the first caller becomes mine, after which the adapter credits that address's questions.

In this launch HmmMine's constructor calls bind() in the same launchCustom transaction as the adapter's deployment, and the Intake-side checks (requests(requestId).target == this, the mine's questionOf) mean a stranger who did bind an adapter could not credit anything on the real mine.

The residual risk is operational: an adapter deployed on its own (a redeploy, a manual deployment to the same bytecode) can be claimed by anyone, and the mine that then tries to bind it reverts AlreadyBound, which for a launch means the whole launch transaction reverts. The launch factory's atomic deployment makes this unreachable here; noted so that nobody deploys the adapter separately.

Read in full: src/HmmToken.sol, src/HmmMine.sol, src/SwarmOracleAdapter.sol, src/GenesisForwarder.sol, src/interfaces/{IHmmMine,IIntake,ILaunchRegistry,IOracleAdapter}.sol, test/external/Intake.sol (the vendored Intake v2), test/utils/*, test/fixtures/RealAttestations.sol, script/HmmLaunch.sol, launch/config.json and launch/body.json, docs/SECURITY.md, the protected custom_token test, and the Pashov and oracle-consumer references.

Checked: forge test (80 tests) green; the mainnet-fork rehearsal (test/fork/Launch.fork.t.sol, 4 tests) run against a public mainnet RPC passes through the real ProjectFactory, LaunchRegistry, Intake and IMD; HmmToken is a plain OpenZeppelin ERC-20 with no owner, mint, burn, pause, fee, delegatecall or selfdestruct, bytecode_hash is none, and all runtimes are under EIP-170 (HmmMine 15,031 bytes).

Verified on Ethereum mainnet on 2026-10-13: the GenesisForwarder at 0x876c2fb3eaa91d32ef03186853bb82433b949a71 has exactly the runtime that src/GenesisForwarder.sol compiles to, with registry 0x7c9d5ee697bff5ac4f10e2e54d3f40c44e48fe23 and mineName bytes32("HmmMine") as its immutables; that registry is ProjectFactory(0xff03410d0fe5fa8f7f59f743de35e333d9857120).registry(); a recorded launch (1500) decodes with the repository's ILaunchRegistry ABI; Intake 0xa43e6f75ee006411f79ac1c84120606c2330de82 sells the action at 0.5 IMD, has callbackGas 200000 and a requests getter of the shape the adapter reads, and its runtime equals the vendored copy except for immutable slots; the swarm's live oracle chain list is exactly {1, 56, 4663, 8453, 42161} as _checkSpec allows, and toleranceBps is a valid paid-body key.

The adapter's EIP-712 encoding is pinned by five real attestations signed by the oracle signer 0x5598aa9146215bc13eb26f2c692ad1461fd32982 (test_realSwarmSignatures_recoverTheOracleSigner). The launch manifest inputs in the task (names <= 32 characters, 11 HmmMine arguments in declaration order, the action word decoding to "oracle.request@oracle-1", no zero address) are consistent with the constructors.

Not reachable or not reviewed: the IMD token's own source (an owned, non-proxy contract at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7; the mine assumes it is a plain ERC-20, which the fork rehearsal supports), the ProjectFactory and LaunchRegistry sources beyond their on-chain behaviour, the oracle writer's off-chain pairing of answers to requests, and the web front end.

No critical or high defect was found: access control, reentrancy guards, round accounting, emission bounds and signature verification hold against the Pashov checklist, and no minting, pausing, freezing, delegatecall, proxy or post-deployment initializer exists beyond bind() noted above.

HmmMine.start() (src/HmmMine.sol:288 if (genesis != 0) return;) is a silent no-op once genesis is set, and reserve/baseRate are fixed by the first call only.

GenesisForwarder.forward(n) is permissionless and unconditional: any HMM that reaches the forwarder after the first forward (a mistaken transfer, a second remainder) is transferred to the mine and then start() returns without touching reserve. emittedAt() is bounded by reserve (sum over 64 eras of baseRate*eraLength halvings <= reserve), claims and payDev draw only from assigned <= reserve, and HmmMine has no sweep, so the extra HMM is permanently unrecoverable.

The comment on line 62 says start() reverts in that case, which is the opposite of what the code does; the manifest notes already record this as an accepted limitation ("late HMM can reach the mine but remains outside its reserve and is unrecoverable"). Reported at low severity because only a holder sending HMM to the forwarder after launch loses it (self-inflicted), not a backer or the launch reserve.

Boundary: external call site forward -> mine.start(); assumption (per the comment): a second start reverts and rolls the transfer back; actual: the transfer stands and start() is a no-op.

This is documented design (NatSpec lines 24-25: "A round with no answer emits nothing; what it would have emitted rolls into the next round that gets one"), not a defect in the arithmetic: the first credit of round r assigns emittedAt(roundEnd(r)) - assigned, i.e. the integral of the halving schedule over every unanswered round since the last answered one, and the figure is exact (fuzzed by the repo's Emission tests and by the scratch test).

It is recorded here because the numbers at launch are large and the launch sequence creates the idle window: genesis is fixed when forward() runs (genesisDelay 0), and the clock runs from that second whether or not anyone asks.

With reserve 650,000,000 HMM and eraLength 15,552,000 s, baseRate = 20,897,633,101,852,315,604 wei/s; a steady 600 s round pays 11,911 HMM after the 5% dev share, while the first answered round after 30 idle days pays 51,470,244 HMM (7.9% of the reserve) to the backers of one 0.5 IMD question, and the backlog is winnable by whoever lands the first credited answer.

No funds are lost and the reserve bound holds; the requester should decide whether the forward() call and the first questions are timed accordingly.

Flow gap, execution x periphery. q.target is set once from intake.priceOf at propose (src/HmmMine.sol:331). back() only triggers _ask when raised == q.target (:731), and _ask re-reads the live price (:757) and reverts if it rose (:759). Nothing re-quotes an Open question, and refund() on an Open question is refused until block.timestamp > q.deadline (:358).

So after any price increase the completing backer's transaction reverts (gas lost), the IMD already pooled is locked for the rest of the 3-day window, and the only way forward is a fresh proposal at the new price.

In the other direction, when the price falls below what is already raised (e.g. 0.4 IMD raised of a 0.5 target, live price 0.25) the question still cannot be asked until someone adds the remaining 0.1 to reach the stale target, even though the mine already holds more than it will pay; the excess is then returned as surplus. No IMD is lost in either case and docs/DESIGN.md:44 documents the rise case, so this is a liveness / capital-lockup defect rather than a loss.

Minimal fix preserving the design: in _ask, treat a live price <= q.raised as fundable (ask as soon as raised >= live) and let back() complete when raised reaches the current live price rather than the frozen target; or allow refund() on an Open question once the live price exceeds its target.

Access x asymmetry seam. Every other state change on a question is restricted to a party with a stake in it: backing and refunds move only msg.sender's own IMD, credit/fail come only from the question's adapter, start only from the forwarder. expire() is the one exception: any address, with no stake, may terminate someone else's Asked question once answerDeadline(id) (7 days after the ask) has passed.

The Intake request itself never expires and the oracle attestation is valid for 86400 s from issuance, so a late answer is still perfectly good when a stranger closes the question. credit() then reverts NotAsked inside the Intake callback (test/HmmMine.sol credit: if (id == 0 || q.status != Status.Asked) revert NotAsked();), the Intake records the completion as not delivered and never retries, and the backers' 0.5 IMD stays spent for nothing.

The stranger has a concrete motive: a round's emission is split pro-rata among the questions credited in it, and after a dormant period the first credited round carries everything emitted since the last answered round, so a backer of another pending question profits by closing a competitor's question moments before the writer's completion lands. docs/SECURITY.md documents that anyone may expire, but the asymmetry with refund() (own backing only) and the irreversible loss for third parties make this a guard weaker than its effect.

Preconditions: the swarm's completion is more than 7 days late (an outage of the plane or writer), which is abnormal but not privileged. Minimal fix that preserves the design: restrict expire(id) to an account with backing[id][msg.sender] != 0 (or the proposer), or make the 7-day deadline advisory by letting a later valid completion still credit while only a backer may close.

Severity low: requires the >7 day delay; the loss is bounded by one question's backing and the round share it would have mined.

Merged from audit_math. forward(n) is permissionless and unconditional: it transfers the forwarder's whole HMM balance to the mine and calls start(). HmmMine.start() (src/HmmMine.sol:288 if (genesis != 0) return;) is a silent no-op once genesis is set, and reserve/baseRate are fixed by the first call. emittedAt() sums at most 64 halvings of baseRate*eraLength, which is <= reserve; claim() and payDev() draw only from assigned; HmmMine has no sweep.

So any HMM that reaches the forwarder after the first forward (a mistaken transfer to 0x876c2fb3eaa91d32ef03186853bb82433b949a71, which is a fixed, already-deployed address) is moved into the mine and permanently unrecoverable. The comment on line 62 states the opposite of what the code does.

The requester documents the stranding as a known limitation (docs/SECURITY.md) and the forwarder is already deployed, so the fix is to the mine side or the documentation: either make start() revert AlreadyStarted (which leaves late HMM in the forwarder instead, equally stuck) or correct the comment and the NatSpec of forward() so that nobody relies on a revert. Loss is limited to self-inflicted transfers after launch; the launch reserve and backers' IMD are unaffected.

Merged from audit_permissions. Every other state change on a question is restricted to a party with a stake in it (backing and refund move only msg.sender's IMD, credit/fail come only from the question's adapter, start only from the forwarder). expire(id) is callable by anyone once block.timestamp > answerDeadline[id] (ask time + 7 days) and sets the question to Failed.

The Intake request itself never expires and an attestation is valid for 86,400 s from issuance, so an answer arriving after day 7 is still good; once expire() has run, the adapter's callback calls credit(requestId), which reverts NotAsked (src/HmmMine.sol:423), the whole callback reverts, the Intake records delivered == false and never retries, and the backers' price stays spent.

A stranger has a motive: the first credit of a round after an idle stretch carries everything emitted since the last answered round, so a backer of a competing pending question gains by closing another question moments before its completion lands.

Preconditions: the swarm's completion is more than 7 days late (abnormal, not privileged). docs/SECURITY.md documents that anyone may expire; the asymmetry (no stake needed, irreversible loss for third parties) is the defect. Minimal fix preserving the design: require backing[id][msg.sender] != 0 (or msg.sender == proposer) in expire(), or let a later valid completion still credit while only a backer may close.

Merged from audit_economics. q.target is set once from intake.priceOf at proposal (src/HmmMine.sol:331). back() only calls _ask when raised == q.target (src/HmmMine.sol:731), and _ask re-reads the live price and reverts PriceRose if it rose. Nothing re-quotes an Open question, and refund() on an Open question is refused until block.timestamp > q.deadline (src/HmmMine.sol:358).

After any price rise the completing backer's transaction reverts, the IMD already pooled is locked for the rest of the 3-day window, and the only way forward is a fresh proposal. In the other direction, when the live price falls below what is already raised, the question still cannot be asked until the stale target is reached, even though the mine already holds more than it will pay; the excess is only returned afterwards as surplus.

No IMD is lost (docs/DESIGN.md documents the rise case), so this is a liveness and capital-lockup defect. Minimal fix preserving the design: in _ask treat live <= raised as fundable and let back() complete when raised reaches the live price, or allow refund() on an Open question once the live price exceeds its target.

Merged from audit_economics; recorded as a trust assumption at low severity because the no-steward design is the requester's explicit, documented decision (brief, launch.json notes, docs/SECURITY.md known limitations), not a permission bypass.

Every path that emits HMM runs through two values the launch fixes for good: the action word bytes32("oracle.request@oracle-1") priced by the Intake (read at src/HmmMine.sol:320 and :757) and the oracle signer baked immutably into SwarmOracleAdapter (src/SwarmOracleAdapter.sol:53, enforced at :187). steward is never set and only the steward can name one, so queueConfig/applyConfig are unreachable.

The oracle-consumer reference states these values are expected to move (a new action version or a moved price must not need a redeploy; the signer is owner-settable). The actor is the Intake owner (an ordinary operator action: setPrice(action, IMD, 0) when oracle-2 replaces oracle-1) or an oracle key rotation.

Outcome: propose and back revert NotSold forever, or every delivered answer is rejected bad_signature and each question's 0.5 IMD is spent for nothing; the unemitted reserve stays in the mine permanently since HMM only leaves via claim (needs Answered) or payDev.

Any mitigation (a narrowly scoped action-id rotation, or a dead-man exit for the reserve after N years without an answer) changes the agreed no-admin design and needs a scope decision; nothing in the code is wrong relative to the stated intent. Live mainnet read on 2026-10-13: Intake.priceOf(action, IMD) == 0.5e18, callbackGas == 200000.