# Hard grade: "IMD + SIMD conversion test" thesis (@SuperIMD_eth)

**Verdict: D+ (46 / 100).** The thesis is well organised. Its central question (does subsidised access turn into independent, repeat, user-paid demand?) is the right one, and it does write down a downside case. But the parts it uses to claim rigour are factually wrong, out of date, or not specified well enough to test:

- the on-chain routing description
- the "100% coverage" claim
- the "early cohort" data
- the thresholds

The on-chain record shows that the largest "user" of the subsidy is a wallet funded by the SIMD deployer. The thesis does not disclose this, and it hits the exact failure mode the thesis claims to guard against.

Evidence snapshot: Ethereum mainnet, block ~26,136,338, **2026-10-06 22:31 UTC**. The vault was deployed **2026-10-04 16:02 UTC**, so the whole history covered here is about 54 hours.

Labels used below:
- **[F]** fact checked on-chain or in a cited source
- **[I]** inference
- **[U]** uncertain or unanswered

---

## 1. Scorecard

| Dimension | Weight | Score | Why |
|---|---|---|---|
| Framing of the core question | 15 | 13 | Asks the right question: conversion, not volume. The three demand layers are a useful split. |
| Accuracy of the mechanism description | 20 | 6 | Routing is described as automatic fee → vault. On-chain it goes through a deployer wallet that keeps about 25%. "Targeting full coverage" contradicts the live 50% base rate. Custody and admin powers are left out. |
| Quality of "cohort" evidence | 15 | 3 | These aren't cohort observations. "First ~30–40 jobs" is wrong by more than 10× (575 refunds). Concentration and a related-party wallet are not mentioned. Acceptance rate is the wrong metric. |
| Thresholds (falsifiability) | 20 | 9 | Four thresholds is a good move. But "user-paid" is never defined when about 99% of payers get rebated. Denominators and the "safety floor" are undefined. C is already met trivially and doesn't measure demand. D is easy to sybil. |
| Causal argument | 15 | 4 | Asserted, not shown. No control group, and none is possible while the rebate is near-universal. The mechanism ("quality signal internalised") is not measured. |
| Downside case and risk coverage | 10 | 6 | The downside case is stated honestly. It misses wash or self-dealing activity, deployer custody, and reflexivity in fee income. |
| Completeness and presentation | 5 | 2 | The text is cut off mid-sentence ("converting a"), so the "depth check" section is never finished. |
| **Total** | **100** | **43 → 46** | +3 for raising the right question publicly and including a falsification clause. |

---

## 2. Claim-by-claim verification

### 2.1 "Fees are directed into the protocol vault (0xd604…9b21)"

