# Paying independent machines for AI work: four networks compared

**Public-source snapshot: 1 October 2026 (UTC).** This compares the operator’s position, not token investment returns. “Documented” means a project’s public documentation or code states the mechanism; “observed” means a public endpoint returned it during research. Neither establishes independently audited performance. Weaknesses marked **inference** are analytical judgments. Prices, admission capacity and rewards can change during October; this is not a forecast for the rest of the month.

The four systems reward different things: Bittensor scores subnet outputs; Olas supports autonomous services and paid agent tools; Gensyn’s public training swarm is now archived; IMD coordinates task execution through NFT-authorized coding-agent workers. Consequently, the premise that all four currently offer comparable, continuously paid machine work needs qualification.

## Bittensor: compete within a subnet

**Joining and cost — documented.** An operator registers a wallet hotkey on a chosen subnet, runs that subnet’s software and supplies its required hardware. Registration has a floating price paid in TAO; compute requirements and operating costs depend on the subnet. The current mining guide says most subnets treat registration as a non-refundable expense, but some lock a portion as collateral. A full subnet can evict low-emission participants when new miners register. Registration therefore buys admission, not a guaranteed revenue stream. [Mining guide](https://www.bittensor.com/llms.mdx/docs/guides/mining/content.md)

On collateral-enabled subnets, the locked portion is alpha stake released through subsequent earnings. Leaving without earning enough can strand the remaining collateral; additional subnet-specific deposits may apply. A single network-wide entry price would be misleading. [Registration collateral](https://www.bittensor.com/llms.mdx/docs/guides/mining/collateral/content.md)

**Assignment and verification — documented.** Miners publish endpoints; validators send requests and score responses using the subnet’s incentive mechanism. The chain does not prescribe one universal AI workload. Yuma Consensus aggregates validator evaluations with stake weighting and clips excessive weights against consensus. This settles agreement about utility; it does not independently prove every model response true. [Mining guide](https://www.bittensor.com/llms.mdx/docs/guides/mining/content.md), [Yuma Consensus](https://www.bittensor.com/docs/internals/consensus)

**Payment — documented.** Under Dynamic TAO, workers earn the subnet’s **alpha token**, not simply a fixed TAO wage. The standard participant emission split is 18% to the subnet owner, 41% to miners and 41% to validators/stakers. Miner shares depend on consensus scores and are settled at subnet epochs. Converting alpha into TAO exposes earnings to the subnet pool’s exchange rate and liquidity. [Current emissions documentation](https://www.bittensor.com/llms.mdx/docs/concepts/emissions/content.md)

**Main weakness — inference:** the evaluation mechanism becomes the economic target. A miner can optimize for what validators reward without necessarily creating equivalent customer value; agreement among validators is weaker than an objective correctness proof. Token-price exposure compounds this risk. **Unanswered:** expected net earnings require selecting a subnet, inspecting its actual scoring code and measuring hardware, registration and liquidity costs; network-level documentation cannot supply that figure.

## Olas (Autonolas): operate agents, or sell tools to agents

**Joining and cost — documented.** Individuals can run agents through Pearl on a laptop; developers can register and deploy their own Mech services. Reward-bearing staking programs have separate eligibility, stake and capacity requirements. In the official contract directory’s **1 October, 14:10 UTC** snapshot, examples include Omenstrat III at **40 OLAS**, Optimus I at **100 OLAS**, and other programs at **1,000–10,000 OLAS**. These are committed capital requirements, not one universal admission fee. Operators also budget for hardware, transactions and the agent’s tool or trading expenditure. [Operate](https://olas.network/operate), [Staking directory](https://operate.olas.network/contracts), [Mech developer documentation](https://stack.olas.network/mech-tools-dev/)

**Assignment and verification — documented.** A Pearl operator chooses an agent/service whose software pursues its configured goals. Proof of Active Agent staking checks program-specific activity against on-chain KPIs; the whitepaper distinguishes measurable transaction activity from harder-to-verify off-chain work. This is not a universal proof that every answer is correct. [PoAA whitepaper, overview and staking architecture](https://olas.network/documents/whitepaper/PoAA%20Whitepaper.pdf)

For paid Mech work, the requester selects a service and tool. Requests can travel on-chain or directly off-chain; results are delivered through the marketplace. A designated Mech can be replaced after a request deadline, and a Karma reputation mechanism tracks deliveries and failures. Recording a delivered result is distinct from demonstrating its semantic accuracy. [Mech tools](https://stack.olas.network/mech-tools-dev/), [Mech client](https://stack.olas.network/mech-client/)

**Payment — documented.** Active eligible agents earn **OLAS staking emissions**. Separately, Mechs receive service payments: native chain currency, OLAS or supported USDC payments, depending on their configured payment model. Thus not every Olas worker payment is OLAS. [Operate](https://olas.network/operate), [Mech client payment models](https://stack.olas.network/mech-client/)

Olas announced on **29 June 2026** that new staking contracts would target approximately 5% rather than the earlier 100–138.5% APR, with old contracts no longer receiving additional funding. The October directory shows several 4.5–5% rates; quoted yield is not profit after agent expenses. [Emissions update](https://olas.network/blog/lower-emissions), [Current directory](https://operate.olas.network/contracts)

**Main weakness — inference:** activity metrics can reward transactions or task completion without proving useful, profitable AI decisions. Lower subsidies make genuine service demand and operating costs more consequential. **Unanswered:** sustainable earnings depend on the specific agent, staking contract and customer demand; neither an activity count nor an advertised rate establishes them.

## Gensyn: distinguish available tools from a paid training network

**Joining and cost — documented, with a status qualification.** RL Swarm is open-source and permissionless, with CPU and GPU execution paths; participants supply their own compute, electricity or cloud rental. However, current Gensyn documentation places RL Swarm in its legacy testnet archive, says those products are no longer actively maintained, and states that **no official swarms are running**. Community swarms remain an option. There is no verified current official RL Swarm admission price or paid-work offer to quote. [Current documentation](https://docs.gensyn.ai/), [RL Swarm repository](https://github.com/gensyn-ai/rl-swarm)

**Assignment and verification — historical implementation versus current tools.** RL Swarm’s CodeZero documentation describes users running Solver nodes, Proposers generating coding problems and a frozen Evaluator model assigning learning rewards. Nodes train locally and share rollouts. These learning rewards are not themselves token payments. The repository retains older statements calling CodeZero active; its opening pause notice and the current documentation archive take precedence for this report’s status assessment. [RL Swarm README](https://github.com/gensyn-ai/rl-swarm)

Gensyn’s current Reproducible Execution Environment provides receipts for deterministic inference. Its documentation distinguishes hash validation from verification by rerunning inference and comparing outputs. Reproducibility establishes what a model computed; it does not prove that the answer or external tool data is accurate. This tooling should not be presented as evidence that an open, paid training marketplace is currently assigning jobs. [REE receipts](https://docs.gensyn.ai/tech/ree/receipts)

**Payment — documented token, uncertain current worker route.** Gensyn identifies **$AI**, an ERC-20 on its L2, as its payment, staking and verification asset, with initial distribution in April 2026. It allocates 2% of supply to historical testnet rewards. The allocation explanation separates a 1.6% testnet activity pool from a 0.4% bid reward pool and says rewards were integrated into the public sale. These are historical distribution terms, not a standing rate per GPU-hour. [Token documentation](https://docs.gensyn.network/ai-token), [Allocation explanation](https://allocations.gensyn.network/)

**Main weakness — inference:** an operator cannot infer a current income opportunity from the existence of $AI, old participation points or working research software. **Unanswered:** the reviewed sources do not establish a presently open general-purpose worker queue, current compute-provider collateral requirement, or recurring payment schedule. Gensyn should therefore be compared as a technically relevant but presently unverified paid-work route for this use case.

## IMD swarm: NFT seats supplying agent execution

**Joining and cost — documented.** An eligible identity.md NFT authorizes one active device; pairing checks ownership and requires ERC-8004 agent registration. The worker needs Node.js, Git and an authenticated Claude Code or Codex runtime, and consumes the operator’s own account quota. Some work requires approved premium models and additional capabilities. [Worker README](https://github.com/Identity-md/worker)

The token page describes **2,000 seats** and a free initial NFT mint in May 2026. That historical mint does not establish free admission today: a new entrant needs an eligible NFT at its available acquisition price, registration transaction costs, an online machine and sufficient runtime access. No current executable NFT purchase quote was verified. [IMD seat and token page](https://imd.fun/token/)

**Assignment and verification — documented and observed.** The worker connects to a control plane over WSS. Signed messages carry assignments, leases, submissions and acknowledgements; eligibility depends on enrollment and capabilities. Public job records expose attempts, verdicts, reviews and artifacts. The Explorer visibly lists running, incomplete and completed jobs. Those records establish observable coordination, not independent proof of result quality. [API documentation](https://imd.fun/docs/), [Explorer](https://explorer.imd.fun/)

The worker README explicitly distinguishes worker-side website validation from the verifier’s structural/integrity checks. Independent reviewers must use different wallets; that does not prove different human owners or independent model reasoning. Backend source is not distributed with the public worker. [Worker README](https://github.com/Identity-md/worker)

**Payment — observed policy, limited settlement evidence.** The live launch-policy API returned versions **8–10**, created **1 October 2026 at 16:30 UTC**, specifying `equal_connected`: **2% of launch supply** shared equally among wallets with accepted work on that launch, and **8%** shared equally among active, registered seats connected at admission. These are **launch-specific token allocations**, not an IMD hourly wage. The worker release notes corroborate the new split. [Live policies](https://api.imd.fun/launch/policies), [Release notes](https://github.com/Identity-md/worker/blob/main/RELEASE_NOTES.md)

Crucially, those retrieved policies specify **chain ID 11155111 (Sepolia)** and a one-hour contributor lock. This is evidence of configured testnet reward terms, not independently verified liquid mainnet earnings. A dated API copy is retained with this report. Customer requests, meanwhile, are priced separately at **0.5 IMD** on Ethereum mainnet in the API documentation; a customer charge does not prove an equivalent worker payout. [Policy snapshot](evidence/imd-launch-policies.json), [Payment documentation](https://imd.fun/docs/)

**Main weakness — inference:** operators incur real runtime costs while reward value and settlement remain uncertain, and assignment/acceptance depend on the control plane. **Unanswered:** the reviewed evidence does not establish a general cash-equivalent payout for ordinary research jobs, realized resale value of launch allocations, or audited scheduler fairness. NFT ownership and accepted work alone should not be equated with dependable income.

## Summary

| Network | Who can join; principal cost | Assignment and verification | Worker payment | Main weakness / evidence limit |
|---|---|---|---|---|
| **Bittensor** | Subnet-compatible operators; floating TAO registration, possible collateral, hardware | Validators request and score; stake-weighted Yuma consensus | Subnet **alpha** emissions; conversion through TAO pools | Scoring can diverge from customer utility; subnet-specific economics |
| **Olas** | Agent operators or Mech developers; program-specific OLAS stake and running funds | Configured agents; selected Mechs; KPI checks and delivery reputation | **OLAS** emissions; Mech fees in native currency, OLAS or supported USDC | Activity/delivery is not general answer correctness or profitability |
| **Gensyn** | Open software/community swarms; own compute; official RL Swarm paused | Historical cooperative training; current REE replay verifies computation | **$AI** token and historical testnet allocations; current recurring worker pay unverified | Available technology does not establish an open paid-work route |
| **IMD swarm** | Eligible NFT seat, registration, online daemon and paid/runtime quota | Control-plane dispatch; structural checks and task-dependent review | Observed launch-token **2% contributor / 8% connected-seat** allocation; retrieved policies on **Sepolia** | Central coordination and unverified liquid worker income; customer IMD fees are separate |