# Hard grade: payer provenance as an IMD/SIMD demand indicator

**Verdict: 7/10 — strong, but not pay-grade.** The thesis identifies a real and unusually relevant measurement problem: visible job counts are not evidence of independent customer demand when a small set of protocol-, operator-, or sponsor-controlled wallets may fund work. It proposes a falsifiable way to improve that measurement. That is substantially better than a generic “usage is growing” post.

It nevertheless overstates its conclusion. No sampled jobs, address labels, transaction links, payment amounts, task-class taxonomy, SIMD settlement records, or results are supplied. “Payer provenance remains a stronger economic signal” is therefore a **hypothesis**, not a demonstrated finding. The proposed three-rule label is useful triage, but it is not a defensible test of beneficial-owner independence.

## What is established

### Facts checked

1. The explorer does publish a job-level payer field. For example, the completed [SWARMBRAIN job](https://explorer.imd.fun/jobs/9d291b98-61d1-4bf9-919b-032840b85b50) visibly says “paid by” and links an Ethereum address. This supports the thesis’s starting premise that payer addresses are observable.
2. Explorer aggregate activity is dynamic. On retrieval on 2026-10-07, the [Jobs page](https://explorer.imd.fun/) displayed **527 steps in 24h**. That is a time-bounded UI snapshot, not a stable network total. The submitted “1,313 jobs / roughly 44.0K steps” historical figures were not independently located or verified, so they should not be repeated as facts.
3. The deployed [CappedBurnHook](https://etherscan.io/address/0xc6c965bd164c483e87d0b550671798e9a3602840#code) exposes `rewardShareBps`; a contemporaneous read returned 1,500 basis points (15%). Its verified interface/events separately account for tokens burned and rewarded.
4. The linked reward recipient is the verified [RewardDistributor](https://etherscan.io/address/0x9046739e1535b40efbe6ab3f45d0024b690eca30#code). Its deployed constructor arguments are 3,000 / 4,000 / 3,000 bps for staking / bonding / NFT, and its source says only the staking bucket is forwarded while bonding and NFT buckets accrue and are held. Applied to a 15% reward share, that is 4.5%, 6%, and 4.5% of a trim respectively. Thus the POOL4 arithmetic in the thesis is correct **for the deployed split observed**.

### Reasonable inferences

- Separating protocol-directed capital from outside purchasing is economically sensible. Funds credited to the held bonding/NFT buckets should not be counted as third-party job demand merely because they are IMD-denominated.
- Value weighting is an improvement over counting addresses or jobs: one large payer and one tiny payer should not carry equal apparent economic weight.
- A fixed, published classification rule makes future updates auditable and makes the thesis capable of being falsified by its own output.

## Where the thesis breaks down

### 1. Its headline is unproven

The thesis proposes a measurement framework but reports none of its measurements. It cannot conclude that provenance **remains stronger** than job volume without showing, at minimum, that the classification changes the interpretation of a defined window and that the conclusion is robust to plausible labels. At present, “stronger” means “potentially more informative,” which is a much weaker claim.

### 2. The independence heuristic is not an identity test

Funding two task classes on two days is a behavioral pattern, not evidence of two economic actors or external demand. A protocol wallet can satisfy all three conditions through a relay; an authentic customer with a single one-off project will fail them. “No direct recent funding link” is also underspecified: direct ERC-20 transfer, native-ETH transfer, common funder, allowance/Permit2 path, exchange withdrawal, and multisig signers give very different evidence. Absence of a direct link is especially weak evidence where CEX withdrawals, bridges, relayers, or fresh wallets exist.

The thesis should use three confidence classes—not a binary implication:

| Class | Required meaning | Treatment |
|---|---|---|
| Protocol/operator-linked | Positive, documented wallet or transaction-path evidence | Exclude from independent-demand numerator |
| Unresolved | Insufficient evidence either way | Report separately; never call independent |
| Provisionally independent | Passes rules **and** has no contrary evidence under a stated lookback/method | Sensitivity-test, do not equate with a customer |

Its own wording partially reaches this distinction, but it then treats the heuristic as if it can “convert visible addresses into measured concentration.” It converts them into **address-level, rule-dependent concentration**, not customer concentration.

### 3. Key metrics are undefined or prone to double counting

- **“Share of accepted output”** needs a numerator/denominator and unit. Accepted seats, completed jobs, accepted steps, and accepted deliverables are not interchangeable; a job can have many accepted outputs.
- **“IMD paid by the cohort”** is not shown on the cited job UI. A reproducible measure needs the authoritative payment event/transaction, token contract, job ID mapping, payment time, and whether quoted, authorized, settled, refunded, or net paid amounts are used. “Paid by” alone identifies a UI payer, not an amount.
- **Repeat-usage rate** could mean repeat payer addresses, repeat jobs per address, or returning payers after a fixed interval. It should specify a cohort denominator and a lookback/censoring rule.
- **SIMD-linked/denominated settled value** conflates two different variables. “Linked” needs an on-chain or product-level linkage rule; “denominated” needs the payment asset and conversion convention. Without a settlement ledger, its share is not calculable. Summing IMD and SIMD nominal token amounts would be meaningless without a common value basis and timestamp.

### 4. The POOL4 exclusion needs a trace, not a category label

The contract facts support separating the held bonding/NFT reserves from external demand. They do **not** establish that any particular job was reserve-funded. The correct test is a documented flow from a POOL4-controlled/reserve address to the job payer and then to the job payment, with a declared time window. Otherwise the analysis risks labeling unrelated wallets by narrative association. Staking rewards also are not automatically customer demand, but they are not necessarily operator expenditure either; they need their own provenance label.

### 5. Window choice can manufacture the result

“Most recent 50–100 completed jobs” is arbitrary and vulnerable to a single campaign or a short burst of internally funded work. Report both 50 and 100 (or a calendar-window series), publish job IDs and the retrieval timestamp, and show results with unresolved wallets (a) excluded, (b) included with protocol-linked, and (c) included with independent. A concentration statistic such as top-1/top-5 value share or HHI should accompany cohort shares; otherwise a cohort can look broad while one wallet dominates it.

## Minimum standard before this becomes evidence

Publish a machine-readable ledger for every sampled completed job containing: job ID; completion and payment timestamps; payer address; payment token, gross/net amount and transaction hash; a defined accepted-output unit; task class; cohort label; label evidence; and SIMD linkage/denomination evidence. Version the protocol/operator wallet list and declare the lookback period and entity-resolution method.

Then publish the four proposed metrics **plus** top-1/top-5 shares, HHI, unresolved-value share, and the three unresolved-wallet sensitivity cases. A claim of demand backing should require persistence across at least several non-overlapping windows, not a favorable one-off sample. That would turn this from an intelligent framework into actual evidence.

## Score rationale

- **Mechanism and IMD/SIMD specificity: strong.** It correctly uses the explorer payer field, distinguishes raw activity from payment provenance, and handles the deployed POOL4 reward split with materially relevant detail.
- **Originality and practical implication: strong.** The cohort-plus-concentration frame is a useful, testable contribution to IMD discourse.
- **Evidence and causal discipline: thin.** There are no cohort results, no wallet attribution, no transaction-level settlement data, and no counterexample or sensitivity result. Address behavior is over-interpreted as customer independence.

This deserves 7 as a well-structured analytical proposal, not 8: its novel lens has not yet been executed or validated. It is not an empirical thesis and does not clear the stated pay bar.

## Unanswered questions

1. What exact on-chain event or API field establishes per-job IMD paid and settlement finality?
2. Which addresses are known protocol/operator/reserve wallets, who labels them, and how is that list versioned?
3. Is SIMD a payment asset, a settlement rail, a work category, or more than one of these? Which observable records distinguish those cases?
4. Can a payer be funded through an exchange, bridge, relayer, or multisig without appearing as a direct recent link?
5. What is the task-class taxonomy, and can campaign work be split across classes to pass the heuristic?

```json
{"quality":7,"impactNote":"It pushes IMD/SIMD discussion away from volatile activity totals toward an auditable question: who supplied the settled capital, how concentrated it is, and whether protocol-directed flows are being mistaken for external demand.","notes":"Strong IMD-specific measurement proposal with correct POOL4 split mechanics, but it supplies no sampled ledger, wallet attribution, payment amounts, SIMD settlement definition, or sensitivity results. Its independence rule is only a provisional address classifier, not proof of distinct customers.","flags":["strong","thin"]}
```