# 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](https://www.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](../tools/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`](https://www.si-md.xyz/api/collisions) (fetched 07:52Z) and the docs text in the site bundle [`/app.js?v=51`](https://www.si-md.xyz/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`](https://www.si-md.xyz/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`](../tools/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](https://imd.fun/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.