Both payout paths are push transfers to a fixed recipient: a flat verdict pays v.missTo (line 225), a ship pays v.builder (line 221), and expire pays v.missTo (line 237). USDC/USDT-class tokens, likely choices for a vesting vault, can blocklist an address after the vault is funded.

For a refund vault whose funder is blocklisted, every flat verdict reverts and expire reverts forever, so the vault can neither close nor pay out its remainder: the tokens sit in the contract permanently. A blocklisted builder has the mirror problem: no ship can ever settle, only misses, and at the deadline everything goes to missTo. Accepted item (4) covers fee-on-transfer, rebasing and tokens that block 0xdEaD, not a blocklisted builder or funder.

Impact falls on the party whose own address is blocked, so this is reported as low. A pull-based claim (record owed amounts, let the recipient withdraw) would remove the lock, but that is an ABI change the owner has ruled out; at minimum the web app should warn that blocklist tokens are unsupported.

Read in full: src/ShipOrBurn.sol (every external and public function: createVault, linkSchedule, settle, expire, questionHash, attestationDigest, getVault, vaultCount, nextVerdictBlock, and _checkPrefix), src/ShipOrBurnIMD.sol, test/ShipOrBurn.t.sol, test/ShipOrBurnIMD.t.sol, test/GoldenVectors.t.sol, script/Deploy.s.sol, and the vendored OpenZeppelin v5.4.0 files the contract imports (ECDSA, EIP712, SafeERC20, ReentrancyGuard, Strings). No contract was out of reach.

Checked and found clean: no DELEGATECALL, CALLCODE, SELFDESTRUCT, proxy, initializer, owner, pause, mint or post-deployment configuration; constructor makes no external calls; ECDSA.recover rejects high-s and zero recoveries; EIP-712 domain, typehash and struct match the protocol reference and the real-signature golden vectors; questionHash matches a real IMD request; replay within a vault is blocked by the spacing rule, across contracts by verifyingContract, across chains by the domain and a.chainId; createVault is balance-checked and nonReentrant; tranchetranches cannot overflow; settled never exceeds tranches so expire's subtraction cannot underflow; conservation (builder + missTo + contract balance = tranchetranches) holds in the existing fuzz test.

Checks that could not be performed offline: whether IMD accepts a block window whose toBlock is beyond the chain head (it would remove the lag precondition of the high finding), and how IMD's panel resolves 'agreed' for large panelSize with a small quorum. forge test: 25 passed, 0 failed, unchanged.

Economic Security / Invariant. Verdict k cannot be counted before toBlock >= startBlock + k6000 (baseline >= startBlock, then MIN_SPACING per verdict, lines 207/214), so the last verdict is settleable no earlier than creation + tranches6000 blocks. The guard assumes 6000 blocks == 20h, i.e. exactly 12.0 s/block.

Mainnet's average is slightly above 12 s (missed slots), so the real time for K verdicts is K6000bt and the single spare 20h in the guard is exhausted once K6000(bt-12) > 72000 s, i.e. K > 12/(bt-12): at 12.1 s/block K >= 121, at 12.05 s K >= 241. Beyond that, the final verdict(s) revert PastDeadline (line 182) no matter how early every verdict is taken, and expire() (lines 241-242) sends those tranches to missTo.

In a refund vault the funder, who chose both tranches and the minimum deadline, is the beneficiary; the builder loses tranches without a single flat window. The contract comment on line 135 ('the baseline plus one verdict per tranche, each at least MIN_SPACING blocks (20h+) apart') claims the guard covers this.

Related to accepted item (5) (12-second blocks); reported because the accepted assumption is a lower bound on mainnet, not the average, and the loss lands on the builder. Minimal fix without changing the ABI: reserve slack proportional to tranches (e.g. 21 hours per verdict, or require deadline >= now + (tranches+1)MIN_SPACING12.5 s), or document that funders must add margin.

Economic Security / Flow Gap (execution x periphery x first principles). The production question answers 'the count at the moment you retrieve it' (window is context only), so the number in an attestation is read when IMD processes the request, which is any time between block toBlock (its blockHash must exist) and the settle block, i.e. anywhere in [toBlock, toBlock+600]. Spacing (line 214) is enforced on toBlock only.

