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

Tweet: https://x.com/0xdropxtor/status/2107415171983405076. The tweet itself was not fetched; the text graded is the one in the brief.
Checked on 2026-10-06 at Ethereum block ~26,132,752 (publicnode RPC + api.imd.fun).

## Verdict

**Quality 6/10, below the pay bar (8).** The thread is unusually concrete for this genre. It names the payTo, the vault's `refundBps()`, the POOL4 hook owner and the burn path, payer shares, and it ends with a dated numeric test. Its headline claim about the 50% refund is correct on-chain. But it asks "broaden or recycle?" and never answers. It lists numbers that point in opposite directions (56.5% self-paid vs. a broader non-SIMD payer count) with no synthesis, model or counter-argument. Its one falsifiable test is set *below* the pace it reports (≥786 vs. 795 now), so it is close to a pre-confirmed prediction. The comparison windows ("earlier windows", 31–263, 15–56) are never defined. That is a well-sourced data dump with a question attached, not pay-grade analysis.

## Evidence checked (primary sources)

| Claim | Check | Result |
|---|---|---|
| 0.5 IMD per paid action | `GET https://api.imd.fun/requests/capabilities`: every action (`job.open`, `job.continue`, `launch.open`, `oracle.request`, `workflow.open`, `schedule.create`, …) has `amount: 500000000000000000` (18 decimals) of asset `0xd34a…63b7`, payTo `0x4e0f…1ADbc` | **VERIFIED** |
| Token is IMD | `symbol()` on `0xd34a99bc…63b7` returns `"IMD"` | **VERIFIED** |
| SIMD vault `refundBps() = 5000` (50%) | `cast call 0xd60483Eb…9B21 "refundBps()(uint256)"` returns `5000` | **VERIFIED** |
| payTo holds 36 IMD | `balanceOf(0x4e0fA57B…1ADbc)` = 40 IMD at check time | **CONSISTENT, with drift** (the balance moves with every payment and sweep; 36 was plausible at posting) |
| POOL4 hook `0xc6c965bd…0840` exists | `eth_getCode` returns contract bytecode | **VERIFIED as a contract**; its owner (0x047f), the 85% trim split and the 33,279 IMD burned were **NOT verified** |
| payTo sent 642 IMD to 0x047f | not traced (needs a full Transfer-log scan) | **UNVERIFIED** |
| SIMD payer `0x9fAd…cf63f` order history | `GET /requests/paid-by/0x9fAd…` returns 100 orders, all `job.open`, all `admitted`/`confirmed`, from 2026-10-05T07:27Z to 2026-10-06T10:27Z | **VERIFIED as an active heavy payer** (~100 orders in ~27 h). The claim that "55 of 100 grade SIMD's thesis contest" is **PLAUSIBLE but not verified**: the endpoint shows job IDs, not job content. This grading task is itself a `[SIMD-THESIS]` job, which fits the claim. |
| 56.5% share, 447 refunds, 136.75 IMD refunded, 56% to own payer, 197 non-SIMD payments, 57 payers | would need a full log scan of payTo inflows and vault refunds over the 41.6 h window | **UNVERIFIED**. Internally consistent: 447 × 0.5 × 0.5 ≈ 111.75, not 136.75, so either some refunds were for multi-unit payments or the counts cover different windows. The thread does not explain the gap. |
| SIMD dashboard says "100%" | dashboard not fetched | **UNVERIFIED**. If true, it is the thread's most useful finding (on-chain 50% vs. advertised 100%). |

## Facts, inferences, and uncertainty

**Facts (verified above):** the price is 0.5 IMD per action, paid to a single payTo; the SIMD vault refunds 50% (`refundBps=5000`); the SIMD payer places about 100 paid `job.open` orders a day.

**Author's inferences, which the thread does not argue:**
- "Recycle." When a single wallet funds ~56% of paid actions and gets half back, the net IMD demand per SIMD action is 0.25 IMD. Much of the remaining activity is SIMD paying the network to grade SIMD's own contest. That is circular demand, and the thread shows the pieces of that argument without stating it.
- "Broaden." 57 non-SIMD payers sits above the earlier 15–56 range. But since "earlier windows" are undefined, one data point at the edge of a range shows nothing.
- POOL4 isolation. "SIMD hasn't moved IMD to/from POOL4" suggests SIMD activity does not feed the burn. But revenue from the payTo flows to 0x047f, which owns POOL4. The thread never closes the loop: does SIMD-paid revenue eventually reach the burn path? That is the deciding question for "broaden vs recycle", and it is left implicit.

**Weaknesses that cap the score:**
1. **No answer to its own question.** The thread lists data from both sides and gives no conclusion or net-demand model (e.g. net IMD bought per SIMD-subsidised action).
2. **Weak falsifiable test.** "≥786 non-SIMD paid actions Oct 13–20, pace now 795" passes if the current pace merely holds. A test should separate hypotheses: what number would mean "recycle"?
3. **Undefined baselines.** "31 to 263 of earlier windows" has no window length, dates or source.
4. **Arithmetic not reconciled.** 447 refunds vs. 136.75 IMD returned does not match 0.25 IMD per refund.
5. **No counter-argument.** It ignores that refund-subsidised demand can bootstrap real users, and that a 50% refund still leaves net buy pressure of 0.25 IMD per action.
6. **Five links, few proofs.** The links point to contract and API pages, not to the queries or transactions behind the percentages.

**Strengths:** IMD/SIMD-specific throughout. It names real mechanisms (payTo, `refundBps`, POOL4 trim → burn, the 0x047f payout). It catches a possible gap between the dashboard and the contract. Its headline on-chain parameter is correct. It frames a genuinely relevant question about reflexive demand.

## Unanswered questions

- Does payTo revenue routed to 0x047f reach POOL4's burn path, and how much of it came from SIMD-refunded payments?
- What exactly are the "earlier windows" and their lengths?
- Does the SIMD dashboard really advertise 100% refunds (not fetched)?
- How do 447 refunds sum to 136.75 IMD?
- Net of refunds, how much IMD does SIMD actually remove from circulation per day?

## Limits

The tweet page, the SIMD dashboard and Etherscan HTML were not opened. Percentages and counts that need full event-log scans were not recomputed. The grade covers analytical quality, not reach, and follower count was not used.

```json
{"quality":6,"impactNote":"Puts verifiable SIMD mechanics into IMD discourse (refundBps()=5000 confirmed on-chain, one payer funding ~56% of paid actions, and a possible gap with a dashboard advertising 100% refunds), which helps readers separate subsidised self-demand from organic demand.","notes":"Strengths: dense, IMD/SIMD-specific, names payTo, vault refundBps, the POOL4 trim/burn path and the 0x047f payout; 0.5 IMD price and 50% refund verified. Weaknesses: never answers its own broaden-vs-recycle question; no net-demand model or counter-argument; the falsifiable test (>=786 vs pace 795) is nearly pre-confirmed; 'earlier windows' undefined; 447 refunds vs 136.75 IMD unreconciled; most percentages unproven in-thread. A data dump with a question, not a thesis.","flags":["thin"]}
```