Blog

How to create a crypto wallet: The basics

Resources
·
August 6, 2025
·
Bryce Ferguson, Co-Founder & CEO of Turnkey

MetaMask didn’t begin as a wallet. It started as a browser extension, a convenience layer, to help users connect to decentralized apps. 

But what the founders of MetaMask quickly discovered was that users didn’t just need access, they needed custody. They needed secure private key storage, transaction signing, and a clear UX around authorization. And in response, MetaMask evolved from a lightweight dApp connector into a full self-custodial wallet. 

There’s a clear lesson here. If your app touches anything onchain, you’re building on top of a wallet. The sooner you design for that, the better.

This article covers high-level information developers need to know about creating crypto wallets, from core components like key management and transaction signing to design decisions that impact security and user experience. 

Whether you’re building a DeFi app, incorporating crypto payments, or launching a crypto game, wallet architecture should be the starting point. This guide explains how developers should think about crypto wallets, the tradeoffs in different approaches, and how Turnkey provides faster, more secure, programmatic wallets that integrate seamlessly into your application flow. 

Understanding the basics: What is a crypto wallet?

Crypto wallets store cryptographic key material and use it to sign transactions, verify identities, and interact with blockchains. Every onchain action, whether it’s moving funds, voting in a DAO, or deploying a contract, starts with a wallet signature.

That signature is what gives a transaction authority. It’s how a smart contract knows you approved that swap and how your app’s backend agent is able to initiate that settlement.

Regardless of your design choices, the same foundational components are needed to build a functional and secure crypto wallet. These primitives define how your wallet behaves, what it can do, and how resilient it is under load or attack.

Let’s take a closer look at each one.

Key generation and management

Every wallet begins with a cryptographic key pair. This typically involves a private key used for signing and a corresponding public key that’s used to derive the wallet’s blockchain address.

Most chains use elliptic curve cryptography, such as secp256k1 for Ethereum and Bitcoin, or ed25519 for networks like Solana and Cosmos.

Generating the key pair is the easy part. The hard part is managing it securely. Private key material should never be exposed outside secure environments, and should only be accessible during tightly controlled signing operations.

Poor key management is the single most common failure point in wallet infrastructure. The security guarantees of your system ultimately depend on where your keys live and how they're controlled during signing.

Address derivation

Wallet addresses are generated from public keys, with the exact method depending on the blockchain. For instance, Ethereum shortens a hashed public key into its address format, while Solana encodes the public key directly using its own scheme.

Many modern wallets also implement hierarchical deterministic (HD) key structures. Instead of generating keys in isolation, HD wallets use a single root seed to create a structured tree of addresses.

This approach gives you scale and organization. A single seed can power many accounts, chains, or use cases. For developers, it means you can provision unique addresses per user, app, or workflow without managing a sprawl of unrelated keys.

Transaction signing

Transaction signing is the heart of wallet functionality. Whether you're approving a token transfer, voting on governance, or authorizing a complex contract interaction, the wallet's job is to prove intent by signing a payload.

Depending on your use case, you may need to support raw signatures, structured data, smart account workflows, or token approvals. 

Wallet infra should also be able to verify what is being signed and why. Wallets that support context-aware signing can enforce guardrails like rejecting transactions from unrecognized domains or allowing signatures only for specific contracts or functions. Some can even enforce limits based on chain ID, gas price, or recipient.

Without this context, signing becomes a blind operation and a liability.

Network communication

Wallets typically don’t connect to the blockchain via their own full node. Instead, they use RPC (Remote Procedure Call) infrastructure — like Infura, Alchemy, or self-hosted nodes — to interact with the network.

This creates an operational dependency: if the RPC provider is slow or unavailable, the wallet will appear slow or unavailable too. 

Reliability directly affects perceived performance, and latency can break time-sensitive flows. Each blockchain also has its own quirks, which may require custom error handling at the protocol level.

In embedded wallets, the RPC layer is usually tied directly to the signing workflow. The app signs a transaction and immediately sends it through the same RPC connection. In browser-based or user-managed wallets, broadcasting is typically handled by the dApp or the wallet’s built-in provider. 

In both cases, RPC performance and availability are part of the wallet’s overall reliability footprint.

Passapp Statement

Design considerations when creating a crypto wallet

Designing a crypto wallet is as much a product decision as it is a technical one. 

Developers need to consider many factors in order to design a wallet that functions according to their needs. At its core, the wallet needs to be secure and usable. But depending on the intended application, other factors could be just as important. 

For example, with the increased interoperability among crypto ecosystems, developers might want the wallet to seamlessly and securely move crypto across chains. If so, designing this intent ahead of time then becomes crucial and will impact many different components of the build.

