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.
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. 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.
Where to go next
Get started
Credentials to a first signature in about five minutes. Start here
Concepts
Workspaces, tokens, accounts, scopes, and how RPC is resolved. Read the concepts
Guides
Task-shaped walkthroughs for the common integration paths. Browse guides
API reference
Every endpoint, with request and response shapes. Open the reference
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 if you need more.
- No RPC service. You bring your own endpoints — see 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. - No self-service tenant registration. Tenants are provisioned by an operator.