Skip to main content

Phala Network

Phala Network (PHA) — a reference card for a crypto project: what the product does and how verifiable the project’s key claims are; also — alignment with the Decentralized AI thesis (DecAI Fit).

Phala Network / Phala Cloud / dstack — an AI/Compute | Infra project: TEE infrastructure for “confidential AI” (CVM, attestation, confidential containers) and a network of compute providers. Token: PHA (ERC‑20, Ethereum; used for staking/delegation and governance; vPHA as the staking/governance token in the ecosystem).

Disclaimer

Important: this page is a reference overview of the project. Within DecAIHub, we separately record a verification based on open sources within the AI thesis (what is real AI/onchain/why a token, and which sources this is based on).
This is not financial advice and not a recommendation to buy/sell/hold any asset. We do not assess price, returns, or entry/exit timing.
Conclusions are based on publicly available materials found as of the verification date. The absence of confirmation does not imply the absence of the technology.

TL;DR (for readers who are not into AI)

  • What it is: infrastructure that allows running applications (including AI) in a Trusted Execution Environment (TEE) and obtaining cryptographic proofs of the environment (attestation).
  • Who it’s for: developers who need “confidential computing/AI” guarantees (the model/data are protected from the host), and compute providers (workers).
  • Why onchain/token: the token is used for staking/delegation (stake‑to‑earn, security of the compute provider network) and governance; some processes are tied to Ethereum staking contracts (PHA→vPHA).
  • What you can actually touch (Tier‑1): Phala Cloud Quick Start + dstack Getting Started.

How it works (very briefly)

  1. The user does: takes an existing Docker application and deploys it into a CVM (Confidential VM) via Phala Cloud/dstack.
  2. The system does: runs the workload in a TEE, provides remote attestation, storage encryption and secret management via a KMS; for dstack, the dstack↔tappd↔decentralized KMS architecture is described.
  3. The user gets: an application that can be verified (attestation), and an environment where the model/data remain confidential from the host operator.
  4. Where the blockchain is: the PHA token and the staking contract live on Ethereum; dstack describes “decentralized code management” via governance smart contracts (without specific addresses/deployed contracts in Tier‑1 sources).
  5. Token role: staking/delegation (stake‑to‑earn, backing of compute providers) + governance; vPHA is used as the staking/governance token.

Quick links: AI thesis fit

Project passport

Field Value
Project name Phala Network
Also known as (aliases) Phala Cloud | dstack | PHA
Logo (logo) ../assets/68_phala-network_logo.svg
Token symbol (ticker) PHA
Category AI/Compute | Infra
Primary chain (chain) Ethereum
Type EVM
Network status mainnet
Consensus (consensus) PoS (Ethereum)
Launch date (launch_date) —
Project status (status) active
Token (standard) ERC-20
Token contract 0x6c5bA91642F10282b576d91922Ae6448C9d52f4E
Token model (token_type) utility (staking + governance)
Max supply 1,000,000,000
Issuance fixed
Tokenomics (tokenomics, brief) Max total supply 1B (Etherscan); PHA→vPHA staking on Ethereum.
Governance DAO
Admins/keys —
Audit yes
Bug bounty yes
Team (team) —
Funding (investors/funding) —
AI component (ai_component) confidential computing for AI (TEE)
Use‑case (use_case) confidential AI cloud + CVM attestation
DecAI Fit — AI thesis fit 5/6 — high alignment with the Decentralized AI thesis
DecAI Fit component summary ai_score 3 / onchain_score 1 / token_score 2 / evidence_score 3
Last verified 2026-02-11

General project overview

Phala develops a stack for confidential computing in Web3 and for AI scenarios: Phala Cloud is described as a “Confidential AI native Neocloud” — an environment where Docker applications can be run in a TEE, obtaining attestation and isolation of the model/data from the host. In parallel, the open‑source SDK/platform dstack is described: running docker containers in a CVM (Confidential VM), remote attestation, “RA‑HTTPS” and a KMS layer for keys/encryption and migration between TEEs without vendor lock‑in.

In the token documentation, PHA is positioned as the native token of the compute provider ecosystem: it is used for rewarding workers, for staking/delegation (stake‑to‑earn) and for governance. An Ethereum staking contract that converts PHA into vPHA (the governance+staking token) is described separately.

Features/modules

  • Phala Cloud: a managed “confidential AI” platform, deploying Docker in a TEE, CVM, attestation (Tier‑1).
  • dstack SDK: TEE infrastructure for “confidential containers”: docker‑compose → CVM, RA‑TLS/RA‑HTTPS, KMS/encryption (Tier‑1).
  • Staking/Delegation: stake‑to‑earn, the StakePool/Vault delegation mechanics; PHA→vPHA staking on Ethereum (Tier‑1).
  • Security: the dstack security audit (zkSecurity), separate materials on security architecture/attestation (Tier‑1).

