---
title: "What TEE Docker is, and what the TEE does"
description: "A wallet API whose signing runs inside a trusted execution environment — what that protects, how it differs from Docker containers, and the model behind the endpoints."
---

> Documentation Index
> Fetch the complete documentation index at: https://tee.hypetrade.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# What TEE Docker is, and what the TEE does

TEE Docker gives an application one consistent HTTP API for managed wallet
workspaces: accounts, wallets, addresses, signing, transactions, and optional
encrypted key export. You do not need to understand wallet storage internals to
use it.

The service runs at `https://tee-api.hypetrade.xyz`, and every route is prefixed
with `/v1`.

## What the name means

**TEE** stands for **trusted execution environment** — a region of a machine
where code runs with its memory encrypted and sealed off from everything
outside it, including the operating system, the hypervisor, and whoever
administers the host.

That is the property this service is built around. A wallet API holds private
keys in memory whenever it signs, which normally means every party with
administrative reach over the machine is implicitly trusted with those keys:
the cloud provider, the ops team, anyone who can attach a debugger or read a
memory dump. A trusted execution environment removes that implicit trust. Keys
are unsealed, used, and re-sealed inside a boundary the host cannot see into.

> **Status**
>
> The architecture described here is what the service is designed around. The
> hardware platform is not yet selected, so this page does not yet publish the
> attestation procedure — the mechanism by which you verify, rather than take on
> faith, which code is running inside the enclave. That section lands with the
> deployment. Until then, treat this as the design, not as a deployed guarantee.

## It is not Docker

The name collides with a container platform, and the two solve different
problems. Worth being explicit, because the distinction *is* the product:

| | Docker container | Trusted execution environment |
|---|---|---|
| Isolates you from | Other workloads on the host | **The host itself** |
| Memory readable by root? | Yes | No — encrypted in hardware |
| Protects against | Noisy neighbours, dependency drift | A compromised or hostile operator |
| Answers | "Does it run the same everywhere?" | "Who could extract this key?" |

A container is a packaging and isolation boundary that the host administers and
can therefore inspect. An enclave is a confidentiality boundary that the host
runs but cannot read. If you are choosing where to put signing keys, that
difference is the whole decision — and it is why "run the wallet in a
container" and "run the wallet in a TEE" are not variants of the same idea.

TEE Docker uses containers too, for ordinary deployment reasons. They are not
what the name refers to.

## What the boundary does and does not cover

Being precise about scope, since a security claim is only as useful as its
edges:

**Inside.** Key material at rest and in use — mnemonics, private keys, the
signing operation itself, and the workspace encryption that keeps accounts
locked until a token opens them.

**Outside.** Everything a network observer sees. Transaction contents go to an
RPC endpoint in the clear, because that is what broadcasting a transaction
means. Addresses, amounts and destinations are public by the time they reach a
chain. An enclave protects the key, not the transaction's privacy.

**Also outside.** Your credentials, once they leave your side. Tenant API keys
and workspace passwords are yours to protect — see
[Safe usage](/safe-usage/). A boundary that keeps an operator from reading a
key cannot help if a token leaks from your own infrastructure.

## The model in one screen

Five nouns carry the whole API. Learn these and the endpoint list mostly
explains itself.

| Term | What it is |
|---|---|
| **Tenant** | A team or application with its own API credentials and usage limits. |
| **Workspace** | A password-protected collection of accounts. Locked at rest. |
| **Workspace token** | A bearer token that holds one workspace open for a limited time. |
| **Account** | A container of wallets, either HD (from a mnemonic) or PK (one imported key). |
| **Wallet** | Holds the addresses used for signing and transactions. |

Two credential tiers sit on top of that. Tenant credentials
(`X-Api-Key` + `X-Api-Secret`) administer workspaces and mint tokens. Everything
else — accounts, wallets, signing, transactions — uses a workspace token as
`Authorization: Bearer`.

> **A token is the unlock**
>
> There is no separate "unlock" call for a workspace. Minting a token opens the
> workspace, and the token's lifetime *is* the unlock session. Revoking the token
> locks the workspace again.

## Where to go next

- **Get started** — Credentials to a first signature in about five minutes.
[Start here](/get-started/)
- **Concepts** — Workspaces, tokens, accounts, scopes, and how RPC is resolved.
[Read the concepts](/concepts/)
- **Guides** — Task-shaped walkthroughs for the common integration paths.
[Browse guides](/guides/)
- **API reference** — Every endpoint, with request and response shapes.
[Open the reference](/api/)

## What this service does not do

Being explicit about the edges saves integration time:

- **No transaction lifecycle tracking or webhooks.** Submission returns as soon
  as the network accepts the transaction; poll
  [transaction status](/api/transactions/) if you need more.
- **No RPC service.** You bring your own endpoints — see
  [Networks and RPC](/concepts/networks-and-rpc/).
- **No nonce allocator.** The service does not exclusively own your addresses,
  so it lets the RPC assign nonces rather than pretending to manage them.
- **No balance lookup in this release.** The route exists and returns a stable
  `501` — see [Addresses](/api/addresses/).
- **No self-service tenant registration.** Tenants are provisioned by an operator.

Source: https://tee.hypetrade.xyz/overview/index.mdx
