Skip to main content

What Is Phala Network? TEE Cloud for Onchain Apps

Phala Network runs apps in CPU and GPU TEEs with remote attestation. How Phala Cloud, dstack and the PHA token work, per Phala's docs, and where TEEs fall short.

Written by Eco
What Is Phala Network? TEE Cloud for Onchain Apps

What Is Phala Network? TEE Cloud for Onchain Apps

Phala Network is a confidential computing platform that runs applications inside hardware Trusted Execution Environments (TEEs) and produces cryptographic proof of what ran. Its docs describe Phala Network as "a decentralized cloud computing protocol" built for off-chain execution with on-chain verification, per the Phala Network docs overview. Today its main product, Phala Cloud, lets developers deploy standard Docker applications into CPU and GPU TEEs.
​

This page explains what Phala offers now, how its TEE cloud and the dstack framework work, how remote attestation lets outsiders check a workload, what role the PHA token plays according to Phala's own docs, and where TEE-based systems have limits. Sources were fetched October 21, 2026.
​

What is Phala Network today?

Phala Network today is a TEE cloud plus a token network. Developers rent confidential virtual machines and GPUs, run AI models or agent backends inside them, and get attestation reports that prove the hardware and code. The network side covers staking, governance and GPU compute providers on an Ethereum layer 2.
​

The Phala docs home calls Phala Cloud a "confidential AI native Neocloud" where any standard Docker application can be deployed into a TEE, billed by the minute, per the Phala documentation home. The Phala homepage lists three product lines: an agent sandbox that runs agent backends in a confidential VM, a GPU marketplace offering H100, H200 and B300 capacity with TEE-backed runtime proof, and confidential LLM endpoints that are OpenAI-compatible.
​

The project started earlier as a blockchain for confidential smart contracts. Phala's own five-year retrospective post describes Phat Contracts evolving into AI Agent Contracts, executed by worker nodes running a program called pRuntime inside Intel SGX enclaves. Phala's compute provider docs say the network has since sunset its parachain, migrated to an Ethereum L2, and upgraded its infrastructure to Intel TDX and GPU confidential computing.
​

How does Phala's TEE cloud work?

Phala's cloud runs each application inside a Confidential VM (CVM) on TEE hardware, such as Intel TDX for CPUs and NVIDIA confidential computing for GPUs. The hardware encrypts memory so the host cannot read it, and the dstack framework handles keys, networking and attestation for the containers inside.
​

CPU and GPU TEEs

A deploy on Phala selects a CPU TEE (Intel TDX) and, for GPU jobs, a GPU TEE (NVIDIA CC), as the example deploy flow on the Phala homepage shows. The same page's FAQ says confidential GPU workloads typically target near-native performance, with roughly 5 to 10 percent overhead depending on workload and hardware.
​

dstack

dstack is the software layer that turns Docker containers into confidential apps. Per the dstack overview, it deploys any Docker container as a CVM on supported TEEs, generates remote attestation reports, wraps HTTP services with automatic RA-HTTPS and content-addressed domains, and keeps applications portable across hardware through decentralized root-of-trust key management. Multiple containers from one Docker Compose file can run inside a single CVM.
​

Key management

Phala's dstack-cloud threat model says the key management service (dstack-kms) runs in its own TEE, that keys are generated and stored inside it, and that workload measurements must be registered on-chain before the KMS will release keys. Governance changes to those on-chain contracts go through a multisig and a timelock.
​

How does remote attestation work on Phala?

Remote attestation is a signed report from the TEE hardware that states what hardware, operating system and application code are running. Anyone can check the signature against the chip vendor's root certificates. On Phala, the report binds the Docker image hash, startup arguments and configuration, so a verifier can confirm the code was not swapped.
​

Per Phala's attestation overview, a CVM generates a quote that includes measurements of the Intel TDX CPU, the OS images, the application configuration and optional custom data such as public keys. Intel hardware signs the quote, and verifiers check it against Intel's root certificates. The docs split verification into three layers: the application, the platform (OS, KMS and network) and the complete chain end to end.
​

The dstack overview adds that the report is signed by the TEE hardware and co-signed by the application's own derived key. Earlier, Phala's retrospective post described a zkDCAP verifier, a zero-knowledge module meant to make verification of these attestations possible on Ethereum.
​

What do developers use Phala for?

