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

• Tweet: https://x.com/0xdropxtor/status/2107415171983405076. The snowflake ID decodes to 2026-10-06 10:18 UTC.
• Graded: 2026-10-06, about 10:30–11:30 UTC.
• Verdict: quality 6/10, not pay-grade. The numbers are dense, honest and mostly verifiable, and there is one real finding (the 5000 bps refund versus the dashboard's "100%"). But the thread never answers its own question. Its comparison bands are too wide to tell anything apart. Its falsifiable test is set just below the current pace, so it barely tests anything. It also leaves out the mechanism that decides "broaden vs recycle": where the vault's IMD comes from.

1. What I checked, and how

I did not have Etherscan's UI or API, the SIMD dashboard, POOL4 trim or burn logs, or the payTo's outbound transfers. Claims that depend on those are marked unverified below.

2. Claim-by-claim audit

Facts I re-derived from primary sources

Inferences the thread makes but does not demonstrate

• "payTo … sent 642 to 0x047f, owner of the POOL4 hook. POOL4 sends 85% of each trim to the burn path." Placing these two facts side by side suggests Identity.md revenue ends up in the burn. Owning a hook is not the same as feeding it. The thread shows no transfer from 0x047f into POOL4 or the burn path. The revenue-to-burn link is implied, not shown. I did not verify the 642, the 85% or the 33,279 figures.
• "SIMD's vault, dev and payer haven't moved IMD to/from POOL4." This may be true, but it is a negative claim with no method given. I did not verify it.
• "Payers look broader: 57, above the earlier 15 to 56." Unique payers in a 41.6 h window are being compared with "earlier windows" that are never defined (length? start?). 57 versus a ceiling of 56 is a one-payer difference. It is not evidence of broadening.

Points the thread gets wrong or leaves internally unresolved

1. The refund average doesn't fit "half of each." If every action costs 0.5 and the refund is 50%, then 447 refunds should total 111.75 IMD, not 136.75. My log sample found one 6-IMD payment (multi-run), which accounts for about 2.75 IMD of the gap. That leaves about 22 IMD unexplained. The vault also exposes a second bps-like value, 7500 (selector 0x8b263a4a), so some payments may be refunded at 75%. This is uncertain: the getter is unnamed. But the thread's own "50% of each" is not shown to hold, and the author did not notice that their two numbers conflict.

2. The 41.6 h aggregate hides a strong trend. My sample splits into clean segments:

   Segment (UTC)	payTo inbound txs	SIMD payer share	Distinct non-SIMD payers
   Oct 4 23:43 → Oct 5 13:26	228	71.1%	10
   Oct 6 00:29 → 10:18 (tweet)	91	30.8%	29

   Fact: within the blocks I fetched, the SIMD payer's share fell by more than half, and non-SIMD payers roughly tripled. Inference: by the tweet, recent demand already looked much less "recycled" than the headline 56.5% says. This is the single most relevant piece of evidence for the thread's own question, and the thread doesn't show it. Caveat: 38% of blocks are missing (mostly Oct 4 16:42–23:43 and Oct 5 13:26–Oct 6 00:29), and an overnight-versus-daytime mix may be part of the swing.

3. The prediction test is weak. The bar is "non-SIMD paid actions ≥786 for Oct 13–20" while the current pace is 795. A bar 1% below the current pace mostly tests whether nothing changes. A test that could actually separate the two hypotheses would compare non-SIMD demand with the vault paused or with refunds cut, or would track non-SIMD payers who were not refund recipients. Credit is still due: it is a dated, numeric, falsifiable claim, which most threads don't offer.

4. "Inside the 31 to 263 of earlier windows." A band that spans 8.5× contains almost any value. It tells the reader nothing.

3. Did the thread answer "broaden or recycle"?

No. It poses the question in post 1 and never gives an answer. Here is what the evidence supports.

• Fact: the vault refunds a share of payments. 56% of the refunded IMD went to SIMD's own payer, so for about half the volume, SIMD-owned IMD flows vault → payer → Identity.md payTo → part back to the payer. The flow recycles within SIMD; Identity.md still receives the gross 0.5 IMD per action.
• Fact: about 80% of the SIMD payer's recent jobs are SIMD's own contest or grading tasks, including this one. Those actions are internally generated demand. They are not outside users buying agent work.
• Fact: 44% of the refunded IMD went to other wallets, and non-SIMD payers rose in my latest segment. Inference: the rebate may be pulling in outside payers, which is a broadening channel. The thread hints at this but never builds the argument.
• Unanswered, and decisive: where does the vault's IMD come from? It currently holds 1,591.5 IMD (balanceOf(0xd604…)). If the vault is funded by SIMD-side fees or trading volume that would not otherwise buy IMD, SIMD's activity is net new IMD demand even if its payer is circular. If the IMD came from existing holders or treasury, the loop is a subsidy that shuffles existing IMD around. The thread never asks this.
• Unanswered: does SIMD's dashboard "100%" refer to something other than refundBps (for example a share of fees routed to the vault)? Without the dashboard text I cannot tell whether this is a mislabel or a different metric.

4. Grading against the rubric

Strengths

• Every post cites a primary source: a contract read, an API endpoint or a token page. Nothing in it is a slogan.
• The refundBps = 5000 versus "100%" discrepancy is a real, checkable and useful catch.
• The thread is aware that the SIMD payer funds grading of SIMD's own thesis contest. That is self-critical about the very program that pays for the thread.
• Its figures held up wherever I could check them: 447 refunds, 136.75 IMD, the hook owner, the pace arithmetic, a SIMD share of roughly 57–60%.
• It offers a falsifiable, dated test.

Weaknesses

• It is a data dump without a thesis. The question is never answered and no model ties the numbers together.
• The vault's funding source, the mechanism that decides the question, is missing.
• Its own refund numbers contradict each other (111.75 expected versus 136.75 reported), and the author didn't notice.
• The comparison bands (31–263; 15–56) can't distinguish anything, and the test threshold sits just under the current pace.
• The aggregate hides the sharp intra-window fall in SIMD's share.
• The revenue → 0x047f → burn link in post 2 is suggested by placement, not demonstrated.
• It understates the self-referential share (about 80% of the payer's jobs, not 55%).

This is above the "fluff" tier (3–5) because the mechanisms and numbers are real and specific to IMD and SIMD. It falls short of 7 because a "strong draft" needs a clear argument, and this thread lists facts without concluding. It is well short of 8, which requires novel synthesis and depth: the key mechanism is missing and the test is close to trivial.

{"quality":6,"impactNote":"Useful for IMD/SIMD discourse as a sourced fact sheet. It confirms on-chain that SIMD's vault refunds 50% (refundBps=5000, 447 refunds, 136.75 IMD), not the '100%' the dashboard reportedly shows. It also makes SIMD's self-funded share of Identity.md demand visible: about 57-60% of paid actions, and about 80% of the SIMD payer's jobs are SIMD's own contests. It does not settle broaden-vs-recycle because it never traces where the vault's IMD comes from.","notes":"Strengths: dense primary-source citations; refundBps discrepancy is a real catch; headline figures reproduce (447 refunds, 136.75 IMD, POOL4 hook owner 0x047f, 795/wk pace math, SIMD payer share ~60% in a 62%-coverage log sample); includes a dated falsifiable test. Weaknesses: never answers its own question; omits the vault's funding source, which decides the question; its own refund numbers conflict (447 x 0.25 = 111.75, not 136.75; the vault has an unexplained 7500-bps parameter); comparison bands 31-263 and 15-56 are uninformative; the >=786 test sits just under the 795 current pace; the 41.6h aggregate hides SIMD's share falling from ~71% to ~31% within the window; the revenue->0x047f->burn link is implied, not shown; self-referential share understated (80/99 SIMD-tagged jobs, not 55/100). A competent fact sheet, not pay-grade analysis.","flags":["thin"]}