Secret Network to Silicon: Building a True Confidential Computing Stack with Intel TDX on Bare Metal

Most blockchains expose everything by design. Every transaction, every smart contract call, every byte of on-chain state is visible to anyone who runs a node. For public verification, that’s a feature. For enterprises handling regulated data, processing private AI models, or running financial logic that competitors shouldn’t see, it’s a non-starter.

Secret Network changed the conversation. By running smart contracts inside Trusted Execution Environments (TEEs), Secret Network proved that blockchains can keep data confidential — encrypted inputs, encrypted outputs, encrypted state. The application layer can be private.

But here’s the question that doesn’t get asked often enough: where does that encrypted computation actually run? Who owns the physical hardware? Who controls the hypervisor? Who can inspect the memory bus?

Application-layer privacy is necessary but not sufficient. If the infrastructure beneath it is shared, provider-controlled, and physically accessible to parties outside your trust boundary, the confidentiality model has a gap. Intel Trust Domain Extensions (TDX) — deployed on dedicated bare metal hardware — closes that gap. This article explains the full confidential computing stack: from privacy-preserving smart contracts to hardware-enforced isolation at the silicon level, and why every layer matters.

Key Takeaways

• Secret Network demonstrates production-ready privacy-preserving smart contracts — encrypted inputs, encrypted state, and TEE-based computation that prevents node operators from inspecting data during processing.
• Application-layer encryption alone does not eliminate infrastructure risk. Hypervisor visibility, memory inspection, and multi-tenant attack surfaces remain in shared cloud environments.
• Intel TDX provides VM-level hardware-enforced isolation, encrypting virtual machine memory with CPU-managed keys that even the host OS and hypervisor cannot access.
• A complete confidential computing stack spans five layers: smart contract encryption, VM isolation, hardware TEE, dedicated bare metal, and physical data center controls.
• TDX-enabled bare metal eliminates the trust gap that hyperscaler confidential VMs leave open by removing shared physical infrastructure from the equation entirely.

The Transparency Problem in Web3

Blockchain’s default operating mode is radical transparency. On Ethereum, Solana, and most other public chains, every transaction is broadcast, every smart contract’s state is publicly readable, and every node operator can see every input to every function call. This design serves decentralization and auditability — but it creates a hard wall for enterprise adoption.

Enterprises operating under HIPAA, GDPR, or financial privacy regulations can’t put sensitive data on a system where every participant can read it. AI workloads that process patient records, proprietary models, or financial signals need confidentiality guarantees that go beyond “encrypt it before you send it.” And any organization running competitive business logic — pricing algorithms, trading strategies, supply chain optimizations — needs assurance that the computation itself is private, not just the data at rest.

This is the design tension that privacy-focused blockchains address. Not by rejecting transparency, but by making confidentiality programmable — available where it’s needed, verifiable where it’s required.

Secret Network is the clearest example of that approach in production today.

What Secret Network Gets Right

Secret Network is a Layer 1 blockchain built on the Cosmos SDK that treats privacy as a first-class architectural feature, not a bolt-on.

Encrypted Smart Contracts

Smart contracts on Secret Network — called “Secret Contracts” — encrypt their inputs, outputs, and internal state. On Ethereum, if you call a function on a smart contract, the parameters you pass and the resulting state changes are visible on-chain to everyone. On Secret Network, that data is encrypted. Only the parties authorized by the contract logic can decrypt and read it.

This isn’t just transport encryption. The state stored on-chain is encrypted at rest, and the computation that transforms that state happens inside a protected environment. An observer watching the chain sees that a transaction occurred, but not what it contained or what it changed.

TEE-Based Computation

Secret Network nodes execute Secret Contracts inside TEEs — specifically, Intel Software Guard Extensions (SGX) enclaves. SGX creates a small, hardware-isolated memory region where code and data are protected from the rest of the operating system, other processes, and even the node operator. The node runs the computation, but it cannot inspect the data being processed.

