DEV Community: Soulman

PHA Is Becoming the Currency of Compute on Phala Cloud

Soulman — Wed, 12 Aug 2026 16:43:49 +0000

Note: This article is adapted from the official Phala Foundation announcement. See it here: https://x.com/phalafoundation/status/2083189377841152133

Phala Foundation just announced a real shift in how $PHA works inside the network, and it’s worth breaking down for anyone building on or holding the token. The vision behind it is simple: increase value to holders by tying $PHA directly to the compute people are already using every day on Phala Cloud. This is described as the first step of many toward that goal, and it comes in two parts.

Paying for Compute With $PHA
Soon, $PHA payments will be live on Phala Cloud. That means instead of $PHA sitting off to the side as something you hold or stake, it becomes the actual currency you spend to run confidential compute for AI and agents. For developers and institutions already deploying on Phala, this closes the gap between the token and the product. The more compute gets used, the more $PHA gets used too, and that’s the kind of direct utility that matters more than any promise on paper.

Staking $PHA for $vPHA on Ethereum
The second path is staking. You can stake $PHA on Ethereum and receive $vPHA at the current exchange rate. $vPHA isn’t a passive receipt token either, it actually does three things: it gives you voting power in Snapshot governance, it lets you take part in L2 staking, and it can serve as collateral for GPU resources on the network. So staking here isn’t just about sitting on a position, it’s about getting a working stake in how the network runs and grows.
A couple of details to keep in mind before staking. Unstaking takes 21 days, so treat it as a commitment rather than something liquid. Ethereum gas fees apply when you stake and unstake, so smaller amounts should factor that cost in. And claiming is manual, nothing shows up in your wallet automatically, you have to go in and claim it yourself once it’s ready.

What This Means Going Forward
For builders and institutions running or planning workloads on Phala Cloud, this update points to where the network is heading which is a token that’s actually used to run things, not just held or voted with. If $PHA is already part of your setup, now is a good time to look at where staking for $vPHA fits into your plans before the payment system goes live.

Head over to Phala’s official channels for the full details on staking and to stay updated on when $PHA payments launch on Phala Cloud.

DeepSeek V4 Flash 0731 Is Now Live on Phala

Soulman — Wed, 12 Aug 2026 16:37:42 +0000

Note: This article is Adapted from Phala Network’s official release announcement.

Phala just rolled out the official release of DeepSeek V4 Flash 0731, replacing the earlier preview checkpoint with a version that brings real improvements to agentic work. If you tested the preview and were curious what the finished model looks like, this is it, and it runs through confidential GPU TEE inference, so your prompts and outputs stay protected even from the infrastructure running them.

What’s Actually Different
DeepSeek kept the same efficient setup that made the preview interesting in the first place: 284 billion total parameters with only 13 billion activated at once, paired with a 1 million token context window. That combination means you get a model that can hold a lot of context without demanding the compute cost of a fully dense model that size.
What changed is performance. DeepSeek is reporting solid gains in coding agents, tool use, cybersecurity tasks, and full-stack development work. These are the areas where agentic models tend to fall apart under real workloads, so improvements here matter more than a bump on a generic benchmark.

Pricing and How to Access It
The model is available now under the id deepseek/deepseek-v4-flash. Pricing comes in at $0.20 per million input tokens, $0.40 per million output tokens, and $0.07 per million for cached reads, keeping it accessible for teams running frequent agent calls or long context sessions.
If you’re building agents, automating dev workflows, or just want inference that keeps your data private by design, this is worth trying today. Head over to Phala Cloud, pull up the model, and put it to work on your next build.
Go pull up the model on Phala here: https://phala.com/models/deepseek/deepseek-v4-flash and see how it handles your workload.
Read the official release here: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-0731

Kimi K3 Is Now Live on Phala, and It Runs Inside a Confidential GPU

Soulman — Wed, 12 Aug 2026 16:32:13 +0000

Note: This article is adapted from Phala official announcement on the launch of Kimi K3.