Verdict k can therefore be requested and settled at toBlock_k+600 (count read ~600 blocks after toBlock_k) while verdict k+1 is requested and settled at toBlock_k+6000 exactly (count read at that block). The two reads are 5,400 blocks apart although both attestations are 6,000 blocks apart on-chain. The stated rule (accepted item 1) is that a builder must ship once per MIN_SPACING window of 6,000 blocks; the enforceable window is 5,400 blocks.

A refund-vault funder who settles verdict k late and verdict k+1 at the first eligible block captures one tranche from a builder merging on a steady 18h<cadence<=20h. Cost to the funder: two oracle requests (1 IMD) for 1 tranche; repeatable every other verdict against a builder who keeps a 20h cadence.

Mitigation that keeps the ABI: measure spacing from the block the previous verdict was settled in (store block.number instead of a.toBlock for spacing), or state the 18h effective window in the builder-facing docs.

Economic Security ('break dependencies'). The contract trusts the oracle answer as a monotone counter, but the production question is answered from GitHub's search API total_count, which can over-count transiently (index lag, incomplete_results) even with 4-of-5 panel agreement when all agents query the same endpoint.

There is no way to recover from one high answer: every honest attestation below lastCount reverts, so no verdict can be counted at all until the real count reaches lastCount, and the attestation that first reaches it reads count == lastCount and is charged as a miss even though the builder merged (lastCount - realCount) pull requests to get there. If the live count never catches up before the deadline the whole remainder expires to missTo.

This is a dependency-failure mode, not a bug in the signature or ordering logic; it is reported so the author can decide whether a lower count should be treated as 'flat' (not revert) or whether vault docs should state that one bad panel answer can forfeit the rest of the vault.

Seam: boundary (600-block freshness allowance) x invariant (windows do not overlap). The spacing rule at line 214 (a.toBlock < v.lastToBlock + MIN_SPACING) is measured on the attestation's toBlock, but the count IMD signs is the live count at retrieval, which the vault's question defines as 'the count at the moment you retrieve it' with the window as context only. Line 203 accepts any attestation whose toBlock is up to 600 blocks in the past.

A settler can therefore request a window ending at block T while the panel reads the counter at T+590, and the contract stores lastToBlock = T. The next verdict may use toBlock T+6000, read at T+6000. Two consecutive counted reads are then 5,410 blocks apart (about 18 hours), not the 6,000 blocks (20 hours) the rule states, and a merge that happened at T+300, inside the next window [T, T+6000), is absorbed into verdict k instead of counting for verdict k+1.

The slack is symmetric: a settler who favours the builder can name toBlock T for a read at T+590 that includes a merge at T+500, which was outside window [T-6000, T), and get it paid. In a refund vault the funder is paid for the manufactured flat verdict, so this is an economic incentive, not just a griefing path.

Both parties can close the race by settling promptly at each window end, which is why this is rated low and not medium: the prior accepted fix (the 600-block bound) shrank an unbounded version of this problem to a 600-block one but did not remove it.

A minimal ABI-preserving mitigation is to measure spacing from the settlement block (store uint64(block.number) in lastToBlock, or require a.toBlock >= v.lastToBlock + MIN_SPACING + (settleBlock_k - toBlock_k)), or to shrink the lag to what delivery actually needs (IMD answers in minutes, about 10 to 30 blocks). The 'Accepted by the owner (1)' note says the rule is 'at least MIN_SPACING after the last counted one', which this interval violates by up to 10%.

Seam: boundary (minimum deadline) x precision (block time). The floor converts MIN_SPACING = 6,000 blocks to 20 hours at exactly 12 s per block and allows one spare spacing. Verdict k needs toBlock >= startBlock + 6000k and must be settled at block.timestamp <= deadline, so all N verdicts fit only if 6000 * N * b <= (N+1) * 72000 s, i.e. b <= 12 * (N+1)/N seconds per block.

Mainnet's post-merge average is about 12.05 to 12.1 s because of missed slots, so the floor passes vaults whose last tranche cannot be settled whenever N >= 12/(b-12): about 120 tranches at 12.1 s, 240 at 12.05 s.

For N = 200 at b = 12.1 s the 200th verdict's toBlock is reached at 200 * 6000 * 12.1 = 14,520,000 s after creation, but the minimum deadline is 201 * 72000 = 14,472,000 s, so verdict 200 cannot be settled and expire() sends that tranche to missTo although the builder shipped every window.

