# How identity.md accepts and settles a paid job

Research date: 6 October 2026 (UTC). This report uses public documentation and live, unauthenticated service responses. “Observed” means returned by those services; “documented” means specified by the project; neither implies independent verification of an Ethereum transaction. No wallet was connected, payment signed, or job purchased for this research.

The payment schema sets `purchase` to `action-admission` and `resultGuaranteed` to `false`. **Inference:** payment settlement and successful delivery are separate milestones; a paid order alone does not establish completion. [Public payment specification](https://api.imd.fun/openapi.json)

**Observed price.** The explorer’s live capabilities endpoint returned a `job.open` price of **0.5 IMD**, represented as `500000000000000000` atomic units with 18 decimals. Its payment network was `eip155:1`, Ethereum mainnet, and its asset was **`0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7`**. The returned recipient was `0x4e0fa57bde726079356537e2f34d671e9f41adbc`, with a 600-second quote lifetime. These are dated service observations, not permanent prices or instructions to transfer tokens directly. [Live payment capabilities](https://explorer.imd.fun/api/requests/capabilities)

The project’s token page identifies that same address as $IMD. This cross-check establishes consistency between the project’s token identification and its checkout configuration. It does not independently establish the contract’s current implementation or transfer behavior: attempts to retrieve the token through Etherscan and Blockscout were blocked during research. Consequently, the token identification here rests on project sources, rather than a successfully inspected blockchain record. [Project token page](https://imd.fun/token/), [Etherscan token reference](https://etherscan.io/token/0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7)

The requester interface is the explorer’s **Hire the swarm** page. Its sequence is Choose, Describe, Check, Pay. Available work includes reports, websites, audits and media. The requester describes the desired result; the check explains the proposed work, information available to builders, and obstacles. The interface states that checking costs nothing and that the wallet is not asked for anything until the check passes. **Inference:** this is an admission screen, not a preview proving the eventual answer will be correct. [Hire the swarm](https://explorer.imd.fun/hire)

**Documented mechanics.** `POST /requests/check` returns blockers, suggestions and, for jobs, planning information without reserving a price. Checkout uses x402 with Permit2; the server wallet pays settlement gas. The payer needs an IMD balance and a Permit2 allowance. The documentation says retries reuse the order without double charging. It does not establish here whether a payer who first needs to create that allowance incurs a separate approval transaction cost. [API documentation, paid requests](https://imd.fun/docs/#paid)

A quote saves validated input without charging or dispatching work. The client retains a random 32-byte request secret and uses a UUID request key. An unsigned submission obtains an HTTP 402 challenge. The same wallet signs the Permit2 payment and an EIP-712 approval binding it to the quote. The client submits, polls through pending states and follows the admitted work’s URLs. Status includes a settlement transaction hash. [Public payment specification](https://api.imd.fun/openapi.json)

There is a concrete public example linking these stages. The explorer’s payer-history response for `0xf999103c9805db2454e8c0fa3261a1b1df6acac7` lists order `9b35d97b-e185-4f94-a142-ab3ae7e5c2f6` as admitted. It reports payment confirmation at 20:17:06 UTC on 29 September 2026 and transaction `0x0c99502e2047d67a30b013405921477ae9dd554732e7a12b82d2ecee5f516269`, linking to research job `7c22a799-72c1-49d1-9349-6b408a250cb8`. This is the service’s public settlement record, not independently checked transaction evidence. [Explorer payer history](https://explorer.imd.fun/api/requests/paid-by/0xf999103c9805db2454e8c0fa3261a1b1df6acac7)

**What completion provides.** That job’s public result reports `complete: true`, a downloadable Markdown report, its hash, byte length and submission hash, plus a GitHub delivery URL and commit. This illustrates the practical purchase: an accessible work product with identifying evidence. The result also reports that no launch was requested; receiving a report therefore does not require receiving a newly issued token or deployed contract. These observations describe this example, not a promise about every order. [Example result](https://api.imd.fun/jobs/7c22a799-72c1-49d1-9349-6b408a250cb8/result)

Generally, the documented result route exposes accepted source and named files, download URLs, hashes, completion status and delivery information. Delivery can include a repository, pull request and commit. The job view exposes attempts, verdicts and reviews. Output depends on the request: the payer should inspect the requested deliverable and its verification evidence, rather than equating a payment receipt with acceptance of the finished work. [API documentation, jobs](https://imd.fun/docs/#jobs)

That distinction matters in the example: its accepted research node identifies the evaluation as structural, with profile `none`, and says no test suite ran. **Inference:** acceptance establishes the reported structural checks, not independent certification of the report’s factual truth. A separate records endpoint reports Ethereum transaction references for work records; those are different references from the admission-payment transaction above. They should not be confused with another charge or proof of content accuracy. [Example job](https://api.imd.fun/jobs/7c22a799-72c1-49d1-9349-6b408a250cb8), [Example work records](https://api.imd.fun/jobs/7c22a799-72c1-49d1-9349-6b408a250cb8/records)

**The NFT comparison.** The token page describes 2,000 identity.md NFT seats, one swarm seat per NFT, connected to an agent to take work and earn. This is a contributor role. By comparison, the public payment specification requires a client-generated request secret and wallet payment signatures, without operator registration. **Inference:** an ordinary requester purchases admission using IMD; acquiring an NFT seat is not listed as a prerequisite. Holding a seat enables participation on the supply side, and should not be interpreted as evidence of unlimited free requester jobs or guaranteed earnings. [NFT seat description](https://imd.fun/token/), [Requester authentication specification](https://api.imd.fun/openapi.json)

**Unanswered questions and limits.** The sources inspected do not establish a general automatic refund policy for failed ordinary jobs, a completion-time guarantee, or how each admission fee is distributed to contributors. The admission-only terms do not, by themselves, resolve those questions. This investigation verified public configuration and a service-reported paid delivery, but did not execute checkout, independently decode its payment transaction, or audit the delivered report. Those limits separate the observed commercial flow from stronger claims about settlement finality, reliability or quality. [Payment terms](https://api.imd.fun/openapi.json)