DEV Community: Soulman

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

GLM-5.2 Is Now Live on Phala: What Builders Need to Know

Soulman — Sun, 21 Jun 2026 12:33:20 +0000

Note: This article is adapted from the official Phala blog post. Original article published June 16, 2026 at https://phala.com/posts/glm-5-2-open-source-sota-confidential-ai-phala

Phala Network just became a launch partner for GLM-5.2, the latest open-source model from Z.ai. If you build agents, run long-context workflows, or work with sensitive data in production, this one is worth a closer look. The partnership brings together a model that sits at the top of open-source coding benchmarks with infrastructure built specifically for private, verifiable AI inference.
GLM-5.2 comes with a 1 million token context window and strong performance across long-horizon coding tasks. On FrontierSWE it trails Claude Opus 4.8 by just 1% and edges out GPT-5.5 by the same margin. It also scored first on Design Arena’s code category with 1360 Elo, and shows a sharp improvement over GLM-5.1 on Terminal-Bench 2.1 and SWE-bench Pro. For an open-source model with open weights, those numbers put it in serious company.

Why Running It on Phala Changes the Equation
Model capability gets a lot of attention, but where and how a model runs matters just as much when the workloads are sensitive. Agents handling source code, customer records, legal documents, or internal business logic carry real privacy risk inside every prompt and tool trace. Phala addresses this by running inference inside hardware-isolated environments called TEEs, where execution is protected and the runtime properties can be independently verified. Redpill provides an OpenAI-compatible API layer on top, so developers can route into this stack without changing their existing integrations.

How It Performs in a Real Environment

Phala ran their own benchmark of GLM-5.2-FP8 on an 8xH200 setup using SGLang. At standard context lengths, it holds above 25 tokens per second per user through 64 concurrent users, with aggregate throughput continuing to scale. At longer input shapes it maintains that same threshold through 32 concurrent users before latency pressure increases at higher concurrency. These are practical serving numbers that reflect how the model actually behaves under load, not just isolated lab conditions.

Where to Access It
GLM-5.2 is live on both Phala and Redpill at $1.40 per million input tokens and $4.60 per million output tokens. Most infrastructure conversations treat privacy as something added after deployment. Phala’s approach builds it into the deployment layer from the start, and this launch is a clear signal of where that infrastructure is heading.

GLM-5.2 on Phala: https://phala.com/models/z-ai/glm-5.2 on Redpill: https://redpill.ai/models/z-ai/glm-5.2

Reach out to the Phala team directly at @PhalaNetwork on X or visit https://phala.com/ to explore enterprise access and deployment options.

For individual developers and teams, getting started is straightforward through either platform. For institutions, this is a more significant conversation. If your organization is evaluating AI infrastructure for workloads that involve regulated data, client information, or anything where data exposure is a compliance or legal risk, Phala confidential inference stack is one of the few production ready options that addresses that problem at the infrastructure level rather than asking you to manage it yourself. The combination of open source model strength, verifiable execution, and a familiar API surface makes this a practical starting point, not just a proof of concept.

PaddleOCR on Phala Cloud: Extract Documents Without Exposing What’s Inside

Soulman — Mon, 15 Jun 2026 17:57:20 +0000

Note: This article is Adapted from the official Phala announcement. Original post published on the Phala X handle. Find it here: https://x.com/phalanetwork/status/2065573625588261019

PaddleOCR is one of the more capable open-source OCR engines available, built by PaddlePaddle, and it handles everything from printed text to tables with solid accuracy. Phala Network has added it as a deployable template on Phala Cloud, and the reason that matters is where it runs. When you deploy this template, your OCR workload runs inside a TEE CVM, a hardware-level isolated environment where the document contents, pipeline logic, and extracted results all stay private. That includes from the node operators themselves.

What This Opens Up
The practical value is in documents that have always been awkward to process in the cloud. Financial statements, legal contracts, medical records, internal reports. Content sensitive enough that you don’t want raw data sitting in a general-purpose cloud environment during processing. With this setup, PaddleOCR runs inside the enclave, structured data comes out, and the source material never gets exposed.
For teams building pipelines in regulated industries or handling client data under strict privacy requirements, that changes what’s actually buildable.
The template is live at https://cloud.phala.com/templates/paddleocr and the full code is on GitHub under Phala here: https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/paddleocr. and on Upstream: https://github.com/PaddlePaddle/PaddleOCR

Why This Matters for Phala
Phala keeps shipping deployable templates that let builders plug real tools into a private compute environment without starting from scratch. PaddleOCR is one more example of that pattern, and for developers and institutions taking data privacy in AI pipelines seriously, that’s the kind of progress worth paying attention to.

Flue on Phala Cloud: TypeScript Agents With Privacy Built In

Soulman — Mon, 15 Jun 2026 17:45:57 +0000

Note: This article is Adapted from the official Phala announcement. Original post published on the X handle. Check it here: https://x.com/PhalaNetwork/status/2064931094139638104

If you’re building AI agents in TypeScript, there’s always a setup tax before you write any real logic. Sessions, tool calls, sandboxes, skill routing, Flue handles all of that in one harness so you can focus on what your agent actually does.
The template is live on Phala Cloud at https://cloud.phala.com/templates/flue, with code open on GitHub under the Phala here: https://github.com/Phala-Network/phala-cloud/tree/main/templates/prebuilt/flue. The upstream framework is at withastro/flue.check it here: https://github.com/withastro/flue

What Phala Adds
Deploying on Phala Cloud means your agent runs inside a TEE confidential virtual machine. Your repo context, prompts, and tool calls stay inside a hardware-verified environment that nobody outside it can access, including the infrastructure provider. Most agent frameworks have no real answer for this. You usually end up trusting your cloud provider with everything running inside it. Phala closes that gap without changing how you write your agent.

Why It Matters
Combining TypeScript tooling with hardware level privacy in a one-click template is not something you see often. A lot of projects treat confidential compute as a roadmap item. Phala ships it as something you can deploy today.
For teams running agent logic they can’t afford to expose, that’s a real difference, and it’s why Phala stays worth watching as the agent space grows.