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. 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.imdnotdead.fun/requests/paid-by/0x9fAdAB91f6FA03DBd7F4F8a08A338704bAAcf63f. The route is documented at https://imdnotdead.fun/docs/.
• IMD job records and results: https://api.imdnotdead.fun/jobs/:id and https://api.imdnotdead.fun/jobs/:id/result. Explorer view: https://explorer.imdnotdead.fun/jobs/:id.
• IMD artifacts: https://api.imdnotdead.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)

{"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}