Typical scenarios

  • Scenario 1 (AI dev): deploys an LLM/agent service to Phala Cloud → gets isolation and attestation for trust in the environment.
  • Scenario 2 (Web3 dev): packages a service into docker‑compose → deploys via dstack → gets an RA report, storage encryption and secrets.
  • Scenario 3 (token holder): stakes PHA on Ethereum → receives vPHA → uses it for governance/staking/collateral in the ecosystem.

Getting started (wallet/network)

  • What you need: a Phala Cloud account (if managed) or access to a compatible TDX server (if self‑hosting dstack); an EVM wallet — for the token/staking.
  • Network/chain: PHA→vPHA staking — Ethereum Mainnet; the PHA token — ERC‑20 on Ethereum.
  • Fees: Ethereum gas for staking/transfers; the costs of cloud instances/usage in Phala Cloud (per the pricing).

Architecture/tech (non‑AI)

  • Components (dstack): dstack-vmm, dstack-gateway, dstack-kms, dstack-guest-agent, meta-dstack (Tier‑1 Getting Started).
  • Components (CVM path): docker containers inside a CVM; dstack manages the life cycle and attestation; tappd communicates with the decentralized KMS (Tier‑1 overview).
  • Participant roles: developers deploy applications; users/clients verify attestation; compute providers (workers) provide resources to the network.
  • Where logic runs: the workload runs offchain in a TEE/CVM; attestations/crypto proofs are produced in the TEE; part of governance/staking — onchain on Ethereum.
  • Dependencies: TEE (Intel TDX and others), docker‑compose, a KMS service; Ethereum for the staking contract.

Token/economics (expanded, no forecasts)

  • Token utility: PHA is used for rewards to compute providers (workers), for staking/delegation (stake‑to‑earn) and governance (Tier‑1 token intro).
  • Protocol necessity drivers: the delegation docs describe that compute providers must be “staked with some PHA” (stake as backing) (Tier‑1).
  • Who pays fees: users pay Ethereum gas when staking; delegators/stakers — network fees for operations.
  • Where fees go: the delegation docs state that 20% of rewards go to the treasury (Tier‑1).
  • Issuance/burn: a fixed supply of 1B PHA; 70% of the supply is allocated to the mining rewards pool. Within the pool: treasury 20%, Ethereum staking rewards 40%, GPU miners 40% (Tier‑1).
  • Security/incentive mechanisms: stake‑to‑earn delegation via StakePool/Vault; rewards are distributed among the treasury, pool owners and delegators (Tier‑1).
  • Distribution and token issuance schedule: a fixed supply of 1B; 70% of the supply — the mining rewards pool; the pool breakdown: treasury 20%, Ethereum staking rewards 40%, GPU miners 40% (Tier‑1).
  • Treasury: there is a treasury component (Tier‑1 delegation).

Governance

  • Who makes decisions: Phala is described as a DAO governed by PHA token holders; governance is mentioned in the token intro (Tier‑1).
  • How protocol parameters change: via governance mechanics; vPHA is used for Snapshot voting (Tier‑1).
  • Where decisions are discussed/made: Snapshot is listed as part of vPHA usage (Tier‑1 staking page).
  • Keys/multisig: —.

Security and incidents

  • Audits: dstack audited by zkSecurity (May–Jun 2025) + a link to the PDF report (Tier‑1).
  • Bug bounty: there is a public bounty program (Tier‑1 GitHub).
  • Incidents: —.
  • Threat model: TEE vulnerabilities/side channels, attestation/RA‑TLS errors, KMS/key risks and trust in hardware vendors, risks of centralized control in the managed layer.

Project status and timeline

  • Current status: active (the Phala Cloud docs and changelog are updated regularly; the dstack docs and audit are available).
  • Key releases/milestones: the dstack security audit has been completed and marked as a milestone; the Phala Cloud changelog records regular updates.
  • Roadmap: — (no formal roadmap was extracted from Tier‑1).

Ecosystem/integrations

  • Integrations: dstack and Phala Cloud are intended for deploying Docker services; “Building Confidential AI” contains integration cases (Eliza plugin, Virtuals game agent) (Tier‑1).
  • Partners: —.
  • Where it’s actually used: examples/cases from “Building Confidential AI” (Tier‑1).

