IMD: a paid work pipeline, with an unproven contributor-pay loop

Research for @tagrunimd · 6 October 2026 · public records inspected on that date.

Verdict — inference: IMD demonstrates more than a conversational interface: one customer payment can be traced to an identified worker, an accepted source tree, and a merged delivery. But this case does not establish a self-sustaining agent economy. The customer’s 0.5 IMD reaches the service’s configured recipient; no job-specific payment to the worker was established. Acceptance certifies a narrow structural result, not working software or independent review. The receipts and limits follow.

Here, “agent economy” means attributable paid work, verifiable delivery, and observable compensation for its producers. That is this report’s analytical test, not an official definition. One case cannot establish network-wide profitability, autonomy, customer independence, or demand.

One job, from payment to delivery

Case: website continuation 906db5eb-dba7-41dc-bb3d-b581166c3c00, project version 5. The requested change removed Twitter sign-in, preview examples, and three directory categories while keeping All projects. This was an incremental website edit, not a new token launch. Job API, Explorer.

Stage	Observed receipt	What it establishes
Order	IMD lists order 62333110-77f8-4471-b5cf-b31cded4c53c, action job.continue, created 09:52:21.231 UTC; payment confirmed at 09:53:06; result names this exact job.	The service’s explicit payment-to-job association, rather than a guessed match by wallet or time. Paid-order API.
Settlement	Ethereum transaction 0x4426d8b7989c854c5f48dda964538aa1f7d900ee880917ab8b2979f92865e2ff, successful receipt, block 26,132,560. The IMD token’s Transfer log moves 500000000000000000 raw units from the customer to the configured recipient.	An RPC-observed token transfer: 0.5 IMD, using the API’s 18-decimal denomination. The chain receipt does not itself name the job. Saved RPC response, request metadata, transaction lookup, asset configuration.
Execution	Job opened 09:53:06.734 UTC; one implementation node accepted 10:08:46.362. Seat 150, registry agent 51354.	Recorded assignment and acceptance. Job API.
Worker	Submission ee324a443b89b10e8d7e942bbe6025638141a155128fcdf4980a08c91ff4e39e; device prefix 992fb0c2029425f3; runtime recorded as Codex / gpt-6-astra, seven turns.	Service-recorded attribution; not independent proof of who controlled the machine. Work record.
Source delivery	GitHub PR #5 merged at 10:09:14 UTC, 29 changed files, commit 125a93a27339de963e2072db09bcfcc3e3dbd57e. Its Git tree is c2aefc6686ca9eaf0380a27f61e70b0ac0e96a37, identical to the work record’s verified tree.	A concrete delivered source artifact matching the accepted tree identifier. PR, commit API.
Hosting	Job API records IPFS CID bafybeif42ineggdq4inbrmepqvgizieciej7rtoxiln5r33fvp3hcvtcoy, 493,957 bytes, named at 10:09:51.148 UTC.	Service-reported publication. I also fetched the live public configuration, but did not verify every hosted byte against IPFS or exercise the application in a browser. Job API, live configuration.

The request-to-merged-delivery interval was about 16 minutes. This is one observed latency, not a service guarantee.

Who gets paid?

Observed transfer: customer 0x424f7381b6cfe63963732c52613c87cb54c5c755 → recipient 0x4e0fa57bde726079356537e2f34d671e9f41adbc. Token contract: 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7. The recipient also submitted the Ethereum transaction; it differs from the token sender. The RPC returned chain ID 1 and receipt status 0x1. Receipt.

Documented mechanism: the current API advertises 0.5 IMD for job.continue, the same recipient, and x402/Permit2 payment authorization. Documentation says the server wallet pays gas. This describes the mechanism; the actual amount above comes from the receipt, not today’s price alone. OpenAPI, official documentation.

Worker compensation — unanswered: Explorer attributes seat 150 to holder 0xf40addecdca67bf9e7cc145eae607a83b7349540. That is a current service-reported holder, not a verified historical payee. Its earnings endpoint returns launch-token amounts, including entries on testnet; those rows are not evidence of a fee payment for this website edit or of realized income. The inspected response is only the first 100 rows. Agent page, earnings endpoint.

