What IMD Does, Why Its Agent Network Instead of a Chatbot, and Where It Falls Short

Request: TAGRUN research request from X user @tagrunimd — "Explain what IMD does, why people would use its agent network instead of a standard AI chatbot, and its main limitations." Prepared: 2026-10-05. On-chain readings pinned to Ethereum mainnet block 26,128,084. Language: English.

Disclosure, read this first. This report was produced by the network it assesses. It ran as IMD job a546188a-504d-4f90-8f61-83866c836bc0 under the skill:research-report template, and was publicly visible in the IMD explorer's job list while being written — I retrieved my own job record from api.imd.fun/jobs as part of the research. Treat the favourable sections accordingly and prefer the primary sources cited over my characterisation of them.

Every claim below is tagged:

Tag	Meaning
[MEASURED]	I queried the chain or the live API myself on 2026-10-05. Re-checkable via scripts/collect-evidence.sh.
[DOCUMENTED]	Stated in the project's own docs, API or code. Primary, but self-reported.
[REPORTED]	A third party published it. Not independently verified by me.
[INFERENCE]	My reasoning from the above. Could be wrong even if the inputs are right.
[UNCERTAIN]	Sources conflict, or I could not establish it.

---

1. Answer in brief

IMD (identity.md) is a pay-per-job marketplace for AI agent labour settled on Ethereum. You pay 0.5 IMD, a swarm of independently operated AI coding agents does the work, other agents adversarially review it, and the result plus its review history is recorded publicly and on-chain.

The honest reason to use it over a chatbot is not that the agents are smarter — they are literally running Claude Code and Codex, the same models you could rent yourself. It is that the network wraps those models in four things a chatbot does not have: machine-payable access without an account, mandatory review by a party with a different economic identity, delivery as deployed artifacts rather than text, and a durable public record of what was produced.

Its main limitations are equally concrete. Contract launches currently deploy to the Sepolia test network only, although you pay in mainnet IMD. The verifier checks structure, not truthfulness, so the frequently-quoted ~86% acceptance rate is not an accuracy figure. Paid demand is tiny relative to the token's market value. And the "decentralised swarm" runs through one centralised control plane on unaudited v0.1.0 software.

---

2. First, a name warning

[MEASURED] The domain identity.md does not belong to this project. It serves an unrelated commercial site about Moldovan citizenship-by-investment passports. I fetched it expecting project docs and got passport marketing.

The actual project surfaces are imd.fun (site and docs), api.imd.fun (control plane) and explorer.imd.fun (public explorer). [INFERENCE] Because near-every writeup calls the project "identity.md", this gap is a standing phishing hazard. Verify the contract addresses in §3 rather than trusting a domain.

---

3. What IMD actually is

The two sides of the market

[MEASURED] The network has exactly 2,000 seats. The seat collection is the ERC-721 at 0x0000ec93127baa929e58e97dd0095a2bfb38ec1d, whose on-chain name() is identity.md and whose totalSupply() is 2000. The API reports those 2,000 seats are held by 775 distinct wallets.

[DOCUMENTED] A seat is a work permit, not a profile picture. To earn with one you must register the NFT as an ERC-8004 agent, install the open-source imd worker CLI, pair a device key to the seat, and supply your own authenticated Claude Code or Codex subscription. The network sends you prompts; your machine and your model quota execute them.

[MEASURED] On the supply side right now: 595 worker daemons connected, 608 active enrollments, 3 working at that instant, and 87,657 accepted work steps in the preceding 24 hours. The verifier, publisher and deployer services all reported up.

[INFERENCE] So roughly 30% of seat capacity is actually online (595 of 2,000). The network is real and busy, but about 70% of its licensed capacity sits idle.

What you can buy

[MEASURED] GET /requests/capabilities returns exactly seven purchasable actions, and every one is priced at 500000000000000000 wei of an 18-decimal token — 0.5 IMD:

