Turnkey
- Name: Turnkey
- URL: https://www.turnkey.com/
- Category: wallet infrastructure company / embedded-wallet and machine-signing operator / key-management workflow platform
- Tags: ethereum-ecosystem solana-ecosystem bitcoin-ecosystem
- Summary: Turnkey belongs as an entity note, not a protocol note. The useful cut is that a named company operates a hosted signer control plane spanning wallet creation, credential issuance, recovery, approval policy, and machine-account automation. The practical leverage lives in org auth, policy configuration, supported activity surfaces, and recovery / observability workflow rather than in any standalone onchain account primitive.
- What it does:
- Provides embedded-wallet infrastructure for app developers
- Offers programmable wallet generation, signing, and automation primitives for both user-facing and machine accounts
- Exposes SDKs, APIs, and documentation for integrating wallet creation and signing into products
- Uses trusted hardware / secure enclaves as a core part of its security and key-management model
- Supports multichain activity surfaces across EVM, Solana / SVM, and Bitcoin-adjacent Spark flows rather than tying itself to one chain ecosystem
- Key claims:
- The homepage positions Turnkey as
secure, flexible, and scalable wallet infrastructure - Official materials say Turnkey is fully non-custodial and built on secure enclaves / TEEs
- Official materials claim its code can be independently verified, replacing blind trust with cryptographic proof
- Marketing materials emphasize low-latency signing, high availability, and support for signing millions of transactions quickly; those scale numbers should still be treated as vendor claims unless independently verified
- The docs corpus exposes first-class activity surfaces for EVM transaction broadcast, SVM transaction broadcast, and Spark transfer claiming, which makes the operating boundary more concrete than the homepage alone
- GitHub materials show public docs, SDKs, demo wallets, and enclave-related repositories, reinforcing that Turnkey is a company-run workflow stack rather than a thin API facade
- The homepage positions Turnkey as
- Whitepaper: No classic whitepaper or litepaper was found during this pass. The strongest primary materials were Turnkey’s official site, docs portal, public API references, and GitHub organization; see
../whitepapers/turnkey-primary-sources-2026-04-22.mdand../whitepapers/turnkey-primary-sources-2026-06-07.md. - Sources:
Internal linkages
- Alias / prior project-layer entry: turnkey.
- Keep this note on the clearest adjacent signer-infrastructure reads: dfns, privy, and safe.
- Reusable lens: when a team says
embedded walletsormachine wallets, the real leverage often sits in credential issuance, recovery, policy, and hosted signing workflow rather than in the account abstraction wrapper.
Protocol / company boundary
- There is no especially useful standalone
Turnkey protocolboundary doing separate analytical work here. - The practical dependency is the company-run signer workflow around credential issuance, recovery, policy, observability, and machine-account automation rather than a neutral lower-layer primitive.
- Keep turnkey only as an alias so legacy links keep resolving without pretending Turnkey is a protocol peer to more autonomous onchain systems.
Control surface
-
Practical leverage sits in org and workspace authentication, API credentials, wallet creation policy, recovery workflow, approval logic, machine-account scope, telemetry, and which chains or activity types Turnkey makes easiest to operate.
-
The sticky dependency is the hosted signer workflow and auth fabric around the keys, not only the enclave primitive itself.
-
Read Turnkey as a company-run signer control plane, not as the durable account substrate.
-
Last reviewed: 2026-08-10 UTC