Compare decentralized compute platforms

Summary

“Decentralized compute” covers services with different customer paths and provider roles. Compare the particular route you will use, not a project's token alone. This table distinguishes confirmed documentation from gaps; an unspecified identity-check requirement is not evidence that no checks exist.

Access, admission and payments

Platform and route	Customer onboarding	Provider admission documented in the cited sources	Payment or incentives
Akash, Console Air	Connect a wallet and sign transactions yourself; the interface is self-hostable.	Provider build guide specifies a Kubernetes cluster and operational prerequisites. This does not establish every listing or audit requirement.	Console Air documents an AKT/ACT wallet workflow. Check the current deployment denomination rather than treating the two assets as interchangeable.
Bacalhau, an operated cluster	Connect the CLI to the selected deployment.	Administrators can approve a pending compute node to join a cluster and receive work.	No marketplace payment token is established by these orchestration documents.
Aethir, Cloud portal	Bind a wallet; the customer wallet guide requires KYC before claiming or withdrawing ATH.	Hosts connect a wallet before onboarding GPUs; KYC is required before claiming or withdrawing earnings.	The documented portal balance and claims use ATH.
Bittensor, subnet participation	Use the network SDK/CLI and a wallet; inspect the chosen subnet's separate interface.	Miners produce a subnet's commodity and validators score contributions. Exact participation requirements need the chosen subnet's documentation.	The network documentation describes TAO incentives; it does not establish a universal customer tariff.
Fluence, Console and Provider Application	Console documentation lists email, Google or GitHub sign-in; it still includes an alpha-program eligibility note.	Provider documentation requires team approval, KYB and Tier 3 or Tier 4 data centers.	Console uses a prepaid USD balance funded by card or crypto. Protocol documentation separately describes USDC provider revenue and FLT capacity incentives.
Marlin Oyster, CVM CLI	Deploy from a wallet using a Docker Compose file.	The canonical repository includes an AWS-account setup path and operator control-plane software.	The documented Arbitrum deployment path needs USDC and ETH for gas.
Phala Cloud	Use a Cloud workspace and its balance.	This is the documented hosted Cloud path; a general independent-provider admission rule is not established here.	The FAQ documents balance top-ups and card auto-top-up. It does not require treating PHA as the customer billing unit.
0G Compute	Router with an API key, or Direct SDK with wallet-signed requests.	The inference-provider guide requires a compatible model service, supported TEE hardware and a provider broker.	Router deposits use 0G tokens; the provider guide also requires 0G tokens for gas.

Workloads and confidentiality

Platform	Workload established by its documentation	Confidentiality evidence
Akash	Container deployments.	The cited wallet/provider guides do not establish host-confidential execution.
Bacalhau	Docker and WebAssembly jobs placed near data.	Cluster membership controls do not establish protection from the compute-node operator.
Aethir	GPU capacity in the Cloud host/customer workflow.	The cited portal and payment guides do not establish enclave isolation.
Bittensor	Subnet-defined digital commodities, including compute, storage and prediction.	Contribution scoring is not itself evidence of host-confidential execution.
Fluence	CPU and GPU instances, including virtual machines.	The cited instance and admission documentation does not establish a TEE guarantee.
Marlin Oyster	Docker Compose workloads and enclave tooling.	The repository includes attestation generation and verification components; deployment must bind a workload to the expected attestation.
Phala Cloud	Container applications inside confidential VMs.	Its FAQ documents Intel TDX isolation and an attestation workflow.
0G Compute	Model inference and fine-tuning.	The provider guide documents CPU/GPU attestation and signed results. Router-side verification has its own trust boundary.

Trust model / threat model

A notable distinction is explicit in 0G's verification documentation: requesting verify_tee asks the Router to verify the provider signature. The returned boolean is the Router's assertion; it is not the raw proof. The same document describes independent verification for callers who do not want to rely on that assertion.

For any TEE route, decide which measurement, signer and security baseline you accept before releasing secrets. See remote attestation and TEE state and revocation. For other routes, do not infer host secrecy from decentralization, payments or performance scoring.

Readiness

Usable with route-specific qualifications. These are documented software and service paths, not equivalent products. Some cited guides retain eligibility or rollout qualifications. Verify the exact customer and provider path before committing a workload.

Limits

No blanket “no KYC,” permissionless-provider or confidential-by-default claim is made. Prices, capacity, performance rankings and token investment claims are omitted. Use decentralized compute as the broader map, then verify the selected deployment's contract, billing and recovery conditions.

Primary sources

Also in Confidential Computing

Page history

Updated: 2026-10-25
Origin: Written for ungovernable.tech.
Improve this page: Suggest an edit — issues and pull requests are welcome.