AI component of the project

  • What is real AI here? infrastructure for running LLM/AI models and AI agents in a GPU TEE (confidential AI computing) + attestation/verifiable results (Tier‑1 Phala Cloud).
  • What is truly onchain? the PHA token (ERC‑20) and the PHA→vPHA staking contract on Ethereum; the stake‑to‑earn mechanics and governance are described in the documentation (Tier‑1).
  • Why is a token needed? incentives for compute providers, stake/delegation as backing, governance (Tier‑1).
  • Red flags (based on the information found): AI‑washing — low (explicitly “confidential AI”); onchain‑washing — medium (the workload is offchain in a TEE, onchain is mostly incentives/governance); token‑washing — low (stake‑to‑earn is described as the key mechanism of the compute provider network).

DecAI Fit component summary

  • DecAI Fit: 5/6 — high alignment with the Decentralized AI thesis
Component Level Score
AI reality high 3
Onchain necessity low 1
Token necessity medium 2
Evidence Tier‑1 present 3
Details

AI reality

AI_0 — AI intent (Tier‑1 roadmap) (1/0)

  • AI_0 (decision): 0
  • Claim (one line): AI is described as the current focus of the product (confidential AI computing), not as an “intent”.
  • Evidence: Tier‑1 — https://docs.phala.network/phala-cloud/what-is/what-is-phala-cloud
  • Why sufficient / why not (one line): the intent flag is not needed.
  • Conflict note (if any): —

AI_1 — what the AI does (1/0)

  • AI_1 (decision): 1
  • Claim (one line): Phala Cloud provides TEE infrastructure for running AI models/agents with confidentiality and attestation (“verifiable results”).
  • Evidence: Tier‑1 — https://docs.phala.network/phala-cloud/what-is/what-is-phala-cloud , https://docs.phala.network/phala-cloud/cases/tee_with_ai
  • Why sufficient / why not (one line): Tier‑1 explicitly describes the AI purpose and benefits (confidential AI).
  • Conflict note (if any): —

AI_2 — demos/examples (1/0)

  • AI_2 (decision): 1
  • Claim (one line): there are step‑by‑step quick start/Getting Started guides for deploying a CVM (confidential app) and verifying attestation.
  • Evidence: Tier‑1 — https://docs.phala.network/dstack/getting-started , https://docs.phala.network/phala-cloud/what-is/what-is-phala-cloud
  • Why sufficient / why not (one line): a reproducible developer flow with deployment and attestation steps.
  • Conflict note (if any): —

AI_3 — metrics/quality (1/0)

  • AI_3 (decision): 0
  • Metrics: —.
  • Context (version/date/how measured): —.
  • Evidence: Tier‑1 — https://docs.phala.network/phala-cloud/changelog
  • Why sufficient / why not (one line): the changelog lists models/updates but gives no reproducible AI quality metrics.
  • Conflict note (if any): —

AI_4 — tech description/architecture/versions (1/0)

  • AI_4 (decision): 1
  • Claim (one line): the dstack components, the CVM architecture, KMS/Root‑of‑Trust and the “assume breach” threat model are described.
  • Evidence: Tier‑1 — https://docs.phala.network/dstack/overview , https://docs.phala.network/dstack/design-documents/whitepaper
  • Why sufficient / why not (one line): there is an architectural technical description.
  • Conflict note (if any): —

Onchain necessity

OC_1 — contracts/addresses/chain (1/0)

  • OC_1 (decision): 1
  • Chain: Ethereum (token/staking).
  • Addresses/identifiers: PHA (ERC‑20) 0x6c5bA91642F10282b576d91922Ae6448C9d52f4E; vPHA (ERC‑20) 0x21d6eC8fc14CaAcc55aFA23cBa66798DAB3a0ec0.
  • Evidence: Tier‑1 — https://docs.phala.network/network/overview/phala-staking , https://etherscan.io/token/0x6c5bA91642F10282b576d91922Ae6448C9d52f4E
  • Why sufficient / why not (one line): the docs record the official addresses; the explorer confirms the token.
  • Conflict note (if any): —

OC_2 — onchain beyond just a token (1/0)

  • OC_2 (decision): 0
  • What useful logic is onchain: apart from the token/staking addresses, no specific “dstack governance” onchain contracts are given in Tier‑1 sources.
  • Evidence: Tier‑1 — https://docs.phala.network/dstack/design-documents/whitepaper
  • Why sufficient / why not (one line): the whitepaper describes governance smart contracts conceptually, without addresses/deployed contracts.
  • Conflict note (if any): —

OC_3 — onchain is critical (1/0)

  • OC_3 (decision): 0
  • “Replace the blockchain” test: the core functions of confidential compute/attestation are possible without a blockchain; the criticality of onchain for the product is not proven by Tier‑1.
  • Evidence: Tier‑1 — https://docs.phala.network/phala-cloud/what-is/what-is-phala-cloud
  • Why sufficient / why not (one line): onchain is primarily about incentives/governance.
  • Conflict note (if any): —

