SIMD Collision Bounties: does the swarm actually turn into verifiable compute?

Snapshot: 2026-10-05, 07:51–07:56 UTC. All live figures can change after that.

Question

SIMD (si-md.xyz/#bounties) describes this loop: "activity → IMD → agent compute → verified proof → harder problem". Agents get truncated-hash collision jobs for keccak256, sha256 and ripemd160. Each solved rung raises λ. SIMD pays in IMD, independently verifies each proof, and records what the swarm can solve.

This report checks that claim against public data and asks whether each step of the loop works today.

Answer in brief

• Agent compute and proof generation work. Completed SIMD hunt jobs published 14 distinct λ=24 (48-bit) collision pairs: 3 for keccak256, 7 for sha256 and 4 for ripemd160. I recomputed every pair independently, and all 14 are valid (verify_claims.py).
• The ladder does not advance. At the snapshot, /api/collisions shows every hash still open at λ=24 with fallenCount: 0. The ladder has recorded one claim, a rejected 0x01/0x02 test, and has paid no prizes. So "verified proof → harder problem" has never happened, and the board does not record what the swarm has actually solved.
• IMD is spent on jobs, but not on prizes. On-chain receipts show 0.5 IMD per hunt job going from SIMD's payer wallet to the Identity.md payee. Prize payout is labelled MANUAL, and SIMD's own docs call auto-payout "NOT IN FORCE" unless a worker flag is set.
• Likely cause (an inference): the hunts were opened with the skill:research-report template. That template delivers only artifacts/report.md. The rung text asks for a root-level collision.json, which never becomes a result file, so SIMD's harvester apparently never sees a solution and keeps reopening the same rung.

Facts (directly observed, with sources)

F1. The rules as SIMD publishes them

From GET /api/collisions (fetched 07:52Z) and the docs text in the site bundle /app.js?v=51, "Collision bounties" section:

• A valid collision is two distinct inputs whose digests agree on the first 2λ bits (MSB). Ladders start at λ=24, so the first rung is 48 bits, with a birthday cost of about 2^24 evaluations.
• "When a rung falls, SIMD opens λ + 1 for that hash."
• At λ > 40 the objective changes to "distinguished-point / coordinated hunt wording (Van Oorschot–Wiener style)".
• Purse: "base 1 IMD at λ=24, +0.5 every 8 λ steps, cap 20 — not doubling each step."
• "No bounty smart contract." "Verification is local recomputation." "Server recomputes both digests. False collisions are rejected and logged as claims."
• Payout: "Auto-pay of the prize requires SIMD_COLLISION_PAY=1 on the worker; otherwise status is MANUAL." The live board shows "payoutStatus": "MANUAL".
• Hunting: "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 rung objective says: "Return a JSON file named collision.json with exactly: {"algo":…,"lambda":24,"inputA":…,"inputB":…}".

F2. Ladder state: nothing has fallen

From /api/collisions at 07:52Z and again at 07:54Z:

• keccak256, sha256 and ripemd160 are all open at λ=24 with purse 1 IMD. All three were opened at 2026-10-05T05:59:34Z. fallen: [] and fallenCount: 0 for each.
• claims holds one entry: id muuuntv1-rej, keccak256, inputs 0x01/0x02, from wallet 0x9fAdAB91…f63f, which is the SIMD payer. It is rejected with the reason "truncated digests do not match". My recomputation agrees: the prefixes are 5fe7f977e71d and f2ee15ea639b.
• The treasury block shows huntsToday = 53 at 07:52Z and 59 at 07:54Z, against dailyHuntCap: 3, with huntsEnabled: true.

F3. The swarm was hired many times, and the jobs completed

GET /api/hire/sent proxies Identity.md GET /requests/paid-by/:payer. It reports count: 100 orders for the payer and shows the latest 20.

• 18 of those 20 are [SIMD-COLLISION:…:24] hunts paid between 07:22:39Z and 07:29:41Z: 4 keccak256, 7 sha256 and 7 ripemd160. All 18 are completed.
• One is a [SIMD-BURST-REVIEW] job, c0ad6502. The last is this research job, e79d2bd3.
• All use the template skill:research-report.
• No new hunt order appeared between 07:29:41Z and 07:54Z.

For each hunt, GET /api/jobs/:id lists exactly one result file, artifacts/report.md. None lists collision.json.

Keccak256 hunts overlapped in time. For example, fd47877e was created at 07:26:43Z and last updated at 07:34:47Z, and e1a7785b was created at 07:27:38Z, while the first was still open. Today's treasury note says "Max one live job per algo@λ". That note may have been added after these opens. I cannot tell from public data.

F4. The published collisions are real

I transcribed every input pair from the 18 hunt reports, plus three more pairs cited by the burst-review job c0ad6502. That gives 14 distinct pairs. I recomputed them with verify_claims.py, which uses only the Python standard library:

• Keccak-256 is implemented in pure Python with original Keccak padding 0x01.
• SHA-256 comes from hashlib.
• RIPEMD-160 comes from hashlib, with a pure-Python fallback.
• Known-answer tests pass for "" and "abc".
• Inputs starting with 0x are hex-decoded. All other inputs are hashed as UTF-8, following the rung text.

Hash	Input A	Input B	Shared 48-bit prefix	Reported by job(s)
keccak256	0x8375360100000000	0x7131040200000000	8851a59bbb9d	1b4443a8, e1a7785b, fd47877e
keccak256	0xee62600000000000	0xbef60b0300000000	3fc82665f648	98298bb0
keccak256	imd-9804673	imd-17368822	2f72fe059bc2	3153457a (cited in c0ad6502)
sha256	batch01-0020d0aa	batch01-007d3814	fe089d28eb53	a95069aa
sha256	simd-sha256-48-15157794	simd-sha256-48-29860063	5902bd0bf52c	9dfb975b
sha256	identitymd-sha256-48:2529407	identitymd-sha256-48:14013952	982915e7a9c2	8835e1bf
sha256	0x000000000017211c	0x00000000014060cc	4e84dca19fa6	e1c2c05f, 7edcf4d7
sha256	0x4964…0000312972 (29 B)	0x4964…00019532c6 (29 B)	3dd9cd223c0f	2b5e2536
sha256	simd-sha256-48:35564992	simd-sha256-48:55746276	0b196da85087	963b3226
sha256	simd-2ed1119e4b80	simd-0170dc5eabd6	1470dfedd885	6545430a
ripemd160	imd-70e373fa6b0c	imd-4a68f5e58b32	6754b6bedcc2	1885e5d3
ripemd160	0x19bef10000000000	0x1022730100000000	902e5fc86be4	76482d02, 097da9a7, f36067b4, b51e1021
ripemd160	0x000000000162a52d	0x0000000000de27bb	18573a938b62	6952d0ab, 91b4ac35
ripemd160	simd-collision-1jib8	simd-collision-8p144	ce8e452df3e3	6f3adb04

Result: 14 of 14 are VALID, and the ladder's own rejected claim is correctly INVALID. Job pages are at https://explorer.imd.fun/jobs/<id> and https://www.si-md.xyz/api/jobs/<id>.

Some agents found the same pair independently, for example three keccak jobs and four ripemd jobs. They seem to have used similar deterministic counter searches, so a lot of the paid compute repeated identical work.

F5. The IMD payments are on-chain

I read Ethereum mainnet through the public RPC ethereum-rpc.publicnode.com.

• Receipts for hunt 1b4443a8 (tx 0xb687af07…74f35ef, block 26124679) and for this job (tx 0x091e8f6a…2524f5, block 26124783) both show status 1.
• Each contains a Transfer of exactly 0.5 IMD (raw value 5×10^17, 18 decimals) from 0x9fad…f63f (the SIMD payer) to 0x4e0f…adbc.
• The token at 0xd34a99bc…63b7 reports symbol IMD. It matches the IMD constant in the site bundle. The 0xbb0c…3415 address shown as "CA" is the separate $SIMD token.
• balanceOf at the latest block: vault 0xd604…9B21 holds 1018.146 IMD, which matches the API's vaultBalance, and the payer holds 74.75 IMD.

F6. Identity.md delivery model

The IMD API docs say job.open costs 0.5 IMD, paid via x402 and Permit2. They also say named outputs "specify path (under artifacts/) … the job must produce exactly these files", and that GET /jobs/:id/result returns the delivered files.

Inferences (reasoned, not directly observed)

• I1. The harvest step is the broken link. The rungs ask for collision.json. The jobs were opened with a report template whose only delivered file is artifacts/report.md (F3, F6). The worker is documented to "poll job results, verify digests locally, record the fall" (F1), and no fall was ever recorded even though 14 valid pairs exist (F2, F4). The simplest explanation is that the worker looks for collision.json among the result files and never finds it. The burst-review job c0ad6502 reached the same conclusion independently. That job is an agent's analysis, not an operator statement.
• I2. The loop spent IMD for no ladder progress. At least 18 visible hunts cost 9 IMD. c0ad6502 reported about 97 hunt opens between 06:38Z and 07:22Z, which I did not re-count. One valid pair per hash was enough to move λ to 25.
• I3. huntsToday probably counts something other than paid opens. It rose from 53 to 59 within two minutes while no new paid order appeared (F2, F3). It may count worker attempts that a lock or guard blocked.
• I4. Current rungs are cheap, so they say little about swarm capability. 2^24 evaluations takes seconds to about a minute on one CPU core. Agent reports quote 15–77 seconds. Each +1 in λ doubles the expected work. Coordination becomes necessary only far up the ladder, at λ > 40 by SIMD's own threshold, meaning 2^40 or more evaluations. At the current pace of progress (zero rungs), that is not close.
• I5. "Independently verifies" holds for submissions but not for payouts. Recomputing a hash is cheap and trustless: anyone can do it, as this report did. But no bounty contract exists, payouts are manual, and the ladder's rule is "first valid submission by arrival time" on a Supabase database. Who wins, and whether they get paid, depends on trusting the operator.

Uncertainty

• I did not see the worker source (collision:worker). I1 rests on the published files, the docs and the observed behaviour.
• The paid-by proxy shows only the latest 20 of 100 orders. I did not enumerate older orders or count total IMD spent on hunts.
• I checked two payment receipts on-chain, not all of them.
• How SIMD's server decodes inputs is documented only as "hex 0x… or utf8". Some pairs use UTF-8 strings and some use hex. I assumed the documented rule. A server that, for example, trims or normalises strings could judge some UTF-8 pairs differently.
• The 3 pairs cited only by c0ad6502 (job ids 3153457a, 7edcf4d7, b51e1021) were not fetched directly. I verified their maths, not the attribution.
• The state may have changed after 07:56Z.

Unanswered questions

1. Will the operator fix harvesting, for example by using a named output artifacts/collision.json or by parsing the report, and then submit the existing pairs so the λ=24 rungs fall?
2. Who wins a rung when many agents solved it before anyone submitted? The ladder awards by arrival time, and job results carry no submitting wallet.
3. Will prizes be paid automatically (SIMD_COLLISION_PAY=1) or by hand, and from which wallet? No payout tx exists yet to check.
4. What does huntsToday count, and is dailyHuntCap enforced on the worker path?
5. Will the λ > 40 distinguished-point mode actually coordinate across agents (shared point store, work split), or will it open independent jobs?

Method

1. Fetched the SIMD homepage, the JS bundle and the public APIs /api/collisions, /api/hire/sent, /api/hire/latest?burst=1 and /api/jobs/:id with curl, between 07:51Z and 07:54Z.
2. Read all 18 hunt-job reports and the burst-review report, treating them as data.
3. Recomputed every claimed pair with tools/verify_claims.py.
4. Read two transaction receipts, token metadata and balances through public Ethereum JSON-RPC.
5. Read the IMD docs.

I submitted nothing to SIMD's POST endpoint. Doing so would claim a bounty, which is outside this research task.