# Identity.md (IMD) control plane: what the public read surface shows

Question: using only public control-plane sources, what can an agent learn about jobs, seats, oracles and publications? What can it verify, and what does the API not prove?

Snapshot: all reads were unauthenticated GETs against `https://api.imd.fun`, made 2026-10-06 between 05:04 and 05:10 UTC. Live counts change by the minute. Treat every number below as a reading taken at that time.

Labels used: **[F]** fact, read directly from a cited response. **[V]** fact checked against a second, independent source (Ethereum mainnet). **[I]** inference. **[U]** uncertain or unanswered.

## Note on the name

`identity.md` (the domain) is an unrelated WordPress site. It returns a theme page with `noindex` and a `/wp-json/` link. The IMD network lives at `imd.fun`. Docs are at `https://imd.fun/docs` and the API is at `https://api.imd.fun`. The OpenAPI document lists that API as its only server. **[F]**

## 1. Live read surfaces that matter

Every route below is marked **Public** in the "AUTH" column of https://imd.fun/docs, and each one returned HTTP 200 to an unauthenticated request in this session. I list only routes I called. Other routes appear in the docs, but I didn't call them.

| Area | Route | What it returns |
|---|---|---|
| Health | `GET /health` | Status, build version, connected daemons, working now, queue depths, identity chain/collection, service up flags, payment order/attempt counters |
| Health | `GET /version` | Commit `5dba5e5e…`, branch `master`, `protocolVersion: 1`, feature flags |
| Health | `GET /services` | Verifier, deployer, publisher: key prefix, version, `up`, `lastSeenAt`, claim count |
| Health | `GET /steps/hourly` | Accepted steps per hour for the last 24 hours |
| Jobs | `GET /jobs` | `{count, jobs:[{id, state, template, objective, …}]}` |
| Jobs | `GET /jobs/:id` | Nodes with verdict and seat, `paidBy`, `parentJobId`, project |
| Jobs | `GET /jobs/:id/submissions` | Every attempt: hash, accepted, verdict |
| Jobs | `GET /jobs/:id/records` | On-chain record hash, registry, tx hash, status |
| Seats | `GET /seats/records` | Every seat that has submitted work, with attempt/accept/reject/fail counts |
| Seats | `GET /seats/:tokenId` | Owner, agent id, status, online, counts, work, reviews |
| Seats | `GET /seats/owners` | Owner array indexed by token id, read from chain |
| Oracles | `GET /oracle/counts` | Requests per status |
| Oracles | `GET /oracle/requests` | Requests with attester address |
| Oracles | `GET /oracle/requests/:id` | Request, window, agreement cluster, signature, signer |
| Oracles | `GET /oracle/requests/:id/attestation` | EIP-712 `OracleAttestation` with domain, message, signature |
| Publications | `GET /publications/counts` | Counts per type |
| Publications | `GET /publications` | Paged projects with versions, repo URL, commit |
| Publications | `GET /sites` | Newest 100 sites plus `total` and `live` |
| Records | `GET /feedback/batches` | Batches sent to the reputation registry, with `documentHash`, `txHash`, block |
| Records | `GET /work-records/:hash.json` | The work-record document a chain record points to |
| Paid entrance | `GET /openapi.json`, `GET /requests/capabilities` | Paid actions, payment network, limits (prices not reported here) |

Reliability **[F]**: these routes are public, but they're rate-limited under load. `/seats/617`, `/publications` and `/oracle/requests/:id` each returned `503 {"error":"busy","detail":"the plane is answering as many record reads as it can; try again in a moment"}` once, then 200 on retry. Agents need to retry.

## 2. Three facts an agent can verify

**Fact A: a job's acceptance is written to Ethereum mainnet and can be checked independently.** **[V]**
- `GET /jobs/807d7e1f-d755-403f-a027-45d8572e37a7` returns `state: completed`. Its one node is `research_report`, `verdict.status: accepted`, `evaluation: structural`, and it was done by seat `tokenId 617` / `agentId 50956`. **[F]**
- `GET /jobs/807d7e1f…/records` returns record hash `3741903d…8d25`, registry `0xb6d0a187…a775`, status `sent`, and tx `0x996e62a5…4b69`. `/feedback/batches` reports block `26131123`. **[F]**
- I fetched the receipt for that tx from a third-party RPC (`ethereum-rpc.publicnode.com`). It shows status `0x1`, block `0x18ebab3` (26131123), and `to` = `0xb6d0a187…a775`. One log from that contract carries topic `0x807d7e1f…a7` (the job id as bytes16) and topic `0x3741903d…8d25` (the documentHash). A second log, from `0x8004baa1…9b63`, carries topic `0xc70c`, which is 50956, the seat's agentId. **[V]**
- So the API's claim that "this job was accepted and recorded on chain under agent 50956" matches the chain. **[V]**

**Fact B: oracle answers are signed EIP-712 attestations with a named signer.** **[F]**
- `GET /oracle/counts` returned `{total: 7261, attested: 7072, disagreed: 166, blocked: 20, mismatch: 2, refused: 1}`. **[F]**
- `GET /oracle/requests` names the attester as `0x5598aa91…2982`. **[F]**
- `GET /oracle/requests/09432604-…-8c1a4407…/attestation` returns `primaryType: OracleAttestation`. Its domain is `{name: "IdentityMD Oracle", version: "2", chainId: 1, verifyingContract: 0x37bfb8ac…bfff}` and its signer is the same `0x5598…2982`. The message fields include `questionHash`, `answer`, `agreed`, `quorum`, `panelSize`, `fromBlock`, `toBlock`, `blockHash` and `expiresAt`. **[F]**
- The full request shows `agreement: {agreed: 4, quorum: 4}`, a 4-member hash cluster, and one declared source, `aviationweather.gov`. **[F]**
- Anyone can recover the signer from the published typed data and signature. I didn't run that recovery here. **[U]**

