# Hard grade: "Separate $IMD execution from $SIMD verification" thread

- **Author:** @chukwue46258952
- **Tweet:** https://x.com/chukwue46258952/status/2107159717684404512 (the fetch returned HTTP 402, so this grade uses the text supplied in the task)
- **Graded:** 2026-10-05
- **Verdict:** **4 / 10.** Below the pay bar.

## 1. What the thread claims

1. $IMD is a labour market where you pay before you are admitted. `job.open` costs 0.5 IMD through x402 and Permit2, and seats are ERC-8004 registrations.
2. The live pipeline is not a propose/critique/decide committee. It "executes 2 jobs & ships immediately", trading consensus for latency.
3. Collision bounties (λ = 24/48-bit sha256) can be solved by a Python script in about 70 s, and their payouts have no smart contract. So they are an anti-sybil handshake, not proof of competence.
4. Real validation is asynchronous verifier reruns. The proposed frontier metric is the "Deterministic Verifier Agreement Rate" $V_{pass}$.
5. $SIMD is an unpermissioned telemetry and observer layer. It is also "strictly gated": you need at least 1000 $SIMD on Ethereum mainnet.

## 2. Claims checked against sources

| # | Claim | Status | Evidence |
|---|---|---|---|
| 1a | `job.open` = 0.5 IMD via x402 + Permit2 | **Confirmed (fact)** | IMD docs: "0.5 IMD each" via x402 with Permit2 on Ethereum mainnet. Flow is quote → 402 challenge → Permit2 + EIP-712 `QuoteApproval` → status `admitted` ([imd.fun/docs/#paid](https://imd.fun/docs/#paid)). Bankless and KuCoin also give 0.5 IMD via x402 ([Bankless](https://www.bankless.com/read/inside-imd-ethereum-s-new-ai-swarm-experiment), [KuCoin](https://www.kucoin.com/blog/vn-imd-token-community-owned-ai-agents)). |
| 1b | Seats are ERC-8004 | **Confirmed (fact)** | Docs: seats are ERC-8004 agent registrations, and workers pair devices with an EIP-712 `WorkerAuthorization`. Bankless says the same. ERC-8004 itself is a draft standard defining Identity, Reputation and Validation registries ([Polygon docs](https://docs.polygon.technology/payment-services/agentic-payments/erc8004)). |
| 1c | "Pay-before-admission" framing | **Confirmed (fact)** | Docs: the client polls until `status: "admitted"` after payment. "Admission" is the right word. |
| 2 | Pipeline "executes 2 jobs & ships immediately" | **Not supported, partly contradicted** | The docs describe workflow stages (contracts → deployment → frontend → publishing → validating) and multi-version projects. They also describe an evaluator at quote time, a planner, and an audit panel ("4 specialists + judge") for contract launches. The explorer shows labels like "v2 of 2" and "v4 of 5" ([explorer.imd.fun](https://explorer.imd.fun/)). The author appears to have generalised one "v2 of 2" pattern into a fixed 2-job rule. There is still a review/judge structure, which goes against "no intra-pipeline consensus". |
| 3 | Collision bounties: 24/48-bit sha256, ~70 s Python solve, no payout contract | **Unverified** | The public docs have nothing on collision bounties, λ, or sha256 targets. The ~70 s figure is plausible arithmetic for a 24-bit target (about 2^24 hashes). It is not plausible for a full 48-bit collision on one thread unless "48-bit" means something else, such as a birthday bound of about 2^24. The thread doesn't say. No script, link or transaction is cited. |
| 4a | Validation is verifier reruns | **Partly confirmed, but the timing is wrong** | Bankless: "a verifier rebuilds each submission in a sealed-off container… Other seats review the work adversarially, and accepted efforts get logged onchain as reputation." KuCoin says the same. That describes verification as a **gate before acceptance and reputation**, not something that happens after shipping. The thread's central "ships first, proven later" framing conflicts with this. |
| 4b | $V_{pass}$ as the frontier metric | **Author's proposal (inference). No data.** | No number, formula, endpoint or sample is given. The closest public number is an overall acceptance rate "near 86 percent" across more than 43,800 accepted submissions (KuCoin, late Sept 2026). The thread does not cite it or reconcile with it. |
| 5a | SIMD is the "observer layer" | **Partly supported** | superimdc.xyz: SIMD is "a protocol tracking IMD agents in real time, using protocol fees to cover 100% of Identity.md job costs", on **Robinhood Chain (4663)** ([superimdc.xyz](https://www.superimdc.xyz/)). The site describes tracking, but its stated purpose is **subsidising job fees**, which the thread leaves out entirely. |
| 5b | ≥1000 $SIMD on Ethereum mainnet gates the endpoints | **Unverified, and conflicts with sources** | No public source found mentions a ≥1000 SIMD gate. si-md.xyz (linked to @SuperIMD_eth) shows an Ethereum contract, but superimdc.xyz says Robinhood Chain. The chain is ambiguous across sites, and the gate has no evidence behind it. |
| 5c | SIMD is "un-permissioned" and "strictly gated" | **Internal contradiction** | The thread calls the same layer unpermissioned and token-gated, and never resolves the two. |

## 3. Assessment

### Strengths
- The mechanics in the opening are correct and specific: 0.5 IMD, x402, Permit2, ERC-8004, "admission". Those are real protocol details, not slogans.
- "A receipt proves admission; verifiers prove execution" is a useful distinction. It is the best line in the thread.
- Proposing a measurable metric instead of price talk points the discussion in the right direction.
- Treating cheap hash puzzles as anti-sybil friction rather than proof of skill is a fair point, even though it can't be checked.

### Weaknesses (why it is not 7+)
- **The core argument rests on an unsupported claim.** "Ships after 2 jobs, verified later" is the reason the thread gives for $V_{pass}$ being the frontier metric. The public descriptions put container rebuilds and adversarial review **before** acceptance. If that's right, the thesis gets the order of events backwards.
- **$V_{pass}$ is a name, not a model.** There is no definition of agreement (bitwise? test-pass?), no denominator, no data, and no way to read it. The roughly 86% acceptance figure already in public goes unmentioned.
- **Key "facts" have no source:** the 70 s solver, 48-bit λ, missing payout contracts, and the 1000 SIMD gate. None are linked or reproducible. The SIMD gate also contradicts the "un-permissioned" framing and the chain shown on SIMD's own site.
- **It misses SIMD's actual stated role** (protocol fees covering 100% of job costs). That is the most concrete link between IMD and SIMD, and the most interesting one to analyse.
- **No tradeoffs are worked through.** "Latency over consensus" is asserted, not analysed. There is nothing on the cost of a failed verification after shipping, or on who bears it.
- **Thread padding:** 🧵👇, "Here is the actual architecture", "not hype". The summary repeats earlier points without adding anything.

### Why 4 and not 5–6
The specific mechanics earn credit above pure fluff. But a thesis is judged on its central claim. Here that claim (async verification after a fixed 2-job ship) and the SIMD gate are unsupported or contradicted by the sources I could reach, and the proposed metric has no content. A competent but shallow outline (5) would at least not mislead on the architecture. This thread does, so it lands in the 3–4 range, at the top of it.

## 4. Facts, inferences, uncertainty, open questions

- **Facts (sourced):** 0.5 IMD `job.open` via x402 + Permit2 on Ethereum mainnet. ERC-8004 seats. Admission status flow. Verifier container rebuild plus adversarial review before on-chain reputation (per Bankless and KuCoin). SIMD on superimdc.xyz is a fee-subsidy and tracking protocol on Robinhood Chain.
- **Inferences (mine):** The "2 jobs" claim probably over-generalises the explorer's "v2 of 2" labels. The thesis's timeline of verification likely conflicts with how acceptance actually works.
- **Uncertain:** Whether collision bounties exist and what parameters they use. Whether any SIMD token gate exists. Which chain the canonical SIMD token lives on (the two sites disagree). Whether verification is truly a blocking step in the live code: my sources are secondary press articles plus docs, and I did not read the code.
- **Open questions:** What exactly is $V_{pass}$ measuring, and how does it relate to the ~86% acceptance rate? Who operates verifiers, and can they be paid or sybilled? How does SIMD's fee subsidy change the "pay-before-admission" price signal the thread treats as central?

## 5. Grade

```json
{"quality":4,"impactNote":"Gets the discussion onto concrete IMD mechanics (0.5 IMD job.open via x402+Permit2, ERC-8004 seats, admission vs. execution) and proposes a measurable verifier-agreement metric. That is a useful direction, but it is weakened by an unsupported description of the architecture that could mislead readers about how verification is ordered.","notes":"Strengths: the opening mechanics are accurate and match imd.fun/docs; the 'receipt proves admission, verifiers prove execution' framing is good. Weaknesses: the central claim that the pipeline ships after 2 jobs and is verified asynchronously conflicts with public accounts of container rebuilds and adversarial review before acceptance; V_pass has no definition or data and ignores the ~86% public acceptance rate; the collision-bounty numbers (70s, 24/48-bit) and the >=1000 SIMD mainnet gate are unsourced and could not be verified; it calls SIMD both 'un-permissioned' and 'strictly gated'; it omits SIMD's stated role of covering 100% of job costs; thread padding and a slogan close.","flags":["thin","padded"]}
```