This model enables use cases that transparent blockchains can’t support: confidential voting where tallies are verifiable but individual votes are private, sealed-bid auctions where bids are hidden until the auction closes, private DeFi transactions where trade amounts aren’t front-runnable, and AI inference on encrypted data where model inputs remain confidential.

The Follow-Up Question

Secret Network’s architecture is a genuine technical contribution. But it raises an infrastructure question that the project’s documentation — and most confidential computing content — doesn’t address:

If the smart contract is encrypted and the computation runs inside a TEE, who controls the physical machine that the TEE runs on? Is it a shared cloud VM? Is the hypervisor operated by a third party? Can the infrastructure operator access memory outside the enclave?

The answer matters more than most teams realize.

The Infrastructure Trust Gap

Application-level encryption protects data within the application’s boundary. It does not protect against threats that operate beneath that boundary — at the hypervisor, firmware, or physical hardware layer. In shared cloud environments, these threats are structural, not theoretical.

Hypervisor Visibility

On hyperscaler infrastructure, the cloud provider’s hypervisor manages all guest VMs running on a physical server. That hypervisor has, by design, visibility into guest VM memory. Even when an application inside the VM encrypts its data, the hypervisor layer sits between the application and the hardware. The provider controls the hypervisor code, its update schedule, and its access controls.

For most workloads, this is an acceptable tradeoff. For confidential computing — where the explicit goal is to protect data even from the infrastructure operator — it’s a gap.

Multi-Tenant Attack Surfaces

Shared infrastructure means shared physical resources: CPU caches, memory buses, and I/O controllers are partitioned by software, not by physical separation. Side-channel attacks that exploit shared CPU caches (Spectre, Meltdown, and their variants) have demonstrated that co-tenant data leakage is a real and documented risk. Memory bus snooping and row-hammer attacks add further vectors. These aren’t speculation — they’re published research with working proof-of-concept exploits.

Insider Threat Models

Enterprise security frameworks — SOC 2, ISO 27001, FedRAMP — require organizations to assess insider threats. On shared cloud infrastructure, “insiders” include the cloud provider’s operations team, their automated systems, and any entity with administrative access to the hypervisor layer. On dedicated bare metal, the only insider is your own team.

The transition from application-layer encryption to full-stack confidentiality requires addressing these infrastructure risks directly. Software-only encryption doesn’t do it. Hardware-enforced isolation does.

Intel TDX: Hardware-Enforced Isolation

Intel Trust Domain Extensions (TDX) is a CPU-level security feature that creates hardware-isolated virtual machines called Trust Domains (TDs). TDX addresses the infrastructure trust gap by moving the isolation boundary from software into silicon.

How Trust Domains Work

A Trust Domain is a virtual machine whose memory is encrypted by the CPU itself, using keys that are generated and managed entirely within the processor hardware. The host OS and hypervisor can still manage the VM’s lifecycle — starting, stopping, scheduling, and allocating resources — but they cannot read the VM’s memory contents. The isolation is enforced by the CPU’s memory encryption engine, not by software policy.

This is a fundamental architectural shift. In a traditional VM, the hypervisor is part of the trusted computing base — it has full access to guest memory. With TDX, the hypervisor is explicitly removed from the trusted computing base. It manages resources but cannot inspect data.

Remote Attestation

TDX supports cryptographic remote attestation through Intel’s Trust Authority service. A third party — a customer, an auditor, or an automated verification system — can request proof that a Trust Domain is running specific code on genuine Intel TDX hardware, with a specific security configuration. The attestation report is signed by keys rooted in the CPU hardware, making it verifiable without trusting the infrastructure operator.

For blockchain infrastructure, this is directly relevant: a validator node running inside a TDX Trust Domain can prove to the network that it’s executing the expected software in a hardware-isolated environment. For AI workloads, a model-serving endpoint can attest that patient data or proprietary model weights are processed inside a protected domain.

TDX vs. SGX: VM-Level vs. Enclave-Level

Secret Network’s existing TEE model uses Intel SGX, which protects individual application enclaves — small, isolated memory regions within a single process. SGX is well-suited for protecting specific functions or data structures, but it requires applications to be written (or re-written) to fit within the enclave model. Enclave memory is limited, and cross-enclave communication adds complexity.