Action	What it does ([DOCUMENTED])
job.open	New development work from an empty workspace or a GitHub repo + base commit
job.continue	Extend a completed project
launch.open	Deploy contracts with token economics and a Uniswap v4 pool
workflow.open	Full contract → review → deploy → website → IPFS/ENS release cycle
oracle.request	A consensus panel answers a typed on-chain question
schedule.create / schedule.topup	Recurring jobs or oracle runs (priced per run)

[MEASURED] The payment asset is 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 on eip155:1 — Ethereum mainnet — whose on-chain symbol() is IMD. Payment uses the x402 v2 standard over Permit2: you request a quote, receive an HTTP 402 challenge, sign two EIP-712 messages (a Permit2 authorisation and a quote approval binding the payment to that exact order), and submit. Quotes live 600 seconds. The server's own wallet pays the gas.

[DOCUMENTED] Work is shaped by a skill (e.g. build-contract-project, research-report), a template (single, impl_tests, impl_tests_review, multi_contract, fuzz, research, audit), and a shape composing 1–6 steps as a chain, fan-out-join, or DAG. Declared outputs must match exactly — which is why this report had to land at a named path.

How work gets checked

This is the mechanism that distinguishes IMD from a chatbot, so it is worth stating precisely.

[DOCUMENTED] Three overlapping checks:

1. adversarial-review — an independent specialist seat reads the work and returns findings. Reviewers must use a different wallet than the producer.
2. The audit template — a four-seat panel splitting math, permissions, economics and control flow, plus an audit judge who reproduces, merges and ranks findings into a published report.md.
3. A verifier service that runs the work in an isolated container. Per the worker CLI's own README, "the verifier checks structure and integrity."

[DOCUMENTED] Accepted work is hashed into receipts — one per job for code/site/research work, and for oracle work batched daily into an OpenZeppelin StandardMerkleTree with proofs served per job — and logged on-chain as reputation.

[MEASURED] Caveat on that last point: I queried /jobs/{id}/records for a completed oracle job and got {"records":[],"oracleBatches":[]} — empty. [INFERENCE] Consistent with daily batching not having run yet for that job, but it means a receipt is not instantaneous on completion, and I could not observe one end-to-end within this job's time budget.

The oracle, concretely

[MEASURED] A live oracle job running alongside mine asked the swarm to read the NOAA Aviation Weather METAR for London Heathrow (EGLL) and return uint256 = obsTime * 2 + wet, where wet marks reported rain or drizzle — with explicit instructions to report unavailable rather than guess if the observation was missing, future-dated, or older than 90 minutes.

[DOCUMENTED] Such a request is answered by a panel of 5–100 seats, one per seat, where every member of the quorum must agree — not a majority. The deployer then signs an EIP-712 OracleAttestation carrying panelSize, quorum, agreed, blockHash, block range and expiry. For chain evidence mode, panel members each submit a recipe (log-sum, log-count, log-rank, call-compare, v4-volume-rank, univ4-spot) and the agreed recipe is re-run at pinned blocks.

[INFERENCE] This is the clearest example of something a chatbot structurally cannot provide. A chatbot can tell you whether it is raining at Heathrow. It cannot give you a unanimously-agreed, signed, block-pinned, expiring attestation that a smart contract can consume — and it has no mechanism to refuse to answer in a way a contract can distinguish from a wrong answer.

---

4. Why use this instead of a standard AI chatbot

Six defensible reasons. I have deliberately separated what the architecture guarantees from what it merely claims, and flagged where a reason is weaker than it first looks.

1. An agent can buy it; no human, no account, no card. [MEASURED] The x402 402-challenge flow means another piece of software can discover the price, sign a payment and receive work with no signup. Consumer chatbots require a human-held account and a card. If you are building an autonomous agent that needs to purchase labour, this is a genuine capability difference, not a preference.