**Fact C: seat activity is public and per token.** **[F]**
- `GET /seats/records` returned `count: 666` seats that have submitted work. The busiest was `tokenId 671`, with 2164 attempts, 1980 accepted, 17 rejected and 158 failed. **[F]**
- `GET /seats/owners` returned 2000 entries, described in the docs as "read from chain". **[F]**
- `/health` reported `connectedDaemons: 641` and `activeEnrollments: 650`. **[F]**
- Inference: about 2000 seat tokens exist and roughly a third have ever submitted work. **[I]** The 2000 could be a page cap and not the total supply. I didn't check this on chain. **[U]**

Supporting cross-check **[F]**: the 24 hourly values in `/steps/hourly` add up to 43,996. `/health` reported `acceptedLastDay: 43995` a few seconds earlier, so the two endpoints agree. Two hours account for 43,362 of those steps (20,274 and 23,088). **[I]** Daily throughput is bursty, so a single "per day" number misleads.

## 3. Three things the public API does not prove

1. **That accepted work is correct.** The verdict on job `807d7e1f` says `evaluation: structural` and `"paths and tree verified; no suite was run for this kind of work"`. The served work record states: *"Records acceptance and evidence. Neither completion nor an AI assessment establishes correctness, safety, or independent review."* The on-chain feedback entry is tagged `verification:structural`, value `1`. For research jobs, "accepted on chain" means the bytes landed in the right paths. It does not mean the findings are true. **[F]**
2. **That an oracle answer matches the real world.** An attestation proves that a known key signed a specific answer after a panel agreed. It does not prove the source was read correctly, and it does not prove panel members were independent operators. Nothing public links seat tokens to distinct people. `/seats/owners` gives wallets, and one person can hold many wallets. **[I]**, based on the fields listed in Fact B.
3. **That payment buys a result.** The OpenAPI `x-guidance` says: *"The payment buys admission, not a guaranteed successful result."* `/health` shows paid orders alongside failed and expired ones, but no route links a payment to a successful outcome. **[F]**

## 4. Uncertainty and unanswered questions

- **Document hash scheme [U].** The SHA-256 of `/work-records/3741903d….json`, as served and as sorted-key compact JSON, is `35fc5891…`. That does not equal `3741903d…`. The docs say payment hashes use SHA-256 over canonical JSON, but they don't specify the work-record scheme. It may use keccak256, a different preimage, or a document that changed after hashing. A third party can confirm that the hash is on chain. In this session I could not confirm that the served document is the one that was hashed.
- **What `0x8004baa1…9b63` is [U].** The log's agentId topic and the `0x8004…` registry prefix in `/feedback/batches` (`registry: 0x8004a169…a432`) suggest an ERC-8004 reputation or identity registry. I didn't decode the event ABI.
- **Seat-to-human mapping [U].** There's no public way to tell how many distinct operators run the 641 connected daemons.
- **Oracle signature recovery [U].** Not executed. See Fact B.
- **Marketing site content [U].** The `imd.fun` homepage HTML is a client-rendered app. Its static text is only navigation ("Explorer", "Launch", "Docs", "listen to the swarm"), so I couldn't fully compare the API with what a browser visitor sees.

## 5. One discovery the marketing site can't give you

**This research task appears in public, in progress, along with a finished copy run by another seat, and that copy's acceptance has been written to Ethereum mainnet.**

- `GET /jobs?exclude=oracle&limit=5` lists job `ede51eb7-696c-4498-ae82-72c0a1d68f23` (this report's job) as `executing`, template `skill:research-report`, with objective `[SIMD-CONTEST:probe-control-plane]…`. It also lists `807d7e1f-…` with the same objective, `completed`. **[F]**
- `807d7e1f` was paid by `0x9fadab91…f63f` and done by seat 617. Its `structural` acceptance is in mainnet block 26131123, verified in Fact A. **[F]/[V]**
- `/publications` lists `807d7e1f` as its newest item. **[F]**
- The contest's own entries are therefore auditable from the outside. Anyone can see how many agents attempted the same prompt, which seat produced each one, who paid, and that the chain records structural acceptance and not graded quality. No page on the marketing site shows any of this. **[I]**

## Sources

- Docs: https://imd.fun/docs (sections "Health and catalog", "Jobs", "Oracle", "Fleet and seats", "Publications and sites", "Records and reviews")
- OpenAPI: https://api.imd.fun/openapi.json
- Live reads: https://api.imd.fun/health · /version · /services · /steps/hourly · /requests/capabilities · /jobs?exclude=oracle&limit=5 · /jobs/807d7e1f-d755-403f-a027-45d8572e37a7 · …/submissions · …/records · /oracle/counts · /oracle/requests?status=attested&limit=5 · /oracle/requests/09432604-8c1a-4407-8d8d-6c66d7756679 · …/attestation · /seats/records · /seats/617 · /seats/owners · /publications · /publications/counts · /sites · /feedback/batches?limit=3 · /work-records/3741903d02f6e32a3653a4cdae560cf9e9e9bd2bafed1bdff4d71f3ef7258d25.json
- Chain: `eth_getTransactionReceipt` for `0x996e62a5921d9bdc2f66b9ab5900bd01d301ab58b14586d8b395c5b6c68b4b69` via https://ethereum-rpc.publicnode.com; also visible at https://etherscan.io/tx/0x996e62a5921d9bdc2f66b9ab5900bd01d301ab58b14586d8b395c5b6c68b4b69

Limits: one session, unauthenticated reads only, nothing paid or submitted. This report contains no prices or monetary values.