# Hard grade: demand, execution and POOL4 reserves

**Quality: 7/10. Below the pay bar of 8.** This is a strong, technically grounded draft, not an exceptional economic analysis. Its useful contribution is separating customer payments, execution counters and earmarked capital. Its weakness is treating their relative growth as a test of sustainability without measuring costs, payer independence or comparable units of output.

Assessment date: 2026-10-06. Evaluated text: the thesis supplied in the assignment, attributed to [@chidifinance_'s post](https://x.com/chidifinance_/status/2107382993950224739). Direct retrieval of that post returned 403; this report does not certify that the supplied text matches the live post. No follower count or engagement estimate affects the grade.

## Evidence and claim status

| Claim | Finding and attribution | Limit |
|---|---|---|
| September recorded 100 jobs, 91 completed, 2,669 accepted submissions in 24 hours and 38 paid orders. | **Unverified historical claim.** Searches and the current [official explorer](https://explorer.imd.fun/) did not recover that dated snapshot. | The explorer is a changing present-day view, not corroboration of September. This is missing evidence, not proof the numbers are false. The thesis also does not establish that all four counters cover the same window or cohort. |
| POOL4 allocates retired IMD 85% to burn and 15% to rewards, including 6% for bonding and 4.5% for NFT nodes. | **Supported as documented policy.** The [official POOL4 docs, §§3–5](https://pool4.imd.fun/docs) describe excess pool inventory being retired and the reward allocation. The omitted 4.5% goes to stakers. | These are percentages of retired IMD, not percentages of customer receipts or all trading volume. The documentation labels parameters as launch values and describes bounded owner adjustments. Current deployed settings were not independently read. |
| Bonding and the node program are not live. | **Supported by the documentation retrieved on the assessment date.** [POOL4 §§7–8](https://pool4.imd.fun/docs) describe held IMD, future conversion through bonds into ETH for inference, and an unlaunched node payout program. | A documentation statement is not a deployment audit or a dated September archive. An accumulating token balance is neither realized spending nor delivered computation. |
| Paid requests can be distinguished from execution. | **Supported at the interface level.** The [official API docs](https://imd.fun/docs/) describe x402 paid actions, a payer field on jobs, submission verdict/usage records, and hourly accepted-step counts. | Payment and acceptance records do not establish independent customers, useful final output or profitability. The historical counter's definition remains unverified. |

## Why this earns 7

The argument identifies actual IMD mechanisms and makes a concrete recommendation: attach execution to its funding source rather than present busy workers and reserve growth as interchangeable adoption signals. It recognizes the tradeoff between protocol-supported bootstrapping and evidence of customer-supported operation. Naming POOL4, x402, the orchestrator allocation and the unlaunched node program makes this more than generic “AI agents need revenue” commentary.

Its technical honesty is strongest where it refuses to equate earmarked IMD with productive compute. Its conditional conclusion also avoids claiming that the snapshot already proves commercial traction. Those merits justify a strong-draft score even with the historical evidence gap.

## Why this does not earn 8

1. **The core synthesis is useful but familiar.** Activity versus revenue versus subsidy is standard economic accounting. Applying it to POOL4 adds specificity, but the essay supplies no original dataset, implemented attribution scheme, quantitative model or worked counterexample.
2. **Requests are not revenue coverage.** More paid requests and repeat customers can coexist with rising losses if prices are too low or execution becomes more expensive. Conversely, flat request counts can support a viable business if paid value or efficiency rises. Relative count growth is a directional signal, not a sufficient or necessary sustainability test.
3. **Acceptance is not normalized productive output.** Jobs, internal steps, reviews and final deliverables need not map one-to-one. A change in task decomposition can raise submissions without raising customer value. The thesis names output quality but does not define it or control for workload mix.
4. **Independence is asserted, not operationalized.** A paid wallet may belong to the protocol, receive reimbursements or spend grants. Repeat wallets need not be repeat independent customers. The essay offers no treatment of affiliates, incentives, refunds or common ownership.
5. **It slips from reserves to reserve-supported execution.** Its own account says the cited programs are unlaunched. That supports rejecting reserve growth as compute; it does not establish that these reserves currently carry execution costs. Actual disbursements and other funding sources must be traced before describing current dependence.

These are substantive omissions, not reasons to reward added length. The final paragraph repeats the main distinction rather than developing it. SIMD is named in the assignment but the thesis offers no separate SIMD-specific mechanism; this grade credits the concrete IMD analysis only.

## What would make the test genuinely falsifiable

The following is an evaluator proposal, not an observed result. Define a fixed observation window, settled net payment value, independent-payer rules, customer cohorts, and comparable delivered-output units. Join order/payment identifiers to job trees, final outputs and execution usage. Separate reserve accrual from actual spending and classify external payments, protocol purchases, grants and contributor-funded inference without double counting.

Then report independent net revenue divided by the full cost of delivering the associated work, alongside retention and customer acceptance. Include contributor-borne inference, retries, review, orchestration and delivery costs. A specified threshold such as coverage of at least 1 over a predeclared period, with acceptable output quality, would test operating cost coverage; it would still not prove indefinite sustainability. Protocol funding can rationally build reusable infrastructure, so evaluate its later customer benefit rather than treating every subsidized task as economically worthless.

Unanswered questions are the snapshot's dated source and counter definitions; payer affiliation and refunds; costs borne outside the protocol; reserve disbursements; and whether accepted outputs solve customers' problems. Without those answers, neither present self-sustainability nor present reserve dependence is established.

**Impact:** The thesis improves IMD discourse by discouraging dashboard activity from being sold as demand and token earmarks from being sold as compute. Its practical value is a measurement agenda. It is not yet evidence that the proposed economic transition is happening, and it does not cross the pay-grade originality/depth threshold.

```json
{"quality":7,"impactNote":"Improves IMD discourse by separating customer demand, execution counters and POOL4 reserve accrual; provides a useful measurement agenda rather than evidence of sustainability.","notes":"Strong IMD-specific argument with documented reserve mechanics and honest launch-status distinctions. Below pay grade: historical snapshot unverified, familiar synthesis, no cost-coverage model, payer-independence rules, normalized output or traced reserve-funded execution.","flags":["strong"]}
```