Another important consideration is the ability to maintain control as you scale for different use cases beyond what you initially set out to create. Having modular wallet infrastructure and enough control to build the wallet you need, when you need it, is essential for growing your application over time.       

Security: The architecture behind key trust

At the heart of wallet security is not just where the key is stored, but how it is isolated and who can access it. Simply generating a key in a browser or on a backend server is no longer sufficient for production-grade use cases. Without scoped access and fine-grained policies, one vulnerable signing operation can compromise the entire system.

What matters is minimizing key exposure, not just encrypting storage. The key should only exist in memory when it’s actively being used, and every access should be provable and traceable.

Systems that rely on static file-based keys, browser storage, or unrestricted signer access will inevitably leak control, especially under automation. 

In short, secure systems don't just manage keys. They define the full lifecycle of signing intent, from creation to authorization to destruction. 

Usability: how users interact with the wallet

Wallet UX starts with the first interaction, whether that’s connecting MetaMask or silently provisioning a wallet in the background. And it continues across the entire lifecycle: confirmations, error handling, transaction visibility, and recovery.

A clear UX reduces dropoff, lowers support load, and builds trust. 

For some audiences, that may mean manual signing with human-readable messages and domain verification. For example, a DeFi lending protocol might send a wallet holder an EIP-712 message containing structured, verifiable data that confirms they are approving a specific transaction on the platform.

For others, invisible flows with passkeys or session-based delegation make the experience seamless. Biometrics, for instance, might be used by a web3 game to ensure uninterrupted gameplay without repeated wallet prompts. 

Higher-level users might even need more options like social recovery, 2FA, or multisig — a DAO treasurer, for example, might need a multisig wallet requiring 2 to 3 signers for every transaction. 

Think about how the wallet feels at every step, not just during key generation.

Flexibility: Are you building for one chain or many?

Supporting multiple chains adds surface area to every part of the wallet stack: address formatting, signing logic, RPC handling, metadata parsing, and more.

Feature EVM Chains (e.g., Ethereum, Polygon) Non-EVM Chains (e.g., Solana, Cosmos)
Signature Algorithm secp256k1 + ECDSA Typically ed25519 + EdDSA
Address Format Last 20 bytes of keccak256(pubkey) (hex) Varies by chain; often ed25519 → base58 or bech32
Transaction Format RLP-encoded; chain-specific fields like gas JSON, protobuf, or custom formats (non-RLP)
Nonce Management Incrementing integer per account Some use nonces, others rely on recent blockhashes
RPC Layer JSON-RPC (eth_* methods) Tendermint RPC, custom APIs, or GRPC
EIP/Standard Support EIP-1559, EIP-712, ERCs Chain-specific proposals (CIPs, SIPs, etc.)
Wallet Compatibility MetaMask, WalletConnect, hardware wallets Custom SDKs or chain-specific wallet tooling
Cross-chain UX Easier due to format consistency Requires deeper integration and normalization

Control: Scalability and developer experience

A wallet is as much a security system as it is a development tool, and part of your ever-growing infrastructure.  If you're building for scale, the wallet must do more than sign transactions. It needs to be flexible, programmable, and easy to manage as your application grows.

That means your wallet infrastructure should support:

  • Modular design: Add new chains, features, or signing logic without a full rewrite.

  • Custom workflows: Integrate signing into any flow (auth, payments, automation) without changing core infrastructure.

  • Programmable signing: Handle structured data and context-aware approvals, like EIP-712.

  • Policy enforcement: Restrict signing by domain, chain, function, or recipient.

  • Auditability: Trace every signature back to policy and context for full transparency.

Scalability isn’t just about performance. It’s about developer control, policy transparency, and operational readiness. A wallet that works today should still work when your user base grows 10x, your app spans multiple chains, and your security needs evolve.

Build for scale now, and your infrastructure won’t hold you back later.

Layer3 Statement

Anchoring your design: Custody, architecture, and integration

Every wallet design is defined by three decisions: who controls the keys, how authorization works, and how users connect to it. These choices — custody, architecture, and integration — set the boundaries for security, usability, and trust, shaping everything from onboarding to recovery to long-term scalability.

Custody in wallet design

In general, crypto custody refers to the secure storage and transfer of cryptoassets. One of the first decisions developers face is whether to build their wallets with a custodial or non-custodial model. This choice sets the foundation for how security, control, and user trust are handled.

  • Custodial wallets are managed by a third party–you trust them to hold keys and sign on your behalf. This model is common in exchanges or fintech apps, where regulatory or UX constraints require centralized control.

  • Non-custodial wallets give the user full control of their keys. Nothing moves without their signature. This model aligns more closely with Web3 values of sovereignty, transparency, and verifiability.

