# Hard grade: "conversion is the only leading indicator" thesis on IMD + SIMD

- **Thesis:** https://x.com/chukwue46258952/status/2107605191264473553 (@chukwue46258952, ≈10 followers, tagging @SuperIMD_eth)
- **Posted:** 2026-10-06 22:53 UTC. I got this from the tweet ID's snowflake timestamp, because x.com returned HTTP 402 to my fetcher. I graded the text as quoted in the task.
- **Data pulled:** 2026-10-06, about 22:55–23:20 UTC.
- **Grade: 4 / 10** (0–10 scale; most posts land at 2–5)

## 1. Verdict

The analytical frame is reasonable and better than most posts: measure retention, not activity; set falsifiable thresholds; treat "pure faucet" as the base case. It is not original. Activation vs. retention cohorts is standard growth-analytics thinking. The post fails on the thing it calls "solved": its factual description of the capital rail. Three concrete claims are wrong, and they were wrong when it was posted.

1. **"Currently covering the full 0.5 IMD price on every eligible job": false.** The vault's on-chain base refund rate is 50%. 481 of 582 payouts were 0.25 IMD. Full-price refunds happened only during the first ~15 hours, under a one-off boost covering 100 payments. That boost ended at 2026-10-05 06:50 UTC, about 40 hours before the tweet. In fairness to the author, SIMD's own dashboard still labels the rule "100% · 0.5 IMD", even though that same dashboard counts zero full-price payouts.
2. **"Vault outflows are occurring in clean, full-price batches rather than fragmented partials": false.** Outflows are mostly half-price. SIMD's own dashboard reports **0** payouts matching the full-price rule.
3. **"SIMD trading fees flow into the designated vault … simple and public … That part is solved": materially overstated.**
   - 99.8% of the vault's IMD came from transfers sent by the **dev EOA**, not straight from fees. That EOA collects fees from a FeeEscrow and passes on only part of them.
   - The dev sets the refund rate and boosts, has no keeper delegated, and can sweep the entire vault to themselves (`ESVault()`).
   - The rail does work. It is not a trust-minimised or "solved" mechanism.

Two other problems:

- The post leaves out the biggest confounder in its own "early signal": **about half of all subsidised activity is SIMD paying itself.**
- Its headline thresholds are **untestable as written**. The program is about 3 days old, and the vault automatically refunds essentially every payer, so a "fully self-paid job" or a "non-subsidized paying wallet" structurally cannot appear.

## 2. Evidence base (primary sources)