Phala just added Kimi K3 to its lineup of models available for confidential inference, and it’s worth paying attention to if you build anything that touches sensitive data. Kimi K3 comes from Moonshot AI and it’s a massive model, 2.8 trillion parameters, built to handle serious coding work, research, and agent tasks that stretch on for a long time. It also understands images natively, not as a bolted on feature, and it can hold up to 1 million tokens of context at once, so it can keep track of an entire codebase or a long stack of documents without losing the thread.
What makes this deployment different from just calling the model through a regular API is where it runs. Phala hosts Kimi K3 inside a GPU trusted execution environment, which is a secure enclave that keeps your prompts, your documents, and everything you send to the model shielded from the infrastructure around it. Nobody operating the servers can see what you’re sending or what comes back, and the whole setup can be independently verified through attestation, so you’re not just taking someone’s word for it.

Why This Matters for Builders
If you’re working with proprietary code, internal research, client data, or anything you wouldn’t want sitting in the clear on a third party server, this changes what’s possible. You get a frontier level model capable of long coding sessions, deep research, and vision based agent work, but without giving up privacy to get there. That combination has been hard to find until now. Most powerful models require you to trust the provider with your data. Here, the trust is replaced with verification.
This is useful for teams building coding agents that need to work across large repositories over long sessions, for researchers combining text and visual data, and for any application where the cost of a data leak is too high to risk. You get the intelligence of a frontier model with a much smaller attack surface.

Getting Started
Kimi K3 is available now on Phala Cloud under the model name moonshotai/kimi-k3, priced at $3 per million input tokens and $15 per million output tokens.
The API documentation is available on Phala’s docs site here: https://phala.com/models/moonshotai/kimi-k3, and if you want to understand the architecture behind the model itself, Moonshot AI has published the full technical report. Check it here: https://arxiv.org/abs/2607.24653

How iExec Uses dstack to Bring Verifiable Trust to Confidential DeFi

Soulman — Fri, 24 Jul 2026 03:08:49 +0000

Note: This article is adapted from the official Phala blog post, How iExec Uses dstack For OnChain Finance. Full credit for the original reporting and technical details goes to the Phala team.
See it here: https://phala.com/posts/iexec-dstack-nox-chain-of-trust

Confidential DeFi has a problem that doesn’t get talked about enough. You can encrypt data on chain all day, but eventually that data has to be processed somewhere off chain, and someone has to trust that the processing actually happened the way it was supposed to. iExec is addressing this with Nox, its confidential compute protocol for DeFi and RWA applications, and they’re using Phala’s dstack to handle the trust part of that equation.

What iExec and Nox Do
iExec builds infrastructure for confidential computing in on-chain finance. Nox is their programmable confidentiality protocol, and it lets DeFi and RWA applications work with sensitive financial data without exposing it publicly on chain. Builders can add confidential execution, selective disclosure, and verifiable computation to existing EVM applications without rebuilding everything from scratch. The first product direction for Nox is confidential token infrastructure, which matters most in situations where users want privacy, protocols need to confirm correctness, and institutions need a reviewable path for permissions.

How dstack Fits In
Nox handles the on-chain side with encrypted handles and smart contracts, but the actual computation still happens off chain, and that’s where dstack comes in. dstack runs the Nox workload inside a measured environment on real hardware. It boots the system, captures evidence of exactly what code is running and what state it’s in, and generates a quote that can be tied to a specific request, deployment, or transaction. A verifier checks that evidence before anything sensitive happens, like releasing keys or accepting a result. In practice, a runner processes encrypted financial data, produces proof of its own environment through a lightweight service called dstack-quote-service, and only after that proof checks out does it get access to the next step. Most of that complexity sits behind simple APIs, so builders don’t need to become experts in trusted execution environments just to use it.

Why This Matters
DeFi and RWA applications sit on a real tension. Users want their data private. Protocols and institutions still need a way to verify things are correct and compliant. This setup gives both sides what they need. Sensitive data stays encrypted, computation happens in a verifiable environment, and there’s an audit trail available when it’s needed, without ever exposing the raw data itself.
For anyone building in confidential DeFi or RWAs, this is a practical example of what privacy infrastructure looks like when it’s built to actually be verified, not just taken on trust.

