TEE Docker gives an application one consistent HTTP API for managed wallet workspaces: accounts, wallets, addresses, signing, and optional encrypted key export. It custodies keys and signs; you broadcast the signed payload yourself. You do not need to understand wallet storage internals to use it.
The service runs at https://<your-api-host>, and every route is prefixed
with /v1.
What you can do with it
A quick sense of the surface, before the model that ties it together:
- Hold wallets without holding keys. Create password-locked workspaces, generate HD accounts or import private keys, derive wallets, and read addresses across EVM and Solana chains.
- Sign. Sign messages, EIP-712 typed data, a raw 32-byte digest (EVM), or raw bytes (Solana) by address. The service returns the signature; you broadcast the signed payload yourself.
- Hand an end user their own durable key. Mint a single-string, account-scoped API key a browser can hold — it reads its bound account and, at the Unlimited tier, exports; signing stays with your workspace token. No workspace password ever leaves your server.
- Let a user recover their key, sealed. Export a mnemonic or private key as a blob encrypted to the end user’s own key, which the server never holds.
- Run it yourself. Self-host the whole thing in a trusted execution environment — see Deploy.
New here? Get started walks the common cases end to end.
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. The signed payload, once it leaves the enclave. You broadcast it yourself, so its contents — addresses, amounts, destinations — are public by the time they reach a chain. An enclave protects the key, not the payload’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. |
| Account | A container of wallets, either HD (from a mnemonic) or PK (one imported key). Creating one already gives you a first wallet. |
| Wallet | Holds the addresses used for signing — one address per VM. |
| Address | A public key on one chain. Sign against it directly. |
Two kinds of credential sit on top of that, plus one more for operators. Tenant
credentials (X-Api-Key + X-Api-Secret) administer workspaces, read quota,
and mint tokens. Everything else — accounts, wallets, signing — uses a bearer
token: either a workspace token or a durable
scoped API key a tenant mints for an end user. A separate
super-admin X-Admin-Key tier raises a tenant’s limits and exposes read-only
operational diagnostics.
Where to go next
Get started
The common cases, credentials to a first signature, in about five minutes. Start here
Concepts
Workspaces, tokens, accounts, scopes and tiers, and the network registry. 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 broadcasting. The service signs; you submit the signed payload to a chain yourself.
- No chain RPC. It never contacts a node — no sending, no simulating, no balance reads. The network registry only fixes which chain and signing scheme an address uses.
- No balance or transaction reads. Nothing here touches a chain to look up state.
- No self-service tenant registration. Tenants are provisioned by an operator.