# Hard grade: "Most people watching IMD + SIMD are tracking the wrong metric"

**Thesis author:** @chukwue46258952 (~10 followers) — [tweet](https://x.com/chukwue46258952/status/2107605191264473553). The tweet itself could not be fetched (HTTP 402). This grade works from the thesis text supplied in the task.
**Data snapshot:** 2026-10-06, roughly 23:00–23:25 UTC (Ethereum block ~26,136,594). The SIMD program had been running for about **55 hours** at that point.
**Overall grade: D+**

The framing is right: retention matters more than activity. But two of the thesis's key factual claims are false when checked on-chain. Its "early signal" bullets don't measure what the thesis says they measure. Two of its four thresholds can't be measured under the current refund design. And it misses the biggest problem in the data: a large share of the subsidy goes to demand that already existed, or to the protocol's own wallet.

| Component | Grade | One-line reason |
|---|---|---|
| Core framing (conversion > activity) | B+ | Correct and useful. Not original. |
| Description of the capital path | D | The rail is real, but it is manual and custodial, not automatic. |
| "Full 0.5 IMD on every eligible job" | F | False. The base refund is 50%, and 481 of 582 refunds were 0.25 IMD. |
| "Clean, full-price batches" | F | False. Partial 0.25 refunds dominate, in batches of 1 to 50. |
| "Early signal" bullets | D | The acceptance rate measures agent sub-tasks, not buyers. "Independent wallets" was never tested. |
| Four thresholds | C− | Measurable in spirit, but internally inconsistent, and #1 and #4 are undefined under 50% auto-refunds. |
| Failure-mode / base-case honesty | B | Treating "pure faucet" as the base case is the right default. |
| Missed analysis | — | No pre-SIMD baseline, no deadweight check, no look at self-dealing or custody risk. |

---

## 1. What the rail actually is (facts, with sources)

All on-chain figures come from Ethereum mainnet, read through [eth.blockscout.com](https://eth.blockscout.com) and a public RPC (`cast call`).

**F1. The SIMD token.** Ethereum ERC-20 [`0xbB0c1F82A2ea0253ea3D91c2f05cADed82133415`](https://etherscan.io/token/0xbb0c1f82a2ea0253ea3d91c2f05caded82133415), supply 1B, 607 holders. It was deployed through a `LaunchFactory` contract ([`0xc6B0…977B`](https://eth.blockscout.com/address/0xc6B080DEd03C3382476A76345e79f82BD480977B)). Its main pool is SIMD/IMD Uniswap v4, created **2026-10-04 16:46 UTC** ([DexScreener pair](https://dexscreener.com/ethereum/0x99de115f6fcf3a505e94a16175fbb34a304425f9a72a2e091c60fb723dc39a4e)). The project site [si-md.xyz](https://www.si-md.xyz/) and the @SuperIMD_eth account point to this token. At the snapshot it had a market cap of about $279K, about $165K of 24h volume, and a 24h price change of **−56%**.
- *Name collision warning:* at least two other "SIMD" tokens exist. One is on Robinhood Chain (`0x577b…03ae`, [superimdc.xyz](https://www.superimdc.xyz/), X handle @superimdx, about $12–32 of liquidity) and makes the same "100% of job costs" claim. Another is an unrelated Ethereum `0xB602…f995` with no listed socials. Readers checking "public explorer data" can easily look at the wrong one.

**F2. The vault.** [`0xd60483Eb8004e3DE3e283b3efF0e67FBb57f9B21`](https://etherscan.io/address/0xd60483Eb8004e3DE3e283b3efF0e67FBb57f9B21) is a verified contract named **`IMDJobsPayer`**. Its creator and current `dev()` is `0xE132be23CE6255930556a45406075E62fb6340C0`. The address is the one the thesis cites, and it matches `VAULT` in si-md.xyz's `app.js` and the `/api/token` response.

**F3. What the contract says it does** (from its NatSpec): it refunds `paid × refundBpsAt(paidAt) / 10_000` IMD to **whoever paid** for any Identity.md action. Covered actions are job.open/continue, launch.open, oracle.request, workflow.open and schedule.create/topup. The **default rate is 50%** (`DEFAULT_REFUND_BPS = 5_000`). The dev can raise it, or run temporary boosts by time or by payment count.

**F4. Live parameters** (read via `cast call` at block ~26,136,594):

| Parameter | Value |
|---|---|
| `refundBps` | **5000 (50%)** |
| `countBoostBps` / `countBoostRemaining` | 10000 / **0** (a 100% boost for a number of payments was used up) |
| `boostBps` (time boost) | 0 |
| `refundCount` / `totalRefunded` | **582 / 171 IMD** |
| `maxRefundPerDay` | 100 IMD (remaining today: 31.5) |
| `hook()` | **0x0 (no SIMD hook wired, so no in-swap buying)** |
| `totalEthSpent` / `totalTokenBought` | 0.01 ETH / 2.95 IMD |
| `keeper()` | 0x0 (the dev operates alone) |
| `launchpadForwardBps` | 7500 (75% of fee claims forwarded, 25% kept by the creator "for marketing") |
| `paymentEndpoints().payTos` | `0x4e0fA57Bde726079356537E2F34d671E9F41ADbc` (the Identity.md treasury, as configured) |
| IMD `balanceOf(vault)` | **1,657.39 IMD** |

**F5. How money actually moves** (full transfer history of the vault and the dev wallet):
- SIMD trading fees accrue in a `FeeEscrow` contract ([`0xAcef…24BA`](https://eth.blockscout.com/address/0xAcefe251da006887dA41C063D06CC82A060824BA)), deployed by the same deployer as `LaunchFactory`.
- The **dev EOA claimed 2,500.2 IMD** from FeeEscrow in 279 claims between 2026-10-04 and 2026-10-06.
- The dev EOA then forwarded **1,825.4 IMD (73%) to the vault** in 276 plain `transfer` calls. Separately it sent **104 IMD directly to the SIMD payer wallet**, sold 30 IMD into a Uniswap pool, and burned 12.88M SIMD (its own allocation) to `0xdead`.
- Vault inflows: 277 transfers, 1,828.4 IMD. 276 came from the dev EOA, and 1 was the vault's own 2.95 IMD `buyToken` swap.
- Vault outflows: **582 refunds, 171 IMD total — about 9% of inflows.** By amount: **481 × 0.25 IMD, 100 × 0.5 IMD, 1 × 0.75 IMD**. The 0.5 IMD refunds all fall between 2026-10-04 17:06 and 2026-10-05 06:50 UTC, which matches the exhausted count boost. Every payout since then has been 0.25 IMD. There were 203 refund transactions, carrying 1 to 50 entries each.

**F6. The SIMD payer wallet** `0x9fAdAB91f6FA03DBd7F4F8a08A338704bAAcf63f` is a server wallet. si-md.xyz's own API says: *"Hire is paid by the server wallet in SIMD_PAYER_PRIVATE_KEY … The visitor does not sign."* ([/api/state](https://www.si-md.xyz/api/state), `constraints.payment`). It paid **287 × 0.5 IMD (143.5 IMD)** to the treasury and received **286 refunds (85 IMD)** from the vault. That is **49% of all refunds**. It opens contest, "hunt" and **thesis-grading** jobs ([/api/hire/sent](https://www.si-md.xyz/api/hire/sent)). The job that produced this report is one of them.

**F7. Network-wide payments to the treasury** (IMD transfers into `0x4e0f…ADbc`):

| Window | Payments | Paying wallets | IMD |
|---|---|---|---|
| Pre-SIMD: 2026-09-25 → 2026-10-04 16:00 UTC (~9.7 days) | 792 | 151 | 399.0 |
| Post-SIMD: 2026-10-04 16:00 → 2026-10-06 23:20 UTC (~2.3 days) | 588 | 77 | 315.0 |
| ↳ from the SIMD payer wallet | 287 | 1 | 143.5 |
| ↳ from all other wallets | 301 | 76 | 171.5 |

- Of the 76 other post-launch payers, **75 received refunds**, and 296 of their 301 payments were refunded. Their **net self-funded spend was 85.5 IMD** (171.5 paid, 86 refunded).
- **149 of those 301 payments (49.5%) came from wallets that were already paying before SIMD existed.** 23 of the 75 refunded wallets were pre-existing payers.

**F8. Acceptance rates.** si-md.xyz relays IMD's `/workers` data. Across 726 seats, 887,266 sub-tasks were judged: 878,887 accepted and 8,379 rejected, a "qualityRate" of 0.99. These are **agent sub-task attempts judged by IMD's own verifier**, covering the whole network, not SIMD-funded jobs specifically. [Bankless (2026-09-25)](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment.md) reported about 86% of ~50,700 attempts accepted. Also from Bankless and [KuCoin](https://www.kucoin.com/blog/imd-token-community-owned-ai-agents): public jobs cost 0.5 IMD over x402, and the agent network opened 2026-09-20.

**F9. The SIMD site contradicts itself.** Its own `/api/state` shows `vault.stats.fullPrice = 0` and `jobsPaid = 146`. It also shows `constraints.reward.status = "NOT IN FORCE"`, `payoutsSent = 0`, and `constraints.token.fees = false`, even though the vault has visibly paid 582 refunds. Treat the dashboard as unreliable and the chain as authoritative.

## 2. Claim-by-claim verdict

| # | Thesis claim | Verdict | Evidence |
|---|---|---|---|
| 1 | "SIMD trading fees flow into the designated vault (0xd60483eb…)" | **Partly true, materially misdescribed** | Fees go FeeEscrow → dev EOA → *manual* transfers to the vault (F5). The contract's in-swap hook is unset (F4). About 27% of claimed fees did not reach the vault, and 25% retention by the creator is written into the contract. The flow depends on one person's discretion; it is not mechanical. |
| 2 | "Currently covering the full 0.5 IMD price on every eligible job" | **False** | `refundBps = 5000`. Every refund since 2026-10-05 06:50 UTC has been 0.25 IMD. Full price only applied to the first 100 refunds (F4, F5). |
| 3 | "This is not a promise. It is already executing" | **True** | 582 refunds, 171 IMD (F4). |
| 4 | "Dozens of on-chain reimbursements have cleared" | **True (understated)** | 582. |
| 5 | "Vault has repeatedly held 500–1,300+ IMD ready for distribution" | **True but misread** | Now 1,657 IMD. The balance grows because outflows are only about 9% of inflows. A large idle balance shows *low uptake*, not strength. And the dev can withdraw all of it in one call with `ESVault()` (contract lines ~615–640). |
| 6 | "Agents routinely clearing 90%+ on large judged samples … even under subsidy" | **Number true, inference invalid** | The rate is internal verifier acceptance of agent sub-tasks across the whole network (F8). It is not buyer-judged quality, and not split between subsidized and unsubsidized jobs. It cannot say anything about retention. |
| 7 | "Multiple independent wallets have already used the reimbursement rail to ship real work" | **Partly supported, "independent" untested** | 75 non-protocol wallets were refunded (F7). But the largest recipient (49% of refunds) is SIMD's own server wallet, about half of the rest are pre-existing payers, and no Sybil or clustering check was done. "Real work" was not assessed. |
| 8 | "Vault outflows are occurring in clean, full-price batches rather than fragmented partials" | **False** | 481 of 582 payouts are 0.25 IMD (half price). The batch-size distribution runs from 1 to 50 entries (F5). |
| 9 | "The sample is still small" | **True, severely understated** | About 55 hours of program life. Every threshold in the thesis needs 21 to 90 days. |

## 3. The thresholds, stress-tested

1. **"≥30% of first-time reimbursed users return with a fully self-paid job inside 45 days."** *Undefined under the current design.* The vault refunds any IMD payment to the treasury (F3), and 296 of 301 non-protocol payments were in fact refunded (F7). As long as the vault is funded, there is effectively no such thing as a "fully self-paid job". A job only becomes fully self-paid if the refund queue skips it, which happens when the daily cap is hit, the payment is above `maxPaidPerPayment` (5 IMD), refunds are paused or reset, or the token changes. The metric needs to be redefined, for example as "a repeat payment after refunds stop", or "net-of-refund spend per cohort". "First-time" is also wrong for about half the cohort, who were paying before SIMD (F7).
2. **"Median time to second paid job under 21 days for converters."** Fine as a secondary metric, but it depends on #1's broken definition of "paid".
3. **"SIMD fee inflow covers ≥75% of daily reimbursements for any rolling 10-day window without vault draw-down."** *Internally inconsistent.* If fees cover 75%, the other 25% *is* vault draw-down. As things stand it is trivially met: about 1,000 IMD/day of fees were claimed in launch week against refunds capped at 100 IMD/day. That says more about speculative SIMD launch volume (−56% in 24h at snapshot) than about the model. The useful version is the threshold's ratio measured during a *non-launch* period at the *current refund rate*.
4. **"At least 40 unique non-subsidized paying wallets within 90 days."** *Currently 1, and structurally near 0* while auto-refunds run (F7). This is a function of how the program is built, not a demand signal. Also, the pre-SIMD period already had **151 unsubsidized paying wallets in 9.7 days**. Measured against that baseline, a 40-wallet target is too low.
- **The "fail two for a full month" rule** doesn't fit thresholds defined over 45- and 90-day windows. It can't be evaluated at one month.
- **"Leading indicator."** A 45-day repeat rate is not leading. It reports a month and a half late. Better leading proxies would be a cohort's 7-day repeat rate, net-of-refund spend per wallet, or the share of payments from wallets first seen after launch.

## 4. What the thesis missed (the most important critique)

- **Incrementality and deadweight.** Organic, unsubsidized demand already existed before SIMD: 792 payments from 151 wallets in about 9.7 days (F7). Since launch, about half of non-protocol payments come from those same pre-existing payers, so the subsidy rebates people who were paying anyway. The right question is not "do subsidized users convert?" but **"does the subsidy raise total net user-funded demand above the pre-SIMD baseline?"** In the post-launch window, net self-funded spend by non-protocol wallets was 85.5 IMD in about 2.3 days, roughly 37 IMD/day. Before launch, gross organic spend was about 41 IMD/day (399 IMD over 9.7 days). *Inference, low confidence (short windows, launch effects):* so far there is no evidence of an increase in net user-funded spend.
- **Self-generated demand.** 287 of 588 post-launch payments (49%) are the SIMD payer wallet buying jobs for its own contests and thesis grading (F6). That is the protocol paying itself, and it should be excluded from any demand metric.
- **Custody and governance risk.** The program is run by a single dev wallet: no keeper, and the dev sets the rate. The dev can sweep the whole vault with `ESVault()`, keeps 25% of fee claims by design, and has already routed 104 IMD of fees straight to the payer wallet. "Public and observable" is true. "Solved" is not.
- **Reflexivity.** Fee inflow depends on trading volume in a two-day-old memecoin. If SIMD volume fades, threshold 3 fails mechanically, whatever the demand quality.

## 5. Facts vs. inferences vs. unknowns

- **Facts (verified on-chain or from primary APIs):** F1–F7 and the verdicts on claims 2, 3, 4 and 8.
- **Inferences (reasoned, not proven):** the large vault balance reflects low uptake. About half the subsidy is deadweight. Net user-funded demand hasn't risen yet. Thresholds #1 and #4 are structurally undefined.
- **Uncertain:**
  - It is not certain that `0x4e0f…ADbc` is the *only* Identity.md payTo. It is the vault's configured endpoint, but payments to other addresses would be missed.
  - Pre-window coverage starts 2026-09-25, not at network open on 2026-09-20.
  - Wallet independence (Sybil clustering) was not analyzed.
  - The contract NatSpec says "1.2% of every $SIMD trade". Bankless describes a launchpad split of 1% to LPs, 0.5% to the launcher and 0.5% burned. The effective fee rate was not reconciled.
- **Unanswered:**
  - Any 21-, 45- or 90-day cohort outcome. None can exist yet.
  - Whether site visitors (identified by X account, paid for by the server wallet) ever go on to pay from their own wallets. That requires off-chain data that SIMD would need to publish.
  - Whether the dev will keep forwarding fees.

## 6. What a passing version of this thesis would say

"The rail is live. It refunds 50% of every IMD payment, not 100%. It runs at one dev's discretion, and about half of it currently goes to SIMD's own server wallet or to people who were already paying. Measure net-of-refund spend per wallet against the pre-SIMD baseline (151 payers and about 41 IMD/day), exclude the protocol's own wallets, and publish the cohort curves." Grade that version against the evidence above, not against the volume of activity.