VoxCPM2 Can Clone Any Voice. Phala Makes Sure No One Else Hears It.

Soulman — Fri, 24 Jul 2026 03:01:24 +0000

Note: This article is Adapted from the official Phala Network post.

VoxCPM2 turns multilingual text-to-speech and voice cloning into something developers can build with directly, and Phala’s approach to hosting it is worth understanding before you touch the code.

What VoxCPM2 actually does
VoxCPM2 is an open source speech model from OpenBMB that generates natural sounding speech across 30 languages, and it can clone a voice from a short audio clip. You can also design a completely new voice just by describing it in plain language, no reference audio required. The model outputs studio quality 48kHz audio and runs fast enough for real-time use. It is fully open source under an Apache 2.0 license, so it is free to use commercially, and that alone makes it a serious option for any app or product that needs voice.

Why Phala’s hosting matters here
Voice cloning only works if you feed it real audio samples, along with prompts, cloning settings, and whatever credentials your app needs to run. That is sensitive material by nature. Phala deploys VoxCPM2 inside a TEE CVM, which is essentially a sealed computing environment. Everything processed inside it, the voice data, the configuration, the app credentials, stays hidden from outside view, including from the infrastructure provider itself. So the privacy protection is not something you add later, it is built into how the deployment works from the start.

Why Phala is worth watching
This is not an isolated example. Phala keeps shipping practical, ready to deploy templates that put real privacy protections around AI workloads, instead of just talking about confidential computing as a concept. For developers and institutions that need to handle sensitive data responsibly, that consistency is what makes Phala worth paying attention to right now.
If you want to try VoxCPM2 yourself, the deploy template is live on Phala Cloud: https://cloud.phala.com/templates/voxcpm, and both the template code: https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/voxcpm and the original VoxCPM repository from OpenBMB are open on GitHub. find it here: https://github.com/OpenBMB/VoxCPM

Your Research Notebook Just Got Its Privacy Back

Soulman — Fri, 24 Jul 2026 02:54:22 +0000

Note: This article is Adapted from the official Phala post.

Open Notebook brings that NotebookLM style research workflow, the kind where you feed in sources and let AI help you organize your thinking, into a self-hosted setup you can actually control. If you’ve used NotebookLM before, you know how useful it is to dump in a pile of documents and have something make sense of them for you. The catch has always been that your documents, your notes, and your questions all end up sitting on someone else’s servers. Open Notebook gives you that same experience without handing everything over.
What makes the Phala version worth paying attention to is where it actually runs. Your sources, your notes, your prompts, and even the app’s internal state stay inside a TEE CVM, which is just a way of saying the whole thing runs in an isolated environment that even the infrastructure provider can’t peek into while it’s active. So you get the convenience of a polished research tool, but without the usual tradeoff of exposing sensitive material to get it.

You can deploy it yourself right now at https://cloud.phala.com/templates/open-notebook, and it’s live in minutes.
You can also check the Template code: https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/open-notebook
Upstream: https://github.com/lfnovo/open-notebook
For developers building on this, the setup stays familiar, you’re just running it somewhere that doesn’t ask you to trust a third party with your data. For institutions dealing with sensitive research or proprietary documents, that’s often the difference between being able to use a tool like this at all and having to sit it out entirely.

Why Nvidia’s Blackwell Changes the Math on Confidential AI

Soulman — Fri, 24 Jul 2026 02:49:25 +0000

Note: This article is adapted from Phala’s official blog post, “TEE is Really Fast on Nvidia Blackwell,” originally published on July 2, 2026. Full credit goes to the Phala research team for the original research and writing.
See it here: https://phala.com/posts/blackwell-gpu-cc-serialized-bridge