Developers use Phala to run workloads where the operator should not see the data or should not be able to change the code unnoticed. Phala's own materials name private LLM inference, AI agent backends holding sealed keys, confidential GPU jobs such as training or fine-tuning, and agents that act onchain with verifiable execution.

  • Private inference. OpenAI-compatible LLM endpoints with private prompts and verifiable runtime state, per the Phala homepage.

  • Agent backends. Agent code in a confidential VM with sealed keys and private memory, per the same page.

  • GPU workloads. Deploying or fine-tuning models on TEE-protected GPUs and verifying the hardware, per the Phala docs home.

  • Offchain compute for smart contracts. The earlier AI Agent Contracts model let EVM contracts control agents that run offchain in TEEs, per Phala's retrospective post.

How do TEEs compare with ZK proofs and MPC?

TEEs, zero-knowledge proofs and multi-party computation all aim to compute on sensitive data without exposing it, but they place trust in different things. TEEs trust chip hardware and its vendor. ZK proofs trust mathematics and add proving cost. MPC splits data or keys across parties and trusts that enough of them stay honest.

Approach

What you trust

Main trade-off

TEE

CPU or GPU hardware and its vendor's attestation keys

Runs ordinary code close to native speed; exposed to hardware flaws

ZK proof

Cryptographic soundness of the proof system

Verification needs no hardware trust; generating proofs costs extra compute

MPC

A threshold of independent parties not colluding

No single holder sees the secret; parties must communicate for each operation

The approaches also combine. Phala's retrospective post describes a multi-proof design pairing TEE proofs with ZK proofs, and the dstack-cloud threat model lists MPC as a future plan for distributing KMS root key generation. A longer breakdown of when each fits is in TEE vs ZK proofs: when to use each.
​

What is the PHA token used for?

PHA is Phala Network's ERC-20 token on Ethereum. Staking PHA in Phala's Ethereum staking contract produces vPHA, which Phala's docs describe as the core token for the Phala L2, used for governance, staking, GPU worker collateral and future L2 applications. Phala Cloud itself is billed with standard pricing.
​

Per Phala's PHA token docs, PHA works in any EVM-compatible wallet, while vPHA "represents staked value and governance power" and is generally not used for transfers or payments. PHA and vPHA move between Ethereum and Phala L2 through a bridge.
​

Phala's compute provider docs state a fixed total supply of 1 billion PHA, with 70 percent allocated to mining rewards. That pool is split 20 percent to the treasury, 40 percent to Ethereum staking rewards and 40 percent to GPU miners. GPU miners earn vPHA based on hardware weight and uptime, with H100 weighted 1.0, H200 1.5 and B200 1.8, and payouts every hour.
​

Where this falls short

TEE systems move trust onto hardware rather than removing it. Users must trust the chip vendor's design and signing keys, side-channel attacks remain a known class of risk, and the operator can still switch machines off. Phala's own threat model lists these as residual risks.

  • Hardware and vendor trust. Attestation is checked against Intel's root certificates, per Phala's attestation overview, so the proof is only as strong as the vendor's hardware and key handling.

  • Side channels. The dstack-cloud threat model says TEE hardware may be vulnerable to microarchitectural side-channel attacks such as Spectre and Meltdown variants, and recommends keeping TCB firmware updated.

  • Single root key. The same page says the KMS root key is currently a single point of trust within the KMS TEE.

  • Availability. The cloud provider or host operator can shut down CVMs, so the threat model recommends cross-region, cross-provider redundancy.

  • Governance and RPC inputs. Colluding multisig signers meeting the threshold, or all RPC providers returning false chain state, can lead the KMS to accept unauthorized code, per the same threat model.

Frequently asked questions

Is Phala Network a blockchain?

It was a parachain; it has since migrated to an Ethereum L2, per Phala's compute provider docs. Most developer use today is through Phala Cloud.
​

Do I need PHA to use Phala Cloud?

Phala's docs home describes a Web2 pricing model billed by the minute; the token docs tie PHA and vPHA to staking, governance and GPU mining.
​

What is dstack?

dstack is Phala's framework for running Docker containers as attested confidential VMs, per the dstack overview.
​

Related reading

Methodology and sources

Every claim about Phala comes from Phala's own website, documentation or blog, fetched October 21, 2026. Hardware lists, token allocations and reward weights change with network upgrades; check Phala's docs for current values. This page does not cover token prices or markets.

Did this answer your question?