> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcium.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How it works

> Trust split across GPU Confidential Computing and Arcium's MPC network, with the host reduced to transport.

Blackthorn keeps the CPU Trusted Execution Environment out of the trust path entirely and splits trust across two independent roots.

![A prompt sealed with your inner key passes through the Arcium Network's outer SPDM layer and an untrusted relayer host into the GPU's Confidential Computing region, where the model runs; the output returns encrypted the same way.](https://mintcdn.com/arcium/UCGqEQdzsrhUMjrT/images/blackthorn/encrypted-flow.png?fit=max\&auto=format\&n=UCGqEQdzsrhUMjrT\&q=85\&s=2d9d20e3bd82d606a38c25f8b2e85e49)

## The two roots

* **GPU Confidential Computing does the compute.** On a Confidential-Computing GPU, a protected region of GPU memory is walled off from everything outside the GPU package, including the host CPU. Your model runs there in the clear; nothing outside the GPU can read it.
* **Arcium's MPC network holds the keys.** Instead of one machine holding the GPU's session keys, they're split across a set of independent MPC parties. No single party, including the host nor any one node, can reconstruct them.

## The host is only transport

The machine that physically runs the GPU is reduced to a **transport role**. It shuttles ciphertext between your client, the MPC network and the GPU, and it holds no key that can open any of it. Your client seals each prompt on your own device; it is decrypted, run, and re-sealed entirely inside the GPU's protected memory; and your client verifies and decrypts the reply. End to end, the plaintext exists only on your device and inside the GPU.

## A request, step by step

1. **Client seals the prompt.** Your client tokenizes it and encrypts it with AES-256-GCM under a key shared only between your client and the GPU.
2. **Host relays ciphertext.** It forwards the sealed bytes to the GPU. It holds no session key and cannot open them.
3. **GPU runs the model.** Inside the protected region, the engine decrypts the prompt, runs the model, and seals each response chunk back to your client.
4. **Client verifies and reads.** Your client checks and decrypts each chunk as it streams in.

The MPC network establishes and holds the GPU's channel keys so the host never does; it is not in the per-token loop, so it adds no measurable latency to generation.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.