TEE is Really Fast on Nvidia Blackwell
Confidential computing has always come with a trade off. You get privacy, but you pay for it in speed. New research from Phala’s team shows that on Nvidia’s newest Blackwell chips, that trade off is starting to disappear, and the real story is more interesting than just it’s faster now.
The chip is no longer the problem
On Nvidia’s B300 Blackwell chips, running AI computation under confidential computing costs almost nothing. Matrix multiplication, the basic math behind every AI model, runs at 0.998x normal speed. On longer runs, it actually matched or slightly beat non-confidential speed. For years, people assumed privacy meant slow. That assumption no longer holds on this hardware. The chip itself is not where the slowdown lives anymore.

So where does the cost go instead?
It goes into the connection between the secure part of the system and the GPU. Every time data has to move across that connection, it moves one piece at a time and pays a real setup cost, even when the software thinks it is running in the background. This quietly breaks a lot of popular AI serving tools, including widely used ones like vLLM. These tools try to save time by overlapping tasks, but under confidential computing, that trick backfires and adds delay instead of avoiding it. In one test, simply turning off that default setting took performance from 3550 tokens per second to 4104. A deeper fix pushed it to 5518 tokens per second, landing within 8 percent of normal, non-confidential speed.

The cost depends on what you are running
Not every workload pays the same price. Light, simple serving barely notices any slowdown at all. Heavier, steady workloads lose around 13 to 14 percent. Mixture of experts models and jobs that rely heavily on cached data lose the most, up to 27 percent, because they move more data across that same connection. The pattern is consistent: more data movement means more cost.
Loading models shows the exact same pattern. The normal way of loading a large 120 billion parameter model took almost 5 minutes on Blackwell hardware. A smarter loading method cut that down to about 8 seconds. That difference decides whether confidential AI can actually be treated as something ready for real production use, or whether it stays stuck as a research demo. The research also confirmed that confidential workloads can run across multiple GPUs connected together, with very high data transfer speeds between them, over 510 gigabytes per second. That is a real step toward trusting an entire cluster of GPUs together, not just single chips on their own.

Why this matters, and why Phala stands out
Most teams working in confidential AI are focused on simply getting the technology to work at all. This research goes further. It explains exactly why confidential computing is slow in certain situations and shows how to fix the actual cause instead of just accepting the cost as unavoidable. That is a meaningful difference. It is the difference between a research demo and something developers and institutions can actually rely on for real workloads.
This kind of work directly shapes how confidential AI systems should be built going forward, from how workloads get scheduled, to how models get loaded quickly, to how cached data gets handled, to how entire GPU clusters can be trusted together. It is the foundation that will decide whether confidential AI stays a niche option or becomes the normal, expected way that AI models get served.
If you work with AI infrastructure, or you are evaluating confidential computing for your own systems, this research is worth reading directly. The full paper is called “The Serialized Bridge: Understanding and Recovering LLM Serving Performance under Blackwell GPU Confidential Computing,” and it goes much deeper into every result mentioned here.
Find the full paper here: https://arxiv.org/abs/2606.23969

OPPO and Phala Just Solved a Real Problem in Confidential AI on Kubernetes

Soulman — Tue, 30 Jun 2026 23:47:35 +0000

Note: This article is Adapted from the official OPPO × Phala research paper: https://arxiv.org/abs/2606.03323

If you are running AI workloads on Kubernetes and handling sensitive data, you have probably asked yourself at some point: how do I actually know what is running, where it is running, and whether it has been tampered with? Most setups leave that question unanswered at the container layer. This paper from OPPO and Phala changes that.

What the Paper Actually Does
The research introduces a way to verify three things before any sensitive data enters your workload: the physical hardware running the job, the container image that was loaded, and the identity of the Pod itself. This is done through remote attestation at the Pod level inside Kubernetes, which means the verification happens where the work actually runs, not just at the machine level below it.
Most confidential compute setups today handle attestation at the hardware or virtual machine level. That leaves a gap. Once you move into container orchestration with Kubernetes, you lose that chain of trust unless something bridges it. This paper builds that bridge.