TDX operates at a different level: it protects entire virtual machines. A blockchain node, an AI inference service, or a database server runs as a normal VM — no application rewriting required — and TDX encrypts the entire VM’s memory space. For workloads that run as complete operating system environments (which describes most production blockchain nodes and AI serving pipelines), TDX provides broader isolation with less application-level friction.

SGX and TDX are complementary, not competing. A deployment could run Secret Network nodes inside SGX enclaves for application-layer privacy and host those nodes on TDX-isolated VMs for infrastructure-layer isolation. The two technologies address different layers of the same stack.

The Five-Layer Confidential Computing Stack

True confidential computing is not a single technology. It’s an architectural property that emerges from multiple layers working together. If any single layer is compromised, the confidentiality guarantee weakens. Defense-in-depth means each layer provides independent protection.

Most confidential computing deployments address Layer 1 and assume the rest. Hyperscaler confidential VMs address Layers 1–3 but leave Layers 4 and 5 in the provider’s control — the physical hardware is shared, and the data center is operated by the hyperscaler. A team that deploys TDX-enabled VMs on AWS or Azure still trusts Amazon or Microsoft with the physical server, the firmware update process, and the data center access policy.

Deploying on dedicated bare metal with TDX support is the only model that puts Layers 1 through 5 under the customer’s control.

OpenMetal TDX-Enabled Bare Metal: Where the Stack Meets Silicon

Building the full confidential computing stack requires infrastructure that supports TDX at the hardware level, runs on dedicated (not shared) physical servers, and gives the customer full control over the hypervisor, networking, and storage layers. OpenMetal’s TDX-enabled Bare Metal Servers are designed for exactly this model. 

XXL v4: High-Memory Confidential Compute

The XXL v4’s 2TB of RAM makes it a strong fit for workloads that maintain large in-memory state inside TDX Trust Domains — confidential blockchain validator clusters that keep chain state resident, multi-tenant confidential services where each tenant runs in its own TD, and AI inference workloads with large model weights that need to stay in encrypted memory.

XL v5: Latest-Generation Confidential Compute

The XL v5 brings Granite Rapids architecture with 33% faster memory bandwidth (DDR5-6400 vs. DDR5-5600) and Intel’s full suite of integrated accelerators. Intel AMX provides hardware-accelerated matrix operations for AI inference, while QAT offloads cryptographic operations — directly relevant to both blockchain transaction processing and TDX attestation workflows. For teams building private AI inference clusters, regulated SaaS platforms, or confidential Web3 infrastructure on current-generation silicon, the XL v5 is the natural starting point.

Both configurations share the properties that make bare metal the right choice for confidential computing: the customer controls the physical server and the hypervisor running on it, networking and storage are dedicated (not shared with other tenants), pricing is fixed and predictable rather than per-hour or per-VM, and the entire deployment runs on open-source infrastructure with no proprietary lock-in.

Where This Stack Applies

The combination of application-layer privacy and infrastructure-layer hardware isolation isn’t a solution looking for a problem. It maps directly to workloads where data confidentiality is a hard requirement — not a preference.

Regulated DeFi. Decentralized finance platforms handling KYC data, transaction amounts, and counterparty information need privacy at the smart contract layer and isolation at the infrastructure layer to satisfy financial regulators. Encrypted transaction logic on Secret Network paired with TDX-isolated validator nodes on dedicated hardware provides both.

Confidential governance. On-chain governance systems for DAOs, corporate voting, and sealed-bid procurement need verifiable outcomes without exposing individual votes or bid amounts. Hardware-enforced isolation ensures that no infrastructure operator can inspect ballot data during tallying.

Healthcare AI inference. Processing patient data through AI models requires HIPAA-compliant infrastructure where data is encrypted during computation (not just at rest and in transit). TDX-protected inference pipelines on dedicated servers meet that requirement without forcing data into a hyperscaler’s shared environment.

