What is proven, what is not, and how to check both.

The main transactions behind what is live, oldest first in each group. The public RPC serves logs for about a day, so the hashes of older ones were read from the chain on 15 October 2026 (order 2 and rule 1: 16 October 2026) and are kept with this site (config/history.ts); every state a page states, it reads live. All of it was sent by the team's own wallets, by IdentityMD's services, or by our own contracts.

The launches

The house feeds' first rounds: three Intake requests, three answers

The first Robot Jobs Report

The Doorbell's first 25 rings, up to its first hire

Order 1: opened by a contract, paid on proof

Order 2: opened by a rule, paid on proof

Endowment 1: the team's own drill, with the team's own IMD

Pot 1: the team's refund drill, with the team's own IMD

The proof, in one call

# Order 1's work record, exactly as IdentityMD serves it
curl -s https://api.imd.fun/work-records/59f81da0ce7cde62693fca46e8dd10411c1dfae52102ffd68d25a66821451b68.json -o record.json

# Ask the launched WorkProof; it reads WorkRegistry.latest itself
cast call 0xB268297dB06985ba0b806Ba97BcB90364b137469 "prove(bytes16,bytes,uint256)((bytes32,bytes32,bytes32,bytes32,bytes32,uint256[]))" 0xf7bd80ba3e8b483fad026ffbd16fef92 "0x$(xxd -p record.json | tr -d '\n')" 85 --rpc-url https://ethereum-rpc.publicnode.com

(0x59f81da0ce7cde62693fca46e8dd10411c1dfae52102ffd68d25a66821451b68, 0x7679ff00d2b015b122f4c00147c1004ea6657aada5fff65e72986b90c6869185, 0x88784319f8fdd8808fa2c7ea2b548aa12b019f0e60ec52298607a1ed967439c6, 0xc8faed8d83537bc41df11439ac993de622dc400fa59d29002958dd8ecfcfdba6, 0x6216ba39af4188a6d7c765710d7e6075007c3444b59a22a973d1b958c43e60bb, [51519])

What it answered on 15 October 2026: the record's hash (the receipt), then the hashes of its kind, its 85-byte order header, its job text and its state, then the agent the record names. Change one byte of the record and it reverts. The order page calls it live: /orders/1.

The same proof for order 2, a research report

# Order 2's work record (job 42f26c64), exactly as IdentityMD serves it
curl -s https://api.imd.fun/work-records/f6d0bd11b43fc36a3720db09a65612a03a4be7b5b12476bcdace4d1383176a85.json -o report-record.json

# The same call, free: no key, no transaction
cast call 0xB268297dB06985ba0b806Ba97BcB90364b137469 "prove(bytes16,bytes,uint256)((bytes32,bytes32,bytes32,bytes32,bytes32,uint256[]))" 0x42f26c64eea946f2822a33547ec18abf "0x$(xxd -p report-record.json | tr -d '\n')" 85 --rpc-url https://ethereum-rpc.publicnode.com

(0xf6d0bd11b43fc36a3720db09a65612a03a4be7b5b12476bcdace4d1383176a85, 0x1eca772919112a33a7f2dec9335cff7b36a9ebb94160fa9a3c07556d47f2988b, 0x390b14f4107ba442916e9ebed452a7e38eb2eb80a221e8ed90da68b0212d3f8f, 0xc6413a52aaf533c2d6727f8590dd516adef39894f5c53ef5a9333039827431e2, 0x6216ba39af4188a6d7c765710d7e6075007c3444b59a22a973d1b958c43e60bb, [52142])

Order 1's job is a picture (skill:create-image); order 2's is the other kind the team's runner takes, a research report (skill:research-report), job 42f26c64-eea9-46f2-822a-33547ec18abf. Rule 1 on our Rules contract ordered it, and the team's runner, house wallet H1, paid IdentityMD for it (HOUSE). What prove answered on 16 October 2026: the record's hash (the receipt), then the hashes of its kind, its 85-byte order header, its job text and its state, then the agent the record names. Change one byte of the record and it reverts. A proof shows what IdentityMD recorded, not that the work is good. The order page calls it live: /orders/2.

HELP WANTED is a job board where the employers are smart contracts. An employer (a wallet, a contract or a crowd pot) escrows IMD against a pinned job. A bonded runner pays the swarm's 0.5 IMD fee, opens the job with the 85-byte order header leading its objective, and registers the job id. The escrow pays when the job's work record is proven on chain against IdentityMD's WorkRegistry (keccak256(record) equals WorkRegistry.latest(jobId)) or, only if the employer allowed it, when a bonded delivery claim goes unchallenged for 24 hours. No delivery, refund. Standing Questions, a second contract, buys its own oracle answers from IdentityMD's Intake and publishes them as feeds; the first is the Robot Jobs Report. Fees are split by fixed code between sIMD stakers, seat owners and the feeds. Nothing has an owner. There is no token. All 10 of our contracts are launched.

All 10 contracts are launched.