Why This Matters for Builders and Institutions
If you are building AI pipelines where the data cannot be exposed, healthcare, finance, legal, or enterprise AI, you need more than a promise that the environment is secure. You need proof. What this architecture gives you is a cryptographic receipt that covers the full stack: the chip, the image, and the workload identity, all verified before a single byte of sensitive data goes in.
For institutions evaluating confidential AI infrastructure, this is the kind of auditability that makes deployment decisions easier. You are not trusting a vendor claim. You are verifying it.
The full paper is available at https://arxiv.org/abs/2606.03323 and it is worth a read if this is part of what you are building toward.

Private AI Gateway by Phala: What It Is and What It Actually Does

Soulman — Tue, 30 Jun 2026 23:43:03 +0000

Note: This article is Adapted from the official Phala Network blog post: https://phala.com/posts/private-ai-gateway-verified-private-ai-compute

Most people building with AI today assume their prompts are private because they’re using HTTPS. That assumption has a gap. Encrypting the connection protects data in transit, but it doesn’t tell you anything about what happens inside the server handling your request. Private AI Gateway is built to close that gap.
Private AI Gateway is a routing and verification layer for AI inference running inside Trusted Execution Environments. It sits above your model providers and makes sure every request travels a verified path from client to model and back, with proof attached at every step. The result is that developers get a familiar API surface, security teams get something concrete to inspect, and sensitive prompt content stays protected the entire time.

How the verification actually works
When you send a request through Private AI Gateway, the client first checks the gateway’s attestation report. That report confirms which workload is running and exposes the workload’s encryption key. The client then uses that verified key to encrypt sensitive parts of the request before it even leaves the client machine. Only the verified gateway workload holds the matching private key, so nothing in between can read the prompt content. Routing information like billing, model selection, and rate limits stays visible because the gateway still needs to do its job. The sensitive parts stay locked until they reach the verified boundary.
Every request also produces a signed receipt. That receipt records which model route handled the request, what verification was checked before the prompt moved forward, and a chain of hashes from the original request to the final response. It gives security teams an auditable record after the fact rather than a trust assumption made upfront.

Why fragmented compute is a real problem
TEE-based model capacity is spread across many providers right now, and they all handle verification differently. Some bind their TLS key to the attestation. Some expose a separate encryption key. Some rely on GPU-level attestation. If you are routing across multiple providers, you currently have to handle each of these verification styles manually, which is an operational burden that compounds as you add providers.
Private AI Gateway handles that by aggregating providers based on their proof properties. A route only becomes available when it has the right model, acceptable latency, and a verified state. The gateway pre-verifies providers in the background, enforces the right channel binding for each one, and fails the request if the required proof is missing rather than silently routing to an unverified fallback.

What this means for developers, builders, and institutions
The API surface is OpenAI-compatible, so integration does not require rewriting existing code. You add an attestation check and an encryption step, and the rest of your workflow stays the same.
For institutions handling sensitive data, the signed receipts solve a compliance problem that attestation alone cannot. Knowing a workload was verified at boot is useful. Knowing which verified route handled each specific request, with a hash chain to prove it, is what security and legal teams actually need when they review AI usage.

Read the full blog post above from where this article is adapted from.

OpenMed Is Now Deployable on Phala Cloud

Soulman — Sun, 21 Jun 2026 12:52:58 +0000

Note: This article is Adapted from the official Phala announcement.

Healthcare AI has a data problem that most people don’t talk about enough. Clinical notes are some of the most sensitive information that exists, and yet to get value out of them with AI, you have to run them through pipelines that process, store, and analyze that data somewhere. The question is always where, and who can see it. OpenMed solves the first part by taking unstructured clinical text and turning it into structured data that AI systems can actually use. Phala Cloud solves the second part by making sure all of that happens inside a confidential compute environment where the data stays protected the entire time it’s being processed.

What Running OpenMed on Phala Actually Means
When you deploy OpenMed using Phala’s template, your clinical notes, the NLP pipeline processing them, and your app credentials all run inside a Phala TEE CVM. That means even the infrastructure provider cannot access what’s happening inside. For developers building healthcare tools or institutions evaluating AI adoption, this removes one of the biggest blockers, which is proving that sensitive patient data never left a protected environment. You don’t have to take anyone’s word for it. The architecture makes it verifiable.

