Confidential compute · API v1

Trustless compute
you can actually verify.

Deploy a container with an H200 GPU straight from your browser. Pay per second in ETH or USDC, with no account and no KYC. Then check the cryptographic attestation yourself before you send a single byte of data.

H200 · confidential (TDX + NVIDIA CC) per-tenant process isolation VRAM zeroed on rotation CORS-friendly
enclave · tdx + nvidia-cc sealed
measurement (rtmr3) 0x0000…0000
The model

Don't trust the operator. Measure it.

NAN runs your workload inside a hardware-isolated, attested enclave, so the operator can't read your memory, your keys, or your traffic, and you don't have to take our word for it. Every claim on this page is something you can check on-chain or in a signed attestation. We're equally explicit about the part that isn't hardware-enforced: how tenants are kept apart from each other on a shared GPU. See exactly how isolation works ↓

verifiable

Trustless

Each enclave produces an Intel TDX quote and an NVIDIA GPU attestation report. Verify them client-side against published measurements, then connect.

no accounts

Crypto-native

Funds live in an on-chain escrow you control. Top up with ETH or USDC, meter by the second, withdraw the remainder whenever you want.

cors

Browser-native

The whole API is CORS-enabled. Spin up a server, stream logs, and pull attestation from front-end JavaScript. No backend required.

h200

Real GPUs

Full H200s in NVIDIA confidential-computing mode. The whole GPU is one attested trust domain (CC disables MIG, so there's no hardware sub-slicing). You buy a VRAM slice and a compute share; tenants share the card by time, isolated from each other at the process level. How that's enforced →

Lifecycle

Five calls, start to finish.

The path from an empty wallet to a verified GPU endpoint. Click a step to see exactly what crosses the wire.

Root of trust

What "trustless" actually means here.

"Trustless" isn't a slogan. It's a chain of measurements that ends in your browser. Walk each link to see what gets verified and why the operator can't fake it.

GET /v1/deployments/{id}/attestation
attestation.json
How isolation is achieved

Two boundaries. One is hardware. One is not. We tell you which.

Most "confidential GPU" pitches blur these together. NAN keeps them separate because they're enforced by different things and carry different guarantees. Here is precisely what protects you, and from whom.

hardware · attested

You vs. the operator

Your enclave runs in a CPU TEE (Intel TDX) with the H200 in NVIDIA confidential-computing mode. The CPU↔GPU link is encrypted and the GPU is walled off from the host. NAN, the operator, cannot read your VRAM, RAM, keys, or traffic. This is enforced by hardware and proven by an attestation you verify in your browser before sending data. This is the strong guarantee, and it's the one you can check cryptographically.

software · process-level

You vs. other tenants

CC seals the whole GPU as a single trust domain and disables MIG, so there's no hardware partition between tenants on one card. We isolate tenants the way an OS isolates processes: each tenant runs in its own dedicated worker process, never sharing one with another tenant. That boundary, not a hardware slice, is what keeps tenants apart, and we don't pretend otherwise.

What the process boundary actually buys you, with each point measured on our own hardware:

  • No cross-tenant reads. Separate processes get separate GPU address spaces. A kernel in one tenant's process that tries to read another tenant's memory faults. The address simply isn't mapped. (Verified: the cross-process read attempt raised an illegal-access fault.)
  • Blast radius of one. A tenant whose kernel crashes or runs illegal memory access takes down only their own worker. A co-tenant running on the same GPU kept executing without a single error, and the GPU stayed healthy. (Verified under a live fault.)
  • Memory wiped on rotation. When a worker exits (normally, on idle, or by crashing), the driver zeroes its VRAM before those pages are handed to anyone else. We confirmed a fresh allocation came back fully zeroed even after a tenant wrote ~117 GB and was killed without cleaning up. A tenant rotation is a process exit, so the scrub is structural, not best-effort.
  • Fair share, not free-for-all. Each worker is capped to its purchased compute share so one tenant can't starve the GPU, and a watchdog kills any worker that exceeds its slice or hangs.

What we do not claim

Inter-tenant isolation is enforced by the operating system and the NVIDIA GPU driver, the one component every tenant's workload passes through. So tenants are isolated from each other at the process level, modulo the integrity of that shared driver, not by per-tenant hardware partitioning (which this GPU generation does not offer with confidential computing on). If your threat model requires hardware-enforced isolation from other tenants specifically, run a dedicated full-GPU deployment instead of a shared one. Isolation from us, the operator, is hardware-enforced and attested either way.

Pricing

Metered per second. Paid on-chain.

Pick a single share of the H200, from 1% to 100% of the card. That share gives you a matching slice of VRAM, compute, CPU, and host RAM at once (25% of the card is ~35 GB of VRAM, a quarter of its throughput, ~4 vCPU and ~16 GB RAM), so nothing can be stranded by another tenant. It is a software cap, not a hardware MIG partition (CC disables MIG). Billed per second at your share of the full-GPU rate. Escrow drains while a deployment runs and stops the instant it does. Rates in USDC; pay the equivalent in ETH at settlement.

ExampleShareVRAM + computePer hourPer second
Slice10%~14 GB · 10%$0.60$0.0001667
Quarter25%~35 GB · 25%$1.50$0.0004167
Half50%~70 GB · 50%$3.00$0.0008333
Full GPU100%141 GB · 100%$6.00$0.0016667

These are example points on a continuous scale, not a fixed menu. The share is a software cap dialed in whole-percent steps (1% to 100% of the card, where each percent is ≈1.4 GB of VRAM and ≈1.3 SMs of compute together). One dial means VRAM, compute, CPU and host RAM are always allocated in the same proportion, so a tenant can't grab one resource and strand another. A Full GPU deployment (100%) is the option to choose when you want no co-tenants on the card at all. It's the only configuration where isolation from other tenants is also hardware-enforced, not just process-level. Tenants on a shared card are isolated from each other at the process level (how →) and always isolated from the operator by confidential computing.