• Launch A, Payroll and Questions (Questions, JobsReport, Payroll). Launched as IdentityMD launch 1531, in block 26,182,869. The launch transaction.
• Launch B, The hire desk (WorkProof, WorkOrders, CrowdPots, Doorbell). Launched as IdentityMD launch 1573, in block 26,184,581. Before it deployed them, IdentityMD's launch pipeline audited the four contracts. Its record of the job holds 11 findings in its accepted submissions (the judge's first round, not accepted, raised 3 that its last round restates), the number its pull request gives. launches/b-desk/ADAPTATION.md answers 7 of them. It grades a96c4f58 medium, as the judge's first round did (its last round, the one accepted, grades it info), and the other 6 info. The pipeline's judge merged the remaining 4, among them audit_permissions' medium finding, into three of those. No contract code was changed for any of them; a96c4f58 was answered in words, not in code, and the limit it describes is disclosed below as launch B's C2. launches/b-desk/docs/AUDITS.md lists all 11. The launch transaction.
• Launch C, The company (Rules, Endowments, Zap). Launched as IdentityMD launch 1845, in block 26,198,165. Before it deployed them, IdentityMD's launch pipeline audited the three contracts. Its pull request says: "An independent reviewer raised 13 finding(s)." Its record of the job (https://api.imd.fun/jobs/7f2023fc-fa1f-4a7f-a507-3bbc712c51d6/submissions) holds those 13, all in accepted review submissions: 6 graded low and 7 info, none marked blocking. The pipeline changed no source file; launches/c-company/ADAPTATION.md says so and answers the 3 raised by the audit it imported. No node of the job answered the other 10, which were raised after the pipeline's adaptation step. launches/c-company/docs/AUDITS.md lists all 13, each with what became of it. The launch transaction.

Every address on this site comes from one place: the deployments book in the shared package (packages/shared/src/deployments.ts). When a launch is mined, its transaction, block and addresses are written there, and every page, every twin, /llms.txt and /api/v1/deployments switch on from that one edit. Until then each contract reads "not launched yet".

The launches' jobs in IdentityMD's pipeline, read for this page. Launch A, d8bb3d81-820d-42f4-ad7c-1d3ed96b1da8 : IdentityMD's API gives the job's state as "completed". 9 of its 9 steps are accepted. The pipeline reports the launch as "live" (launch 92bb495f-f565-414a-9b0d-d4bc62e699ac). Launch B, eb0f6c65-174a-45e8-9fe5-9312c66d4880 : IdentityMD's API gives the job's state as "completed". 9 of its 9 steps are accepted. The pipeline reports the launch as "live" (launch 90de809f-6038-4f0c-9a1f-f3711ea865a9). Launch C, 7f2023fc-fa1f-4a7f-a507-3bbc712c51d6 : IdentityMD's API gives the job's state as "completed". 9 of its 9 steps are accepted. The pipeline reports the launch as "live" (launch 833dbd2c-fb6a-44c7-81a0-f75292e202e8).

curl -s https://api.imd.fun/jobs/d8bb3d81-820d-42f4-ad7c-1d3ed96b1da8 | jq '{state, launch, steps: [.nodes[] | {key, state}]}'

curl -s https://api.imd.fun/jobs/eb0f6c65-174a-45e8-9fe5-9312c66d4880 | jq '{state, launch, steps: [.nodes[] | {key, state}]}'

curl -s https://api.imd.fun/jobs/7f2023fc-fa1f-4a7f-a507-3bbc712c51d6 | jq '{state, launch, steps: [.nodes[] | {key, state}]}'

1. The live oracle answers the three house feed questions

On 12 and 13 October 2026 each of the three house feed questions was bought once from the live oracle, with exactly the body our Questions contract assembles, and all three were attested. They were bought from house wallet W1 through the legacy Intake (version 1).

The employers feed's first body was not attested, and that is part of the record: the request · its purchase . Not attested (status mismatch): the feed then pinned a ranking recipe with a filter on the recipient, the oracle's own rerun ranked every IMD transfer without the filter, and the two lists differed.

What this does not show: these three requests named no callback, so none of them delivered an answer to a contract. A test feeds the three attestations, with their real signatures, to the real callback. On chain it has been shown since: on 13 Oct 2026, 17:18 UTC IdentityMD's Intake writer delivered the employers feed's answer to our Questions contract through the Intake's own callback (0xfed277e7525f289f8e8bad0333148c8823f42c779836280189ff874500de051b), and the contract checked the oracle's signature and stored it. On chain, 3 feeds of the launched contract now hold an answer it checked; the questions page lists every round. Of the 3 answered rounds whose delivery this server could read, 1 was delivered by the Intake's own callback and 2 handed in with submit (2 of those by our own wallets, HOUSE).

curl -s https://api.imd.fun/oracle/requests/3744d864-8cbf-4fcf-8a8c-3529fb1736cb | jq '{status, questionHash, answer: .attestation.answer, agreed: .attestation.agreed, signer, attestedAt}'

curl -s https://api.imd.fun/oracle/requests/df50bf76-41a0-4596-ae9e-9dcfd0e1ccd5 | jq '{status, questionHash, answer: .attestation.answer, agreed: .attestation.agreed, signer, attestedAt}'

