Skip to main content
Turnkey provides the infrastructure to create and manage wallets, sign transactions, and secure cryptographic keys at scale. Every signing operation happens inside hardware-backed secure enclaves — private keys are never exposed to Turnkey, your application, or your team.

​
How Turnkey works

Instead of managing private keys directly, Turnkey abstracts key management into a layered system. Your application is a parent organization, and sub-organizations are available to fully isolate wallets, users, and policies per end user or tenant. Every action — signing, creating wallets, updating permissions — is evaluated by a policy engine running inside a hardware-backed secure enclave before anything executes. Keys never leave the enclave. Turnkey returns signed payloads and supports transaction broadcasting directly to the network. Turnkey operates based on a shared responsibility model. Turnkey is responsible for the security of the platform itself, including enclave infrastructure, policy engine correctness, key confidentiality, and service availability. You are responsible for securing your integration: configuring your root quorum, scoping user permissions, authoring policies, and managing credentials. See the full model for details.
Turnkey architecture: organizations, sub-organizations, users, authenticators, policies, and wallets

​
Core concepts

  • Organization — Top-level entity representing your application. Contains users, wallets, and policies.
  • Sub-organization — Fully isolated organization nested under the parent, typically representing an end user or business customer. Parent orgs have read-only access and cannot modify sub-org contents.
  • User — A resource within an org or sub-org that submits activities via a valid credential. Users can have tags, which policies reference for role-based controls.
  • Root user / root quorum — Root users can bypass the policy engine. A root quorum sets the approval threshold required to exercise root permissions.
  • Authenticator — A credential used to stamp API requests: passkeys, API keys, email OTP, or OAuth.
  • Activity — Any action submitted to Turnkey (sign transaction, create user, update policy). All activities are evaluated by the policy engine.
  • Policy — A logical rule that evaluates to ALLOW, DENY, or REQUIRES_CONSENSUS. Controls who can sign what, under what conditions.
  • Wallet — An HD wallet (seed phrase) that generates multiple accounts across chains. Lives inside the enclave; only addresses and signatures are returned.

​
When to use Turnkey

Turnkey is the right fit when you need to:
  • Embed wallets in a consumer app — Non-custodial wallets your users access with email, passkeys, phone number, or social login. No seed phrases or browser extensions. See Embedded Wallets.
  • Automate onchain operations — Server-side wallets for payouts, treasury operations, payment orchestration, and smart contract management at scale. See Company Wallets.
  • Give AI agents signing authority — Provision an agent with its own wallet and constrain it with policies: spending caps, destination allowlists, and approval flows. See Agentic Wallets.
  • Secure high-value keys — Hardware-backed storage and programmable access controls for signing keys, encryption keys, and secrets, including enterprise disaster recovery. See Key Management.
  • Run verifiable workloads — Deploy your own applications to enclave-backed infrastructure with remote attestation and verifiable proofs of exactly what code is running. See Turnkey Verifiable Cloud.
  • Sign at scale across chains — Millions of isolated sub-organizations and low-latency signing for EVM chains, Solana, Bitcoin, and more. Turnkey can sign any payload with generated keys.

​
How applications and agents call Turnkey

Turnkey is API-first: every operation is a JSON POST to https://api.turnkey.com, signed (“stamped”) with a P-256 API key or passkey. Create an organization and API key self-serve in the Turnkey dashboard, then integrate via:

​
Where to start