The funder chooses the deadline and the owner accepted that MIN_SPACING assumes 12-second blocks, so this is low: the defect is that the floor gives a false guarantee for large tranche counts (and for any longer chain-wide slowdown).

Mitigation: size the floor with a margin per tranche (for example 6,000 blocks * 13 s, or (tranches + 1) * 20 hours + tranches * 1 hour), or document that funders must leave more than the floor for long vaults.

MIN_SPACING is enforced on the attestations' toBlock values (line 214: if (a.toBlock < v.lastToBlock + MIN_SPACING) revert TooSoon();), but the question is answered with the counter's value at retrieval, not at toBlock, and the freshness rule at line 203 lets a window be settled up to 600 blocks after it ends.

A requester who pins an explicit window whose toBlock is 599 blocks in the past has IMD read the count ~600 blocks after toBlock; the next verdict can then name toBlock = previous toBlock + 6,000 and be read at that block. The two counts are therefore read 5,400 blocks (~18 h) apart while the contract treats them as 6,000 blocks apart.

A builder who relies on the stated ~20 h per window and merges 18-20 h after the last count can be charged a flat tranche for that window (the merge is counted next window, so one tranche moves from builder to missTo). The compression is at most 600 blocks and is not cumulative (alternating backdated and fresh windows averages 6,000), so impact is bounded to one tranche per such alignment.

Fix without ABI change: when a vault has a baseline, also require the settlement block to be at least MIN_SPACING after the block at which the previous attestation was settled (store it in the unused slack of the Vault struct), or document the 18 h effective minimum for builders.

The signed issuedAt field is not compared with anything (the canonical OracleAttestationConsumer rejects issuedAt more than 5 minutes ahead of block.timestamp). The 600-block freshness check only bounds how long after toBlock a window is settled; nothing bounds how long before toBlock the count was read.