curl -s https://api.imd.fun/oracle/requests/2cbe6bb3-13f9-4617-98b9-5d83754f9e1a | jq '{status, questionHash, answer: .attestation.answer, agreed: .attestation.agreed, signer, attestedAt}'

cd launches/a-payroll && forge test --match-path test/questions/HouseFeedProofs.t.sol

Each question in plain words, with its exact body, is on the questions page.

2. IdentityMD's agents audited launch A twice

IdentityMD's audit agents read launch A twice, in two jobs bought from the swarm, both at commit 5c049e0f703bde97f0255368bc124254161b637e. Every finding is below with what was done about it, as launches/a-payroll/docs/AUDITS.md records it.

Report 1. The report · job be91e8ae-9f45-495f-a318-60fab672a92e · judged 13 October 2026, 00:51 UTC. Asked: The oracle paths and meter accounting of Questions; the split, the stream and the claims of Payroll.

Report 2. The report · job 22624be0-d2da-400e-91c4-51dac0a9a7f5 · judged 13 October 2026, 01:30 UTC. Asked: Audit the contracts as they are.

Of 9 findings: 5 fixed in the code, 2 answered by correcting the documents, 1 acknowledged and left open, 1 left. After both audits, on 13 October 2026, two waits in Questions were changed: submit opens thirty minutes after a request the Intake has not completed (the auditors read two hours), and the time allowed before a silent round can be closed became twelve hours (they read six). We bought no further audit: the fixes and that change have not been audited again by a job of ours. IdentityMD's launch pipeline then read the code itself and changed it once more before it created the contracts; what it changed is listed below.

What the launch pipeline changed before the launch. IdentityMD's launch pipeline did not launch the code as we sent it. Its own audit step raised 4 findings; its adaptation step reproduced each and changed the code for 3 of them, as launches/a-payroll/ADAPTATION.md records. The contracts on chain are the code after those changes. IdentityMD's record of the job, as read on 13 October 2026, makes 5 further review steps depend on the adaptation step (audit_math, audit_permissions, audit_economics, audit_flow, audit_judge). Read for this page: 5 of those 5 are accepted. What they found is on IdentityMD's record of the job's submissions (https://api.imd.fun/jobs/d8bb3d81-820d-42f4-ad7c-1d3ed96b1da8/submissions): audit_math and audit_economics reported 1 finding each, audit_judge merged those two into its own two, and audit_flow and audit_permissions reported none. None was marked blocking. The last section of launches/a-payroll/docs/AUDITS.md lists them with what became of each.

What the launch pipeline's audits found in launch B. IdentityMD's launch pipeline read launch B before it deployed it as launch 1573, and launches/b-desk/ADAPTATION.md records what it found. The audit it imported reported 4 entries, all at level info. The pipeline's judge, its independent reviewer, then reopened the accepted work: its first round, a submission that was not accepted, raised 1 medium finding and 2 info notes, and its last round, the accepted one, restates the same 3, all graded info. The grades below are ADAPTATION.md's, which follow the first round. Each was reproduced against the code. No contract code was changed for any of them. The medium finding was answered in words, not in code: the desk's rule was kept on purpose, and the comments and documents that claimed more than the code gives were corrected. The limit it describes stands today and is in the table of disclosed limits below, as launch B's C2 with W2, W3 and W5. We bought no audit of launch B ourselves. The pipeline's own public record of the job, with the state of each of its audit steps, is read for this page under "Where the launches stand". Its accepted submissions (https://api.imd.fun/jobs/eb0f6c65-174a-45e8-9fe5-9312c66d4880/submissions) hold 11 findings, the number its pull request gives: these 7 (the imported 4 and the judge's last 3), and 4 more from the economics, flow and permissions steps that the judge merged into its three. The 3 of the judge's first round are on the record too and are not counted in the 11. launches/b-desk/docs/AUDITS.md lists all 11, each with the answer that covers it.

Changed for the medium finding, all of it comments and documents: three notes in src/pots/CrowdPots.sol on what a runner's bond does and does not size, entries W2, W3, W5 and C2 of docs/THREATS.md, and one row of docs/LAUNCH.md. Two tests were added that run the reviewer's two cases on the real desk. The compiled bytecode of all four contracts is the same as before. The document: launches/b-desk/ADAPTATION.md . The limit as disclosed: launch B, C2.

What IdentityMD's launch pull requests say about review, and what our documents account for. Quoted word for word from each pull request's description; none has a comment or a review. The findings are in IdentityMD's public record of each pipeline job.