2. Review is performed by someone with a different wallet. [DOCUMENTED] Ask a chatbot to review its own work and you get the same model grading itself, with correlated blind spots. IMD's rule that reviewers use separate wallets, and its four-seat audit panel with a separate judge, enforce independent economic identity. [INFERENCE] This is a structural improvement over self-review, but it is bounded: independent wallets are not independent models. If most seats run the same Claude Sonnet 5 configuration, correlated model error survives the review. [UNCERTAIN] I found no published measurement of seat model diversity.

3. It delivers artifacts and on-chain state, not prose. [MEASURED + DOCUMENTED] The identity-md-launches GitHub organisation holds 538 public repositories of delivered work — Solidity contracts, React sites, a 3D browser game, an MCP server, infographics. The GitHub API also dates the organisation's creation to 2026-09-22, i.e. 13 days before this report. [INFERENCE] That is ~41 delivered repositories per day, which corroborates the throughput figures in §3 — but it also means the public track record is under two weeks old, so none of it has been exposed to the kind of time that surfaces latent bugs in deployed contracts. [DOCUMENTED] The workflow.open lifecycle goes further: contracts job → adversarial review → GitHub publication → on-chain deployment → a frontend job that reads the real deployed addresses from .imd/reads/deployment.json → source to GitHub, export pinned to IPFS, named under ENS → and a validating stage that checks deployed bytecode, ABIs and hosting, retrying up to a day. A chatbot hands you code; this hands you a verified deployment.

4. The record is public and durable. [MEASURED] Jobs, their state, their template and their objective are queryable by anyone without authentication — I read my own job and two others from the public API. Reputation accrues to ERC-8004 identities. A chatbot conversation is private, deniable and leaves no track record you can show a counterparty.

5. Parallelism with a capacity floor. [MEASURED] ~595 concurrent runtimes and ~88,000 accepted steps/day is throughput a single chat session cannot reach, and a 5–100 seat oracle panel genuinely runs the same question many times over.

6. Unanimity as a safety property. [DOCUMENTED] Requiring the whole quorum to agree converts disagreement into a refusal to answer rather than a confidently wrong answer. [INFERENCE] For on-chain consumers, a loud failure is usually worth far more than a plausible guess — this is the single most valuable design choice in the system.

The honest counter-case

[INFERENCE] For ordinary question-answering, explanation, drafting or one-off code, a chatbot is cheaper, instant, requires no token, no wallet, no 600-second quote window and no 0.5 IMD. IMD's advantages only materialise when you specifically need machine-payable purchase, independent adversarial review, on-chain-consumable output, or an auditable public record. Outside those four cases, the extra machinery buys you nothing. Anyone telling you the swarm is a general-purpose chatbot upgrade is overselling it.

---

5. Main limitations

5.1 Contract launches are testnet-only, but priced in mainnet tokens — [MEASURED]

The single largest gap between pitch and present reality. GET /requests/capabilities reports the launch configuration as defaultChainId: 11155111 with a chains array containing exactly one entry: Sepolia, flagged testnet: true. The health endpoint's pendingDeploymentByChain likewise contains only key 11155111.

[INFERENCE] You pay real mainnet IMD for launch.open, and the contracts deploy to a test network where the tokens and pools have no economic reality. The documented launch economics — 10% to the swarm split 2% to wallets with accepted work and 8% per connected seat, 90% to the requester, 1.25% default trading fee — describe a mainnet system that is not yet the system you can buy. [REPORTED] Bankless describes mainnet as planned, not live.

5.2 The verifier checks structure, not truth — so ~86% is not an accuracy rate — [DOCUMENTED]

[REPORTED] Bankless reports ~86% of ~50,700 attempts accepted, only ~1% outright rejected; KuCoin reports 43,800+ accepted submissions at 86%. These numbers circulate as a quality claim.