- **[F]** The address is a verified contract named `IMDJobsPayer` on Ethereum mainnet. It was created by `0xE132be23CE6255930556a45406075E62fb6340C0` (the "dev") in tx `0x7144eb1d…6be9`. Sources: [Etherscan](https://etherscan.io/address/0xd60483eb8004e3de3e283b3eff0e67fbb57f9b21), [Blockscout](https://eth.blockscout.com/address/0xd60483Eb8004e3DE3e283b3efF0e67FBb57f9B21).
- **[F]** The contract NatSpec says the vault "Receives 1.2% of every $SIMD trade" through a `SIMDHook`. **But `hook()` returns `0x0000…0000`.** No hook is linked, so the automatic in-swap fee path described in the contract is not live (checked with `cast call … hook()`).
- **[F]** Lifetime IMD inflow to the vault is **1,826.16 IMD**:
  - **1,823.22 IMD (99.8%)** came as manual transfers from the dev EOA.
  - **2.95 IMD** came from the Uniswap v4 PoolManager (`0x0000…4444c5dc…`).
- **[F]** The dev EOA received **2,497.27 IMD** from a contract named `FeeEscrow` (`0xAcefe251…24BA`) in 278 claims. `FeeEscrow` and the `LaunchFactory` that minted SIMD (`0xbB0c1F82…3415`, 1B supply) were deployed by the same address, `0xec4529D8…9A17`. Of those claims, the dev forwarded 1,823.22 IMD to the vault, which is **73.0%**. This matches the contract's `launchpadForwardBps() = 7500` ("75% to the vault, 25% kept for marketing").
- **[F]** From the retained share, the dev also sent **104 IMD directly to wallet `0x9fad…f63f`** and **30 IMD to a Uniswap V3 pool** (tx `0x211e4358…be17`).
- **[I]** The real route is:

  SIMD trading on an IMD-denominated launchpad pool → creator fee in IMD → `FeeEscrow` → **deployer EOA (custodial, discretionary)** → ~75% forwarded by hand → vault → keeper/dev `refund()` → payer.

  The thesis presents "fee → vault → payout" as a mechanical rail. It is a discretionary, operator-run one.
- **[F] Omitted custody risk.** The contract gives the dev `sToken()` and `ESVault()`, which send **all** vault IMD/ETH to the dev wallet at any time. The dev can also reset the refund queue (`resetRefunds`), change the refund rate, and switch the payment token. `keeper()` is currently `address(0)`, so the dev operates the vault alone. A thesis that calls itself "technically honest" should state this.
- **[U]** The project site says SIMD is on **Robinhood Chain** (chain 4663, CA `0x577bc74a…03ae`) ([superimdc.xyz](https://www.superimdc.xyz/)). The vault and the fee flow above are on **Ethereum** (SIMD `0xbB0c…3415`). The thesis doesn't say which chain or deployment it means, or whether Robinhood-chain fees reach this vault at all. I did not check Robinhood Chain flows.

### 2.2 "Currently targeting full coverage of the ~0.5 IMD task price … Coverage has already reached 100% on multiple batches"

- **[F]** Live state: `refundBps() = 5000` (50%), `boostActive() = false`, `countBoostRemaining() = 0`, and `quoteRefund(0.5 IMD) = 0.25 IMD`. **The vault currently refunds 50%, not 100%.**
- **[F]** Of 575 refunds, **474 were 0.25 IMD (50%)**, **100 were 0.5 IMD (100%)** and 1 was 0.75 IMD. 100 full refunds is exactly what a `setRefundBoostCount(10000, 100)` would produce, and `countBoostBps()` still reads 10000.
- **Grade:** "100% on multiple batches" is literally true. Read as "the mechanism covers the job price", it is misleading: full coverage was a one-off promotion covering about 17.6% of refunds.
- **[F]** There are hard limits: `maxRefundPerDay = 100 IMD`, which is at most 400 jobs a day at 50% or 200 a day at 100%, and `maxPaidPerPayment = 5 IMD`. The subsidy is capped regardless of fee income. The thesis doesn't mention this.

### 2.3 "Early cohort observations (first ~30–40 jobs)"

| Thesis claim | On-chain / source finding | Grade |
|---|---|---|
| "first ~30–40 jobs" | **575 refunds** to **74 wallets** in ~54 h **[F]** | Wrong (stale or invented) |
| Vault "repeatedly held hundreds to 1,000+ IMD" | Holds **1,656.91 IMD** now; net of 169.25 out **[F]** | True |
| "Dozens of jobs reimbursed at or near full price" | 101 at ≥100% **[F]** | True but understated. It hides that 82% were at 50%. |
| Acceptance "90%+ on large samples" | Bankless (Sep 25): ~50,700 attempts, **~86%** acceptance ([Bankless](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment)); KuCoin: "near 86 percent" ([KuCoin](https://www.kucoin.com/blog/imd-token-community-owned-ai-agents)) **[F]**. Some agents may be at 90%+ **[U]**. | Cherry-picked. Also off-topic: acceptance is an internal orchestrator verdict on agent submissions, not evidence that buyers value the output. |
| "Multiple independent builders" use the rail | **One wallet, `0x9fad…f63f`, received 282 of 575 refunds (49%)**. Its first IMD came from the dev EOA (tx `0xedc56228…`, 2026-10-04 18:09, ~2 h after the vault went live), then another 100 IMD (tx `0xe088fdf8…`) and 2 IMD (tx `0xcdcfa02a…`). It paid the treasury 284 × 0.5 = 142 IMD and received 84.5 IMD back. **[F]** | **Materially misleading.** [I] The single largest "user" is funded by the subsidy's own operator: related-party or self-dealing activity at best, and an unknown at worst. |

More cohort facts the thesis should have reported **[F]**. These come from IMD transfers into the Identity.md treasury `0x4e0fA57B…ADbc`, which is the vault's configured `payTo`:

- **Before the vault** (2026-09-27 to 2026-10-04 16:02, about 7.7 days): **686 payments** from **122 wallets**, about 89/day.
- **After the vault** (about 2.27 days): **581 payments** from **75 wallets**, about 256/day. **74 of the 75 payers were refunded.**
- **Without wallet `0x9fad`**, post-vault payments are **297**, about 131/day. **[I]** Most of the visible lift comes from the one dev-funded wallet. The organic lift is maybe +45%/day, measured over 2 days with no seasonality control (there were also large single days pre-vault: 175 on 10-03, 170 on 09-27).
- **21 of the 74 refunded wallets were already paying before the vault existed.** **[I]** At least about 28% of the "subsidised cohort" wasn't acquired by the subsidy. Counting them as conversions would inflate threshold A.
- Fee claims per UTC day: **796.7 (10-04, partial) → 1,190.4 (10-05) → 510.2 (10-06)**. **[I]** Fee income fell about 57% day-on-day by day 3, which is typical of post-launch volume decay.

### 2.4 Causal argument

**[I]** The argument is a plausible story, not a causal one. It says the subsidy lowers trial friction, users internalise quality, and willingness to pay follows. Its weaknesses:

1. **No counterfactual exists.** 74/75 recent payers get a rebate, so there is no unsubsidised comparison group. Any "conversion" can't be told apart from the trend.
2. **"Quality internalised" is never measured.** Acceptance rate is an orchestrator metric, not a buyer outcome.
3. **"Remove the support and measure residual demand"** is the right experiment. But the thesis proposes no removal schedule, and the dev can and does change the rate at will (50% → 100% promotions → 50%).
4. **Reflexivity is ignored.** Subsidy funding comes from SIMD trading. If SIMD trading rises because people expect subsidised IMD activity, then subsidy and demand are endogenous. Correlation between the two says nothing about the direction of cause.

---

## 3. The four thresholds, stress-tested

| # | Threshold | Problems | Fix |
|---|---|---|---|
| A | ≥25% "organic conversion" within 30 d of first reimbursed job | "Organic" and "user-paid" are undefined while the base rebate is 50% for nearly everyone. Pre-existing payers (21/74) contaminate the denominator. No sybil filter. | Define user-paid as a job **paid at a time and rate where refund = 0**, or count net IMD out-of-pocket. Restrict the cohort to wallets whose **first ever** treasury payment came after vault launch. Exclude operator-funded wallets. |
| B | ≥40% of converted users submit a 2nd user-paid job within 60 d | Inherits A's definitional gap. One wallet with 284 jobs dominates any count-based metric. | Report wallet-level retention and the median (not mean) jobs per wallet. Cap the contribution of any single wallet. |
| C | Daily fee inflow ≥80% of reimbursements for 14 d without breaching a "safety floor" | **Already passing by about 15×** (2,497 IMD fees vs 169 IMD refunds) because refunds are capped at 100 IMD/day. It measures SIMD speculation, not product demand. The "safety floor" is undefined. Fees go through a discretionary EOA, so "inflow to the vault" is an operator choice. | Swap in a demand-side sustainability test: **unsubsidised job revenue / total job revenue**. State the floor in IMD. Measure fee inflow at `FeeEscrow`, not at the vault. |
| D | ≥50 unique paying wallets outside the original cohort | Very cheap to sybil: 50 × 0.5 IMD = 25 IMD. "Original cohort" isn't defined by date or rule. Pre-vault the treasury already saw **122 paying wallets in about 8 days**, so 50 is a low bar. | Require wallets with no funding link to the operator or cohort wallets (funding-graph check), at least 2 paid jobs each, and a time-bounded definition. |

"Miss these for two consecutive months" is a reasonable horizon. But with 54 h of history and fee income already decaying, the thesis should also set an **early-warning** check, for example a weekly unsubsidised-payment share.

---

## 4. What the thesis gets right

- It separates *accepted execution*, *subsidised activity* and *independent repeat demand*, and puts durable value only in the last. That is the correct lens.
- It states the downside case plainly ("subsidy can grow volume without creating durable value") and says it should be measurable.
- It commits to numeric thresholds and a time-boxed falsification rule. Few token theses do.

## 5. What a strong version would need

1. Correct mechanism text: hook unset, deployer-custodied fees, 75% forward, 50% base rebate, 100 IMD/day cap, dev sweep powers.
2. Disclosure of the `0x9fad` wallet relationship and whether it is operator-controlled, plus metrics computed both with and without it.
3. A true cohort table: first-payment date, subsidy rate received, subsequent payments at zero rebate.
4. A pre-registered subsidy step-down (for example 50% → 25% → 0% on announced dates) so residual demand can be read off directly.
5. A buyer-side quality metric (repeat rate, job continuations, `job.continue` share) instead of agent acceptance rate.
6. The missing end of the "depth check" section.

## 6. Unanswered questions [U]

- Is `0x9fad…f63f` controlled by the SIMD deployer, a contracted builder, or an unrelated user? On-chain funding links it to the dev. Control is unknown.
- Does any Robinhood-chain SIMD fee flow reach this vault?
- What did the dev do with the ~674 IMD of claimed fees that wasn't forwarded (104 to `0x9fad`, 30 to a V3 pool, the rest held)?
- Do refunded wallets keep paying once rebates stop? This can't be tested until rebates stop.
- Treasury payments on chains other than Ethereum (if any) were not counted here.

## 7. Method and limits

- On-chain data came from the Blockscout Ethereum API (`/api/v2/addresses/{addr}/token-transfers`, `/smart-contracts/{addr}`) and live `eth_call` reads via Foundry `cast` against a public RPC, on 2026-10-06 22:31 UTC.
- Vault: all 851 IMD transfers. Dev EOA: all 564 token transfers. Treasury: IMD inbound transfers back to 2026-09-26 (1,300 records).
- Contract claims are quoted from the verified source's NatSpec, and checked against storage reads where possible.
- Secondary sources (Bankless, KuCoin, project site) are used only for acceptance-rate and chain context. They are not independently verified.
- "Payment" means an IMD transfer into the treasury address. I did not decode x402 calldata to tell job types apart (job.open vs launch.open etc.).
- The 54-hour window is far too short for any retention conclusion. This report grades the thesis's claims and design, not the long-run outcome.