# Hard grade: payer provenance is a useful signal, not a demand measure

**Subject:** `[SIMD-THESIS]:muwhe0xo-7g5oj`  
**Author assessed:** `@chidifinance_`  
**Assessment date:** 2026-10-06 UTC  
**Verdict:** **7/10 — strong draft, below the pay bar of 8**  
**Flags:** `strong`, `thin`

## Executive verdict

The thesis is directionally right and unusually disciplined for a crypto-growth claim. It correctly rejects the shortcut `jobs = customers`, identifies the observable chain `payer → job → agent → execution → accepted output`, and states a falsifiable split between broadening external demand and activity funded by a common network. That is a real IMD-specific insight.

The important correction is that a payer address is not yet “payment provenance” in the economic sense. It is an on-chain funding endpoint. The explorer shows `paid by`, but the public evidence does not establish beneficial ownership, control, reimbursement, or the relationship between a payer and the person who requested the work. The thesis says this caveat, but its proposed cohort method still risks sounding more identifying than the data permits.

The POOL4 section is mechanically credible. The official docs state that excess IMD is trimmed, with an 85% burn / 15% reward split; the 15% is then divided 30% / 40% / 30% among stakers, bonding, and nodes—equivalent to 4.5% / 6% / 4.5% of the original reward batch. The docs call the latter two balances “bonding reserve” and “node reserve” and say they are booked and held. That supports classifying them as protocol-directed allocations, not evidence of customer revenue. It does **not** prove that any particular execution was funded by those reserves, nor that the wallets are protocol-controlled without address-level tracing.

The thesis earns 7 because the synthesis is concrete, honest about ambiguity, and testable. It misses 8 because it supplies no measured payer concentration, no address list or cohort sample, no independence heuristic, no amount-weighted denominator, and almost no explicit SIMD measurement despite being framed as an IMD/SIMD thesis.

## What is verified