Choosing between custodial and non-custodial models ultimately shapes the balance between convenience and user control. The right approach depends on your audience’s needs, risk tolerance, regulations, and the trust assumptions you’re willing to make.

Wallet architecture

Wallet architecture refers to the underlying model that governs how a wallet is structured, how it authorizes actions, and what features it can support onchain. 

At the protocol level, wallets come in two main types:  Externally Owned Accounts (EOAs) and smart contract wallets.

  • EOAs are the simplest and most common form of wallet. They’re controlled by a single private key and are native to Ethereum and most Layer 1s. MetaMask, Ledger, and most traditional wallets use this model. They’re lightweight and easy to use, but they’re limited, as they can’t enforce custom logic like spending limits, role-based access, or social recovery.

  • Smart wallets, often referred to as account abstraction wallets, are smart contracts that manage their own authorization logic. Instead of relying on a single key, they can enforce arbitrary rules like batched transactions, multi-signature authorization, or time-based spending policies. 

Standards like EIP-4337 and EIP-7702 are accelerating adoption by making these wallets easier to deploy and maintain.

Your wallet’s architecture sets the foundation for what’s possible in your application. EOAs offer simplicity but limit features like recovery or automation, while smart wallets enable richer controls, compliance workflows, and smoother user experiences.

Developer integration patterns in wallets

Integration patterns describe how wallets are delivered to users, whether the application provisions keys behind the scenes or the user connects a wallet they already control. This choice defines the onboarding flow, the level of friction, and how much control users retain.

While architecture defines what a wallet is, integration defines how users experience it. 

There are two main developer integration patterns:

  • Embedded wallets are created and managed by the application itself, often without exposing private key material to the user. These wallets are ideal for onboarding non-technical users or supporting programmatic agents.
  • User-managed wallets (like MetaMask or Ledger) require the user to bring their own wallet and connect it manually. This model preserves full user control, but introduces friction, especially for mainstream users unfamiliar with seed phrases or chain switching.

This decision affects onboarding flows, security assumptions, support models, and how transactions are signed. If you're building for developers, prosumers, or DeFi natives, user-managed wallets may be fine. If you're targeting broader audiences, embedded wallets are often the better fit.

Introducing Turnkey: Modern, secure crypto wallet infrastructure

Turnkey provides wallet infrastructure built on secure enclaves, ensuring private keys never leave trusted execution environments. Private keys are created, stored, and used for signing within secure enclaves, preventing both Turnkey and external attackers from ever accessing raw keys.

This removes the main weakness in wallet security.

How Turnkey differs from legacy wallets  

Legacy wallets like MetaMask were designed for single users in trusted environments. They often assume keys can sit in browser storage, local files, or hardware devices. That breaks down in enterprise or backend settings where automation, scale, and compliance are required. 

Turnkey goes further with:

These controls give developers fine-grained guardrails without re-engineering their own cryptography.

Best practices for developers creating a secure wallet

Turnkey’s architecture reflects what modern best practices already demand:

  • Minimized attack surface areas. Keep private keys inside enclaves and only expose them during tightly scoped signing operations.

  • Policy-driven workflows. Enforce rules at the signing layer instead of relying on application logic alone.

  • User-friendly UX. Use embedded wallets with passkeys or session delegation to keep security strong while removing the burden of seed phrases for users.

  • Recovery and migration options. Build in secure ways for users to regain access — such as social recovery, key rotation, or controlled exports — without weakening overall security.

When to use Turnkey vs. building your own

For prototypes, building your own wallet with ethers.js or solana/web3.js works. But at scale, when you need policies, multi-user workflows, and verifiable custody, building in-house becomes a risk. 

Turnkey delivers a secure, production-ready foundation so you can focus on your app, not wallet infrastructure.

Turnkey helps developers create secure wallets at scale

Creating a crypto wallet securely and efficiently requires more than just generating key pairs. Developers need to think about key storage, transaction context, policy enforcement, and user experience from the very start. 

The right approach balances flexibility with safety, ensuring wallets can scale without exposing keys or creating blind spots in monitoring.

Turnkey provides the wallet infrastructure to make that balance practical. By combining enclave security with policy-driven signing and seamless developer tooling, it gives teams a faster path to production-grade wallets. 

Whether you’re building for DeFi, gaming, or backend automation, Turnkey delivers the foundation for wallets that are both secure and developer-friendly. Try Turnkey today. 

Related articles