The developer tooling stack for building secure crypto wallets faster
As more applications add wallets and digital asset flows, a new category of developer tooling has become important: wallet and key management infrastructure.
This tooling is what developers use to create wallets, manage private keys, enforce policies, sign transactions, and integrate blockchain functionality into their applications. But those workflows interact with the assets themselves, which makes security a first-order requirement.
The challenge for development teams is building this infrastructure securely without making key management the entire engineering focus.
Turnkey helps crypto and fintech development teams meet that challenge with a complete toolkit for wallet infrastructure: REST APIs, client and server SDKs across six languages and frameworks, web3 library adapters, transaction management tools, and a policy engine that controls what can be signed and by whom.
In this article, we’ll look at how wallet and key management fit into the broader developer tooling category, and why they matter for teams building crypto and fintech applications. We’ll also explain how the right tooling helps developers build secure digital asset products faster, without taking on the full burden of designing private key infrastructure themselves.
Why many teams don't build private key management in-house
Private key management means taking responsibility for the full key lifecycle. That includes key generation, private key storage, signing infrastructure, access controls, recovery flows, audit logs, and operational security.
Each piece has to work reliably in production. Each piece adds risk if it is designed poorly.
Building this in-house also pulls engineering teams away from the product they set out to build. Instead of working on the essential infrastructure to build their applications, developers spend time maintaining security infrastructure, hardening signing paths, and reviewing access rules.
Turnkey offers a complete toolkit for wallet infrastructure: SDKs, authentication flows, private key management, transaction management, multichain support, policy controls, AI agent wallet tooling, and code examples.
1) SDKs, adapters, and low-level primitives
Turnkey's SDK layer is organized into three tiers: client-side SDKs for building user-facing wallet experiences, server-side SDKs for backend and scripting workflows, and web3 library adapters for teams integrating into existing decentralized applications (dApps).
Client-side SDKs
Client-side SDKs handle user authentication, wallet creation, signing, and import/export. They cover six targets.
TypeScript and React are the primary web targets. Both support the full feature set: email, SMS, passkey, and social authentication; wallet creation and signing; wallet import and export; and arbitrary request signing via stamping.
React Native brings the same capabilities to mobile. Teams building consumer wallets on iOS and Android can use the React Native SDK for authentication, wallet management, and signing without a separate infrastructure stack.
Flutter covers cross-platform mobile development. The Flutter SDK supports authentication and wallet operations and includes a full demo app showing registration, wallet creation, export, and transaction signing.
Swift targets native iOS development. The Swift SDK includes examples for OTP, OAuth, and passkey authentication alongside wallet creation, message signing, and transaction sending.
Kotlin targets native Android development with the same authentication and wallet management capabilities.
Server-side SDKs
Server-side SDKs are for backend workflows: automated signing, policy management, wallet provisioning, and scripting. Turnkey supports five server-side targets: TypeScript, Go, Ruby, Rust, and Python.
All five support authentication. TypeScript, Go, and Ruby additionally cover wallet management and policy management, making them the preferred choices for teams building backend automation or orchestration layers.
Web3 library adapters
For teams already building with web3 libraries, Turnkey ships named adapters that replace the signer in existing code without requiring a full architectural change:
- @turnkey/ethers for ethers.js
- @turnkey/viem for viem
- @turnkey/eip-1193 for any EIP-1193-compatible provider
- @turnkey/cosmjs for Cosmos via CosmJS
- @turnkey/solana for Solana transactions
- @turnkey/gas-station for sponsored transaction workflows
These adapters let teams keep their preferred web3 libraries while moving key management, signing, and policy enforcement into Turnkey's secure infrastructure.
Advanced SDK layer
For teams that need low-level control over how Turnkey requests are authenticated, the advanced SDK layer exposes individual stamper primitives:
- ApiKeyStamper for server-to-server API key authentication
- WalletStamper for signing Turnkey requests with an external wallet (MetaMask, Phantom)
- WebAuthnStamper for passkey-based request signing
- IframeStamper for secure wallet import and export flows
- IndexedDbStamper for browser-persisted credential storage
These composable primitives are what the higher-level SDKs are built on. Teams with custom auth flows or non-standard environments can use them directly.
Related resources:
2) Authentication methods and session management
Turnkey supports two authentication paths: API authentication for server-to-server requests and user authentication for client-facing flows.
API authentication uses an API secret to verify requests from your backend directly. Policies layered on top control which wallets and resources each API key can access.
User authentication covers nine methods for end-user-facing applications:
- Passkeys and WebAuthn for biometric or device-based login
- Email OTP for passwordless email login
- SMS OTP for phone-based authentication
- OAuth and social login including Google, Apple, Discord, and X (Twitter)
- Magic links via email OTP
- External wallet login via Sign-In With Ethereum and Sign-In With Solana, using the wallet stamper
All auth methods produce the same common user object. A user who registers with a passkey and later links a Google account is the same user in Turnkey's model. Sessions created after authentication can represent an active user session or authorize requests to your backend.
For teams that need to integrate Turnkey authentication with an existing auth system, Auth Proxy and Bring Your Own Auth provide patterns for validating JWTs and routing authenticated requests through your own backend.
Related resources:
3) Gas sponsorship, broadcast, and transaction monitoring
When it comes to transactions, Turnkey handles the full transaction lifecycle, not just signing.
For the chains that Turnkey supports, a single API call covers transaction construction, fee estimation, signing, broadcast, and status monitoring. Developers pass a minimal payload and Turnkey fills in the rest, including nonce management, gas estimation, and priority fees.
With gas sponsorship enabled, users never need to hold native tokens to pay fees. Spend limits are configurable at the organization and sub-organization level, denominated in USD.
Turnkey's gas sponsorship contracts are open source. Transaction construction happens inside the enclave, so a compromised provider cannot replay or modify requests. EVM sponsorship covers Base, Polygon, Ethereum, and Arbitrum plus their testnets. Solana sponsorship covers mainnet and devnet.
Webhooks deliver real-time transaction status and balance change events, so teams can track signing and broadcast outcomes without polling. For teams building on EVM without Turnkey's transaction management, paymaster integrations support ERC-20 gas payment on supported networks.
Related resources:
Case study
Explore how Turnkey powers agent wallets for Parallel Studios
Turnkey's developer tooling (clear docs, SDKs, and responsive support) let Parallel Studios ship Wayfinder's LLM trading-agent wallets fast. They reached full integration in three weeks and have created 550k+ user wallets at a 90% onboarding completion rate.
Read the case study →4) Policy controls and access management
A policy engine gives teams programmable control over what can be signed, by whom, and under what conditions. Policies are defined in JSON using Turnkey's policy language. Each policy has three components: an effect (allow or deny), a consensus expression defining which users can take an action, and a condition expression defining when the policy applies.
For example, a policy can restrict a specific user to signing transactions only to a specific destination address. The effect, consensus, and condition fields can be used independently or together to express any combination of user permissions and signing constraints.
Policies run inside the enclave on every signing request, at the same trust boundary as key operations. They are not evaluated at the API layer, which means they cannot be bypassed by modifying requests outside the enclave.
For teams building multi-user applications, Turnkey's organization model separates the parent organization from sub-organizations. Each sub-organization can have its own users, credentials, wallets, and policies. The parent has read-only visibility across all sub-organizations. This structure makes it practical to model end-user wallets, institutional accounts, or multi-tenant applications without shared credential state between accounts.
Related resources:
5) Smart contract tooling with policy enforcement
For many teams, wallet infrastructure does not stop at creating wallets or signing simple transfers. Production applications often need to interact with smart contracts for swaps, deposits, minting, staking and other application-specific workflows. That makes smart contract tooling part of the wallet infrastructure layer.
Turnkey helps teams bring policy enforcement into those workflows, so developers can define not only who can sign, but what contract actions they are allowed to perform.
Smart contract interfaces
Policies that enforce rules based on destination address or wallet are useful. Policies that understand what a contract call is actually doing are more powerful.
Turnkey's policy engine supports uploaded Ethereum ABIs and Solana IDLs. When an ABI or IDL is registered against a contract address or program, the policy engine parses transaction calldata using the interface definition and exposes named function arguments directly in policy conditions.
For EVM, this means a policy can reference the function name, function signature, and individual named arguments. A policy restricting token transfers to a specific recipient and below a specific amount can be written against argument names defined in the ABI, rather than raw byte offsets. Without an uploaded ABI, calldata inspection falls back to raw hex slicing, which is more brittle and harder to maintain as contracts evolve.
For Solana, the equivalent is an Anchor-formatted IDL. Once uploaded, policies can reference the instruction name, named accounts, and program call arguments on any instruction in the transaction. A policy governing a Jupiter swap can target the route instruction specifically and enforce limits on the input amount argument by name.
Both ABI and IDL uploads can be managed through the Turnkey dashboard or programmatically via the SDK. The interface is registered against a specific contract or program address, and policies targeting that address automatically get access to the parsed argument namespace.
Related resource: Smart contract interfaces
Smart contract management
Turnkey gives teams policy-enforced control across the full smart contract lifecycle: deployment, ongoing interactions, and upgrades.
Deployment is permissioned by default. A designated deployer wallet is scoped by policy to sign only contract creation transactions on a specific network. This means the deployer key cannot be used for anything else, limiting exposure if credentials are compromised.
Post-deployment, function-level policies govern how contracts can be interacted with. A minting policy, for example, can restrict a specific operator to a designated wallet, target only the deployed contract address, and allow only the mint function. Uploading the contract ABI is the recommended approach for production: it lets policies reference function names and constrain named arguments directly, rather than matching raw function selectors.
Upgrades are the most sensitive operation in the contract lifecycle. Turnkey's recommended pattern is to keep the upgrade owner wallet dormant and create a temporary, tightly scoped policy only when an upgrade is needed. Once the upgrade transaction is signed and confirmed, the policy is deleted and the wallet goes back to dormant, minimizing the window during which upgrade authority is active.
For teams using Foundry, Turnkey wallets serve as the signing backend for contract deployment and interaction via the native Foundry integration. The deployer, operator, and upgrade owner can each be separate Turnkey wallets with their own scoped policies, fitting naturally into a Foundry-based workflow.
Related resource: Smart contract management
Case study
See how Pass App ships AI-powered wallets with Turnkey
Pass App uses Turnkey's wallet and key-management tooling to power an AI-driven wallet that interprets user intent and signs securely inside enclaves. The team integrated in two weeks, saved six months of engineering time, and has run at 99.9% uptime since launch.
Read the case study →6) Developer tooling for AI agent wallets
AI agents introduce a new wallet use case. As agents become more capable, they may need to initiate payments, sign transactions, interact with smart contracts, or execute financial workflows on behalf of a user or application.
That does not mean agents should have unlimited control. Agentic wallets need scoped authority: permission to take specific actions, within specific limits, under specific conditions.
Developers use the policy engine to define exactly what an agent can sign: which wallets, which destination addresses, which contract interactions, and whether human approval is required before execution. The agent gets enough authority to be useful, not enough to drain an account or bypass review. Turnkey supports account abstraction integrations with ZeroDev and Biconomy for teams that need smart account features alongside policy-controlled signing.
For teams building with AI coding assistants, Turnkey also ships Agent Skills: a set of composable SKILL.md files that give AI agents step-by-step instructions for common Turnkey operations. Skills cover wallet creation, transaction signing, policy management, user management, and activity monitoring. They work with Claude Code, OpenAI, and other agent frameworks, and can be combined for any workflow.
Related resources:
7) Multichain support
Digital asset products often need to support more than one chain. A payment product may need stablecoin support on EVM chains. A consumer app may need Solana. A treasury workflow may need Bitcoin.
Turnkey supports address derivation and signing across EVM-compatible chains, Solana, Bitcoin, Cosmos, Aptos, Sui, Tron, TON, XRP, Dogecoin, Stacks, Movement, and others.
Each chain uses the appropriate address format and signing curve. EVM chains use secp256k1 with Ethereum-formatted addresses; Solana, Aptos, and Sui use ed25519 with their respective address formats.
Teams building across networks use a single private key management and policy layer regardless of which chains their application touches.
8) Embedded wallet features
Beyond signing infrastructure, Turnkey includes developer features that address common embedded wallet UX challenges: getting assets into a new user's wallet before they have authenticated, and sending funds to someone who has not yet signed up.
Pregenerated wallets let developers create a wallet for a user before they authenticate. If an email or phone number is known in advance, a sub-organization can be created with only that contact linked as the root user and no other authenticators, ensuring only the end user can claim it.
When the user is ready, they complete an email auth flow to access the wallet and sign transactions or add a new authenticator.
Claim links let existing users send crypto to people who have not signed up yet. A temporary escrow sub-organization holds the funds and embeds an API key inside a URL.
When the recipient clicks the link, they land in the app with a pre-funded wallet visible. They complete a standard onboarding flow to create a permanent sub-organization, and the funds are transferred from the escrow wallet to their new wallet.
The sender retains the ability to reclaim the funds if the link is never claimed.
Related resources:
9) Code examples
Turnkey also maintains a GitHub repository of 40-plus working examples covering authentication patterns, wallet management, chain-specific signing, DeFi protocol integrations, account abstraction setups, and full demo applications.
Highlights include:
- Full embedded wallet demos in React, React Native, Flutter, and Swift (iOS)
- Chain-specific signing examples for Ethereum, Solana, Bitcoin, Cosmos, Aptos, Sui, Tron, TON, and others
- DeFi integrations with Uniswap, Aave, Morpho, 0x, Li.Fi, Jupiter, and others
- Gas Station and paymaster examples for EVM and Solana
- Policy and delegated access examples
- Smart contract deployment via Foundry
The examples repository is the fastest way to see how Turnkey fits into a production workflow. Most examples can be run locally with minimal configuration.
Related resource: Code examples
Getting started with Turnkey
Turnkey is developer tooling for wallet infrastructure and private key management. It gives teams the APIs, SDKs, embedded wallet components, signing workflows, policy controls, and multichain support they need to build digital asset applications without building private key management from scratch.
Explore the docs, start with the quickstart, build an embedded wallet, or sign up for Turnkey to begin building.
Related articles
Turnkey’s 3 phases of secure software development
Explore Turnkey’s software development process. See how each stage turns source code into a cryptographically verifiable artifact that is built, approved, and attested.
.avif)
Yesterday never dies: Securing stateless systems against downgrade attacks
In this post, we’ll trace the evolution of Turnkey’s defense against downgrade attacks, exploring what worked, what didn’t, and what we learned along the way.