| Claim | Status | Evidence and limits |
|---|---|---|
| The explorer exposes job-level payer addresses. | **Verified** | A completed job page labels a wallet `paid by` and links it to Etherscan. The page also exposes the job’s agent, accepted receipt, score, block, and work record. [Example job page](https://explorer.imd.fun/jobs/83f1d0a6-1216-4b69-99a6-4236e5a00d89) |
| The explorer connects execution to agents and accepted output. | **Verified** | The same job page shows agent `#1799`, a completed research-report attempt, a `work accepted` receipt, an accepted score, and an artifact. [Example job page](https://explorer.imd.fun/jobs/83f1d0a6-1216-4b69-99a6-4236e5a00d89) |
| The thesis’s 1,313 jobs / 1,230 completed / 83 incomplete / about 44.0K steps was a real explorer snapshot. | **Verified as a snapshot, not current** | Search-indexed explorer content preserved those figures. On the 2026-10-06 check, the live page showed 1,342 total, 1,251 completed, 83 incomplete, 8 running, and 43.9K steps in 24h. [Explorer](https://explorer.imd.fun/) |
| POOL4 trims excess inventory rather than treating it as an ordinary swap. | **Verified** | The official docs say sells above the cap are trimmed and retired, with proportional ETH recovered for the buy wall. [POOL4 docs, trim and burn](https://pool4.imd.fun/docs#trim-and-burn) |
| POOL4 uses an 85% burn / 15% reward split. | **Verified** | The official parameter table states `Burn / rewards 85% / 15%`. [POOL4 docs, parameters](https://pool4.imd.fun/docs#parameters-trust) |
| The reward split is 4.5% / 6% / 4.5% of the original batch. | **Verified by arithmetic** | Official docs state 30 / 40 / 30 for stakers / bonding / nodes. Multiplying each by the 15% reward slice gives 4.5%, 6%, and 4.5%. [POOL4 docs, split and parameters](https://pool4.imd.fun/docs#the-split) |
| Bonding and node allocations are held reserves. | **Verified** | The docs say distribution books bonding and node rewards as held reserves, with separate `Bonding reserve` and `Node reserve` fields. [POOL4 docs, distribute rewards](https://pool4.imd.fun/docs#distribute-rewards) |

## What is inference, not observation

1. **“Different payer addresses” means payer diversity, not customer diversity.** This is the thesis’s strongest point. A wallet can be a customer, operator, treasury, relayer, aggregator, or a funded sub-wallet. Address count is an upper bound on economic-funder count, not a customer count.

2. **Repeated funding from one address is evidence of concentration, not proof of one demand unit.** One customer can rotate wallets; many customers can use one service wallet. Repetition is still useful as a concentration signal, especially when joined to timing, task class, job amount, and funding provenance.

3. **POOL4 reserves are protocol-directed capital.** This follows from the documented destination and “held” language. It is not the same as proving that reserve tokens paid for IMD jobs. The report should say “exclude from customer-demand claims unless a transfer path into job payment is demonstrated,” not simply exclude all related addresses by label.

4. **Accepted output is better than job count, but not equivalent to product-market demand.** Acceptance shows that the system produced work that passed its current verification path. It does not reveal whether the work was externally commissioned, economically valuable, repeated by an independent buyer, or subsidized.

## Hard corrections to the thesis

### 1. Define the unit before grouping

“Payer cohort” needs an explicit hierarchy:

* `address`: exact payer wallet;
* `cluster`: only addresses linked by public evidence such as common control, explicit protocol role, or funding path;
* `economic source`: a much stronger label requiring evidence about the person or organization behind the cluster.

The analysis should publish address-level results first and call clusters “heuristic” unless the linkage is independently evidenced. ENS names, similar timing, or common task themes are not enough.

### 2. Weight money and work separately

Report at least four denominators: unique payer addresses, funded jobs, IMD paid, and accepted outputs/steps. A single wallet paying 500 tiny jobs and another paying 5 large jobs should not be reduced to a single count. The thesis is right that a burst of low-value work can inflate job growth, but it never specifies the needed value-weighted test.

### 3. Add concentration metrics

The minimum useful dashboard is:

`unique payers`, `jobs per payer`, `IMD per payer`, `accepted jobs per payer`, `repeat rate`, `top-1/top-5 payer share`, and a payer Herfindahl-Hirschman Index (HHI). Compute each for all jobs and for completed/accepted jobs, then split by task class and time window. This turns the thesis from a good warning into a measurable demand monitor.

### 4. Define “independent” conservatively

Use three buckets: `known protocol/infra`, `linked or operator-associated`, and `unresolved`. Do not promote unresolved wallets to “external customers.” A widening unresolved set is evidence of wider funding endpoints, not proof of wider demand. The falsifiable claim should compare the lower-bound count of independent cohorts with concentration and repeat behavior over time.

### 5. Make the SIMD connection explicit

The argument is mostly about Identity.md’s execution economy. It does not explain what SIMD can observe or why SIMD’s measurement layer changes the conclusion. A stronger version would specify a recurring SIMD report or scorecard: payer concentration, accepted-work concentration, task-class mix, repeat funding, and the share of flows attributable to protocol reserves. Without that bridge, the thesis is an IMD demand critique with SIMD in the title, not yet a developed IMD/SIMD thesis.

## A falsifiable measurement plan

For each job `j`, record:

`payer_address(j)`, `job_id(j)`, `payment_amount(j)`, `created_at(j)`, `task_class(j)`, `accepted(j)`, `accepted_steps(j)`, `agents(j)`, and `funding_path(j)`.

Then publish two views:

* **Address view:** exact observable facts, with no ownership inference.
* **Economic-source view:** only addresses/clusters supported by explicit evidence; everything else remains unresolved.

For a rolling window, call growth “demand-backed” only if all of the following improve together: the lower-bound number of independent cohorts rises; no small cohort dominates funded IMD or accepted work; repeat usage occurs across new jobs rather than only repeated variants; and protocol/linked/reserve-associated funding does not account for the increase. If only jobs and steps rise, the correct conclusion is increased execution activity or capacity utilization—not equivalent growth in independent demand.

The cleanest future test is a panel across weekly windows. Let `C_t` be the lower-bound independent-cohort count, `H_t` payer HHI, `R_t` repeat-job share, and `P_t` the share of paid IMD from known protocol/linked sources. Evidence for widening demand would look like `C_t ↑`, `H_t ↓` or stable, `R_t` reflecting new work rather than duplication, and `P_t ↓` or stable. The opposite pattern supports the thesis’s caution. This is a measurement proposal, not a result: the public pages checked here do not expose the complete dataset needed to calculate it.

## Bottom line

Keep the thesis. Its central sentence should be tightened to: **“Payer addresses are an observable upper-bound signal for funding diversity; they are not a customer count.”** Keep the POOL4 reserve separation, but label it as a protocol-flow classification and trace actual payments before asserting funding. Add an address-level sample, concentration numbers, payment amounts, and a concrete SIMD scorecard. Those additions could move the work from a strong 7 to an 8; without them, an 8 would overstate the evidence.

## Sources

* [IMD Explorer jobs](https://explorer.imd.fun/) — live counts and 24-hour steps, checked 2026-10-06 UTC.
* [IMD Explorer example completed job](https://explorer.imd.fun/jobs/83f1d0a6-1216-4b69-99a6-4236e5a00d89) — payer, agent, accepted receipt, score, and artifact fields.
* [POOL4 official documentation](https://pool4.imd.fun/docs) — trim, burn, reward distribution, reserves, parameters, and trust disclosures.
* [POOL4 official parameter section](https://pool4.imd.fun/docs#parameters-trust) — 85/15 and 30/40/30 splits.
* [Worker repository](https://github.com/Identity-md/worker) — public description of IdentityMD worker identity and accepted-output publication; used only as context, not as evidence for customer identity.
* [Source post](https://x.com/chidifinance_/status/2107403513605296288) — assessed thesis and author attribution; follower count was not used in grading.

```json
{"quality":7,"impactNote":"The thesis improves IMD/SIMD discourse by replacing raw job growth with a conservative funding-provenance and concentration question, while warning that wallets are not customers and POOL4 reserves are not automatically revenue.","notes":"Strong IMD-specific mechanism and falsifiable direction. Below the pay bar because it supplies no measured payer cohorts, payment-weighted concentration, address sample, independence heuristic, or developed SIMD measurement layer; current explorer counts also differ from the thesis snapshot.","flags":["strong","thin"]}
```