# Decentralized AI should be invisible

**Published by:** [Lemniscap](https://paragraph.com/@lemniscap/)
**Published on:** 2026-09-03
**Categories:** research
**URL:** https://paragraph.com/@lemniscap/decentralized-ai-should-be-invisible

## Content

Can open coordination turn fragmented compute into a reliable AI service? Decentralized AI (dAI) will work best if customers never have to deal with the network underneath. Centralized providers already work well, but a small group of frontier labs controls access to the most capable closed models and can change how they are deployed or which uses they allow. Open weights reduce that dependence but the risk there is that harmful uses become harder to contain once the weights are released. Permissionless inference needs two things: model weights that independent operators may run and a supply network they may join. A closed model hosted across several approved datacenters is distributed, but not permissionless. A coordination market could combine open models and independent compute behind a reliable service. The old “idle GPUs become a decentralized cloud” narrative started with supply, but that was backwards. Buyers start with the a job they want to finish at a known price and service level. The commercial test is whether coordination can meet those terms at a competitive all-in cost, or improve access, privacy, or verifiability enough to justify a premium. Which workloads can pass that test depends on how easily work can move between suppliers, outputs can be checked, and service quality can be preserved. Blockchain is a separate design choice within the coordination layer. Whether it improves coordination, and whether a protocol token captures value, are separate questions from whether the service works. A decentralized OpenRouter? User experience matches a centralized service, but a coordination layer manages distributed suppliers underneath. Blockchain can provide shared state or neutral settlement where those functions improve coordination. Hiding fragmentation Ambient shows how this model works in practice. Customers access it through OpenRouter as they would any other provider. Behind the API, Ambient auctions requests to miners, checks sampled outputs with proof of logits, penalizes failed work, and reruns jobs when needed. Customers neither choose the miner nor settle disputes. OpenRouter also gives Ambient access to existing demand. Because its miners serve models already used by OpenRouter customers, Ambient does not need buyers to adopt a new model or crypto workflow. At one point, Ambient served more than 20 billion Kimi K2.7 Code tokens per day and handled as much as 44% of the model’s OpenRouter traffic. Engy uses a different distribution path. Rather than enter through OpenRouter, it operates its own OpenAI-compatible gateway. Engy reports that its Qwen 3.6-35B traffic exceeded 20 billion tokens on several days. Together, these examples show two ways open supply can reach live inference demand through familiar interfaces. Regardless of how demand enters, the network must keep the service consistent as traffic and supplier diversity grow. Scaling this comes down to routing. The router needs a good read on which suppliers are available and likely to finish the job. Each success or failure gives it more data. If a node misses the service terms, the network needs spare capacity elsewhere. Rerouting only helps when the workload can move without breaking its latency, privacy, or reliability requirements. Where distributed supply works Open supply works only if a job can move without changing what the buyer receives. That is easiest when another operator can take over and the result is easy to check. Private data, tightly synchronized machines, and latency intolerance make substitution harder. Open-weight inference is the clearest fit because many operators can host the same weights, and that supplier pool should widen as smaller models become more capable. Qwen3.8-27B hit 52 on Artificial Analysis’s Intelligence Index, matching Gemini 3.6 Flash (high), GPT-5.6 Luna (max), Claude Opus 5 (low), and DeepSeek V4 Flash (max; 284B parameters) on the same benchmark despite having only 27 billion parameters. Source: Artificial Analysis Overflow work also fits because the buyer already values incremental capacity wherever it is available. Regional inference can work when latency or data residency makes nearby infrastructure preferable (e.g., see Intelligent Internet’s National Champion model). For sovereign buyers, domestic ownership and jurisdictional control may justify local capacity even when it is not the cheapest option. Trust and technical coupling set the harder limit. Most frontier-model demand still favors datacenter GPUs, firm SLAs, known providers, and confidentiality. A hospital or software company is unlikely to send medical records or proprietary code to unknown operators just to save a little money. Frontier-scale training also still favors homogeneous accelerators, fast interconnects, and coordinated availability. Beyond the initial markets, the technical difficulty rises through asynchronous workloads such as RL rollouts, evaluations, simulations, synthetic data, and batch scoring; confidential inference supported by attestations; low-bandwidth training and post-training; and, at the outer limit, frontier pre-training. Pluralis and Teutonic show that this boundary is moving. Pluralis used fourteen Macs across four countries to generate practice runs for reinforcement learning, while a single B200 GPU updated the model. Its first-attempt success rate on held-out tests rose from 29% to 63%. Teutonic ran a 70-day contest in which independent participants tried to improve a shared 10B model. A validator compared each new checkpoint with the current version and accepted it when it performed better. Of 2,163 completed comparisons, 203 challengers were accepted. These experiments show that selected model-improvement tasks can be distributed. They do not show that customers will keep paying for it or that it costs less than using a centralized provider. Technical feasibility has to come first, and then the network needs to show that it can turn that work into an equivalent service at a competitive cost. Portable workloads with verifiable outputs are easier to coordinate across suppliers, while privacy, tight compute coupling, and strict service requirements favor centralized clusters. (Positions and boundaries are illustrative.) What is the buyer actually purchasing? The buyer is purchasing a completed job on agreed terms, not "spare compute." The service contract defines the model, price, latency, privacy policy, and what counts as a success. The coordination layer turns those terms into operating decisions: which suppliers qualify, where capacity is available, who receives the job, how execution is checked, and what happens when it fails. Payment only comes after either verified delivery or buyer acceptance. Each result then feeds back to update supplier reputation and any collateral involved. None of this inherently requires a blockchain. An offchain coordinator like OpenRouter can onboard providers, monitor their performance, and route requests. A blockchain earns its place only if it improves the market: suppliers can join without bilateral contracts, independent parties can rely on shared performance and collateral records, or accepted work can settle without one company controlling adjudication and payment. Putting records onchain adds little if one company still decides who can join the network or which transactions are valid or not. The economic heuristic is simple: All-in cost per accepted job = (cost of all attempts + routing + verification + settlement) ÷ accepted jobs Suppose a centralized provider incurs an all-in cost of $1.00 for each of 1,000 accepted jobs: $1,000 total. A distributed network spends $770 on 1,100 attempts and another $90 on routing, verification, and settlement. If 1,000 results are accepted, its all-in cost is $860, or $0.86 per accepted job, a 14% discount assuming the same model and service quality. However, the advantage diminishes with acceptance rate. Coordination raises total cost, while failures spread that cost across fewer accepted jobs. An open-supply network can win if its compute savings outweigh both of these effects. Verification improves the service only when the risk it removes is worth more than the cost it adds. For instance, OpenGradient lets buyers choose among signed execution, TEE attestations, or ZKML, with proofs settled asynchronously from inference. NEAR AI also uses hardware attestations to confirm that an approved model ran inside a confidential-computing environment. Darkbloom routes encrypted requests to independently operated Macs whose hardware and configuration are verified by its coordinator. Each method reduces a different uncertainty about the supplier or execution, but can add operational overhead. The all-in comparison must include both that cost and whatever risk remains. This cost test also gives “proof of useful work” (PoUW) an economic definition. Computation is commercially useful only if an external buyer pays for the output, the result meets buyer-defined acceptance criteria, and the supplier retains a positive margin after infrastructure costs. Work heavily subsidized by network incentives would not meet this definition. Pareton applies this idea to inference optimization. Contributors submit changes to an existing serving engine. Pareton tests each change against the current version using the same model, hardware, and workload, and keeps it only if it cuts GPU time without reducing quality or otherwise breaking the SLA. This ties each contribution to measurable cost savings. What we have vs. what we need Current systems answer different questions. None so far closes the full loop from independent supply to reliable service, repeat demand, and self-sustaining suppliers. Sources: Ambient traffic; Engy traffic; Pluralis RL post-training; Teutonic 10B; NEAR AI; Darkbloom; OpenGradient; Gensyn Judge; Pareton What we have so far shows that technical feasibility has advanced faster than market economics. Select workloads can be distributed, but the open question is whether open coordination can close the gap in terms of reliability, privacy, support, etc. Capacity claims or reported traffic don't answer that question. I would want to see matched costs at comparable service levels, along with retry rates, tail latency, verification overhead, and supplier concentration and margins. The thesis fails if demand disappears with incentives, most capacity comes from a few contracted operators, or a single company can override the supposedly open market. There are also many open questions about using a crypto token, but product economics should come first. If one company controls the router, customers, pricing, and service margin, equity will probably capture most of the value. A crypto token could be useful or valuable if network activity requires it for fees, collateral, or settlement, or if it serves as the primary economic claim over the network. Otherwise, it may end up capturing little value even if it helps incentivize and coordinate supply. Parting thoughts I doubt an open network will replace the AI cloud. A hybrid looks more plausible: customers still buy from an accountable service, while that service uses outside suppliers for jobs that can move between machines without impairing service quality. This could broaden access to open models while keeping decentralization in the backend. The economics are not proven yet, but these networks have moved from concept to live usage. A durable market still requires repeat customers and independent suppliers that remain profitable as incentives fade. Token counts, capacity, and protocol activity are early signals. The next step is to turn that activity into sustained demand and sustainable margins. If that happens, open supply could become a durable part of the AI stack. Special thanks to Travis and Xavier for the feedback and insights. Disclaimer This article is prepared for general information purposes only. This post reflects the current views of its authors only and is not made on behalf of Lemniscap or its affiliates and does not necessarily reflect the opinions of Lemniscap, its affiliates or individuals. The opinions herein may be subject to change without this article being updated. This article does not constitute investment advice, legal or regulatory advice, investment recommendation, or any solicitation to buy, sell or make any investment. This post should not be used to evaluate the making of any investment decision, and should not be relied upon for legal, compliance, regulatory or other advice, investment recommendations, tax advice or any other similar matters. All liability in connection with this article, its content, and any related services and products and your use thereof, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement is disclaimed. No warranty, endorsement, guarantee, assumption of responsibility or similar is made in respect of any product, service, protocol described herein.

## Publication Information

- [Lemniscap](https://paragraph.com/@lemniscap/): Publication homepage
- [All Posts](https://paragraph.com/@lemniscap/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@lemniscap): Subscribe to updates
- [Twitter](https://twitter.com/lemniscap): Follow on Twitter