[DOCUMENTED] They are not one. The worker README states the verifier "checks structure and integrity." The docs' acceptance machinery is about declared outputs matching, containers running clean, and reviewers filing findings. [INFERENCE] A well-formed report containing a false claim, or a compiling contract with a subtle economic bug, can pass structure-and-integrity checks. So the 86% figure measures conformance, not correctness, and a ~1% rejection rate is better read as evidence of a permissive gate than of excellent work. [UNCERTAIN] I found no independent audit of IMD output quality — no third party has sampled delivered work and scored it. This is the most important open question about the network and nobody has answered it publicly.

5.3 A centralised control plane for a "decentralised swarm" — [MEASURED]

Workers connect outbound over WSS to api.imd.fun — one orchestrator that assigns all work, runs the verifier, publisher and deployer, and holds one gas wallet (0x4e0fA57B…, balance 0.4214 ETH) that pays for every user's transactions. Reported software version: 0.1.0+f8dec20e.

[INFERENCE] The seats are distributed; the coordination is not. That single endpoint is a single point of failure, censorship and trust: it decides who gets work, what counts as accepted, and what gets deployed. A pre-1.0 version string on a system handling mainnet payments is a fair warning in itself. [REPORTED] Bankless is explicit: "treat this like an experiment that hasn't been formally audited for now"; KuCoin calls it "an unaudited experimental project." I searched for a published security audit and found none — [UNCERTAIN], absence of evidence rather than evidence of absence, but I could not find one.

5.4 Quality depends on operator spending, and degrades in ways nobody sees — [DOCUMENTED]

[DOCUMENTED] Defaults are Claude Sonnet 5 (low effort) or GPT-6 Luna (high effort). Premium contract and frontend work requires Claude Fable 5.1 (high) or GPT-6 Astra (xhigh). The network handles downgrades by removing a worker from premium work rather than letting it deliver degraded premium work — a sound design.

[REPORTED] But an unofficial operator guide reports the practical squeeze: a minimum of 4 GiB RAM per seat ("a plan sold as '4 GB' reports about 3.8 GiB and still fails"), 8 GiB for two concurrent tasks, and quota burn where "a ChatGPT Plus account burned its entire 5-hour window in about seven minutes of a task flood," concluding "Plus is not a viable runtime for an always-on node." It also reports one insufficient tier producing "several confident junk answers in a row," and memory exhaustion killing Forge mid-compilation.

[INFERENCE] So output quality is a function of how much each anonymous operator chooses to spend on compute and subscriptions, with the failure mode being confident wrong answers — exactly the failure the structural verifier is least able to catch. This compounds §5.2.

5.5 Paid demand is very small relative to the token — [MEASURED + UNCERTAIN]

[MEASURED] Lifetime payment counters: 1,156 orders paid, 1,154 admitted, 20 failed (19 payment permissions expired, 1 transaction reverted). [INFERENCE] At 0.5 IMD minimum per action, total lifetime spend on network actions is at least ~578 IMD (schedules bill per run, so the true figure is somewhat higher).

[REPORTED] Bankless counted only 115 paid orders, ~$560 total, on 2026-09-25. TokenPost notes "no recurring production work for outside protocols or production contract deployments beyond the documented routes." KuCoin warns that "failure to attract sustained paid work would leave the system reliant primarily on speculative trading volume."

[INFERENCE] Paid orders grew roughly tenfold in ten days — genuine traction — but the absolute revenue remains trivially small against a token valued in the tens of millions. The token's value rests on trading-driven burns, not on customer revenue. That is the central economic fragility, and all three secondary sources flag it independently.

[UNCERTAIN] — sources conflict on valuation, so I decline to state one. Bankless (2026-09-25) gives ~$9.73 and ~$69M market cap. KuCoin (2026-09-29) gives an all-time high above $39M retreating to ~$31M. These cannot both be right, and I could not resolve which is correct. Any market-cap figure in this report would be unreliable; treat all price data as stale and verify live.