If IMD ever signed an explicit window whose toBlock is ahead of the chain head at request time, a requester could pre-buy a series of attestations (toBlock = T, T+6000, T+12000..., all carrying today's count, expiresAt up to 30 days) and settle each in the first block its toBlock becomes current, producing a flat verdict for every window even though the builder merged in each, and winning every race against a builder whose fresh attestation needs panel time.

The real version-2 vector (test/GoldenVectors.t.sol) carries a non-zero blockHash of toBlock, which indicates IMD resolves the window against existing blocks and so does not sign a future toBlock; I could not verify the live intake's validation offline, so this is recorded as an unverified assumption rather than a defect.

If the author wants a contract-side bound that keeps the ABI, requiring issuedAt to be no earlier than block.timestamp - (block.number - toBlock) * 12 - tolerance would reject counts read before the window ended.

Trust-gap (access x asymmetry). settle() is permissionless and the settler picks the attestation (accepted rule 1). The rule that makes this safe is 'a builder must ship within every spacing window', which holds only if the count IMD signs was read at or after the window's toBlock.

The contract proves nothing about that: it bounds toBlock against block.number at settlement, ignores a.issuedAt (the time the panel actually read GitHub) and ignores a.blockHash (the sealed hash of toBlock). The canonical OracleAttestationConsumer at least rejects issuedAt more than 5 minutes in the future; this contract accepts any issuedAt, including one hours before toBlock was mined.

Consequence if IMD will sign an explicit {fromBlock,toBlock} window whose toBlock is still in the future: a refund-vault funder requests such a window while the count is flat, holds the signature (validForSeconds up to 30 days), lets the builder merge inside the window, and at toBlock submits the pre-signed flat attestation. The tranche is refunded to the funder although the builder shipped within the window.

Evidence gathered: both real IMD vectors carry the true mainnet hash of their toBlock (block 26122901 hash 0x22cd78...3059 verified against a public RPC; block 26086885 likewise), and the v2 vector was issued ~70 hours after its toBlock, so IMD resolves a sealed block when it signs and this attack is most likely not reachable against today's service. It is therefore reported as a trust assumption with a cheap on-chain defense, not as a reproduced loss.

Defense that keeps the ABI, constants and typehash: require a.issuedAt <= block.timestamp + 5 minutes and a.issuedAt >= block.timestamp - 2 hours (so the read is as fresh as the window), and/or require blockhash(a.toBlock) == a.blockHash when a.toBlock is within 256 blocks, which proves the signer observed the closed window. The second would tighten keeper timing from 600 to 256 blocks, so it is a design decision for the owner.

Trust-gap. The question hash covers answerType, chainId, definitions, evidence, question, v and window, but not panelSize or quorum, so whoever pays for the request (the funder, the builder or a third party, all of whom may settle) chooses them. The check accepts quorum as low as 4 with any panelSize up to 300, i.e. an answer that only 4 seats of 300 agreed on.

With panel evidence IMD signs the answer that first reaches quorum; the GitHub search total_count is eventually consistent and panelists may split between adjacent values, so a party wanting a particular verdict can re-request with a tiny quorum and a large panel until the minority value is signed. Whether IMD's panel actually settles that way could not be tested here, so no loss is claimed.

A requester-independent floor such as requiring a.quorum * 2 > a.panelSize (no constant or ABI change) would close the gap if the owner wants it.

Merged from audit_flow, audit_economics and audit_math (same root cause). MIN_SPACING is enforced at line 214 on a.toBlock, but the production question answers the live counter at retrieval, and line 203 lets a window be settled up to 600 blocks after it ends. Verdict k can therefore name toBlock T while IMD reads the counter at ~T+600, and verdict k+1 can name toBlock T+6000 and be read at T+6000.

The contract treats the two reads as 6,000 blocks apart when they were 5,400 apart. A builder keeping the stated 20 h cadence can be charged one flat tranche (refund vault: paid to the funder, who controls when to settle). The mirror case lets a settler count a merge made up to 600 blocks after toBlock for the earlier window.

The compression is bounded to 600 blocks and is not cumulative, hence low. The contract cannot observe the read time, so this is a documented gap between the stated rule (accepted item 1: at least MIN_SPACING between counted verdicts) and what the on-chain check enforces.

ABI-preserving options: measure spacing from the settlement block (store uint64(block.number) in lastToBlock), require a.toBlock >= v.lastToBlock + MIN_SPACING + (settleBlock_k - toBlock_k), shrink the 600-block grace to what delivery needs, or state an 18 h effective window in builder-facing docs.

Merged from audit_economics and audit_math (same root cause). Verdict k cannot be counted before toBlock >= startBlock + k6000 (lines 207 and 214), so all N verdicts need N6000 blocks, and the floor reserves (N+1)20 h, i.e. one spare 20 h window at exactly 12 s/block. Mainnet averages slightly above 12 s (missed slots), so the spare window is exhausted once N6000*(bt-12) > 72,000 s: N >= 121 at 12.1 s, N >= 241 at 12.05 s.

Beyond that settle reverts PastDeadline (line 182) for the final verdict(s) even if every verdict was taken at the first eligible block, and expire (lines 241-242) sends those tranches to missTo. The comment on line 135 claims the floor covers the baseline plus one verdict per tranche, which is false for large N. The funder picks tranches and deadline and the owner accepted the 12 s assumption, so low; the loss lands on the builder in a refund vault.

Options that keep the ABI: reserve per-tranche margin (e.g. 21 hours per verdict, or 6,000 blocks * 13 s), or document that funders must leave margin above the floor for long vaults.

Merged from audit_flow and audit_permissions (same root cause). settle() bounds toBlock against block.number at settlement (lines 202-203) but reads neither a.issuedAt (the canonical OracleAttestationConsumer at least rejects issuedAt more than 5 minutes ahead of block.timestamp) nor a.blockHash.

If IMD ever signed an explicit {fromBlock,toBlock} window whose toBlock was still in the future at request time, a refund-vault funder could pre-buy a flat attestation while the count is flat and submit it at toBlock after the builder merged, taking the tranche.

Evidence against reachability today: the oracle-consumer reference says the questionHash covers 'the resolved block window', both real IMD vectors carry the true hash of their toBlock, and the v2 vector was issued ~70 h after its toBlock, so IMD resolves a sealed block when it signs. Recorded as a trust assumption, not a reproduced loss.

ABI-preserving hardening if wanted: require a.issuedAt <= block.timestamp + 5 minutes and a.issuedAt >= (a lower bound tied to toBlock), and/or require blockhash(a.toBlock) == a.blockHash when toBlock is within 256 blocks (this would tighten the keeper window from 600 to 256 blocks, a design decision).