Token necessity

TK_0 — no token (1/0)

  • TK_0 (decision): 0
  • Claim (one line): the project has a token, PHA (ERC‑20), and the PHA→vPHA staking pair (ERC‑20).
  • Evidence: Tier‑1 — https://docs.phala.network/network/overview/phala-staking , https://etherscan.io/token/0x6c5bA91642F10282b576d91922Ae6448C9d52f4E
  • Why sufficient / why not (one line): the onchain fact of the token and the staking contract is confirmed by Tier‑1.
  • Conflict note (if any): —

TK_1..TK_4 (1/0)

TK_1 — payment for the service (1/0)

  • TK_1 (decision): 0
  • Claim (one line): direct “pay‑in‑PHA” for Phala Cloud was not recorded in Tier‑1 (the cloud — a “Web2 pricing model”).
  • Evidence: Tier‑1 — https://docs.phala.network/phala-cloud/what-is/what-is-phala-cloud
  • Why sufficient / why not (one line): the token utility is confirmed via staking/governance/rewards.
  • Conflict note (if any): —

TK_2 — incentives/collateral/penalties (1/0)

  • TK_2 (decision): 1
  • Claim (one line): stake‑to‑earn: workers must be staked with PHA; delegation provides incentives to compute providers and delegators.
  • Evidence: Tier‑1 — https://docs.phala.network/overview/pha-token/delegation/delegate-to-stakepool
  • Why sufficient / why not (one line): the delegation docs describe stake backing and rewards.
  • Conflict note (if any): —

TK_3 — governance (1/0)

  • TK_3 (decision): 1
  • Claim (one line): Phala is described as a DAO governed by PHA token holders; vPHA is used for Snapshot voting.
  • Evidence: Tier‑1 — https://docs.phala.network/overview/pha-token , https://docs.phala.network/network/overview/phala-staking
  • Why sufficient / why not (one line): the token docs and staking docs describe the governance role.
  • Conflict note (if any): —

TK_4 — token is replaceable (1/0)

  • TK_4 (decision): 0
  • Claim (one line): the token is built into the stake‑to‑earn and governance mechanics.
  • Evidence: Tier‑1 — https://docs.phala.network/overview/pha-token , https://docs.phala.network/overview/pha-token/delegation/delegate-to-stakepool
  • Why sufficient / why not (one line): without the token, the incentives/delegation mechanism breaks down.
  • Conflict note (if any): —

Evidence (table)

Tier Source What it proves
Tier‑1 https://docs.phala.network/phala-cloud/what-is/what-is-phala-cloud that Phala Cloud is a confidential AI neocloud: GPU TEE, verifiable results, docker deploy.
Tier‑1 https://docs.phala.network/dstack/overview the dstack/CVM architecture, attestation, decentralized KMS and portable confidential containers.
Tier‑1 https://docs.phala.network/dstack/getting-started a reproducible guide to deploying dstack and deploying docker-compose into a CVM (demo/guide).
Tier‑1 https://docs.phala.network/dstack/design-documents/whitepaper the dstack whitepaper: zero trust platform, KMS and governance model (technical design).
Tier‑1 https://docs.phala.network/dstack/security-audit the dstack security audit by zkSecurity + a link to the PDF report.
Tier‑1 https://docs.phala.network/images/audits/dstack-audit.pdf the full audit report (PDF).
Tier‑1 https://docs.phala.network/phala-cloud/cases/tee_with_ai TEE for AI systems + cases (agent frameworks, integrations).
Tier‑1 https://docs.phala.network/phala-cloud/changelog current Phala Cloud updates (including confidential AI models with TEE attestation).
Tier‑1 https://docs.phala.network/network/overview/phala-staking the staking contract on Ethereum: PHA→vPHA; vPHA uses (governance/staking/collateral).
Tier‑1 https://docs.phala.network/overview/pha-token/delegation/delegate-to-stakepool stake-to-earn delegation: StakePool/Vault, rewards and the treasury share.
Tier‑1 https://docs.phala.network/overview/pha-token the role of PHA (workers rewards, running programs, governance, staking/delegation).
Tier‑1 https://github.com/Phala-Network/bounty-program bounty program (code bounty; disclosure email).
Tier‑1 https://etherscan.io/token/0x6c5bA91642F10282b576d91922Ae6448C9d52f4E the onchain fact of the PHA token (ERC‑20), max total supply 1B.

No comments to display

Back to top