The docs separately describe a token-launch allocation: 2% shared among wallets with accepted work and 8% per connected seat at admission. That conditional launch mechanism cannot be substituted for payment on this case: the job API has launch.requested: false. No worker payout amount, claim transaction, fee split, or compute-cost reimbursement tied to this job was established. This is absence of verified payout evidence, not proof that the contributor was unpaid. Documentation, job record.

What was actually verified?

Recorded verifier facts: profile none, evaluation structural, status accepted, empty checks, and this precise detail: “paths and tree verified; no suite was run for this kind of work”. The execution contract required dist/index.html. The work record contains no assessments. Work record.

Worker claims: its summary reports typechecking, 23 tests, and responsive browser checks. These are self-reported checks, not results from the structural verifier. GitHub’s PR description also expressly limits structural acceptance to integrity/scope and disclaims general correctness. Explorer, PR.

This investigation’s checks: compared identifiers across payment, job, work record, and GitHub; decoded the payment receipt; matched the accepted and merged tree hashes; inspected relevant source diffs. The diff removes authentication gating and example-project initialization, which supports implementation of the request. I did not rerun the worker’s tests. Changed files.

At capture, the work receipt and structural score were still queued for on-chain publication. A successful customer payment is therefore distinct from an anchored work receipt, a reputation score, and contributor compensation. Explorer snapshot.

Where it breaks—or where proof stops

1. Payment does not prove producer income. The fee receipt identifies a service recipient. A job-linked onward transfer or reward claim is missing from the inspected evidence. It cannot establish worker margins or sustainable economics.
2. Acceptance does not establish live functionality. The fetched site configuration has empty supabaseUrl and supabaseAnonKey. The delivered submission component refuses publishing without backend configuration. Inference: this captured default configuration does not enable persistent submissions. Backend deployment is a separate dependency; the worker disclosed it. That does not by itself mean the requested UI removal failed. Live config, source diff.
3. Structural acceptance can coexist with a reported coordination failure. In a separate six-step image job, multiple workers say predecessor panels were missing, so they responded to the initial panel instead. Explorer nevertheless marks the job completed and all six structural scores passed. Observed: these admissions and statuses exist. Inference: structural checks did not enforce the intended narrative handoff. I did not reproduce the workers’ environments, so the underlying cause is unknown. This is a separate failure example, not part of the website payment chain. Image job.
4. Records describe different lifecycle moments. The work record has null publication commit/delivery fields while the later job API and GitHub show delivery. A completion receipt alone is insufficient to reconstruct the final outcome. This mismatch does not show that delivery failed. Work record, GitHub PR.

Remaining questions and confidence

To establish the stronger economy claim, IMD would need a job-linked contributor ledger/transfer or claim, the compensation rule for ordinary jobs, actual compute costs, and evidence of repeat demand from independent customers. To establish delivered functionality, it needs reproducible execution results or an independent review against the intended behavior.

High confidence in the observed records and their identifier links; limited confidence in broader conclusions. The evidence supports a paid agent-work delivery pipeline. It does not settle whether agents autonomously earn and spend, whether the customer and operator are independent, or whether the operation is profitable. No dollar valuation or investment conclusion is offered.

Evidence and method limits

This is a bounded case study, selected from the supplied public lead, not a random sample. Primary sources were fetched read-only: IMD APIs/docs/Explorer, GitHub, and one public Ethereum RPC provider. The RPC is an external corroborating source, not a locally validated chain or independent audit. Etherscan was inaccessible through the web tool; the transaction link is provided for reproduction, not represented as a page successfully inspected. Direct HTTPS retrieval recovered Explorer when the web tool could not read it.

The accompanying evidence/ files retain fetched bytes and URL/hash metadata. Hashes detect changes to this evidence package; they do not authenticate the publisher or prove source truth. The local check verifies evidence consistency and report links, not research truth or application behavior. No independent reviewer was used.