# Hard grade: "Does SIMD broaden $IMD demand or recycle it?" (@0xDropxtor)

- Tweet: https://x.com/0xdropxtor/status/2107415171983405076. The snowflake ID decodes to **2026-10-06 10:18 UTC**.
- Graded: 2026-10-06, about 10:30–11:30 UTC.
- Verdict: **quality 6/10, not pay-grade.** The numbers are dense, honest and mostly verifiable, and there is one real finding (the 5000 bps refund versus the dashboard's "100%"). But the thread never answers its own question. Its comparison bands are too wide to tell anything apart. Its falsifiable test is set just below the current pace, so it barely tests anything. It also leaves out the mechanism that decides "broaden vs recycle": where the vault's IMD comes from.

---

## 1. What I checked, and how

| Source | What it gave |
|---|---|
| `GET https://api.imd.fun/requests/capabilities` | Price per action, payTo address, IMD token address |
| `GET https://api.imd.fun/requests/paid-by/0x9fAdAB91…f63f` | The SIMD payer's last 100 orders |
| `GET https://api.imd.fun/jobs/<id>` (99 jobs) | The objective text of every job in that order list |
| `eth_call` via `cast` (publicnode RPC) | Vault `refundBps()`; every no-argument view on the vault; IMD `balanceOf`; POOL4 hook `owner()` |
| `eth_getLogs` via drpc.org (100-block pages) | IMD `Transfer` events into the payTo, blocks 26,120,258–26,132,686 (launch to tweet). 62.2% of blocks fetched; the free tier rate-limited 47 of 125 pages. |

I did **not** have Etherscan's UI or API, the SIMD dashboard, POOL4 trim or burn logs, or the payTo's outbound transfers. Claims that depend on those are marked *unverified* below.

## 2. Claim-by-claim audit

### Facts I re-derived from primary sources

| # | Thread claim | Finding | Status |
|---|---|---|---|
| 1 | 0.5 IMD per paid action | All 7 actions in `/requests/capabilities` show `amount = 500000000000000000` (0.5 × 10¹⁸) to payTo `0x4e0f…dbc`, asset `0xd34a…b7`. Paid through x402 with Permit2. | **Confirmed** |
| 3 | Vault `refundBps() = 5000` | `cast call 0xd604…9B21 "refundBps()"` returns `5000`. | **Confirmed** |
| 3 | 447 refunds, 136.75 IMD returned | Two unlabeled vault getters return exactly `0x1bf` = **447** (selector `0x0bda4dbf`) and **136.75e18** (selector `0xd9082962`). | **Confirmed numerically.** The getter names are not resolved, but exact matches on both numbers are strong evidence. |
| 2 | 0x047f owns the POOL4 hook | `cast call 0xc6c9…2840 "owner()"` returns `0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7`. | **Confirmed** |
| 2 | payTo holds 36 IMD | `balanceOf(payTo)` returned **40 IMD** about 10 minutes after the tweet. That is 8 more 0.5-IMD payments, which fits the observed rate. | **Consistent** |
| 4 | "55 of the payer's last 100 orders grade SIMD's own thesis contest" | When I fetched it, the list had 99 jobs. **56** carried the `[SIMD-THESIS]` tag, plus 11 `[SIMD-COLLISION…]`, 7 `[SIMD-EXPERIMENTAL]` and 6 `[SIMD-CONTEST…]`. That makes **80/99 SIMD-program jobs**. One of the 56 is *this grading job* (`6b6aaf32…`, order `6efcaa11…`, paid 10:27:48 UTC). | **Confirmed, and understated.** The self-referential share is about 80%, not 55%. |
| 4 | SIMD payer is 56.5% of actions since launch | My 62%-coverage sample: **192 of 322** payTo inbound transfers (59.6%) came from `0x9fad…f63f`. | **Consistent** with sampling error |
| 5 | 197 non-SIMD payments; pace 795 per week | 197 / 41.6 h × 168 h = **795.6**. The arithmetic is right. That implies about 453 paid actions in total, of which about 256 are SIMD's. | **Internally consistent** |
| 4 | 56.5 + 17.7 + 25.8 | Sums to 100.0. | Consistent |

### Inferences the thread makes but does not demonstrate

- **"payTo … sent 642 to 0x047f, owner of the POOL4 hook. POOL4 sends 85% of each trim to the burn path."** Placing these two facts side by side suggests Identity.md revenue ends up in the burn. Owning a hook is not the same as feeding it. The thread shows no transfer from 0x047f into POOL4 or the burn path. The revenue-to-burn link is **implied, not shown**. I did not verify the 642, the 85% or the 33,279 figures.
- **"SIMD's vault, dev and payer haven't moved IMD to/from POOL4."** This may be true, but it is a negative claim with no method given. I did not verify it.
- **"Payers look broader: 57, above the earlier 15 to 56."** Unique payers in a 41.6 h window are being compared with "earlier windows" that are never defined (length? start?). 57 versus a ceiling of 56 is a one-payer difference. It is not evidence of broadening.

### Points the thread gets wrong or leaves internally unresolved

1. **The refund average doesn't fit "half of each."** If every action costs 0.5 and the refund is 50%, then 447 refunds should total **111.75 IMD**, not 136.75. My log sample found one 6-IMD payment (multi-run), which accounts for about 2.75 IMD of the gap. That leaves **about 22 IMD unexplained**. The vault also exposes a second bps-like value, **7500** (selector `0x8b263a4a`), so some payments may be refunded at 75%. This is *uncertain*: the getter is unnamed. But the thread's own "50% of each" is not shown to hold, and the author did not notice that their two numbers conflict.
2. **The 41.6 h aggregate hides a strong trend.** My sample splits into clean segments:

   | Segment (UTC) | payTo inbound txs | SIMD payer share | Distinct non-SIMD payers |
   |---|---|---|---|
   | Oct 4 23:43 → Oct 5 13:26 | 228 | **71.1%** | 10 |
   | Oct 6 00:29 → 10:18 (tweet) | 91 | **30.8%** | 29 |

   *Fact:* within the blocks I fetched, the SIMD payer's share fell by more than half, and non-SIMD payers roughly tripled. *Inference:* by the tweet, recent demand already looked much less "recycled" than the headline 56.5% says. This is the single most relevant piece of evidence for the thread's own question, and the thread doesn't show it. *Caveat:* 38% of blocks are missing (mostly Oct 4 16:42–23:43 and Oct 5 13:26–Oct 6 00:29), and an overnight-versus-daytime mix may be part of the swing.
3. **The prediction test is weak.** The bar is "non-SIMD paid actions ≥786 for Oct 13–20" while the current pace is 795. A bar 1% below the current pace mostly tests whether nothing changes. A test that could actually separate the two hypotheses would compare non-SIMD demand with the vault **paused or with refunds cut**, or would track non-SIMD payers who were *not* refund recipients. Credit is still due: it is a dated, numeric, falsifiable claim, which most threads don't offer.
4. **"Inside the 31 to 263 of earlier windows."** A band that spans 8.5× contains almost any value. It tells the reader nothing.

## 3. Did the thread answer "broaden or recycle"?

**No. It poses the question in post 1 and never gives an answer.** Here is what the evidence supports.

- **Fact:** the vault refunds a share of payments. 56% of the refunded IMD went to SIMD's own payer, so for about half the volume, SIMD-owned IMD flows vault → payer → Identity.md payTo → part back to the payer. The flow **recycles** within SIMD; Identity.md still receives the gross 0.5 IMD per action.
- **Fact:** about 80% of the SIMD payer's recent jobs are SIMD's own contest or grading tasks, including this one. Those actions are **internally generated demand**. They are not outside users buying agent work.
- **Fact:** 44% of the refunded IMD went to *other* wallets, and non-SIMD payers rose in my latest segment. *Inference:* the rebate may be pulling in outside payers, which is a **broadening** channel. The thread hints at this but never builds the argument.
- **Unanswered, and decisive:** where does the vault's IMD come from? It currently holds **1,591.5 IMD** (`balanceOf(0xd604…)`). If the vault is funded by SIMD-side fees or trading volume that would not otherwise buy IMD, SIMD's activity is net new IMD demand even if its payer is circular. If the IMD came from existing holders or treasury, the loop is a subsidy that shuffles existing IMD around. The thread never asks this.
- **Unanswered:** does SIMD's dashboard "100%" refer to something other than `refundBps` (for example a share of fees routed to the vault)? Without the dashboard text I cannot tell whether this is a mislabel or a different metric.

## 4. Grading against the rubric

**Strengths**
- Every post cites a primary source: a contract read, an API endpoint or a token page. Nothing in it is a slogan.
- The `refundBps = 5000` versus "100%" discrepancy is a real, checkable and useful catch.
- The thread is aware that the SIMD payer funds grading of SIMD's own thesis contest. That is self-critical about the very program that pays for the thread.
- Its figures held up wherever I could check them: 447 refunds, 136.75 IMD, the hook owner, the pace arithmetic, a SIMD share of roughly 57–60%.
- It offers a falsifiable, dated test.

**Weaknesses**
- It is a data dump without a thesis. The question is never answered and no model ties the numbers together.
- The vault's funding source, the mechanism that decides the question, is missing.
- Its own refund numbers contradict each other (111.75 expected versus 136.75 reported), and the author didn't notice.
- The comparison bands (31–263; 15–56) can't distinguish anything, and the test threshold sits just under the current pace.
- The aggregate hides the sharp intra-window fall in SIMD's share.
- The revenue → 0x047f → burn link in post 2 is suggested by placement, not demonstrated.
- It understates the self-referential share (about 80% of the payer's jobs, not 55%).

This is above the "fluff" tier (3–5) because the mechanisms and numbers are real and specific to IMD and SIMD. It falls short of 7 because a "strong draft" needs a *clear argument*, and this thread lists facts without concluding. It is well short of 8, which requires novel synthesis and depth: the key mechanism is missing and the test is close to trivial.

```json
{"quality":6,"impactNote":"Useful for IMD/SIMD discourse as a sourced fact sheet. It confirms on-chain that SIMD's vault refunds 50% (refundBps=5000, 447 refunds, 136.75 IMD), not the '100%' the dashboard reportedly shows. It also makes SIMD's self-funded share of Identity.md demand visible: about 57-60% of paid actions, and about 80% of the SIMD payer's jobs are SIMD's own contests. It does not settle broaden-vs-recycle because it never traces where the vault's IMD comes from.","notes":"Strengths: dense primary-source citations; refundBps discrepancy is a real catch; headline figures reproduce (447 refunds, 136.75 IMD, POOL4 hook owner 0x047f, 795/wk pace math, SIMD payer share ~60% in a 62%-coverage log sample); includes a dated falsifiable test. Weaknesses: never answers its own question; omits the vault's funding source, which decides the question; its own refund numbers conflict (447 x 0.25 = 111.75, not 136.75; the vault has an unexplained 7500-bps parameter); comparison bands 31-263 and 15-56 are uninformative; the >=786 test sits just under the 795 current pace; the 41.6h aggregate hides SIMD's share falling from ~71% to ~31% within the window; the revenue->0x047f->burn link is implied, not shown; self-referential share understated (80/99 SIMD-tagged jobs, not 55/100). A competent fact sheet, not pay-grade analysis.","flags":["thin"]}
```