# SIMD payer burst review: 0x9fAdAB91f6FA03DBd7F4F8a08A338704bAAcf63f

**Verdict: KEEP_LOCK. Intent: bug (operator-side collision-worker retry loop). Recommended opens: 0 per 10 min until fixed. After the fix, at most 3 per 10 min (one per open rung).**

The burst is not spam and not an organic contest burst. SIMD's own collision worker keeps paying for hunt jobs on three λ=24 rungs. Agents already solve these rungs, but the worker never harvests the solutions, so the rungs never close.

Machine-readable verdict: [`../burst-review.json`](../burst-review.json). The JSON is copied at the end of this report, because this job's result delivery may drop non-`artifacts/` files. That is the same defect described below.

## Sources (all public GET reads, fetched 2026-10-05 ~07:22–07:24Z)

- IMD paid-by list: `https://api.imd.fun/requests/paid-by/0x9fAdAB91f6FA03DBd7F4F8a08A338704bAAcf63f`. The route is documented at <https://imd.fun/docs/>.
- IMD job records and results: `https://api.imd.fun/jobs/:id` and `https://api.imd.fun/jobs/:id/result`. Explorer view: `https://explorer.imd.fun/jobs/:id`.
- IMD artifacts: `https://api.imd.fun/artifacts/:hash`.
- SIMD collision ladder: `https://www.si-md.xyz/api/collisions`. SIMD docs text is in `https://www.si-md.xyz/app.js?v=48`.

## Facts (directly observed)

1. **Volume.** The paid-by list returned 100 orders, from 06:38:11Z to 07:22:11Z. All are `job.open`: 98 admitted and 2 payment_pending.
2. **Objectives.** I fetched the job record for each admitted order and grouped them by objective tag:

   | Tag | Jobs |
   |---|---|
   | `[SIMD-COLLISION:sha256:24]` | 35 |
   | `[SIMD-COLLISION:keccak256:24]` | 32 |
   | `[SIMD-COLLISION:ripemd160:24]` | 30 |
   | `[SIMD-BURST-REVIEW]` (this job, `c0ad6502-6d24-42a3-be5b-edc0dd079de8`) | 1 |
   | `SIMD-CONTEST` / free-form Hire | 0 |

   Every hunt objective is the verbatim rung text served by `/api/collisions`, and every one asks for `collision.json`.
3. **Cadence.** The orders follow a fixed per-minute rhythm: keccak256 at about :59s, sha256 at about :11s and ripemd160 at about :23s. For example, at 07:05 the orders are `3b11c8bc` (07:05:59Z), `2a0c4011` (07:05:11Z) and `4f76b33a` (07:05:23Z). There were 30 opens in 07:03–07:13Z and 14 in 07:11:20–07:21:20Z. The second count matches the lock's figure of 15 within the boundary of the window.
4. **Task samples resolve to these jobs.** Sample 3, order `43115ecb`, maps to job `a0535ae6` (ripemd160). Sample 4, `44c7ed2b`, maps to `3f781438` (sha256). Sample 15, `a0504841`, maps to `7c6933a9` (keccak256). Samples 1 and 2 (`7dcfc846`, `aa0f3469`) were pending when the task was written and later became jobs `31574aaf` (ripemd160) and `f6528c06` (sha256).
5. **The rungs are being solved.** 85 hunt jobs are `completed`. I recomputed two of the published answers locally with Python `hashlib`:
   - Job `b51e1021-444c-4e11-8f95-e90d3cf80a7e` (ripemd160) gives inputs `0x19bef10000000000` and `0x1022730100000000`. Both have the 48-bit prefix `902e5fc86be4`. **Verified.**
   - Job `7edcf4d7-f6f1-4e0c-a5b0-7290c311e156` (sha256) gives inputs `0x000000000017211c` and `0x00000000014060cc`. Both have the prefix `4e84dca19fa6`. **Verified.**
   - Job `3153457a-baad-4acd-8753-de109ba0d66d` (keccak256) reports `imd-9804673` and `imd-17368822`, with prefix `2f72fe059bc2`. **I did not recompute this one.** No Keccak-256 library was available here.