| Source | What it gave |
|---|---|
| Vault contract `IMDJobsPayer` [0xd60483Eb8004e3DE3e283b3efF0e67FBb57f9B21](https://eth.blockscout.com/address/0xd60483Eb8004e3DE3e283b3efF0e67FBb57f9B21) (Ethereum mainnet, verified source) | Refund logic, roles, rates |
| Live `eth_call` via `ethereum-rpc.publicnode.com` | `refundBps()=5000`, `boostBps()=0`, `boostEnd()=0`, `countBoostRemaining()=0`, `countBoostBps()=10000`, `maxRefundPerDay()=100 IMD`, `maxPaidPerPayment()=5 IMD`, `paused()=false`, `keeper()=0x0`, `dev()=0xe132be23ce6255930556a45406075e62fb6340c0` |
| Blockscout ERC-20 transfer history of the vault (859 transfers, 2026-10-04 16:02 → 2026-10-06 23:03 UTC) | Every inflow and payout |
| Blockscout transfer history of the dev EOA [0xe132…40c0](https://eth.blockscout.com/address/0xe132be23ce6255930556a45406075e62fb6340c0) (567 transfers) | Where the vault's money comes from |
| SIMD site [si-md.xyz](https://www.si-md.xyz/), its `app.js` and `/api/state` | Official vault dashboard stats; names the vault; says the "Hire" jobs are paid by a SIMD server wallet |
| IMD control plane `https://api.imd.fun/jobs` and `/jobs/:id` (8,985 jobs; all have a `paidBy` field) | Who paid for which job, job states, judge verdicts |
| [imd.fun/docs](https://imd.fun/docs/) | 0.5 IMD per paid action, charged per action; x402 + Permit2 payments on Ethereum mainnet |
| SIMD ERC-20 [0xbb0c1f82…3415](https://eth.blockscout.com/token/0xbb0c1f82a2ea0253ea3d91c2f05caded82133415) | Token created by the `LaunchFactory` contract (0xc6B0…977B); 607 holders |

Analysis scripts are in `analysis/` in this repository. The raw pulls were not committed because they are large and change by the minute.

## 3. Claim-by-claim grading

**Labels:** **FACT** = checked directly against the chain or an official API. **INFERENCE** = my reasoning from facts. **UNVERIFIED** = I could not check it.

| # | Thesis claim | Grade | Basis |
|---|---|---|---|
| 1 | Fees flow into the designated vault (0xd60483eb…) | **Partly true** | **FACT:** the vault address matches the one si-md.xyz names. **FACT:** the contract says it "Receives 1.2% of every $SIMD trade". **FACT:** of 1,828.39 IMD that came in, only 2.95 IMD arrived through the contract's own `buyToken` swap. 1,825.44 IMD (276 transfers) came from the dev EOA `0xe132…`. That EOA received 2,500.24 IMD from `FeeEscrow` 0xAcefe251da006887dA41C063D06CC82A060824BA, so ~675 IMD was not forwarded; 104 IMD of that went straight to SIMD's operator wallet. **INFERENCE:** fees do fund the vault, but through a discretionary custodian, not an automatic pipe. |
| 2 | Vault covers the full 0.5 IMD on every eligible job, "currently" | **False** | **FACT:** `refundBps()` = 5000 (50%), with no active boost (live chain read). **FACT:** 100 payouts at 0.5 IMD, all between 2026-10-04 17:00 and 2026-10-05 06:50 UTC. This matches the contract's count boost ("100% for the next 100 payments"). After that, 481 payouts at 0.25 IMD and one at 0.75. **FACT:** SIMD's own `/api/state` has contradictory fields. It says `share: "100%"`, `payoutAmount: "0.5 IMD"` and "The 100% rule names 0.5 IMD", but its stats report `fullPrice: 0` (no payout has matched that rule). **FACT:** a separate site, superimdc.xyz (a Robinhood Chain token 0x577b…03ae linked to @superimdx, not @SuperIMD_eth), also advertises "cover 100% of Identity.md job costs". **INFERENCE:** the author probably repeated the dashboard's headline "100%" label without checking it against the actual payouts or the contract. That is a mitigating factor, but the claim is still false. |
| 3 | "Not a promise … already executing" | **True** | **FACT:** 582 IMD payouts totalling 171.0 IMD to 76 distinct addresses in ~55 hours. |
| 4 | "Dozens of on-chain reimbursements" | **True but understated** | It is hundreds (582), not dozens. Understating is not inflating, but it shows the author did not look at the data closely. |
| 5 | Vault "repeatedly held 500–1,300+ IMD ready for distribution" | **True, misleading framing** | **FACT:** reconstructed balance ≈550 IMD by 2026-10-04 22:00, ≈1,316 by 2026-10-05 18:00, 1,657.39 now. The balance has only gone up. **FACT:** contract cap `maxRefundPerDay` = 100 IMD/day; actual payouts were 17.75, 85.25 and 68.0 IMD/day. **INFERENCE:** a growing idle balance means inflow is far above demand at a 50% rate. "Ready for distribution" also hides that the dev can sweep all of it (`ESVault()`: "Dev only; the funds can only go to the dev"). |
| 6 | High acceptance (90%+) persists under subsidy | **Roughly true, weak evidence** | **FACT:** paid jobs since the vault started: 554 completed, 14 blocked, 3 executing. Node verdicts: 1,196 accepted, 6 rejected, 11 failed. **INFERENCE:** these are verdicts from the swarm's own judges, not customer satisfaction. They say nothing about whether anyone will pay again, which is the thesis's own point. The post uses this as "early signal" for a claim it cannot support. |
| 7 | Multiple independent wallets used the rail to ship real work | **True with a major omission** | **FACT:** 75 recipients besides SIMD's operator. **FACT:** operator wallet `0x9fad…f63f` paid for **286** jobs (50.1% of the 571 paid jobs since the vault started). At least 252 of them carry `[SIMD-…]` tags: hash-collision experiments, contests, and thesis-grading jobs like this one. It received **286** refunds (49.1% of payouts by count, 49.7% by IMD), plus 104 IMD directly from the dev EOA. **INFERENCE:** about half of the "subsidised demand" is the SIMD project buying work from IMD with fee money and then refunding itself. That is circular activity, which is exactly the "activity faucet" the thesis warns about, and the post does not mention it. |
| 8 | Outflows in clean full-price batches | **False** | See #2. Outflows are mostly batched (e.g. 85 payouts in one hour on 10-05, 75 in one hour on 10-06), but at **half** price. |
| 9 | "The sample is still small, but the pattern is visible" | **Unsupported** | No cohort or repeat-payment data is given. The program is ~2.3 days old, so no 21/45/90-day pattern can exist yet. |

## 4. Can the four thresholds be measured? (They can't, as written)

Facts the assessment rests on:

- The vault went live 2026-10-04 16:02 UTC; it was ~55 hours old at the time of the post.
- Of 71 wallets that paid for a job after launch, **70 got refunds**. The remaining one has a single job and may just not have been refunded yet.
- The contract refunds every payment the keeper submits, never to the dev or itself, up to 100 IMD/day.

| Threshold | Can it be evaluated today? | Structural problem |
|---|---|---|
| ≥30% of first-time reimbursed users return with a fully self-paid job within 45 days | No (needs 45 days) | While the 50% rebate applies to *all* payers automatically, a "fully self-paid job" only happens if the vault runs dry, pauses, hits its daily cap, or skips that payer. The metric needs a definition such as "job paid with the refund declined or not issued" or "net price > X". As written it measures vault outages, not demand. |
| Median first subsidised → second paid job < 21 days | No | Same issue: the second job is also subsidised. **FACT:** 22 of the 48 recipient wallets that are new since launch already have ≥2 paid jobs, but every one of those jobs was refunded at 50%. That is not evidence of self-funded retention. |
| Fee inflow ≥75% of daily reimbursements over any rolling 10-day window, no vault draw-down | No (only 3 days of data) | **Trivially passes** at the current rate: inflow 1,828 IMD vs 171 IMD paid out, ≈10.7×. This only tests whether the dev keeps forwarding fees and keeps the rate low, not demand. At 50% refunds and ~0.25 IMD per job, the fee side would have to collapse for this to fail. |
| ≥40 unique non-subsidised paying wallets within 90 days | No | Under universal automatic refunds the count is ~0 by construction (1 wallet so far, probably pending). It would also count wallets nobody can verify are independent: one actor can run many wallets, and 26 of the 48 new recipient wallets made just one paid job. |

**INFERENCE:** the thresholds sound rigorous but would mostly fail for mechanical reasons, or pass trivially (#3), whatever real demand does. A better design:

- Compare paying-wallet cohorts *before* the vault, 2026-09-23 → 2026-10-04: 139 wallets, 894 paid jobs. That is a natural control.
- Track **net IMD spent per wallet** after refunds.
- Exclude the operator wallet and any wallet the dev funded.
- Watch how behaviour changes when the refund rate changes (100% → 50% happened on 10-05).

## 5. Things the post gets right

- **True** to say jobs completed and vault balance are lagging, activity-type metrics, and that conversion to self-funded demand is the real question.
- **Honest base case:** "treat the faucet outcome as the base case until the thresholds prove otherwise". This is correct, and the operator-wallet finding makes it more right than the author knew.
- The Layer 1/2/3 framing (capability → activation → retention) is clear, though generic.
- The "what strong evidence would look like" list is sensible: a rising user-funded share while volume grows, cohort curves, and fee velocity that follows organic demand.

## 6. What separates it from 6+

- The section labelled "solved" contains the errors. A thesis whose argument rests on "the rail is solved, only conversion is open" has its foundation wrong on rate, mechanism and custody.
- It gives no numbers, transactions, links or cohort data, only "public explorer + vault data". Every check I made either contradicted its specifics or showed they were stale.
- It ignores the self-dealing operator volume, the dev's discretionary control, the 50% default and the daily cap. These are all one contract read away.
- The thresholds are arbitrary (why 30%, 21, 75%, 40?) and, as shown above, mostly unmeasurable under the actual mechanism.
- The "psychological shift" argument is plausible but asserted, not evidenced.

## 7. Uncertainty and open questions

**Uncertainty:**

- `paidBy` in the IMD API is present only from 2026-09-23 onward in my pull. The "pre-existing user" counts (23 of 71 recipients who also appear as job payers had paid before the vault) are a lower bound on prior usage.
- Payouts also cover non-job actions (oracle requests, schedules). Matching payouts to jobs is by wallet, not by payment ID.
- The FeeEscrow → dev EOA leg is inferred from transfer history. I did not audit FeeEscrow's code or which pool's 1.2% it collects.
- I could not fetch the tweet itself (x.com returned 402). The text graded is the copy provided with the task.
- Vault and API state change by the minute. All figures are as of ~2026-10-06 23:15 UTC.

**Unanswered questions:**

- Why does ~27% of escrowed fee IMD stay with the dev EOA instead of going to the vault?
- Will refunds to the operator wallet continue? The contract forbids refunds to the dev address, but the operator wallet is a different address.
- What does conversion look like once operator volume is excluded and a pre-vault control cohort is used? Answering that needs ≥45 days of data.
- Did paid activity from non-operator wallets rise because of the subsidy? Paid jobs excluding the operator by day: 175 (10-03, before the vault), then 84 / 110 / 164 on 10-04 / 10-05 / 10-06. So far this is no clear lift over the pre-vault peak days (e.g. 240 on 09-27).