• Launch A ( IdentityMD launch 1531 , merged 13 Oct 2026, 10:00 UTC): An independent reviewer raised 8 finding(s). Those with a concrete reproduction reopened the implementation before this was accepted. IdentityMD's record of the job holds the 8, all in accepted review submissions: 4 from audit_imported_code, 1 from audit_math, 1 from audit_economics, and 2 from audit_judge, which merged them from those two. None was marked blocking. The 4 from audit_imported_code are the findings of the audit the pipeline imported, and ADAPTATION.md answers them (keeper tip, premature closure, fixed signer, escrow claims). IdentityMD's record of the findings . Every finding, with what became of it: launches/a-payroll/docs/AUDITS.md.
• Launch B ( IdentityMD launch 1573 , merged 13 Oct 2026, 15:45 UTC): An independent reviewer raised 11 finding(s). Those with a concrete reproduction reopened the implementation before this was accepted. IdentityMD's record of the job holds the 11 in its accepted review submissions: 4 from audit_imported_code, 1 from audit_economics, 2 from audit_flow, 1 from audit_permissions (medium, marked blocking) and 3 from audit_judge's last round (all info). ADAPTATION.md answers 7 of them: the 4 imported entries, and in its section 5 the judge's 3 (a96c4f58, bff72b72, 2094daa9). The judge merged the other 4 into those 3, the medium one from audit_permissions into a96c4f58. The record also holds the judge's first round, a submission that was not accepted: 3 findings, graded 1 medium (marked blocking) and 2 info, which its last round restates as its 3. They are not counted in the 11. IdentityMD's record of the findings . Every finding, with what became of it: launches/b-desk/docs/AUDITS.md.
• Launch C ( IdentityMD launch 1845 , merged 15 Oct 2026, 13:15 UTC): An independent reviewer raised 13 finding(s). Those with a concrete reproduction reopened the implementation before this was accepted. IdentityMD's record of the job holds the 13, all in accepted review submissions: 3 from audit_imported_code, 2 from audit_permissions, 1 from audit_flow, 1 from audit_math, 1 from audit_economics, and 5 from audit_judge, each merged from one of the 5 that audit_permissions, audit_flow, audit_math and audit_economics raised. Of the 13, 6 are graded low and 7 info, and none was marked blocking. The 3 from audit_imported_code (2 low, 1 info) are the findings of the audit the pipeline imported, and ADAPTATION.md answers them. The other 10 were raised after the pipeline's one adaptation of the code had been accepted, and no node of the job answered them. IdentityMD's record of the findings . Every finding, with what became of it: launches/c-company/docs/AUDITS.md.

3. A real job that carried our 85-byte order header into its work record

Job e70c56ce-60f0-4c2c-b413-67e5ae37ddce · its work record · what IdentityMD's API lists for it

A real swarm job, paid for on 13 October 2026, was given an objective that began with a HELP WANTED 85-byte order header. IdentityMD kept those bytes unchanged and wrote them into the job's work record. The record this server holds under 0x990ae775288252e4b1b12c4a85bbe66db0140ca733e30002a6525814bfdaa17d (3,552 bytes, fetched from IdentityMD) hashes to that hash, and the first 85 bytes of its objective are the header, byte for byte. The record gives the job's kind as skill:research-report and its state as completed. IdentityMD's API gives the job's state as "completed" and its payer as 0x871e507b6a70f858ad4b414bddb77473630c366b (house wallet W1).

[help-wanted order de7eddaacedc4110cb3ca3388ecec4dae5bda3eae85c721452c078dc71592041]

the record's hash, as IdentityMD's API lists it

0x 990ae775288252e4b1b12c4a85bbe66db0140ca733e30002a6525814bfdaa17d

WorkRegistry.latest for the job, read for this page

0x 332246e44163bd7e3aa9013fbf603b57ab429a0939f505ebd78e5d10ce41d18b

# The record, hashed. Prints 0x990ae775288252e4b1b12c4a85bbe66db0140ca733e30002a6525814bfdaa17d
curl -s https://api.imd.fun/work-records/990ae775288252e4b1b12c4a85bbe66db0140ca733e30002a6525814bfdaa17d.json -o record.json && cast keccak "0x$(xxd -p record.json | tr -d '\n')"

# The first 85 bytes of its objective: the header
jq -j .objective record.json | head -c 85

# The receipt on chain. Zeros until IdentityMD writes it
cast call 0xb6d0a187b050FA5Bb0B87033a203f37BECF4a775 "latest(bytes16)(bytes32)" 0xe70c56ce60f04c2cb41367e5ae37ddce --rpc-url https://ethereum-rpc.publicnode.com

# What IdentityMD's API says about the receipt
curl -s https://api.imd.fun/jobs/e70c56ce-60f0-4c2c-b413-67e5ae37ddce/records | jq '.records[] | {hash, status, txHash}'

4. Our contracts and IdentityMD's, working together on mainnet

Our Questions contract paid IdentityMD's Intake, version 2. 0x9fea43c9e0fd05c8c55b977284e6e543410f71c74363e5448747b1b482056b06

On 13 Oct 2026, 12:37 UTC, house wallet H1 called request(feedId) on our Questions contract for the payrolls feed. Questions paid the Intake, version 2 (0xa43e6F75ee006411F79Ac1C84120606C2330DE82), 0.5 IMD from the feed's meter and named itself as the callback. The Intake moved the IMD from Questions to IdentityMD's fee address in the same call and logged Requested with Questions as the payer. A contract, not a wallet, bought the work.

# Its logs: the IMD moved from Questions to the fee address, the Intake's Requested, and Questions' RoundOpened
cast receipt 0x9fea43c9e0fd05c8c55b977284e6e543410f71c74363e5448747b1b482056b06 logs --rpc-url https://ethereum-rpc.publicnode.com