Why This Makes Phala Worth Paying Attention To
What makes Phala stand out is that they keep closing the gap between confidential computing as a concept and confidential computing as something you can actually ship. A ready to deploy OpenMed template is a practical example of that. Builders don’t need to figure out the security architecture from scratch. They pick the template, deploy it, and get a working confidential environment for healthcare AI out of the box.

You can deploy at https://cloud.phala.com/templates/openmed, review the template code on Phala’s GitHub at https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/openmed, and find the upstream OpenMed project at https://github.com/maziyarpanahi/openmed

Why Svelte and Phala Cloud Work Well Together if you deploy it on Phala Cloud

Soulman — Sun, 21 Jun 2026 12:44:34 +0000

Note: This article is Adapted from the official Phala announcement.

Svelte has become a go-to choice for developers who want to build fast, reactive frontends without the weight of a large framework. It compiles your UI down to small, efficient code that runs directly in the browser, which means your app loads quickly and feels responsive. For a lot of projects, that’s exactly what you need on the frontend side. But most real applications don’t stop at the UI. At some point your app needs to run server side logic, call external APIs, or handle user data, and that’s where things get more complicated.

Where Phala Cloud Fits Into the Picture
When you deploy your Svelte app on Phala Cloud, the server side parts of your application run inside a Trusted Execution Environment backed compute instance. This means your API credentials, backend logic, and user data are processed in an environment that is isolated and verifiable, not just sitting on a standard server where you’re hoping nothing goes wrong. For developers and teams building products that institutions or security focused users need to trust, that distinction matters. You’re not asking anyone to take your word for it. The environment itself provides the guarantee.

Getting Started Is Straightforward
Phala Cloud has a ready to use Svelte template that makes it easy to get a project running without starting from scratch. The template code is open and available on GitHub, so you can review exactly how it’s structured before you deploy anything.
If you’re a developer, builder, or team working on an application that needs a clean frontend and secure backend infrastructure, this is a practical starting point worth exploring.

You can deploy directly at https://cloud.phala.com/templates/svelte and find the template code at https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/svelte and the upstream Svelte project at https://github.com/sveltejs/svelte

How Developers and Institutions Can Run AI Models Without Exposing Their Data

Soulman — Sun, 21 Jun 2026 12:38:11 +0000

Note: This article is Adapted from the official Phala and Cluster announcement.

Most people don’t think about what happens to their data the moment it leaves their device and hits an AI model. It travels through servers, APIs, and infrastructure layers, and somewhere along that path, it’s visible. For developers and institutions working with anything sensitive, a privacy policy alone doesn’t fix it.
That’s the gap Cluster and Phala Network are closing together.

What TEE Hardware Actually Does

TEE stands for Trusted Execution Environment. Think of it as a sealed room inside the processor itself. When a model runs inside a TEE, the data is encrypted during processing, not just in transit or at rest. Nobody outside that enclave can see what’s happening inside, not the cloud provider, not Phala, not Cluster.
The models running inside this setup are ones developers already use like DeepSeek, Qwen, GLM, and MiniMax. So there’s no switching costs or rebuilding your stack. You keep your existing workflow, and the hardware handles the privacy layer underneath.

The Attestation Is the Proof

Here’s the part that matters most for anyone serious about verification. Every inference call returns a signed attestation. That’s a cryptographic receipt generated by the hardware itself, confirming that your prompt was processed inside the enclave and never exposed. You’re not taking anyone’s word for it. The hardware signs off on it directly.
For institutions handling financial data, health information, legal documents, or anything else that can’t be exposed, this moves the conversation from policy to proof. If you’re building applications where data handling needs to be demonstrable and not just promised, that’s worth paying close attention to. You can explore the full breakdown through Here: https://x.com/clusterprotocol/status/2066861913267667235