5.6 I could not verify the circulating supply, and the published figure looks wrong — [MEASURED + UNCERTAIN]

[MEASURED] totalSupply() of the mainnet IMD contract at block 26,128,084 is 4,084,649.51 IMD.

[REPORTED] Bankless and KuCoin both put total supply at ~7.1 million, down ~29% from an original 10 million, in late September 2026.

[UNCERTAIN] — do not conclude that 59% has been burned. [REPORTED] IMD supply is spread across Ethereum, Base and Robinhood Chain and is bridgeable 1:1 via LayerZero. With lock/unlock adapter bridging, a single chain's totalSupply() is not the cross-chain total and can move purely because tokens were bridged elsewhere. The clean-looking inference "10M → 4.08M, so 59% burned" is therefore unsupported, and I am flagging it precisely because it is the mistake a reader would naturally make from my measurement. Establishing true circulating supply requires reading the Base and Robinhood Chain contracts plus the bridge adapter's locked balance, which I did not do. [INFERENCE] The direction of travel (supply falls, burns are real) is well supported; the magnitude is not.

5.7 Seat gating concentrates the network — [MEASURED]

2,000 seats, 775 holders, ~595 online. [REPORTED] The NFT floor was 1.99 ETH ($5,360) in late September. [INFERENCE] Participation requires a four-figure capital outlay plus a VPS plus a paid AI subscription, which bounds how decentralised the worker set can become and concentrates both reviewer independence and oracle panels among a few hundred actors. For an oracle needing 5–100 distinct seats, the pool of genuinely independent operators may be materially smaller than the holder count suggests.

5.8 Jobs execute as prompts inside the operator's own environment — [REPORTED + DOCUMENTED]

[REPORTED] The operator guide warns the network sends prompts executed "with that user's environment," so malicious tasks risk data exposure. [DOCUMENTED] Skills are enabled by default; one NFT authorises one device.

[INFERENCE] This cuts both ways and is under-discussed. Operators face prompt-injection and credential-exfiltration risk from paid job text — anyone can buy a job for 0.5 IMD and have their text executed on ~595 strangers' machines holding live AI credentials. Requesters face the mirror risk: proprietary job inputs run on anonymous third-party hardware. [INFERENCE] Do not send confidential material through the network.

5.9 The identity layer it relies on is still a Draft — [DOCUMENTED]

[DOCUMENTED] ERC-8004 ("Trustless Agents"), created 2025-08-13, is Status: Draft. It defines Identity, Reputation and Validation registries. Its own text states that payments are "orthogonal to this protocol and not covered here," that on-chain hashes cannot guarantee advertised agent capabilities "are functional and non-malicious," that reputation inflation through fake agents (Sybil attack) remains possible, and that validator incentives and slashing are external to the registry.

[INFERENCE] So "verifiable on-chain agent identity and reputation" means a durable, attributable pointer — not a guarantee of competence or honesty. The standard could also still change beneath IMD before finalisation.

5.10 Payment-flow friction — [MEASURED + INFERENCE]

[MEASURED] 1,166 orders expired versus 1,156 paid — more quotes lapse than complete — against a 600-second quote TTL, and 19 of 20 failures were expired payment permissions. [INFERENCE] Most likely benign (people request quotes to see prices and never pay), but the pattern is also consistent with real friction in the two-signature Permit2 flow. [UNCERTAIN] I cannot distinguish these from the counters alone; it would need per-order timing data I do not have.

---

6. What I could not answer

Stated plainly, because a research report that hides its gaps is worth less than one that marks them:

1. Is the output actually good? No independent quality evaluation of delivered work exists that I could find. The 86% acceptance figure does not answer this (§5.2). This is the question that most determines whether IMD is useful, and it is open.
2. What is the true circulating supply? Needs multi-chain plus bridge-adapter accounting (§5.6).
3. What is the market cap? Published figures conflict irreconcilably (§5.5).
4. Has anything been security-audited? I found no audit. Secondary sources say explicitly that nothing has been.
5. How model-diverse are the seats? Determines whether adversarial review catches correlated model error (§4, point 2). Unpublished.
6. When does mainnet launch support land? Described as planned; no date verified.
7. Does a complete on-chain receipt land for every accepted job? I observed an empty records response for one completed job and could not watch a receipt through to settlement (§3).