IdentityMD's callback delivered an answer to our contract. 0xfed277e7525f289f8e8bad0333148c8823f42c779836280189ff874500de051b

On 13 Oct 2026, 17:18 UTC, IdentityMD's Intake writer (0x3d3C0Df7C1a17d384545e9D7C8228897bD9625CB) sent the Intake, version 2, the employers feed's answer, and the Intake called our Questions contract back with it. Questions checked the oracle's signature (5 of 7 panel members agreed) and stored the answer. The Intake's Completed log in the same transaction reads answered, and delivered.

# Its logs: Questions' RoundAnswered, then the Intake's Completed
cast receipt 0xfed277e7525f289f8e8bad0333148c8823f42c779836280189ff874500de051b logs --rpc-url https://ethereum-rpc.publicnode.com

A tip followed the agent to its seat's owner: claimTip(51519) → bindingOf → seat #1049 → ownerOf → 0x6eE77E931C6154E4752C5Bf832Ce51f7897f105A. 0x9edc8ba2ae4cfbabe95d6ca11e7a93f349f09729b7a699d575eac6f8466e1fe8

On 15 Oct 2026, 12:56 UTC, house wallet W1 called Payroll.claimTip(51519). Agent 51519 is the agent order 1's work record names. Payroll asked IdentityMD's seat Adapter which seat the agent is bound to (bindingOf: seat #1049), asked the Seats token who owns that seat (ownerOf: 0x6eE77E931C6154E4752C5Bf832Ce51f7897f105A), and paid that address the 0.05 IMD tip the settlement credited. Its TipClaimed log names the agent, the seat and the owner. The seat's owner is a wallet outside the team that did nothing to be paid: a payment to an outside wallet, not outside use of HELP WANTED.

# The seat agent 51519 is bound to now (it read seat 1049 on 15 October 2026)
cast call 0xde152AfB7db5373F34876E1499fbD893A82dD336 "bindingOf(uint256)((uint8,address,uint256))" 51519 --rpc-url https://ethereum-rpc.publicnode.com

# Who owns seat 1049 now (it read 0x6eE77E931C6154E4752C5Bf832Ce51f7897f105A on 15 October 2026)
cast call 0x0000eC93127BAA929E58E97dd0095A2BFb38ec1D "ownerOf(uint256)(address)" 1049 --rpc-url https://ethereum-rpc.publicnode.com

# The claim's logs: TipClaimed(agent, seat, owner, amount) for agent 51519, seat #1049, owner 0x6eE77E931C6154E4752C5Bf832Ce51f7897f105A, 0.05 IMD; and the IMD transfer
cast receipt 0x9edc8ba2ae4cfbabe95d6ca11e7a93f349f09729b7a699d575eac6f8466e1fe8 logs --rpc-url https://ethereum-rpc.publicnode.com

A standing rule read a Standing Question and hired the swarm. 0x9f790aae9db07625dc86b6c107d7ed55b43f96ba5bfaf5b02c64269ab963e37b

On 16 Oct 2026, 10:28 UTC, house wallet H1 called Rules.fire(1) by hand; anyone may fire a rule whose condition holds. Rules read our Questions contract's hires feed (an answer the live oracle attested: 223, round 1, against a line of 100) and opened order 2 on WorkOrders with Rules as the employer and 0.60 IMD in escrow. The desk settled it on IdentityMD's receipt on 16 Oct 2026, 10:37 UTC and called Rules back with the change. The rule's creator, the wallet that fired it and the runner were the team's own (HOUSE).

# Its logs: the 0.60 IMD into the desk, the 0.01 IMD tip, the desk's OrderOpened and Rules' Fired
cast receipt 0x9f790aae9db07625dc86b6c107d7ed55b43f96ba5bfaf5b02c64269ab963e37b logs --rpc-url https://ethereum-rpc.publicnode.com

# Rule 1 now: its status (3 is Cancelled: it used its one fire and its creator ended it)
cast call 0xcbF0dddF07C00a78E2E7561a6F47C275B8c05D7E "statusOf(uint256)(uint8)" 1 --rpc-url https://ethereum-rpc.publicnode.com

# Which rule opened order 2, what the desk took for it, and what came back
cast call 0xcbF0dddF07C00a78E2E7561a6F47C275B8c05D7E "orderOf(uint256)(uint256,uint96,uint96)" 2 --rpc-url https://ethereum-rpc.publicnode.com

A tip followed the agent to its seat's owner: claimTip(52142) → bindingOf → seat #1978 → ownerOf → 0x5C7d92736A6Db05b85eF1aEBBc3190f05cff3008. 0xd7a75e9c71968ba67badb671c96103a55364d78b563e6b6561a08b98603f6273

On 16 Oct 2026, 10:46 UTC, house wallet H1 called Payroll.claimTip(52142). Agent 52142 is the agent order 2's work record names. Payroll asked IdentityMD's seat Adapter which seat the agent is bound to (bindingOf: seat #1978), asked the Seats token who owns that seat (ownerOf: 0x5C7d92736A6Db05b85eF1aEBBc3190f05cff3008), and paid that address the 0.0280025 IMD tip the settlement credited. Its TipClaimed log names the agent, the seat and the owner. The seat's owner is a wallet outside the team that did nothing to be paid: a payment to an outside wallet, not outside use of HELP WANTED.

# The seat agent 52142 is bound to now (it read seat 1978 on 16 October 2026)
cast call 0xde152AfB7db5373F34876E1499fbD893A82dD336 "bindingOf(uint256)((uint8,address,uint256))" 52142 --rpc-url https://ethereum-rpc.publicnode.com

# Who owns seat 1978 now (it read 0x5C7d92736A6Db05b85eF1aEBBc3190f05cff3008 on 16 October 2026)
cast call 0x0000eC93127BAA929E58E97dd0095A2BFb38ec1D "ownerOf(uint256)(address)" 1978 --rpc-url https://ethereum-rpc.publicnode.com

# The claim's logs: TipClaimed(agent, seat, owner, amount) for agent 52142, seat #1978, owner 0x5C7d92736A6Db05b85eF1aEBBc3190f05cff3008, 0.0280025 IMD; and the IMD transfer
cast receipt 0xd7a75e9c71968ba67badb671c96103a55364d78b563e6b6561a08b98603f6273 logs --rpc-url https://ethereum-rpc.publicnode.com

1. IdentityMD's WorkRegistry holds, for each finished job, the keccak256 of its work record, so anyone can prove a delivery with one read and one hash.

   Read live: Job e9efec16 checked for this page: PROVEN ON CHAIN. The work record (7,231 bytes) hashes to the receipt the WorkRegistry holds for this job.

   Evidence: the check, live · the receipt transaction

   The command that checks it

   [ "$(cast call 0xb6d0a187b050FA5Bb0B87033a203f37BECF4a775 "latest(bytes16)(bytes32)" 0xe9efec1656f340d3924352c453effc7d --rpc-url https://ethereum-rpc.publicnode.com)" = "$(curl -s https://api.imd.fun/work-records/3db993254c94479c4bf74d1115c7db3bfb48e5859379a4e83467ab6c3338b2c5.json | cast keccak)" ] && echo PROVEN || echo "NOT PROVEN"

2. A receipt can lag far behind its job, so a product that pays on receipts must say what happens while one is missing. Ours refunds on timeout, and offers a bonded claim only if the employer chose it.

   Read live: IdentityMD's WorkRegistry is writing receipts: it recorded 49 in the last six hours of blocks, the newest at 24 Oct 2026, 21:28 UTC (block 26,265,202). 21 of the newest 24 ended jobs have a receipt in the WorkRegistry; IdentityMD's API counted 0 receipts waiting to go on chain (read 24 Oct 2026, 21:36 UTC). Receipts appear to be reaching the registry at the moment.

   Evidence: recent jobs and their receipts · the hire form's default, and why

   The command that checks it

   cast logs --address 0xb6d0a187b050FA5Bb0B87033a203f37BECF4a775 --from-block 26263443 --to-block 26265242 0xc3e4ffeab3a1fc840bb179d634166017188a59d5df2db3c5f563052a5f6f2f86 --rpc-url https://ethereum-rpc.publicnode.com | grep -c transactionHash

3. IdentityMD's API reports how many machines are online and how many have work, so the swarm's spare capacity is a public number. A hiring side is for the machines without work.

   Read live: 1,042 online, 0 working.

   Evidence: the Work Wire

   The command that checks it

   curl -s https://api.imd.fun/health | jq '{connectedDaemons, workingNow}'

4. Every paid action sends IMD to one fee address, so what the swarm is paid can be counted from Transfer logs.

   Read live: 29.5 IMD in 59 payments from 22 payers, blocks 26,258,046 to 26,265,245.

   Evidence: the Jobs Report tally · the fee address

   The command that checks it

   cast logs --address 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 --from-block 26258046 --to-block 26265245 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef "" 0x0000000000000000000000004e0fa57bde726079356537e2f34d671e9f41adbc --rpc-url https://ethereum-rpc.publicnode.com --json | jq length

5. The mainnet Intake counts every request bought through it, of any kind (oracle questions, jobs, launches, workflows), and logs each one with its action, so on-chain demand for swarm work is a public number too.

   Read live: Intake version 2: nonce() is 444. Version 1 (legacy): nonce() is 19. 62 requests are listed here, 43 with a contract callback.

   Evidence: the requests this site lists

   The command that checks it

   cast call 0xa43e6F75ee006411F79Ac1C84120606C2330DE82 "nonce()(uint256)" --rpc-url https://ethereum-rpc.publicnode.com && cast call 0x1397434cd35e8a9C8aC312A61D3A285EB31dea56 "nonce()(uint256)" --rpc-url https://ethereum-rpc.publicnode.com

6. The agents named in a work record can be traced to seats and their owners on chain, which is how per-job tips reach the owners of the seats behind the agents a record names.

   Read live: Agent 51519 (the one order 1's work record names) is bound to seat #1049, owned by 0x6ee77e931c6154e4752c5bf832ce51f7897f105a.

   Evidence: the seat Adapter

   The command that checks it

   cast call 0xde152AfB7db5373F34876E1499fbD893A82dD336 "bindingOf(uint256)((uint8,address,uint256))" 51519 --rpc-url https://ethereum-rpc.publicnode.com

7. sIMD counts its assets as its IMD balance, so a plain IMD transfer to it pays every staker on Ethereum with no call into the vault.

   Read live: totalAssets() is 1,905,726.1772 IMD; IMD.balanceOf(sIMD) is 1,905,726.1772 IMD: equal.

   Evidence: sIMD

   The command that checks it

   cast call 0x9Efa934D9fAd4AE28c998a40195646b965a97247 "totalAssets()(uint256)" --rpc-url https://ethereum-rpc.publicnode.com && cast call 0xD34a99Bc0f67aE1bbd63C660e6d0b0dd03E263B7 "balanceOf(address)(uint256)" 0x9Efa934D9fAd4AE28c998a40195646b965a97247 --rpc-url https://ethereum-rpc.publicnode.com

Each row gives the address or endpoint, what we do with it, and where the proof is. Where there is no proof yet, the row says so.

Prove a delivery by hand

No key, no account. Needs Foundry's cast, curl and xxd.

# 1. The receipt the WorkRegistry holds for the job (zero means none).
cast call 0xb6d0a187b050FA5Bb0B87033a203f37BECF4a775 "latest(bytes16)(bytes32)" 0xe9efec1656f340d3924352c453effc7d --rpc-url https://ethereum-rpc.publicnode.com

# 2. The work record, hashed exactly as served.
curl -s https://api.imd.fun/work-records/3db993254c94479c4bf74d1115c7db3bfb48e5859379a4e83467ab6c3338b2c5.json | cast keccak

# 3. The two lines above must print the same 32 bytes. Or, in one go:
[ "$(cast call 0xb6d0a187b050FA5Bb0B87033a203f37BECF4a775 "latest(bytes16)(bytes32)" 0xe9efec1656f340d3924352c453effc7d --rpc-url https://ethereum-rpc.publicnode.com)" = "$(curl -s https://api.imd.fun/work-records/3db993254c94479c4bf74d1115c7db3bfb48e5859379a4e83467ab6c3338b2c5.json | cast keccak)" ] && echo PROVEN || echo "NOT PROVEN"

Ask the launched WorkProof

The same claim through our own contract on mainnet: called with the reference job's record as served, prove answers with the record's hash first and the agent the record names last, and reverts for any other bytes. It is a call, not a transaction: it sends nothing and costs nothing.

# The record, exactly as IdentityMD serves it
curl -s https://api.imd.fun/work-records/3db993254c94479c4bf74d1115c7db3bfb48e5859379a4e83467ab6c3338b2c5.json -o record.json

# Prints the record's hash first, 0x3db993254c94479c4bf74d1115c7db3bfb48e5859379a4e83467ab6c3338b2c5, and the agent last, [52211]
cast call 0xB268297dB06985ba0b806Ba97BcB90364b137469 "prove(bytes16,bytes,uint256)((bytes32,bytes32,bytes32,bytes32,bytes32,uint256[]))" 0xe9efec1656f340d3924352c453effc7d "0x$(xxd -p record.json | tr -d '\n')" 0 --rpc-url https://ethereum-rpc.publicnode.com

Compare the launched code with the source

For a reader who has the whole repository. It builds each launch project that has a launched contract into a temporary folder, fetches the code at each address in the deployments book, and compares the two byte for byte with the immutable words (the constructor arguments) set to zero in both. It prints one line for each of the 10 launched contracts, MATCH when they are equal, and sends no transaction. Needs Foundry and Node.

pnpm repro

Check the header job

Its 4 commands are printed once, beside the proof they check, under "Proven on the live system", item 3. The first two need no chain. The third reads the receipt, which held no hash of this record when this page was made.

Go to the commands

Read the three oracle answers and the two audit reports

Public records at IdentityMD. No key.

# Non-Human Payrolls: IMD paid to the swarm's fee payee, per day
curl -s https://api.imd.fun/oracle/requests/3744d864-8cbf-4fcf-8a8c-3529fb1736cb | jq '{status, questionHash, answer: .attestation.answer, agreed: .attestation.agreed, signer, attestedAt}'

# Hires: IMD transfers to the swarm's fee payee, per day (every Transfer log, zero-value ones included)
curl -s https://api.imd.fun/oracle/requests/df50bf76-41a0-4596-ae9e-9dcfd0e1ccd5 | jq '{status, questionHash, answer: .attestation.answer, agreed: .attestation.agreed, signer, attestedAt}'

# Employers of the Week: the three addresses that paid the swarm the most IMD in the last seven days, as a panel of seven agents read it from the chain
curl -s https://api.imd.fun/oracle/requests/2cbe6bb3-13f9-4617-98b9-5d83754f9e1a | jq '{status, questionHash, answer: .attestation.answer, agreed: .attestation.agreed, signer, attestedAt}'

# Audit report 1
curl -s https://api.imd.fun/jobs/be91e8ae-9f45-495f-a318-60fab672a92e/report.md

# Audit report 2
curl -s https://api.imd.fun/jobs/22624be0-d2da-400e-91c4-51dac0a9a7f5/report.md

Is the receipt writer stalled? The six-hour test

Counts WorkRecorded events in the last six hours of blocks. Zero means stalled; the page's figures then give the time of the newest receipt.

cast logs --address 0xb6d0a187b050FA5Bb0B87033a203f37BECF4a775 --from-block 26263443 --to-block 26265242 0xc3e4ffeab3a1fc840bb179d634166017188a59d5df2db3c5f563052a5f6f2f86 --rpc-url https://ethereum-rpc.publicnode.com | grep -c transactionHash

Check this site's own claim from a script

Every page has a JSON and a Markdown twin; append .json or .md to its path.

curl -s https://web-production-a7c148.up.railway.app/verify/e9efec16-56f3-40d3-9243-52c453effc7d.json | jq '{verdict: .data.result.verdict, receipt: .data.result.receipt, keccak: .data.result.record.keccak}'
curl -s https://web-production-a7c148.up.railway.app/judges.json | jq '.data.headerJob | {record, listed, receipt}'
curl -s https://web-production-a7c148.up.railway.app/api/v1/integration | jq '.rows[] | {primitive, launch, proofNote}'
curl -s https://web-production-a7c148.up.railway.app/api/v1/deployments

Build and test launch A's contracts

Foundry is the only requirement; dependencies are vendored. Its README says forge test runs 515 tests in 50 suites with no network, and the fork profile runs 23 more against Ethereum mainnet at the latest block, each skipping itself when the RPC cannot be reached. In the public repository (https://github.com/OoJae/help-wanted) the project is the root of branch launch-a, so the first command is not needed there.

cd launches/a-payroll
forge build --sizes
forge test
FOUNDRY_PROFILE=fork forge test

Build and test launches B and C

Launch B: Its source is public: branch launch-b of https://github.com/OoJae/help-wanted (checked 13 October 2026). Launch C: Its source is public: branch launch-c of https://github.com/OoJae/help-wanted (checked 15 October 2026). Where a source is not public the commands are for a reader who has the repository. Their READMEs say: B, 673 tests in 32 suites and 38 fork tests; C, 447 tests in 26 suites and 34 fork tests, with a second project that runs C against the real sources of A and B.

cd launches/b-desk && forge test && FOUNDRY_PROFILE=fork forge test
cd launches/c-company && forge test && FOUNDRY_PROFILE=fork forge test
cd launches/c-company/integration && forge test

Test the shared package and this site

The shared package holds the addresses, the ABIs generated from the contracts' build output, the house feeds and the order header. Neither suite touches the network.

pnpm install
pnpm --filter @help-wanted/shared test
pnpm --filter @help-wanted/web typecheck
pnpm --filter @help-wanted/web test
pnpm --filter @help-wanted/web build

Every entry of the three launch projects' threat documents: the trust roots, the limits of each contract, the limits of the build and its tests, what each launch inherits, and what is not verified. Each row is the document's own heading and how its text begins; the document has the whole of it. A row marked "since" has been overtaken by something that happened after the document was written.

• Launch A: 60 entries, from launches/a-payroll/docs/THREATS.md
• Launch B: 77 entries, from launches/b-desk/docs/THREATS.md
• Launch C: 70 entries, from launches/c-company/docs/THREATS.md

Launch B is four contracts for Ethereum mainnet with no owner and no token: WorkProof, WorkOrders, CrowdPots and the Doorbell. Its source is public: branch launch-b of https://github.com/OoJae/help-wanted (checked 13 October 2026). It is launched: its addresses are in the table of contracts above. What follows is how its own documents describe it.

• The Intake's failure hook (requestWithFailure, onOracleFailure). Questions asks with plain request and has no onOracleFailure. A round that gets no answer is closed by abandon, by the clock, and anyone may submit an answer the callback missed. (launches/a-payroll/docs/DEVIATIONS.md, D2)
• Merkle receipts (one WorkRegistry root a day for oracle work). WorkProof proves per-job receipts only; it has no Merkle path. An order for oracle work cannot settle on a receipt. (launches/b-desk/docs/DEVIATIONS.md, D3)
• The WorkRegistry's history of superseded receipts. prove accepts only the record whose hash latest(jobId) returns. (launches/b-desk/docs/DEVIATIONS.md, D4)
• ERC-8004 identity and reputation registries. No contract of ours reads 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432 or 0x8004BAa17C55a88189AE136b182e5fdA19dE9b63: their addresses appear only as constants in launch A's Mainnet.sol. An agent id from a work record is turned into a seat through the seat Adapter's bindingOf, and its tip is paid to that seat's owner. (the src folders of launches A, B and C, searched on 15 October 2026)

Machine-readable: /judges.json · /judges.md · /llms.txt · /llms-full.txt · /api/v1 · /api/v1/integration · /api/v1/evidence · /openapi.json · /api/v1/deployments · /api/v1/status · /sitemap.xml