Binance Square
iExec RLC
1.2k Posts

iExec RLC

Square Verified+
Programmable Privacy for Web3.
0 Following
2.8K+ Followers
2.2K+ Liked
Posts
PINNED
·
--
Article
Six Months Building the Missing DeFi LayerAt the start of this year, we made a quiet bet based on intensive market research: That the next phase of onchain finance wouldn't be unlocked by faster chains, bigger throughput, or cheaper gas. That the real blocker keeping institutional capital, regulated funds, and serious financial workflows off public blockchains was something simpler and more structural: confidentiality. Six months later, our research has resulted in shipped products, live infrastructure, real builders, and a category that's becoming impossible to ignore. This is the story of how we got here. February: A Thesis Becomes Public On February 19, we published a manifesto that, at the time, felt obvious to us and slightly contrarian to the rest of the industry. Onchain finance needs confidentiality. Not anonymity. Not opacity. Confidentiality with selective disclosure, the same model traditional finance has always used. Banks don't broadcast your balance to the public. Funds don't publish their investor allocations. OTC desks don't expose counterparty amounts. Yet on public blockchains, all of that is the default. [Our manifesto was simple:](https://www.binance.com/en/square/post/293351333560994?_ul=aHR0cHM6Ly9hcHAuYmluYW5jZS5jb20vdW5pLXFyL2NhcnQvMjkzMzUxMzMzNTYwOTk0P3VzPWNvcHlsaW5rJmw9ZW4mcj1VTFJBMUw0OSZ1Yz13ZWJfc3F1YXJlX3NoYXJlX2xpbmsmdWNvPWVnZ3B1TlQzbEwzYjIyMXRtYnFxSkE&ref=ULRA1L49&utm_campaign=web_square_share_link&utm_content=eggpuNT3lL3b221tmbqqJA&utm_source=copylink) Confidentiality is not secrecy. It is control. The right to choose who sees your data, when they see it, and under what conditions it is disclosed. That is what we believe in, and what we are building toward with Nox: onchain finance where sensitive data stays protected, while regulators, auditors, and approved parties can still access what they need. March: The First Product Ships On March 30, we introduced the Confidential Token at ETHCC, The model is simple. Any existing ERC-20 token can be wrapped into its confidential equivalent. Balances stay encrypted. Transfer amounts stay encrypted. You can use the token across DeFi exactly as before. With selective disclosure, token holders or authorized parties can grant scoped access to regulators, auditors, compliance teams, or other approved third parties when required. Access is not public. It is permissioned. This is the data governance model institutions need on-chain: confidentiality by default, controlled disclosure when oversight or compliance requires it. And the token can be unwrapped back into the public ERC-20 at any time. It's built on the ERC-7984 confidential token standard and runs on Intel TDX, the hardware isolated execution environment that protects data even from the cloud provider running the infrastructure. What it solves is concrete. Tokenized funds couldn't operate onchain at institutional scale because investor allocations were publicly readable. Corporate treasuries couldn't make payments without exposing every amount. RWA issuers couldn't meet compliance mandates because public ledgers don't allow for selective disclosure. With the Confidential Token, all of that becomes possible, without rebuilding a single piece of existing infrastructure. May: The Vault That Doesn't Leak Its Strategy In May, we introduced the Confidential Vault on Arbitrum testnet. The Confidential Token was about confidential assets, the Confidential Vault was about confidential execution. Vaults sit at the center of on chain asset management, they're how managers deploy capital, run strategies, and serve LPs. But public vaults leak more than just positions. They leak the strategy itself: allocation weights, rebalancing triggers, per-vault attribution of every trade. For active strategy managers, that's their alpha published in real time. For institutional LPs, it's a mandate violation before the conversation starts. For RWA issuers, it makes regulated tokenization structurally difficult. The Confidential Vault separates what must stay public from what must stay confidential. Vault structure, fees, and execution attestations remain auditable. Per-LP balances, deposit and redemption amounts, and strategy logic stay encrypted. Auditors and regulators receive scoped access on demand. The market sees nothing it isn't authorized to see. It's built on the asynchronous vault standard (ERC-7540) combined with the confidential token standard (ERC-7984), running inside TEEs. The interface stays compatible with the vault infrastructure already deployed across DeFi. Not one vault. A vault stack. The Confidential Vault isn't a single product. It's a stack, designed to meet different vault protocols where they are. Confidential Vault V1 covers the fundamentals: encrypted LP positions, encrypted balances, and encrypted transaction amounts, with selective disclosure to regulators, auditors, and counterparties. This is the version that shipped on Arbitrum testnet in May, and it's the version most vault protocols can integrate today without rewriting their contracts. Confidential Vault V2 goes further. It encrypts the strategy itself, allocation weights, rebalancing triggers, and per-vault contributions stay encrypted end to end, while NAV, TVL, and APY stay publicly visible for LPs, indexers, and compliance. V2 is designed for active strategy managers whose alpha depends on the strategy staying private, not just the positions. Custom deployments cover everything in between. Some vault protocols need position privacy but public strategy. Some need private strategy but public positions. Some need scoped access flows that don't fit either V1 or V2 out of the box. Because Nox is built as a primitive layer, teams can compose exactly the confidentiality surface their workflow requires. The shared foundation across all three is Nox: encrypted handles, on-chain access control, Intel TDX execution, and cryptographic attestation. What changes is what a specific vault chooses to encrypt. May 19: [Nox Goes Live on Arbitrum](https://app.binance.com/uni-qr/cpos/324837509141554?l=en&r=ULRA1L49&uc=web_square_share_link&uco=eggpuNT3lL3b221tmbqqJA&us=copylink) Two weeks later, Nox, iExec's confidentiality protocol for onchain finance, went live on Arbitrum testnet. This was the moment the individual products became visible as something bigger: a layer. Not a chain. Not a privacy app. Not a single token standard. A protocol that lets DeFi builders plug confidentiality into any workflow using primitives they already understand. Standard Solidity. Encrypted handles. Onchain access control. Cryptographic attestation. The Confidential Token and the Confidential Vault are the first two use cases. But Nox was designed for everything that comes after: confidential lending, confidential payments, confidential settlement, confidential prediction markets, confidential RWA platforms. The point of a protocol layer isn't what it does on day one. It's what builders do with it on day one hundred. June: Nox on Ethereum In June, Nox went live on Ethereum testnet. Ethereum is where serious on chain finance is converging: institutional capital, regulated stablecoins, tokenized funds, RWA experiments from Blackrock, Franklin Templeton, and dozens of others. Bringing Nox to Ethereum meant bringing confidentiality to the chain where the next $100T of capital is most likely to land. This was the moment the multichain story started becoming real. One protocol. Two networks. Same primitives. Same composability. Same on chain access control. More networks to follow. Meeting builders in the tools they already use. Making a protocol multichain isn't only about deploying on more networks. It's about making it effortless for builders to actually work with it. That's why we shipped a native Hardhat plugin alongside the Ethereum testnet launch. For any team already using Hardhat 3 with either Viem or Ethers.js, integrating Nox now takes one package install and a three line config block. The confidential offchain stack spins up automatically via Docker on the first test run. The plugin exposes a clean nox helper that handles encryption, decryption, and handle management. Writing a test against a confidential contract now looks the same as writing a test against any other contract, deploy, read an encrypted handle, ask the Nox stack to decrypt, assert on the cleartext value. No new toolchain. No rewritten workflow. No cryptography expertise required to get started. For the confidentiality layer to become foundational, it has to feel invisible. The Hardhat plugin is one of the first pieces of that invisibility. The Builders Showed Up Somewhere between March and June, something we didn't fully plan for started happening: builders started shipping on Nox. We ran a Vibe Coding Challenge to see what developers would build with confidential primitives. What came back was a glimpse of what confidential DeFi actually looks like in the wild. Three of the standout submissions: Diam | Private OTC. A confidential on-chain OTC desk with encrypted trade amounts, built on Nox with ERC-7984, ChainGPT powered audit and fair price AI. Today, over $30 billion per month flows through OTC desks via Telegram, not because participants want it that way, but because public chains couldn't offer confidentiality at execution. Diam is what happens when they can. ➡️https://www.youtube.com/watch?v=N1QlpmJ916U&feature=youtu.be ➡️https://private-otc.vercel.app/ RWA OS | Confidential asset infrastructure for tokenized finance. A confidential RWA platform handling tenant onboarding, investor mapping, compliance passports, and settlement flows, the operational stack every tokenized fund issuer needs but has to build from scratch today. Deployed on Arbitrum Sepolia, using Nox confidential primitives. ➡️https://rwaos.denkhultech.com/ ➡️ https://dorahacks.io/buidl/43431 DarkOdds | Confidential prediction markets. Public outcomes and odds, but encrypted bet sizes on chain via Nox handles. Winners claim through Intel TDX TEE handlers that compute proportional pari mutuel payouts inside the enclave and re-encrypt the result. This is the first proportional pari mutuel confidential market, solving a problem pure FHE markets couldn't. Selective-disclosure attestations let users prove wins to accountants or seal them forever. ➡️ https://darkodds.site/ None of these teams were large. None had cryptographic specialists. All of them shipped production-grade confidential applications in weeks, using primitives any developer can access through the Nox testnet today. This is what happens when confidentiality becomes a building block instead of a rebuild. The Industry Started Catching Up For most of the past several years, privacy occupied a small corner of crypto, associated with niche tools, controversial mixers, or theoretical research. By mid 2026, that conversation looked different. Ethereum developers proposed new confidential token standards. Starknet shipped STRK20. Arbitrum published a vision for configurable confidentiality in the programmable economy. Chainlink released its Privacy Standard. Regulated entities started asking real questions about how to deploy serious capital onchain without violating mandates. We didn't pivot to meet this moment. We'd been building toward it since 2017. The market is catching up to a direction we never left. Chain of Trust: How Confidential Execution Becomes Verifiable Somewhere between the Confidential Vault launching and going live on Arbitrum, a quieter piece of work was happening in parallel. Not a product. A foundation. For confidential DeFi to work for institutional finance, it isn't enough to make computation private. The market needs a way to prove, cryptographically, that the private computation actually ran the way it was supposed to. That the right code ran on the right hardware, in the right environment, with nothing tampered along the way. [That's what Chain of Trust is](https://app.binance.com/uni-qr/cart/344690501503857?l=en&r=ULRA1L49&uc=web_square_share_link&uco=eggpuNT3lL3b221tmbqqJA&us=copylink). And it's why we've spent the first half of the year building it out. The hardware anchor: Intel TDX. The foundation is Intel Trust Domain Extensions, a capability of recent Intel Xeon processors that lets a virtual machine run as a Trust Domain, isolated from the host operating system, the hypervisor, and even the cloud operator running the machine. The CPU transparently encrypts the memory of each Trust Domain, so neither the host nor a privileged operator can read or modify what's happening inside. Every Nox off-chain component runs inside one of these hardware-isolated environments. TDX also produces a signed measurement of the environment when it boots. That measurement is the starting point for everything else. The orchestration layer: dstack, integrated with Phala Network TDX gives us the hardware guarantee. What we needed on top of it was an orchestration layer that could boot, supervise, and gate Confidential Virtual Machines from a measured, reproducible operating system image, and only release keys and secrets to workloads that could prove they were the ones we expected. That's dstack, the open-source infrastructure developed by Phala Network. Nox integrates dstack to run its confidential workloads inside measured CVMs, using its Key Management Service to gate which workloads are allowed to boot in the first place, and its Gateway to handle TLS termination and encrypted routing between components. The result is that every Nox CVM starts from a verifiable environment, before it is trusted with any sensitive data. Attestations: making the verification concrete. Once a workload is running inside a Trust Domain, it can produce a TDX quote, a cryptographically signed statement of which code is running, on which hardware, in which configuration. Anyone can validate that quote by walking the certificate chain back to Intel's root of trust. This is the mechanism that turns trust us into verify it. A verifier does not have to take our word that a confidential vault position is being processed correctly. They can request a fresh attestation from the running component and check it themselves, against the expected measurements, at any point during the workload's lifetime. Proof of Cloud: the last mile of provenance. Hardware attestation tells you what code is running. It doesn't tell you where the machine physically is. For institutional workloads, that gap matters. A verified TDX chip in an unknown data center is not the same as a verified TDX chip in a known, verified hosting environment. Proof of Cloud closes that gap. It is coordinated by the Proof of Cloud Alliance, a vendor-neutral group iExec is a member of, that maintains a signed registry binding TEE hardware identities to independently verified physical facilities. When a Nox component runs on a Proof of Cloud-sealed node, verifiers can establish not only that the workload ran on genuine confidential hardware, but that this hardware sits in a facility multiple independent parties have vouched for. Why all of this matters. The market has spent years hearing "confidential computing" as a marketing term. What we've been building this year is what makes it a verifiable one. Intel TDX provides the hardware root of trust. dstack, together with Phala Network, provides the measured boot and workload gating. TDX attestations expose the evidence to any verifier who wants to check. Proof of Cloud extends the trust chain into the physical hosting environment. Together, they form the layer that makes confidential DeFi and RWA workflows something institutional counterparties can audit, insure, and integrate into existing compliance frameworks. Not a claim. A chain of verifiable facts. And this is only the foundation. The next parts of Chain of Trust, runtime attestation surfaced through a public portal, source code binding that ties running artifacts back to audited source, and on-chain governance of authorized measurements- are the milestones the second half of the year is being built around. REAL Finance × iExec: Confidentiality Meets RWA Infrastructure In May, we announced a strategic partnership with Real Finance, a purpose-built Layer 1 for institutional real-world asset issuance, distribution, and on-chain financial operations. The premise is straightforward. Institutional RWA adoption needs more than tokenization. It needs infrastructure that supports privacy, compliance, auditability, and settlement at real-world scale. Public ledgers get part of the way there. Confidentiality is what closes the gap. Together, Real Finance and iExec are exploring how Nox can support REAL's Layer 1 across: → Confidential RWA issuance and distribution → Encrypted balances and private investor allocations → Privacy-preserving subscriptions, redemptions, dividends, and financial operations → Selective disclosure for regulators, auditors, and compliance partners → Confidential tokenized funds, private credit, and structured financial products → Future technical integrations, pilot use cases, and ecosystem collaboration Real-world assets are moving on-chain. Now, confidentiality moves with them. July: [Closing One Chapter, Opening the Next](https://app.binance.com/uni-qr/cart/332969397573953?l=en&r=ULRA1L49&uc=web_square_share_link&uco=eggpuNT3lL3b221tmbqqJA&us=copylink) On July 2, the RLC bridge between Ethereum and Bellecour officially shut down. For years, Bellecour was iExec's purpose built sidechain, fast, low cost, and tailored to power decentralized confidential computing. It's where iExec grew up. Millions of tasks were computed there. iApps were deployed. The first decentralized cloud workflows took shape. But the landscape of Web3 evolved. Liquidity, builders, and institutional attention consolidated on a smaller set of EVM networks. Asking projects to come to Bellecour, rather than meeting them where they already operate, became a friction point we couldn't fully overcome. That's what good infrastructure decisions require: acknowledging what is no longer the right path, learning from it, and adapting. The Bellecour sunset is the closing of a chapter. It's also the formal opening of iExec's multichain era. Nox is live on Arbitrum. Nox is live on Ethereum. It will be live on mainnet by the end of year and more chains will follow. The confidentiality layer is moving to where the capital actually is. What the First Six Months Tell Us The thesis we published in February isn't a forecast anymore. It's becoming the consensus. $27 billion in tokenized assets are on chain today against a $100 trillion addressable market. The gap is no longer demand, no longer demand, no longer infrastructure readiness. It's confidentiality, the layer most of the ecosystem has been operating without. We spent six months shipping the products, primitives, and infrastructure that close that gap. Not as a single feature, but as a foundation builders can compose on top of. Encrypted balances. Confidential vaults. Selective disclosure. Auditable execution. Multichain by design. The next six months will be about scale: mainnet, more networks, more builders, more institutional integrations. The destination hasn't changed since February. Confidentiality is not a niche feature. It's foundational infrastructure for the next phase of onchain finance. The first six months proved the thesis. The next six are about scaling it into infrastructure the market can actually build on. Four directions define the rest of the year. Nox mainnet: Nox on Arbitrum and Ethereum testnet was the proof point. Mainnet is where builders ship real products, where institutions deploy real capital, and where the multichain story stops being a promise and becomes a deployment reality. Mainnet lands with a full third party audit of the protocol, because verifiable confidentiality has to start with verifiable code. Institutional partnerships: The conversations we've been having across RWA issuers, tokenized fund managers, and confidential DeFi allocators are moving from exploratory to committed. The next months are about turning those conversations into shipped integrations, live use cases, and the kind of deployments that make on-chain confidentiality no longer a category to explain, but a category to reference. The Nox technical paper: A full public writeup of the Nox architecture, from Chain of Trust through the confidentiality primitives, alongside the RLC business model on mainnet. This is the document institutional teams and technical evaluators have been asking for: how the system works, why the architecture is what it is, and how RLC ties economic activity to the confidential execution layer. More networks, more builders: Multichain by design was always the plan. More EVM networks come online in the second half of the year, and the ecosystem of builders shipping on Nox continues to compound. Every new vault protocol, RWA platform, and confidential DeFi application built on the layer strengthens the case for the next one. The destination hasn't changed since February. What comes next is the scale that turns thesis into infrastructure. Confidential by default. Auditable on demand. We're building it. And we're not alone anymore. Start building today ➡️ https://www.iex.ec/ $RLC

Six Months Building the Missing DeFi Layer

At the start of this year, we made a quiet bet based on intensive market research:
That the next phase of onchain finance wouldn't be unlocked by faster chains, bigger throughput, or cheaper gas. That the real blocker keeping institutional capital, regulated funds, and serious financial workflows off public blockchains was something simpler and more structural: confidentiality.
Six months later, our research has resulted in shipped products, live infrastructure, real builders, and a category that's becoming impossible to ignore.
This is the story of how we got here.
February: A Thesis Becomes Public
On February 19, we published a manifesto that, at the time, felt obvious to us and slightly contrarian to the rest of the industry.
Onchain finance needs confidentiality. Not anonymity. Not opacity. Confidentiality with selective disclosure, the same model traditional finance has always used. Banks don't broadcast your balance to the public. Funds don't publish their investor allocations. OTC desks don't expose counterparty amounts. Yet on public blockchains, all of that is the default.
Our manifesto was simple:
Confidentiality is not secrecy. It is control. The right to choose who sees your data, when they see it, and under what conditions it is disclosed.
That is what we believe in, and what we are building toward with Nox: onchain finance where sensitive data stays protected, while regulators, auditors, and approved parties can still access what they need.
March: The First Product Ships
On March 30, we introduced the Confidential Token at ETHCC,
The model is simple. Any existing ERC-20 token can be wrapped into its confidential equivalent. Balances stay encrypted. Transfer amounts stay encrypted. You can use the token across DeFi exactly as before. With selective disclosure, token holders or authorized parties can grant scoped access to regulators, auditors, compliance teams, or other approved third parties when required. Access is not public. It is permissioned.
This is the data governance model institutions need on-chain: confidentiality by default, controlled disclosure when oversight or compliance requires it.
And the token can be unwrapped back into the public ERC-20 at any time.
It's built on the ERC-7984 confidential token standard and runs on Intel TDX, the hardware isolated execution environment that protects data even from the cloud provider running the infrastructure.
What it solves is concrete. Tokenized funds couldn't operate onchain at institutional scale because investor allocations were publicly readable. Corporate treasuries couldn't make payments without exposing every amount. RWA issuers couldn't meet compliance mandates because public ledgers don't allow for selective disclosure.
With the Confidential Token, all of that becomes possible, without rebuilding a single piece of existing infrastructure.
May: The Vault That Doesn't Leak Its Strategy
In May, we introduced the Confidential Vault on Arbitrum testnet.
The Confidential Token was about confidential assets, the Confidential Vault was about confidential execution. Vaults sit at the center of on chain asset management, they're how managers deploy capital, run strategies, and serve LPs. But public vaults leak more than just positions. They leak the strategy itself: allocation weights, rebalancing triggers, per-vault attribution of every trade.
For active strategy managers, that's their alpha published in real time. For institutional LPs, it's a mandate violation before the conversation starts. For RWA issuers, it makes regulated tokenization structurally difficult.
The Confidential Vault separates what must stay public from what must stay confidential. Vault structure, fees, and execution attestations remain auditable. Per-LP balances, deposit and redemption amounts, and strategy logic stay encrypted. Auditors and regulators receive scoped access on demand. The market sees nothing it isn't authorized to see.
It's built on the asynchronous vault standard (ERC-7540) combined with the confidential token standard (ERC-7984), running inside TEEs. The interface stays compatible with the vault infrastructure already deployed across DeFi.
Not one vault. A vault stack.
The Confidential Vault isn't a single product. It's a stack, designed to meet different vault protocols where they are.
Confidential Vault V1 covers the fundamentals: encrypted LP positions, encrypted balances, and encrypted transaction amounts, with selective disclosure to regulators, auditors, and counterparties. This is the version that shipped on Arbitrum testnet in May, and it's the version most vault protocols can integrate today without rewriting their contracts.
Confidential Vault V2 goes further. It encrypts the strategy itself, allocation weights, rebalancing triggers, and per-vault contributions stay encrypted end to end, while NAV, TVL, and APY stay publicly visible for LPs, indexers, and compliance. V2 is designed for active strategy managers whose alpha depends on the strategy staying private, not just the positions.
Custom deployments cover everything in between. Some vault protocols need position privacy but public strategy. Some need private strategy but public positions. Some need scoped access flows that don't fit either V1 or V2 out of the box. Because Nox is built as a primitive layer, teams can compose exactly the confidentiality surface their workflow requires.
The shared foundation across all three is Nox: encrypted handles, on-chain access control, Intel TDX execution, and cryptographic attestation. What changes is what a specific vault chooses to encrypt.
May 19: Nox Goes Live on Arbitrum
Two weeks later, Nox, iExec's confidentiality protocol for onchain finance, went live on Arbitrum testnet.
This was the moment the individual products became visible as something bigger: a layer. Not a chain. Not a privacy app. Not a single token standard. A protocol that lets DeFi builders plug confidentiality into any workflow using primitives they already understand. Standard Solidity. Encrypted handles. Onchain access control. Cryptographic attestation.
The Confidential Token and the Confidential Vault are the first two use cases. But Nox was designed for everything that comes after: confidential lending, confidential payments, confidential settlement, confidential prediction markets, confidential RWA platforms.
The point of a protocol layer isn't what it does on day one. It's what builders do with it on day one hundred.
June: Nox on Ethereum
In June, Nox went live on Ethereum testnet.
Ethereum is where serious on chain finance is converging: institutional capital, regulated stablecoins, tokenized funds, RWA experiments from Blackrock, Franklin Templeton, and dozens of others. Bringing Nox to Ethereum meant bringing confidentiality to the chain where the next $100T of capital is most likely to land.
This was the moment the multichain story started becoming real. One protocol. Two networks. Same primitives. Same composability. Same on chain access control. More networks to follow.
Meeting builders in the tools they already use.
Making a protocol multichain isn't only about deploying on more networks. It's about making it effortless for builders to actually work with it.
That's why we shipped a native Hardhat plugin alongside the Ethereum testnet launch. For any team already using Hardhat 3 with either Viem or Ethers.js, integrating Nox now takes one package install and a three line config block. The confidential offchain stack spins up automatically via Docker on the first test run. The plugin exposes a clean nox helper that handles encryption, decryption, and handle management.
Writing a test against a confidential contract now looks the same as writing a test against any other contract, deploy, read an encrypted handle, ask the Nox stack to decrypt, assert on the cleartext value. No new toolchain. No rewritten workflow. No cryptography expertise required to get started.
For the confidentiality layer to become foundational, it has to feel invisible. The Hardhat plugin is one of the first pieces of that invisibility.
The Builders Showed Up
Somewhere between March and June, something we didn't fully plan for started happening: builders started shipping on Nox.
We ran a Vibe Coding Challenge to see what developers would build with confidential primitives. What came back was a glimpse of what confidential DeFi actually looks like in the wild. Three of the standout submissions:
Diam | Private OTC. A confidential on-chain OTC desk with encrypted trade amounts, built on Nox with ERC-7984, ChainGPT powered audit and fair price AI. Today, over $30 billion per month flows through OTC desks via Telegram, not because participants want it that way, but because public chains couldn't offer confidentiality at execution. Diam is what happens when they can.
➡️https://www.youtube.com/watch?v=N1QlpmJ916U&feature=youtu.be
➡️https://private-otc.vercel.app/
RWA OS | Confidential asset infrastructure for tokenized finance. A confidential RWA platform handling tenant onboarding, investor mapping, compliance passports, and settlement flows, the operational stack every tokenized fund issuer needs but has to build from scratch today. Deployed on Arbitrum Sepolia, using Nox confidential primitives.
➡️https://rwaos.denkhultech.com/
➡️ https://dorahacks.io/buidl/43431
DarkOdds | Confidential prediction markets. Public outcomes and odds, but encrypted bet sizes on chain via Nox handles. Winners claim through Intel TDX TEE handlers that compute proportional pari mutuel payouts inside the enclave and re-encrypt the result. This is the first proportional pari mutuel confidential market, solving a problem pure FHE markets couldn't. Selective-disclosure attestations let users prove wins to accountants or seal them forever.
➡️ https://darkodds.site/
None of these teams were large. None had cryptographic specialists. All of them shipped production-grade confidential applications in weeks, using primitives any developer can access through the Nox testnet today.
This is what happens when confidentiality becomes a building block instead of a rebuild.
The Industry Started Catching Up
For most of the past several years, privacy occupied a small corner of crypto, associated with niche tools, controversial mixers, or theoretical research. By mid 2026, that conversation looked different.
Ethereum developers proposed new confidential token standards. Starknet shipped STRK20. Arbitrum published a vision for configurable confidentiality in the programmable economy. Chainlink released its Privacy Standard. Regulated entities started asking real questions about how to deploy serious capital onchain without violating mandates.
We didn't pivot to meet this moment. We'd been building toward it since 2017.
The market is catching up to a direction we never left.
Chain of Trust: How Confidential Execution Becomes Verifiable
Somewhere between the Confidential Vault launching and going live on Arbitrum, a quieter piece of work was happening in parallel. Not a product. A foundation.
For confidential DeFi to work for institutional finance, it isn't enough to make computation private. The market needs a way to prove, cryptographically, that the private computation actually ran the way it was supposed to. That the right code ran on the right hardware, in the right environment, with nothing tampered along the way.
That's what Chain of Trust is. And it's why we've spent the first half of the year building it out.
The hardware anchor: Intel TDX.
The foundation is Intel Trust Domain Extensions, a capability of recent Intel Xeon processors that lets a virtual machine run as a Trust Domain, isolated from the host operating system, the hypervisor, and even the cloud operator running the machine. The CPU transparently encrypts the memory of each Trust Domain, so neither the host nor a privileged operator can read or modify what's happening inside. Every Nox off-chain component runs inside one of these hardware-isolated environments.
TDX also produces a signed measurement of the environment when it boots. That measurement is the starting point for everything else.
The orchestration layer: dstack, integrated with Phala Network
TDX gives us the hardware guarantee. What we needed on top of it was an orchestration layer that could boot, supervise, and gate Confidential Virtual Machines from a measured, reproducible operating system image, and only release keys and secrets to workloads that could prove they were the ones we expected.
That's dstack, the open-source infrastructure developed by Phala Network. Nox integrates dstack to run its confidential workloads inside measured CVMs, using its Key Management Service to gate which workloads are allowed to boot in the first place, and its Gateway to handle TLS termination and encrypted routing between components.
The result is that every Nox CVM starts from a verifiable environment, before it is trusted with any sensitive data.
Attestations: making the verification concrete.
Once a workload is running inside a Trust Domain, it can produce a TDX quote, a cryptographically signed statement of which code is running, on which hardware, in which configuration. Anyone can validate that quote by walking the certificate chain back to Intel's root of trust.
This is the mechanism that turns trust us into verify it. A verifier does not have to take our word that a confidential vault position is being processed correctly. They can request a fresh attestation from the running component and check it themselves, against the expected measurements, at any point during the workload's lifetime.
Proof of Cloud: the last mile of provenance.
Hardware attestation tells you what code is running. It doesn't tell you where the machine physically is. For institutional workloads, that gap matters. A verified TDX chip in an unknown data center is not the same as a verified TDX chip in a known, verified hosting environment.
Proof of Cloud closes that gap. It is coordinated by the Proof of Cloud Alliance, a vendor-neutral group iExec is a member of, that maintains a signed registry binding TEE hardware identities to independently verified physical facilities. When a Nox component runs on a Proof of Cloud-sealed node, verifiers can establish not only that the workload ran on genuine confidential hardware, but that this hardware sits in a facility multiple independent parties have vouched for.
Why all of this matters.
The market has spent years hearing "confidential computing" as a marketing term. What we've been building this year is what makes it a verifiable one.
Intel TDX provides the hardware root of trust. dstack, together with Phala Network, provides the measured boot and workload gating. TDX attestations expose the evidence to any verifier who wants to check. Proof of Cloud extends the trust chain into the physical hosting environment. Together, they form the layer that makes confidential DeFi and RWA workflows something institutional counterparties can audit, insure, and integrate into existing compliance frameworks.
Not a claim. A chain of verifiable facts.
And this is only the foundation. The next parts of Chain of Trust, runtime attestation surfaced through a public portal, source code binding that ties running artifacts back to audited source, and on-chain governance of authorized measurements- are the milestones the second half of the year is being built around.
REAL Finance × iExec: Confidentiality Meets RWA Infrastructure
In May, we announced a strategic partnership with Real Finance, a purpose-built Layer 1 for institutional real-world asset issuance, distribution, and on-chain financial operations.
The premise is straightforward. Institutional RWA adoption needs more than tokenization. It needs infrastructure that supports privacy, compliance, auditability, and settlement at real-world scale. Public ledgers get part of the way there. Confidentiality is what closes the gap.
Together, Real Finance and iExec are exploring how Nox can support REAL's Layer 1 across:
→ Confidential RWA issuance and distribution
→ Encrypted balances and private investor allocations
→ Privacy-preserving subscriptions, redemptions, dividends, and financial operations
→ Selective disclosure for regulators, auditors, and compliance partners
→ Confidential tokenized funds, private credit, and structured financial products
→ Future technical integrations, pilot use cases, and ecosystem collaboration
Real-world assets are moving on-chain. Now, confidentiality moves with them.
July: Closing One Chapter, Opening the Next
On July 2, the RLC bridge between Ethereum and Bellecour officially shut down.
For years, Bellecour was iExec's purpose built sidechain, fast, low cost, and tailored to power decentralized confidential computing. It's where iExec grew up. Millions of tasks were computed there. iApps were deployed. The first decentralized cloud workflows took shape.
But the landscape of Web3 evolved. Liquidity, builders, and institutional attention consolidated on a smaller set of EVM networks. Asking projects to come to Bellecour, rather than meeting them where they already operate, became a friction point we couldn't fully overcome.
That's what good infrastructure decisions require: acknowledging what is no longer the right path, learning from it, and adapting.
The Bellecour sunset is the closing of a chapter. It's also the formal opening of iExec's multichain era. Nox is live on Arbitrum. Nox is live on Ethereum. It will be live on mainnet by the end of year and more chains will follow. The confidentiality layer is moving to where the capital actually is.
What the First Six Months Tell Us
The thesis we published in February isn't a forecast anymore. It's becoming the consensus.
$27 billion in tokenized assets are on chain today against a $100 trillion addressable market. The gap is no longer demand, no longer demand, no longer infrastructure readiness. It's confidentiality, the layer most of the ecosystem has been operating without.
We spent six months shipping the products, primitives, and infrastructure that close that gap. Not as a single feature, but as a foundation builders can compose on top of. Encrypted balances. Confidential vaults. Selective disclosure. Auditable execution. Multichain by design.
The next six months will be about scale: mainnet, more networks, more builders, more institutional integrations. The destination hasn't changed since February.
Confidentiality is not a niche feature. It's foundational infrastructure for the next phase of onchain finance.
The first six months proved the thesis. The next six are about scaling it into infrastructure the market can actually build on.
Four directions define the rest of the year.
Nox mainnet: Nox on Arbitrum and Ethereum testnet was the proof point. Mainnet is where builders ship real products, where institutions deploy real capital, and where the multichain story stops being a promise and becomes a deployment reality. Mainnet lands with a full third party audit of the protocol, because verifiable confidentiality has to start with verifiable code.
Institutional partnerships: The conversations we've been having across RWA issuers, tokenized fund managers, and confidential DeFi allocators are moving from exploratory to committed. The next months are about turning those conversations into shipped integrations, live use cases, and the kind of deployments that make on-chain confidentiality no longer a category to explain, but a category to reference.
The Nox technical paper: A full public writeup of the Nox architecture, from Chain of Trust through the confidentiality primitives, alongside the RLC business model on mainnet. This is the document institutional teams and technical evaluators have been asking for: how the system works, why the architecture is what it is, and how RLC ties economic activity to the confidential execution layer.
More networks, more builders: Multichain by design was always the plan. More EVM networks come online in the second half of the year, and the ecosystem of builders shipping on Nox continues to compound. Every new vault protocol, RWA platform, and confidential DeFi application built on the layer strengthens the case for the next one.
The destination hasn't changed since February. What comes next is the scale that turns thesis into infrastructure.
Confidential by default. Auditable on demand.
We're building it. And we're not alone anymore.
Start building today ➡️ https://www.iex.ec/
$RLC
PINNED
Nox is now live on Ethereum testnet. Programmable Privacy coming to the home of EVM. RWA issuers & DeFi builders can now integrate confidentiality at an institutional level. ➡️ Start here: docs.iex.ec $RLC
Nox is now live on Ethereum testnet.

Programmable Privacy coming to the home of EVM.

RWA issuers & DeFi builders can now integrate confidentiality at an institutional level.

➡️ Start here: docs.iex.ec

$RLC
Confidential computing asks three questions: → What code actually processed my data? → Where did it run? → Could the operator have interfered? Encryption answers none of these. Chain of Trust answers all three. Start here:https://trust.noxprotocol.io/ $RLC
Confidential computing asks three questions:

→ What code actually processed my data?
→ Where did it run?
→ Could the operator have interfered?

Encryption answers none of these. Chain of Trust answers all three.

Start here:https://trust.noxprotocol.io/

$RLC
The key rule behind Nox: Secrets aren't handed to workloads. They're unlocked after the workload proves itself. Not handed over. Earned. Start here: https://docs.iex.ec/ $RLC
The key rule behind Nox:

Secrets aren't handed to workloads. They're unlocked after the workload proves itself.

Not handed over. Earned.

Start here: https://docs.iex.ec/

$RLC
For anyone evaluating confidential DeFi infrastructure, the hardware baseline matters. Nox runs only on bare metal servers meeting Intel's TDX enabling requirements. Specific CPU generations. Kernel patches. Quote generation service on the right vsock port. Full spec👇
For anyone evaluating confidential DeFi infrastructure, the hardware baseline matters.

Nox runs only on bare metal servers meeting Intel's TDX enabling requirements. Specific CPU generations. Kernel patches. Quote generation service on the right vsock port.

Full spec👇
iExec RLC
·
--
TEE foundation and boot-time attestation
Author: Aghiles Ait Messaoud, PhD, Research Software Engineer working at iExec.

Introduction

The Nox protocol performs confidential computation over encrypted user data in off-chain services. For such a system to be trustworthy, a user must be convinced of a non-trivial property: that the code processing their data is exactly the code iExec claims to deploy, that it executes on genuine confidential-computing hardware, and that neither the cloud provider nor the protocol operator can observe or tamper with the data while it is being processed. Establishing this property requires a chain of trust, a sequence of cryptographically verifiable links connecting a hardware root of trust to the running workload.
This document is the first part of a series describing that chain of trust. It establishes its foundation: the Trusted Execution Environment (TEE) layer. We describe (i) the hardware substrate, Intel Trust Domain Extensions (TDX), which provides memory-encrypted, hardware-isolated Confidential Virtual Machines (CVMs) together with a signed measurement of their boot state; (ii) dstack, the open-source orchestration layer (developed by Phala Network) that boots, supervises and gates these CVMs; and (iii) how the two are combined to deploy the Nox off-chain components so that every CVM is provably running the expected code before it is granted access to any secret. (iv) We close by discussing Proof-of-Cloud as a complementary seal that binds an attested platform to a known physical hosting environment.
Subsequent parts build on this foundation to cover runtime attestation surfaced to end users, source-code binding, and on-chain governance of the authorized measurements. The present part deliberately limits its scope to the TEE foundation and to boot-time attestation.
The remainder of this document is organised as follows. In Background, we introduce the Nox protocol, define what we mean by a chain of trust, and present the two building blocks of its foundation, Intel TDX and dstack. In Dstack deployment for Nox, we describe how these are instantiated on a TDX host and how the resulting boot-time verification gates every CVM before it receives any secret. In Proof-of-Cloud as a Hardware Provenance Seal, we discuss the complementary seal that ties an attested platform to its physical hosting environment. Finally, the Appendix details the boot sequences of the dstack-KMS, gateway and business CVMs.

Background

In this section, we establish the context and vocabulary used throughout the document. We first introduce the Nox protocol and the components that must be protected, then define the chain of trust, and finally present the two technologies its foundation builds on: Intel TDX at the hardware level and dstack at the orchestration level.

Nox protocol

Nox Protocol ( https://docs.noxprotocol.io/getting-started/welcome ) is iExec's confidential-computation protocol for decentralized finance (DeFi). It acts as a privacy layer that lets smart contracts operate on encrypted data without ever exposing plaintext on-chain, by combining on-chain smart contracts with off-chain Trusted Execution Environments based on Intel TDX. Confidential values are referenced on-chain through opaque handles while the corresponding ciphertext is processed off-chain inside enclaves, so that applications retain full composability with the existing DeFi ecosystem: confidential ERC-7984 tokens remain ERC-20-compatible, contracts are written in standard Solidity, and end users transact from ordinary Ethereum wallets.

The protocol rests on three concepts.
A handle is a 32-byte identifier that acts as a secure pointer to an encrypted value stored off-chain, rather than the ciphertext itself.
An on-chain Access Control List (ACL) governs which addresses may use a handle as a computation input or decrypt its underlying data, enabling selective disclosure to authorized parties such as auditors while privacy is preserved by default.
The computation on confidential data itself takes place inside Intel TDX enclaves, so that even the infrastructure operator cannot read the plaintext during execution.

Operationally, Nox coordinates six components: the on-chain smart contracts (notably the NoxCompute library and the ACL), an event listener (Ingestor), a message queue (NATS), a computation engine (Runner), an encrypted data store (Handle Gateway), and a key-management service (KMS). A confidential operation follows three phases: input, compute and output.
In the input phase, a user encrypts a value through the Handle Gateway (which stores the ciphertext and returns a handle with an EIP-712 proof) and calls a contract using the NoxCompute library, which validates the handles, derives a deterministic result handle and emits an event. In the compute phase, the Ingestor relays the event through NATS to a Runner, which fetches the operands, decrypts them inside the enclave via a decryption-delegation protocol with the KMS, executes the operation, and stores the re-encrypted result. In the output phase, an authorised user retrieves the ciphertext and decrypts it locally. Encryption relies on ECIES over secp256k1 with the KMS public key, and the KMS itself never handles plaintext: it only delegates decryption to the legitimate recipient by encrypting the ECDH shared secret under the requester's ephemeral key.
Several of these off-chain services handle sensitive material in clear within their address space, plaintext operands in the Runner, input plaintext and ciphertext in the Handle Gateway, and the protocol private key in the KMS. Protecting their confidentiality and integrity is the central security concern that the chain of trust addresses, which is why each is deployed as a TDX confidential workload whose boot-time verification is described in this document.

Chain of Trust

We define the chain of trust as the set of mechanisms that establishes a verifiable bridge of confidence between an end user and iExec, a sequence of links, each independently checkable, such that an external party can conclude, end to end, that a given Nox component is genuinely running the expected code on genuine confidential hardware. The foundational link, and the subject of this part, is boot-time verification: the guarantee that a CVM cannot obtain the secrets it needs to operate unless it has booted a known operating-system image and a known application stack on attested TDX hardware. The higher links of the chain, surfacing this evidence to users, binding the running images to public source code, and anchoring the set of authorized measurements on-chain, are treated in later parts.

Intel TDX

Intel Trust Domain Extensions (TDX) is a capability of recent Intel Xeon processors that lets a virtual machine run as a Trust Domain (TD), isolated from the host operating system, the hypervisor and the cloud operator. Two properties make TDX a suitable root of trust for Nox.
First, confidentiality and integrity of runtime state: the CPU transparently encrypts the memory of each TD, so that neither the host nor a privileged operator can read or undetectably modify the guest's memory. Each Nox service therefore runs inside a hardware-isolated CVM whose runtime state is opaque to the hosting provider.

Second, measured boot and remote attestation: as a TD is launched, the BIOS and the TDX module measure its initial state into a set of registers, the static measurement MRTD and the runtime-extendable registers RTMR[0..3], recorded in a signed TD-Report. From this report the platform produces a quote, signed through Intel's Data Center Attestation Primitives (DCAP) and chaining up to the Intel SGX Root CA. A remote verifier validates this quote to obtain a hardware-backed statement of which code the TD runs, and evaluates the platform's Trusted Computing Base (TCB) status against Intel collateral, accepting only an up-to-date TCB.

Running TDX in production imposes a hardware baseline. Nox runs only on bare-metal servers satisfying Intel's TDX enabling guide, summarised below.

Dstack

dstack ( Dstack ) : Open framework for confidential AI) is the open-source orchestration layer, developed by Phala Network, that operates CVMs on top of TDX. It removes the need to manage Trust Domains by hand and provides the gating mechanism on which boot-time verification rests. Its main components are a Virtual Machine Monitor (VMM) and supervisor that boot and supervise CVMs from a measured, reproducible dstack OS image; a KMS CVM that derives application keys inside the enclave and decides which workloads may boot by checking their measurements against a whitelist; and a Gateway CVM that terminates public TLS (with automatic ACME certificates) and reverse-proxies traffic to each registered CVM over an encrypted WireGuard overlay, load-balancing natively between CVMs that share the same application identifier (appId). dstack also offers an optional on-chain authorization contract (DstackKms) able to whitelist OS-image and per-application compose hashes, a capability that Nox has deliberately not yet enabled, the corresponding whitelist being held off-chain at this stage.

Dstack deployment for Nox

This section describes how the foundation above is instantiated for the Nox protocol, and how it yields the boot-time verification guarantee.

General architecture

In this section, we give an overview of how dstack is deployed on a TDX host to run the Nox components, before describing each element in turn. The diagram below shows the overall layout; the tables that follow detail the components running on the host and those composing a single Nox CVM.

dstack architecture for Nox protocol

TDX Host components

Nox CVM component

Proof-of-Cloud as a Hardware Provenance Seal

Measured boot and remote attestation establish what code a CVM runs and that it runs on genuine Intel TDX silicon. They do not, by themselves, establish where that silicon is, the physical and operational provenance of the host. Proof-of-Cloud is the complementary seal that addresses this gap: it binds an attested TDX platform to a known, reputable hosting environment, extending the hardware root of trust with evidence about the provenance of the machine itself.
In the current Nox fleet this property is tracked per node. The testnets fleet runs two TDX nodes, node1, hosted at OVH, and node2, hosted at phoenixNAP, of which node1 carries a Proof-of-Cloud seal and node2 does not. The distinction is meaningful for an external verifier: where present, Proof-of-Cloud raises the cost of a relocation or substitution attack by tying the attested platform to a provider's verified infrastructure, rather than relying on the quote alone to vouch for an otherwise anonymous host.
Concretely, Proof-of-Cloud is coordinated by the Proof of Cloud Alliance (https://proofofcloud.org/), a vendor-neutral group, of which iExec is a member, that maintains a signed, append-only registry binding TEE hardware identities (an Intel DCAP PPID , in case of TDX, extracted from the attestation quote) to independently verified physical facilities. Member organisations cross-verify each location during a dedicated whitelisting ceremony and when pushing a new entry to PPID registry so that a verifier can establish not only that a workload runs on genuine TDX silicon but also that this silicon sits in a facility multiple independent parties have vouched for.
Within the chain of trust, Proof-of-Cloud should be read as a provenance complement to, not a replacement for, TDX attestation: TDX attests the integrity and identity of the execution environment, while Proof-of-Cloud attests the integrity of its hosting context. Together they reinforce the foundational claim on which the remaining links of the chain, runtime attestation, source-code binding and on-chain governance, are built.

Appendixdstack-kms Boot Sequence

The full sequence diagram for dstack-kms boot is available at dstack/docs/kms-boot-sequence.md at master · iExec-Nox/dstack The diagram traces the boot of the dstack-KMS CVM with the local SGX key provider. In summary:
CVM boot and measurement. The VMM starts the KMS CVM under TDX; the CVM boots the dstack OS image and runs dstack-prepare.sh , which measures the application info (the compose_hash, the derived app_id and the instance_id) and emits a runtime event that extends these values into RTMR[3].
Sealing-key request. The script generates an ephemeral keypair and a TDX quote carrying its public key in report_data, then calls the host API over VSOCK, which forwards the request to the SGX key provider (gramine-sealing-key-provider) on localhost:3443.
Mutual attestation and key release. The SGX key provider verifies the KMS TDX quote, derives a sealing key bound to the KMS measurements (MRTD + RTMR[0..3]) and to the hardware, encrypts it under the CVM's public key, and returns it together with its own SGX quote. The CVM verifies that SGX quote, collateral through the PCCS, TCB status, and that report_data commits to the encrypted key, then decrypts the sealing key with its private key.
Key derivation. From the sealing key the CVM derives its application keys (the app_key used to self-sign an RA-TLS certificate, the disk_crypt_key, and a secp256k1 key) and, if a key_provider_id is pinned in app-compose.json, checks that the provider's MR enclave matches the expected value.
Disk mount and container start. The CVM mounts its encrypted disk with the disk_crypt_key, persists the derived app keys, and starts the KMS container through docker-compose.
KMS initialization. If root keys already exist on the encrypted disk they are simply reloaded. On a first boot, one of two paths is taken: Bootstrap (the first KMS): it generates fresh root keys (root CA, secp256k1 root, RPC key and a temporary CA), self-signs its certificates and persists them, no authorization check is performed, since this instance is the origin of the root keys. Onboarding (any subsequent KMS): it obtains a temporary-CA-signed RA-TLS certificate from an existing KMS and requests the root keys over mTLS. The source KMS verifies the requester's TDX attestation and calls the Boot Authorization server (POST /bootAuth/kms), which authorizes only if the TCB is up to date and the OS-image hash, the aggregated measurement and the device id match the kms entry of auth-config.json. On success the root keys are returned and stored; otherwise onboarding aborts and the KMS does not start.
Service ready. The KMS regenerates its certificates from the stored keys (with a fresh TDX attestation) and starts its HTTPS service (container port 8000, exposed as 9201 on the host).
In short, the KMS obtains its sealing key only after proving its measured identity to the SGX key provider, and a non-bootstrap KMS additionally requires Boot Authorization server approval before receiving the protocol root keys.

Business CVM boot Sequence

The full sequence diagram for business CVM (app CVM) boot is available at dstack/docs/app-boot-sequence.md at master · iExec-Nox/dstack The diagram traces the boot of a business (application) CVM, which provisions its keys like the gateway and then additionally joins the WireGuard overlay. In summary:
CVM boot and measurement. The VMM starts the app CVM under TDX; it boots the dstack OS image and runs dstack-prepare.sh, which measures the application info (compose_hash, the derived app_id, instance_id) and extends these values into RTMR[3].
App-key request with mutual attestation. The CVM obtains a temporary CA certificate (and the KMS ca_cert) from the KMS, builds an RA-TLS client certificate embedding its TDX quote, and calls GetAppKey over mTLS. It verifies the KMS server certificate (special_usage == "kms:rpc", emitting mr-kms to RTMR[3]), while the KMS verifies the CVM's attestation from the client certificate.
Authorization. The KMS extracts the boot info and calls the Boot Authorization server (POST /bootAuth/app), which applies the same five checks, tcb_status up to date, and os_image_hash, app_id, compose_hash and device id matching auth-config.json. On refusal the CVM reboots or shuts down.
Key derivation and disk mount. On success the KMS derives the per-app keys from its root keys, disk_crypt_key = HKDF(ca_key, app_id + instance_id + …), env_crypt_key = x25519(HKDF(ca_key, app_id + …)) and k256_key, and returns them with the gateway_app_id. The CVM optionally checks key_provider_id, saves the keys, mounts the encrypted disk with disk_crypt_key, and emits a system-ready event.
Post-mount setup and env decryption. Encrypted environment variables are decrypted with env_crypt_key (x25519 Diffie-Hellman + AES-256-GCM) and written to /dstack/.decrypted_env; the guest agent is configured.
Gateway registration (WireGuard). Unlike the gateway CVM, the app CVM joins the WireGuard overlay through which it is reached: it requests a KMS-signed RA-TLS client certificate (SignCert), connects to the gateway over mTLS (verifying the gateway's app_id matches the gateway_app_id returned by the KMS), and calls RegisterCvm with its WireGuard public key. The gateway verifies the app's identity, allocates a WireGuard IP and returns the peer configuration, after which the CVM brings up its dstack-wg0 interface.
Containers up. docker-compose starts the application container(s); at runtime the app can optionally use the guest agent over /var/run/dstack.sock to derive purpose-specific keys (get_key), obtain a KMS-signed TLS certificate (get_tls_key), or fetch a TDX quote for remote attestation (get_quote). In short, an application CVM follows the same attested, authorized key-provisioning path as the gateway, and then registers with the gateway to enter the encrypted WireGuard network that fronts it.

Environment variables cryptographic state

The full sequence diagram for encrypting and decrypting secret environment variables is available here : Link
Secret environment variables are encrypted by the operator before deployment and decrypted only inside the attested CVM, so that neither the VMM nor the KMS ever sees their plaintext. In summary:
Get the encryption public key. From the compose file the operator computes the app_id and calls the KMS (GetAppEnvEncryptPubKey). The KMS derives a per-app X25519 key pair deterministically, secret = HKDF(ca_key, app_id + "env-encrypt-key"), and returns the public half (env_public_key) together with a k256_root signature over it, which the operator verifies against the whitelisted signer. Encrypt the variables (operator side). The operator serialises the .env file to JSON, generates an ephemeral X25519 key pair, computes a shared secret by Diffie-Hellman with env_public_key, and encrypts the JSON with AES-256-GCM under a random 12-byte IV. The packed blob is eph_public_key (32 B) || IV (12 B) || ciphertext. Deploy. The operator passes the hex-encoded blob to the VMM (CreateVm), which stores it in host-shared/ and never decrypts it. CVM boot. The VMM starts the CVM under TDX; the CVM loads the encrypted blob from host-shared/. Get the decryption key. During key provisioning the CVM calls GetAppKey over the attested mTLS channel; after verifying attestation and authorization, the KMS derives the same key pair and returns the private half as env_crypt_key. Decrypt (CVM side). The CVM splits the blob back into eph_public_key, IV and ciphertext, recomputes the identical shared secret by Diffie-Hellman with env_crypt_key (the X25519 property guarantees both sides agree), decrypts with AES-256-GCM, filters the result against allowed_envs from app-compose.json, and writes it to /dstack/.decrypted_env for the containers.

The construction provides confidentiality (only the attested CVM holding env_crypt_key can decrypt), integrity (AES-GCM detects tampering), forward secrecy (each deployment uses a fresh ephemeral key that is then discarded), and blindness of both the VMM (which only stores the ciphertext) and the KMS (which only serves keys). The env_crypt_key is app-specific, derived from app_id alone, so every instance of the same app shares it, while different apps cannot read one another's variables.

$RLC
The question isn’t, "Can we build this onchain?" anymore. It’s, Can we build it without giving up your privacy $RLC
The question isn’t, "Can we build this onchain?" anymore.

It’s, Can we build it without giving up your privacy

$RLC
The question isn’t, "Can we build this onchain?" anymore. It’s, Can we build it without giving up your privacy
The question isn’t, "Can we build this onchain?" anymore.

It’s, Can we build it without giving up your privacy
Confidentiality onchain isn't a single product. It's a primitive that applies to every workflow where public data creates risk. DeFi, RWAs, payments, custom logic, same underlying tools, different surfaces. Builders decide what stays visible. And what shouldn't be. 👉Get in touch with our team:https://iex.ec/contact?topic=defi-rwa $RLC
Confidentiality onchain isn't a single product. It's a primitive that applies to every workflow where public data creates risk.

DeFi, RWAs, payments, custom logic, same underlying tools, different surfaces.

Builders decide what stays visible. And what shouldn't be.

👉Get in touch with our team:https://iex.ec/contact?topic=defi-rwa

$RLC
Then: Put everything onchain. Now: Put what needs verification onchain, keep what needs confidentiality confidential. $RLC
Then: Put everything onchain.

Now: Put what needs verification onchain, keep what needs confidentiality confidential.

$RLC
"The question isn't whether institutions want to come onchain. It's whether public infrastructure can support the way financial markets actually operate." __ Nathan Chiron, our CRO $RLC
"The question isn't whether institutions want to come onchain. It's whether public infrastructure can support the way financial markets actually operate." __ Nathan Chiron, our CRO

$RLC
Why do we need privacy on chain? Wrong answers only👇
Why do we need privacy on chain?
Wrong answers only👇
The real signal to watch. The iExec Nox ecosystem is growing! Confidentiality becomes useful when builders can actually work with it. $RLC
The real signal to watch.

The iExec Nox ecosystem is growing!

Confidentiality becomes useful when builders can actually work with it.

$RLC
8 words are hiding (privately) in here⬇️ How many can you find ? $RLC
8 words are hiding (privately) in here⬇️

How many can you find ?

$RLC
Confidential on-chain finance, in two concrete examples: 1️⃣ Confidential Token: encrypted balances and amounts, permissioned access preserved. 2️⃣ Confidential Vault: encrypted allocations and strategy, structure and audit trails preserved. ➡️ https://iex.ec/confidential-defi-rwa $RLC
Confidential on-chain finance, in two concrete examples:

1️⃣ Confidential Token: encrypted balances and amounts, permissioned access preserved.

2️⃣ Confidential Vault: encrypted allocations and strategy, structure and audit trails preserved.

➡️ https://iex.ec/confidential-defi-rwa

$RLC
A confidentiality layer for onchain finance has to solve three problems at once: → Encrypted assets → Confidential execution → Controlled disclosure That's the core idea behind Nox. ✅Composability preserved. Data private. Access controlled. Conditions defined by you. https://docs.iex.ec/ $RLC
A confidentiality layer for onchain finance has to solve three problems at once:

→ Encrypted assets
→ Confidential execution
→ Controlled disclosure

That's the core idea behind Nox.

✅Composability preserved. Data private. Access controlled. Conditions defined by you.

https://docs.iex.ec/

$RLC
Privacy is a lifestyle.
Privacy is a lifestyle.
Tokenization was the first step. Bringing assets on chain, technically. The second step is what makes them actually institutional-grade: confidentiality. Private allocations. Encrypted settlement. Auditable execution. All the things transparent by default infrastructure blocks. $RLC
Tokenization was the first step. Bringing assets on chain, technically.

The second step is what makes them actually institutional-grade: confidentiality.

Private allocations. Encrypted settlement. Auditable execution. All the things transparent by default infrastructure blocks.

$RLC
On a scale of 1–10, how important is privacy to you?
On a scale of 1–10, how important is privacy to you?
Boot-time trust starts the chain. Runtime attestation keeps it checkable.
Boot-time trust starts the chain.
Runtime attestation keeps it checkable.
The easiest way to understand Nox: Keep the public parts of DeFi public, and encrypt what the market has no reason to see. Your positions. Your strategy. Where your fund's capital sits. Where it's moving. Try it out➡️https://docs.noxprotocol.io/getting-started/welcome $RLC
The easiest way to understand Nox:

Keep the public parts of DeFi public, and encrypt what the market has no reason to see.

Your positions.
Your strategy.
Where your fund's capital sits.
Where it's moving.

Try it out➡️https://docs.noxprotocol.io/getting-started/welcome

$RLC
Log in to explore more content
Join global crypto users on Binance Square
⚡️ Get latest and useful information about crypto.
💬 Trusted by the world’s largest crypto exchange.
👍 Discover real insights from verified creators.
Email / Phone number
Sitemap
Cookie Preferences
Platform T&Cs