6. **The solutions never reach the result.** For all 85 completed hunt jobs, `GET /jobs/:id/result` lists exactly one file, `artifacts/report.md`, and the job template is `skill:research-report`. `collision.json` is mentioned inside the reports but is never a delivered file.
7. **The ladder never advances.** `/api/collisions` shows keccak256, sha256 and ripemd160 all `open` at λ=24 since 05:59:34Z, with `fallenCount: 0`. The only claim is `muuuntv1-rej`, an input pair `0x01`/`0x02` from the payer wallet, which was rejected. The treasury section shows `huntsToday: 8` against `dailyHuntCap: 20`, while about 97 hunt jobs were opened in 44 minutes.
8. **The freeze does not stop the opener.** A re-fetch at about 07:24Z showed 6 more orders after this review was opened at 07:21:18Z: `6f470351`, `fc99055c`, `47c2120c`, `b37fcc8d`, `a30d2270` and `b8a5727a`. The ones resolved so far are again SIMD-COLLISION hunts (jobs `963b3226` sha256, `91b4ac35` ripemd160, `2b5e2536` sha256).
9. **SIMD's own docs** describe the flow this way: "A local collision worker (`npm run collision:worker`) opens paid IMD jobs whose objective is the open rung text… Worker polls job results, verifies digests locally, records the fall on Supabase, opens the next λ." Each `job.open` costs 0.5 IMD, and the docs warn: "Rapid burst opens can drain the payer before refunds land."

## Inferences

- **This is classification (a), a bug or retry loop.** The worker's harvest step looks for a `collision.json` that the `skill:research-report` delivery never publishes. Every hunt therefore reads as "no result", the rung stays open, and the worker opens another job for it. This is consistent with facts 5–9.
- **It is not (c), malicious spam.** Every opener objective is SIMD-generated rung text. The payer is SIMD's own wallet. The opens are machine-regular, and the only external effect is SIMD spending its own IMD.
- **It is not (b), a legitimate hunt burst, in any useful sense.** A λ=24 rung needs only one valid solution, and solutions already exist (fact 5). About 97 further opens add nothing.
- **The hunt cap is likely not counting these opens** (8 counted against at least 97 observed). It may be broken, or it may count something else.
- **The lock covers the Hire path but not the worker** (fact 8). If the worker is not stopped separately, the lock alone does not stop the spend.

## Recommendation

**KEEP_LOCK** for the collision worker. The recommended rate is 0 opens per 10 minutes until all of the following are done:

1. Stop `collision:worker`. The Hire lock alone does not stop it.
2. Fix harvesting. Either parse the collision from `artifacts/report.md`, or open hunts with a template or named output that delivers `collision.json`. Then submit the existing verified pairs (fact 5) through `POST /api/collisions` so the λ=24 rungs fall.
3. Make the worker skip any rung that already has an `executing` hunt job, and count every open against `dailyHuntCap`.

After the fix, allow at most **1 in-flight job per rung, which is no more than 3 opens per 10 minutes**.

## Uncertainty and unanswered questions

- I did not inspect the worker source. "The harvest expects `collision.json`" is an inference from the published files and docs.
- I did not check the keccak256 pair (fact 5).
- I did not read the payer's IMD balance or on-chain tx receipts. Per the task, no balances are claimed here.
- I cannot see whether the 2 orders that were `payment_pending` at fetch time were settled.
- I did not check whether the `0x01`/`0x02` claim was a manual test.
- `huntsToday` may use a different day boundary or definition than this window, and I cannot confirm that it is broken.

## burst-review.json (copy)

```json
{"verdict":"KEEP_LOCK","intent":"bug","summary":"Operator-side retry loop in the SIMD collision worker, not spam and not an organic contest burst. Hunt jobs for three λ=24 rungs (keccak256/sha256/ripemd160) open about 3 per minute. Agents solve them, but results publish only artifacts/report.md and never collision.json, so the rungs never fall (fallenCount 0) and are reopened at 0.5 IMD each. Opens continued after the freeze. Keep the lock and stop the worker until harvesting is fixed; after that, at most 1 open job per rung (3 per 10 min).","evidence":["paid-by: 100 job.open orders 06:38-07:22Z","tags: sha256:24 x35, keccak256:24 x32, ripemd160:24 x30, BURST-REVIEW x1","85 completed hunts deliver only artifacts/report.md","jobs b51e1021 and 7edcf4d7: collisions verified locally","/api/collisions: fallenCount 0, huntsToday 8 vs about 97 opens","6 more opens 07:21:59-07:24:12Z after the lock"],"recommendedOpensPer10m":0}
```