
Mycelium
Connect devices to run verifiable distributed inference of open source models, get paid with x402
Demo
About
Mycelium connects multiple devices into cooperative networks that run open-source AI models through distributed inference. Instead of relying on a single centralised AI provider, people can pool their hardware to jointly host models, users can discover and pay per request whilst the system stochastically ensures that the advertised model is the model they requested inference from. While one user may be unable to wrong the open source model they want to use, in a swarm each individual needs to have less compute power. Together, more powerful models can be run. The long term goal being that people can function both as users and providers, with the system either handling or integrating routing through services like open router, compared to the current provider self-selection. The application brings that infrastructure into a practical flow: choose a model and provider, receive a request-bound quote, authorize an x402 payment, stream the response, and keep a signed receipt. Hedera provides the payment rail, ENS gives providers human-readable identities, and The Graph makes published receipt history queryable to inform future provider selection. Our verification design separates the machines doing inference from the checker. We utilise model-specific statistical screening and private reference spot-checks, with the checker being run inside a trusted execution environment (TEE) so users can ensure the checker is behaving honestly. The aim is to detect model substitution and forgerys without requiring every inference device to have confidential-computing hardware, or needing to trust in any centralised service or even a quorum of verifiers. Dishonest providers have their staked bond slashed, and the system is designed to ensure that it is economically unfeasible to run inference that is not the model the user requested. In the future we aim to have a system that allows users to also serve as verifiers for inference. Mycelium is designed for both people and software agents, with browser, SDK, CLI, and MCP access. The goal is an open decentralised inference marketplace where users can choose who serves their models, hardware owners can offer underutilised edge compute(phones, laptops, desktop PC's, small Racks), and provider history helps give both humans and agents the information they need to make informed decisions based on the inference providers past history. A system that benefits humanity as a whole and not just people owning data centers.
How it's made
We built the hackathon application around the existing Mycelium distributed-inference project. We built model integrations for Qwen2.5-0.5B-Instruct and a 4-bit Qwen3.8-27B model. The demonstrated 0.5B and 27b routes splits one model across two physical Apple Silicon Macs: MLX executes most transformer layers, while a NumPy worker executes the final layer and output head. The architecture of Mycelium is designed for heterogeneous hardware, although these demonstrated execution paths are Mac-based for simplicity purposes. The application uses Node.js, JavaScript modules, versioned JSON contracts, SQLite-backed state, and a shared HTTP API for browser, SDK, CLI, and MCP clients. Execution, payments, discovery, indexing, and assessment are separate components. Ed25519-signed receipts bind the provider, requested model profile, request, and output. For payments, we integrated native Hedera x402 through Blocky402. The service returns an HTTP 402 challenge containing the payment requirements; the client authorizes the quoted payment, and the application verifies and settles it before admitting the job. Persisted payment-attempt state allows interrupted requests to be reconciled without blindly paying again. ENSv2 records on Sepolia provide human-readable provider identities and discovery. To provide inference, providers must put up a stake. Payments are settled only after verification has occured, and if inference providers are found to be dishonest they are slashed to a mathematically determined degree (based on stake amount, inference price, chance of being audited etc.) to ensure it is not economically viable to serve a different model than the one the user requested. The Graph provides the application’s queryable provider history. Solidity registries on Sepolia emit receipt and assessment events, which custom AssemblyScript subgraph mappings turn into immutable claims, daily activity records, and provider metrics. A reputation formula combines a smoothed assessment pass rate, capped receipt volume, and recent activity. The application uses indexed history to compare providers, while preserving separate counts for mismatches, inconclusive results, and unavailable checks. This makes The Graph part of provider selection rather than just a transaction dashboard, as it allows humans and agents to make informed decisions on where they wish to get their inference from. Our verifier uses two complementary mechanisms. First we have model-specific binary classifier screening ordinary response text: a TF-IDF/LinearSVC model captures lexical patterns, while a trained RoBERTa detector captures learned text features. They are combined in an ensemble and return a likelihood that the respective model was served. Separate trained bundles exist for 0.5B and 27B. Screening runs asynchronously, outside response delivery, and is a monitoring signal as well as a requirement for inference providers to be paid for their inference (withdrawal of attached x402 payment can only be made after verification has occurred). Second, the checker conducts private reference audits. An independent random policy selects observations for auditing (utilising some information from TheGraph to analyse all inference provider swarms and ensure they are roughly all selected at the same rate, 10% uniform per request, given their current uptime, with higher likelihood assignment to new providers, overdue checks and mismatched histories, with the aforementioned classifier triggering audits for three consecutive negatives. The checker sends a new challenge containing exact input token IDs and pinned generation parameters to the provider. It then compares the native output token sequence, output length, and EOS-versus-length termination against a private, profile-bound reference bank. Expected answers remain checker-side. The TEE design places the classifiers, private reference bank, audit scheduler, and comparison logic inside confidential computing on a GCS, while the large generative models remain on providers’ ordinary hardware. With this architectural split, the verification is quite lightweight compared to the actual inference, and even with the auditing it still makes it far easier to do verification than inference. The fees for upkeeping the verification TEE are paid for by a 5% fee on all inference payments, with the remaining 95% going back to the inference providers.