Financial data processing. Settlement, clearing, and risk computation involving counterparty data can run inside confidential smart contracts for logic privacy and on TDX-isolated bare metal for infrastructure isolation — satisfying both operational requirements and regulatory audit expectations.

AI model IP protection. Organizations serving proprietary AI models — trained on private data, representing significant R&D investment — need assurance that model weights can’t be extracted from memory by a co-tenant or infrastructure operator. TDX memory encryption on dedicated hardware prevents both attack vectors.

Privacy-first data marketplaces. Data exchange platforms where buyers can query datasets without seeing raw records need encrypted computation at the application layer and physical isolation at the infrastructure layer to guarantee that no party — including the marketplace operator — can access the underlying data.

The Confidential Computing Horizon

The next generation of infrastructure will not be defined by elasticity alone. It will be defined by verifiable isolation — the ability to prove, cryptographically, that a workload is running in a protected environment on trusted hardware, without depending on the infrastructure operator’s good faith.

Web3 and AI are converging around this requirement from different directions. Blockchain teams need private computation for enterprise-grade use cases. AI teams need confidential inference for regulated and IP-sensitive workloads. Both need hardware-enforced isolation that extends beyond the application boundary.

Secret Network proves the model at the smart contract layer. Intel TDX proves it at the hardware isolation layer. Dedicated bare metal proves it at the physical layer. The complete stack — application privacy, VM isolation, hardware TEE, dedicated infrastructure, physical security — is how confidential computing moves from a feature checkbox to an architectural reality.

For teams building confidential blockchain nodes, private AI inference pipelines, or regulated data processing environments, the question is no longer whether you need hardware-enforced isolation — it’s whether your infrastructure provides it.

OpenMetal’s TDX-enabled Bare Metal Servers deliver that foundation: dedicated hardware, full-stack isolation, and fixed-cost pricing — without surrendering control to a hyperscaler. Talk to an infrastructure engineer about building your confidential computing stack on dedicated hardware.

Contact Us

Frequently Asked Questions

What is Secret Network?

Secret Network is a privacy-first Layer 1 blockchain built on the Cosmos SDK. It uses Trusted Execution Environments (TEEs) to run “Secret Contracts” — smart contracts that encrypt their inputs, outputs, and on-chain state. Unlike transparent blockchains where all data is publicly visible, Secret Network allows developers to build applications where sensitive data remains confidential during computation.

What is Intel TDX?

Intel Trust Domain Extensions (TDX) is a hardware security feature available on recent Intel Xeon processors. TDX creates hardware-isolated virtual machines called Trust Domains (TDs) with CPU-encrypted memory that the host OS and hypervisor cannot read. This removes the hypervisor from the trusted computing base and enables confidential computing at the VM level.

How does Intel TDX differ from Intel SGX?

Intel SGX protects small application enclaves — isolated memory regions within a single process. Intel TDX protects entire virtual machines, encrypting the full VM memory space with hardware-managed keys. For workloads that run as complete OS environments (blockchain nodes, AI inference services, databases), TDX provides broader isolation with less application-level modification. The two technologies are complementary and can be used together at different layers of the same deployment.

Why do confidential workloads need bare metal instead of cloud confidential VMs?

Hyperscaler confidential VMs (Azure, GCP) provide TDX or AMD SEV-SNP isolation at the VM level, but the underlying physical server is still shared with other tenants and operated by the cloud provider. The provider controls the firmware, the physical access, and the data center security. Dedicated bare metal puts the customer in control of the physical hardware, eliminating co-tenant risk and removing the hyperscaler from the trust boundary.

Which OpenMetal servers support Intel TDX?

OpenMetal’s XXL v4 (64 cores, 2TB DDR5-5600, 38.4TB NVMe) and XL v5 (64 cores, 1TB DDR5-6400, 25.6TB NVMe, Granite Rapids architecture) are some of the enterprise Bare Metal Dedicated Servers that support Intel TDX and SGX for confidential computing workloads. The XXL v4 is suited for high-memory confidential workloads; the XL v5 adds latest-generation processors with built-in AI accelerators (AMX, AVX-512) and faster memory bandwidth.