Solutions · Confidential compute
Confidential computing with proof, not promises
Moving sensitive workloads to third-party infrastructure requires examining the trust boundary. VirtEngine supports hardware enclave attestations and payload encryption for compatible workloads; VEID can be an offer-specific counterparty signal, not a guarantee that every lease is identity-verified or safe.
Who this is for: Enterprises with regulated data, proprietary models, or confidentiality obligations.
At a glance
The short version for confidential compute
-
Proof
Attestation as marketplace state
Hardware-signed evidence of the exact measured code running in a TEE, verified through x/enclave — orders can require it as a placement constraint.
-
Secrecy
Secrets sealed to verified targets
Workload secrets stay encrypted until attestation verifies, and client-to-provider links authenticate mutually via chain-anchored TLS certificates.
-
Assurance
Counterparties you can underwrite
Compare provider attributes, audits, benchmarks, and lease-linked reviews; check any disclosed VEID requirement and the applicable dispute process.
The problem
The problem: confidentiality claims you can't verify
Every cloud claims strong isolation; few let you cryptographically verify what actually runs where. For regulated data and proprietary models, an unverifiable claim is a compliance gap — and multi-tenant infrastructure amplifies the exposure.
In one view
Audience-specific visual
Each solution gets its own explanatory figure — not the same template art.
Tenant secret
↓ encrypted
Attested enclave
↓ measurement proof
x/enclave
↓ verified
Workload released The mechanism
How the protocol carries it
How VirtEngine addresses it
Grounded in what the protocol actually does
Attestation as marketplace state
Providers offering confidential compute prove it: enclave attestations — hardware-signed evidence of the exact measured code and configuration running in a TEE — are verified through x/enclave. Orders can require attested enclave execution as a placement constraint, so unverified capacity never matches.
Secrets sealed to verified targets
The encryption module delivers workload secrets encrypted to specific recipients — released only after attestation verifies. Connections between your clients and provider endpoints authenticate mutually via chain-anchored TLS certificates (x/cert).
Counterparties you can underwrite
Provider records can expose attributes, audits (x/audit), benchmarks, and lease-linked reviews. Buyers should check evidence and terms; fraud reporting and dispute processes do not guarantee a particular outcome.
How it works
The path through the protocol, step by step
Select each step — the panel walks the sequence in order, from first action to settled outcome.
Step 1 · Define
Define the trust requirements
Decide which workloads need attested enclaves and which measurements you will accept — the policy your placement constraints will encode.
Step 2 · Constrain
Constrain orders to attested capacity
Require enclave attributes and auditor-signed claims in placement constraints so unverified capacity can never match your orders.
Step 3 · Verify
Verify the attestation flow
Confirm measurement verification and encrypted secret delivery end to end before production data moves.
Step 4 · Contain
Start with a contained workload
Prove the model on a bounded dataset, then scale scope. Escrow-backed leases and hourly settlement give finance a clean, auditable cost trail throughout.
Step 5 · Scale
Scale under the same guarantees
Workloads can use attested execution, sealed secrets, and disputable usage; each offer states its own counterparty requirements.
Economics
Economics
Confidential capacity is priced like everything else — at the offering's listed price for direct orders, or by open bidding where you opt into price discovery. Attested enclave capability is a provider attribute, so its premium reflects supply and demand, not a vendor's enterprise price list. Escrow-backed leases and hourly settlement give finance teams a clean, auditable cost trail.
Getting started
The path in
-
Define the trust requirements
Which workloads need attested enclaves, and what measurements you will accept.
-
Constrain orders to attested capacity
Require enclave attributes and auditor-signed claims in placement constraints.
-
Verify attestation flow
Confirm measurement verification and encrypted secret delivery end to end.
-
Start with a contained workload
Prove the model on a bounded dataset before scaling scope.
Questions
Asked about confidential compute
What actually proves the enclave is genuine?
Hardware-signed attestation evidence — measurements of the exact code and configuration running inside the TEE — verified through x/enclave. Because attestation is marketplace state, orders can demand it as a placement constraint rather than taking a vendor's word.
Who can read our workload secrets?
Only verified targets. The encryption module releases workload secrets encrypted to specific recipients after attestation verifies, and mTLS between your clients and provider endpoints uses chain-anchored certificates from x/cert.
What does the compliance trail look like?
On-chain attestations, auditor-signed provider attributes, published benchmarks, lease-bound reviews, and signed hourly usage records — every claim your auditors need is protocol state, queryable and timestamped.
Related
Continue from here
More solutions