Decentralized Compute: What It Is, How It Works, and Why It Runs on Phones
Decentralized compute: what it is, how it works, and why it runs on phones
Three companies control most of the world’s cloud infrastructure. When you deploy an application, you rent a slice of a building you will never see, operated by a company that can read your memory, change your prices, or switch you off. Decentralized compute is the alternative: workloads that execute on hardware no single operator controls, with cryptographic proof of what actually ran.
The term gets used loosely. Plenty of projects call themselves a decentralized computing platform while running on rented racks in the same data centers everyone else uses. This guide covers what the category actually requires, how a decentralized compute network works underneath, and what you can actually run on one.
The category
Compute without a single owner
No single owner, execution that proves itself.
What decentralized compute actually means
Distributed computing spreads work across many machines. That has existed for decades, and every hyperscaler does it. The machines still belong to one company, sit in buildings that company leases, and answer to that company’s control plane.
Decentralized compute changes ownership, not geography. Three properties separate it from a distributed cloud:
Permissionless supply
Anyone can contribute hardware without asking. No vendor contract, no procurement, no allowlist.
Market-based matching
Work is assigned by an open mechanism with published rules, not by an internal scheduler you cannot inspect.
Verifiable execution
The network proves your code ran unmodified on genuine hardware. Without this, you have swapped one operator you must trust for thousands of them.
That third property is where most of the category falls down. Spreading machines across many owners multiplies the number of parties who could tamper with your workload. A decentralized cloud computing platform that cannot prove execution has made the trust problem worse, not better.
“Decentralization without verification is just a longer list of people you have to trust.”
How a decentralized compute network works
Underneath the branding, these networks share four moving parts. The names below are Acurast’s, but the shapes carry over to other networks in the category.
1. Supply
Independent operators, called Compute Providers, register hardware with the network. On Acurast the hardware is a smartphone running the Processor app, onboarded in about three minutes. The phone reports benchmarks and heartbeats on-chain, so its capacity and liveness are public facts rather than marketing claims.
2. Matching
A developer submits a Deployment: the code to run, the schedule, the resource requirements, and where results should go. The Matcher pairs that Deployment with Processors that fit, through a process called liquid matching. Pricing is set by the mechanism rather than by hand, which is why dynamic pricing matters: manually set provider rates go stale and never get updated.
3. Execution
The Deployment runs inside a runtime on the assigned hardware. Acurast has two: the Acurast Secure Hardware Runtime (ASHR), which executes inside the phone’s Trusted Execution Environment, and the Acurast Zero-Knowledge Runtime (AZKR).
4. Verification and settlement
Execution produces attestation, a hardware-signed statement about what ran. A reputation engine tracks provider behaviour over time, and Staked Compute puts economic weight behind it: providers commit tokens, delegators back them, and bad behaviour costs money. Compute fees are burned as gas rather than paid to the operator.
Note: Acurast runs on its own blockchain, built with Substrate — a framework for building blockchains. The coordination side matches Deployments to phones and tracks provider reputation; the execution side runs your code on the hardware.
The part most networks skip: verification
A Trusted Execution Environment is a hardware-isolated area of a chip. Code inside it is sealed from the operating system, from other applications, and from whoever is holding the machine. Key attestation is the companion mechanism: the silicon signs a statement proving the hardware is genuine and the code loaded into it was not modified.
The practical result is that you do not need to know who runs the hardware. You verify the chip instead.
Which hardware you pick decides how much of this you get for free. Modern smartphones ship TEEs and dedicated security chips as standard, because billions of people store banking credentials and biometrics on them. Server fleets can offer confidential computing too, but as a paid option on specific instance types. On phones it is the floor.
Where the hardware actually comes from
Networks in this category source capacity in three broad ways.
Some aggregate spare capacity from existing data centers. The operator changes, the building does not, and the workload still lands on racked hardware inside a facility with a landlord, a jurisdiction, and a power contract.
Some aggregate purpose-built GPU rigs. This works for training and rendering, and it competes on price per GPU hour, which is a race to the bottom against companies with better financing.
Acurast took the third path. The compute comes from smartphones people already own, including phones that were otherwise heading for a drawer. Around 1.39 billion smartphones are sold every year on a replacement cycle of under three years, so the supply is enormous, already manufactured, and already distributed to where people live.
280K+
Onboarded phones
175+
Countries
918M+
On-chain transactions
The geography follows from that. Cloud regions cost hundreds of millions to build, so the big providers operate a few dozen of them. A network of phones reaches more than 175 countries without building anything, because that is where the phones already are.
What you can actually run
The question that decides whether decentralized cloud infrastructure is usable is a boring one: does existing code run without a rewrite?
Node.js workloads
API integrations, web servers, scheduled jobs, Telegram bots, headless browsers with Puppeteer, WebAssembly modules.
Linux containers
Cargo brought a container model to the mobile edge, so arbitrary Linux binaries deploy to phones the same way they would to a server.
LLM inference
Models in GGUF format run through an integrated llama server that exposes OpenAI-compatible endpoints. Existing clients change a URL instead of a codebase. NodeGhost packaged an entire AI gateway into one Cargo build and ran inference and web search on phones for an hour with nothing dropped.
Deployment happens through the CLI, the SDK, the Acurast Hub, or an x402 Deploy Agent that settles in USDC on Base. No credit card, no servers to manage, no account.
Why this matters
Autonomous agents hold keys, move money, and run without a human in the loop. An agent whose runtime can be paused by a vendor is not autonomous in any meaningful sense, and neither is the business depending on it.
Confidential workloads have the same problem from the other direction. Health, legal, and financial data cannot sit in a provider’s logs, and a policy promise is not the same guarantee as hardware isolation. Acurast, Pocket Network and NodeGhost have been testing what a fully decentralized AI stack looks like when no part of the pipeline touches a cloud server.
Decentralized compute is not a hosting provider with a decentralized coat of paint. It is a verifiable execution layer, and the network running it today has 280,000 phones in more than 175 countries, secured by hardware nobody had to build, in buildings nobody had to construct.
If you have a spare phone, you can be part of the infrastructure shift and get rewarded for your contribution. For the decentralized compute network, every phone matters! Become a Compute Provider.
Building on Acurast? If you’re running your own models, agent backends, or other services on attested devices, come talk to us. Join the Discord.