---

7. Bottom line

[INFERENCE, stated as my judgement rather than fact] IMD is a working, genuinely novel piece of infrastructure — ~595 live agent runtimes, 538 delivered repositories, a functioning machine-payable purchase rail, and an oracle design whose unanimity requirement is better engineering than most of what it will be compared against. The reason to use it over a chatbot is specific and real: independent review, machine payment, on-chain-consumable output, and a public record.

It is also an early, unaudited v0.1.0 experiment with a centralised coordinator, a testnet-only deployment path, a structural rather than semantic quality gate, and a token whose value is supported by trading burns rather than the ~578 IMD of lifetime customer demand I could measure. Both halves of that are true at once, and anyone deciding whether to buy work, buy a seat, or buy the token should weigh them together rather than pick the half that suits them.

---

Sources

Primary — project and standard:

1. IMD API documentation, imd.fun/docs — actions, pricing, x402/Permit2 flow, job/launch/workflow/oracle semantics, review roles, rate and size limits.
2. GET api.imd.fun/requests/capabilities — live: seven actions at 0.5 IMD, payment asset and network, Sepolia-only launch chain.
3. GET api.imd.fun/health — live: version 0.1.0, connected daemons, enrollments, accepted steps/24h, payment order counters, gas wallet, service status.
4. GET api.imd.fun/seats/owners — live: 2,000 seats, 775 holders.
5. GET api.imd.fun/jobs — live job list, including this report's own job and the EGLL METAR oracle request.
6. IdentityMD worker CLI, Identity-md/worker — operator requirements, model/effort tiers, "the verifier checks structure and integrity".
7. identity-md-launches GitHub organisation — delivered work. Counted via api.github.com/orgs/identity-md-launches: public_repos = 538, created_at = 2026-09-22.
8. ERC-8004: Trustless Agents (EIP repository) — Draft status, registries, explicit non-goals and security limitations.
9. IMD explorer — public job and agent browser.

Primary — on-chain, read at Ethereum mainnet block 26,128,084 via a public RPC:

10. IMD ERC-20 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7 — symbol() = IMD, totalSupply() = 4,084,649.507161 (mainnet only). Etherscan
11. identity.md seat collection 0x0000ec93127baa929e58e97dd0095a2bfb38ec1d — name() = identity.md, totalSupply() = 2000. Etherscan

Secondary — independent coverage:

12. William M. Peaster, "Inside IMD, Ethereum's New AI Swarm Experiment", Bankless, 2026-09-25 — acceptance rates, POOL4 mechanics, paid-order count, NFT floor, "hasn't been formally audited".
13. Simon Yoon, "Ethereum's IMD Tests AI-Agent Network With NFT Seats and Token System", TokenPost, 2026-09-25 — "the network remains experimental"; no recurring outside production work.
14. "What Is IMD Token? Ethereum's AI Cooperative Hits a $39M All-Time High", KuCoin, 2026-09-29 — cross-chain 1:1 LayerZero bridging, supply/burn figures, Fren Pet → VIBE → IMD history, "unaudited experimental project".
15. Unofficial IMD node operator guide, johnfreeman777/imd-node-guide — real operator RAM/quota costs, "Plus is not a viable runtime", execution-in-your-environment warning. Unofficial and unaffiliated; treated as a practitioner report, not authority.

Reproducibility: scripts/collect-evidence.sh in this repository re-issues every live call in sources 2–5, 10 and 11 and writes a timestamped JSON snapshot. The snapshot backing this report is evidence/snapshot-2026-10-05.json.