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
- 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]
- 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.
- 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
Limits: one session, unauthenticated reads only, nothing paid or submitted. This report contains no prices or monetary values.