Confidential computing

01 research

The question

A decentralized cloud marketplace inverts the usual trust model: instead of one audited hyperscaler, compute comes from many independent providers with heterogeneous hardware and unknown intentions. The research question is what combination of trusted execution environments, remote attestation, encryption, and protocol-level verification lets a tenant treat that fleet as trustworthy-by-verification rather than trustworthy-by-brand.

02 research

Approach in the protocol

The open VirtEngine repository carries dedicated on-chain modules for this stream: x/enclave (trusted-execution and attestation integration), x/encryption (protocol encryption and key fingerprinting), x/cert (certificates), and x/audit (provider auditing). Device and hardware attestation likewise anchors the VEID identity pipeline — the same verify-the-hardware discipline applied to a different asset.

Around the modules sit operational research questions documented in the repository's HPC and provider-operations guides: how attestation evidence enters provider auditing, how encrypted payloads traverse the deployment pipeline, and how benchmark and fraud modules (x/benchmark, x/fraud) detect providers that misrepresent capacity.

03 research

Shared substrate with DSEMA

DSEMA's containment layer is a consumer of the same research: gVisor-style syscall interception, WASM/WASI capability sandboxes, verified model loading, and sidecar-enforced egress control are confidential-computing techniques applied to autonomous agents instead of tenant workloads. The specification names VirtEngine as the underlying decentralized compute layer a DSEMA collective would autonomously purchase resources from — making attestation the trust bridge between the two programs.