The crypto industry has spent over a decade arguing about custodial vs. non-custodial wallets as if it were a binary with a correct answer. It isn't. The framing itself is the problem.
Call something "non-custodial" and it sounds trustless—until you realize the private key lives inside a browser extension controlled by Google Chrome, backed up to a cloud provider you didn't audit, and recoverable through an email account protected by a password you reuse. Call something "custodial" and it sounds like handing your assets to a bank—until you learn the keys are sharded across independent HSMs in three jurisdictions, with multi-party approval and tamperproof audit trails.
The labels don't tell you much. The implementation tells you everything.
This guide is our attempt to move past the sloganeering and into the plumbing. We'll cover what a wallet actually is (it's more than a key), how custody models work in practice, what key management architectures exist, and—most importantly—how to evaluate a wallet service for your specific use case. Whether you're building a payment app, a gaming platform, or institutional infrastructure, the right wallet isn't the most ideologically pure one. It's the one that gets the job done.
The Custody Spectrum: Why the Binary Is Broken
The traditional framing splits wallets into two camps:
Custodial: a third party holds your keys. You trust them. If they disappear, so do your assets.
Non-custodial (self-custody): you hold your keys. You trust yourself. If you lose them, nobody can help.
This framing was useful in 2014. After Mt. Gox collapsed and a single point of failure wiped out 850,000 BTC, the crypto community had good reason to distrust centralized key management. "Not your keys, not your coins" became a rallying cry, and it wasn't wrong—at the time.
But here's what the binary misses: custody is a legal construct, not a technical one. Technology enables or constrains custody, but it doesn't define it. A wallet can use MPC to distribute key shares across five parties, with the user controlling three of them. Is that custodial? Non-custodial? The honest answer is: it depends on the legal agreement, the jurisdiction, and who can reconstruct the full key under what circumstances.
What actually matters is a set of concrete questions:
- Who generates the keys? On what hardware, in what environment?
- Who can access the key material? Under what conditions?
- Who can sign transactions? With what approval flow?
- Who can recover the account? Through what mechanism?
- What happens if the service disappears? Can you still move your assets?
These questions define a spectrum, not a binary. And the spectrum has at least five meaningful positions.
The Five Configurations
Rather than reducing wallets to "custodial" or "non-custodial," it's more useful to think in terms of control configurations:
| Configuration | Who Controls Keys | Who Signs Transactions | Recovery Responsibility | Example |
|---|---|---|---|---|
| User-controlled | User generates and stores keys on their own device or hardware. | User alone. | Entirely user-managed (seed phrases, backup devices). | Ledger, Trezor, MetaMask (in theory). |
| Co-controlled | Keys are split or shared between user and service provider. Neither party can act alone. | Requires cooperation. | Shared—provider can assist recovery, but can't unilaterally access funds. | Zengo (MPC), Fireblocks (institutional MPC). |
| Delegated | Service generates and manages keys, but user retains legal ownership and can export. | Service signs on user's behalf, often with policy controls. | Provider-managed with export guarantees. | Openfort (smart wallets with flexible signers), Turnkey. |
| Org-controlled | Organization manages all keys centrally, typically for treasury or operational wallets. | Internal approval workflows (multi-sig, policy engines). | Organization handles backup and DR. | Corporate treasury setups, exchange hot wallets. |
| Institutional custody | Licensed custodian holds keys under regulatory obligations. | Custodian executes per client instructions, subject to compliance checks. | Custodian manages—often with insurance and SLAs. | Coinbase Custody, BitGo, Anchorage. |
The configuration you choose depends on your use case, your regulatory environment, and—frankly—how much operational complexity you're willing to absorb.
What Makes a Wallet a Wallet
Here's a misconception that's surprisingly common even among builders: a wallet is not a private key. It's not a signature scheme. It's not a smart contract. It's not a browser extension.
A wallet is the sum of all these parts—a software system that manages the full lifecycle of onchain interactions. Reduce it to any single component and you'll make architectural decisions you'll regret.
A complete wallet service involves several layers:
Key Management Layer. This is the foundation. It handles key generation, storage, rotation, and—critically—the signing of transactions. The security of your entire system bottoms out here. Whether keys live in an HSM, a TEE, an MPC network, or a user's device determines your attack surface.
Transaction Building Layer. Before a transaction is signed, it needs to be constructed—estimating gas, encoding calldata, setting nonce values, simulating execution. This layer is often invisible to users but is where most operational bugs surface.
Transaction Management Layer. Once signed, transactions need to be submitted, monitored for inclusion, resubmitted if stuck, and indexed for status tracking. For applications processing thousands of transactions per hour, this layer is the difference between "it works" and "it works in production."
Policy and Approval Layer. Who can sign what, under what conditions? Spending limits, multi-party approval flows, time-locked operations, whitelisted addresses. For any business beyond a single-user hobby project, programmable policies are not optional.
User and Identity Layer. Linking wallets to users—through social logins, passkeys, email, or enterprise SSO—while managing sessions, devices, and permissions. This is the layer that determines onboarding friction.
Smart Contract Layer. For smart wallets (ERC-4337 and beyond), the wallet itself is a contract on-chain. This enables programmable custody: social recovery, session keys, batched transactions, gas sponsorship, and modular upgrades—none of which are possible with a bare EOA.
Node and Indexing Layer. Wallets need to read blockchain state (balances, token holdings, transaction history) and submit transactions. This means running or connecting to RPC nodes, indexers, and data providers across potentially many chains.
The point is: when you evaluate a wallet service, you're not evaluating a key. You're evaluating an entire infrastructure stack. And the quality of each layer compounds.
Key Management Architectures: The Technical Core
The key management layer deserves its own deep dive, because it's where the most consequential architectural decisions happen. There are four dominant approaches, each with real tradeoffs.
1. Raw EOA (Externally Owned Account)
The simplest model. A single private key—generated from a seed phrase—controls an Ethereum address. The key signs every transaction. Lose the key, lose everything.
Where it works: Personal wallets for crypto-native users who understand operational security. Developer testing environments.
Where it breaks: Any application where key loss is unacceptable, where multiple parties need approval, where you want to sponsor gas, or where you need to onboard users who have never heard of a seed phrase.
The raw EOA is a dead end for application-embedded wallets. It's the equivalent of asking every user of your payment app to manage their own database credentials.
2. MPC (Multi-Party Computation)
MPC splits the private key into shares distributed across multiple parties. Signatures are computed collaboratively without ever reconstructing the full key in one place. If one share is compromised, the attacker still can't sign.
Where it works: Institutional setups where you need distributed trust. Compliance-sensitive environments where no single party should have unilateral control.
Where it breaks: MPC is a signing protocol, not a wallet. It doesn't give you programmable logic, gas sponsorship, session keys, or batched transactions. It's powerful cryptography bolted onto the same EOA model underneath—which means you still have a single onchain address with no upgrade path. It also tends to be slow and expensive to operate at scale.
The theory is that MPC solves the key management problem. The reality is that it solves one specific problem (threshold signing) and introduces a different set of operational burdens.
3. Smart Contract Wallets (Account Abstraction)
Smart contract wallets—enabled by ERC-4337 and more recently EIP-7702—replace the EOA model entirely. Instead of "one key, one account," the account itself is a smart contract that can encode arbitrary authorization logic.
This is the architectural shift that matters. With a smart contract wallet, you can:
- Separate the signer from the account. The key that authorizes transactions can be swapped, rotated, or upgraded without changing the user's address.
- Use any authentication method. Passkeys, social logins, biometrics, hardware keys—any signature scheme that can be verified onchain (or via a companion verifier).
- Implement session keys. Grant temporary, scoped permissions so users don't have to sign every single transaction in a gaming session or trading workflow.
- Sponsor gas. Let the application pay for transactions through Paymasters, eliminating the need for users to hold native tokens.
- Batch transactions. Combine approve + swap, or mint + transfer, into a single operation.
- Program recovery. Social recovery, guardian-based recovery, time-locked recovery—without relying on seed phrases.
- Enforce policies onchain. Spending limits, whitelisted contracts, time-based restrictions—all enforced at the account level.
Over 40 million smart accounts have been deployed since ERC-4337 launched in March 2023, with nearly 20 million deployed in 2024 alone. With EIP-7702 (shipped in Ethereum's Pectra upgrade in May 2025), even existing EOA addresses can temporarily delegate to smart contract logic—making the migration path significantly smoother.
Where it works: Embedded wallets for consumer applications, gaming, payments, DeFi frontends, any context where users shouldn't need to understand blockchain mechanics.
Where it breaks: Smart contract wallets have a small gas overhead from executing contract logic. They require audited, battle-tested implementations—a buggy wallet contract is worse than a simple EOA. And cross-chain identity (same address on every chain) requires careful design around deployment and counterfactual addressing.
4. TEE-Based Signing (Server-Side)
Trusted Execution Environments (TEEs)—like Intel SGX, ARM TrustZone, or AWS Nitro Enclaves—provide hardware-isolated environments where key material can be generated, stored, and used without exposure to the host operating system.
TEE-based signing is increasingly relevant for server-side wallet infrastructure. The keys exist on the service provider's infrastructure, but the TEE provides cryptographic attestation that even the operator cannot extract key material.
Where it works: High-throughput backend signing for applications that need low latency—payment processors, automated trading, agent-driven workflows. Also useful for privacy-preserving architectures where you want to prove that a computation happened correctly without revealing the inputs.
Where it breaks: TEE security depends on the hardware vendor's implementation and firmware integrity. Vulnerabilities like the 2024 IBM CCA CVE serve as reminders: no hardware is invulnerable. TEEs are best used as one layer of defense, not the sole trust anchor.
Choosing an Architecture
In practice, the best wallet services combine these approaches. A smart contract wallet gives you programmable onchain logic; the signer behind it might use MPC for institutional use cases, TEE-based signing for automated operations, or passkeys for consumer onboarding. The smart wallet is the account; the signer is the authentication method. Separating these concerns is what makes a flexible wallet architecture.
At Openfort, this is exactly the model we build around. The wallet is a smart contract. The signer is pluggable—user-controlled passkeys, server-side TEE signers, or custodial key management, depending on what your application needs. Same account, different security profiles.
Security: What Matters Beyond Key Storage
Key management is necessary but not sufficient. A wallet service's security posture includes several dimensions that are easy to overlook until something goes wrong.
The Attack Surface Is Wider Than You Think
Most wallet compromises don't happen because someone cracked the cryptography. They happen because of supply chain attacks on dependencies, phishing that compromises auth flows, misconfigured access controls, or insider threats at the service provider.
When evaluating a wallet service, security questions should span:
Key lifecycle. How are keys generated? In what environment (HSM, TEE, browser, user device)? Who can access them at rest? In transit? During computation? Can they be exported? What algorithms are used?
Authentication and authorization. How are users verified before signing? Is there MFA? Are signing permissions scoped (e.g., can a session key only call specific contract functions)? What happens if a device is compromised?
Transaction integrity. Can transactions be simulated before signing to prevent blind signing? Are there pre-execution checks (KYT, sanctions screening)? Can you enforce approval workflows for high-value operations?
Audit and observability. Are all operations logged immutably? Can you reconstruct who did what, when, and through which device? Do you get webhook notifications for anomalous activity?
Recovery and continuity. If the service provider goes down, can users still access their assets? Is the wallet implementation open-source? Is there a documented export and migration path?
The Continuity Problem
This last point—provider continuity—deserves emphasis. If your wallet service disappears tomorrow, what happens to your users' assets?
For smart contract wallets, the answer can be "nothing changes." The account lives onchain. If the wallet contract supports owner rotation, users (or you) can point the account to a new signer and keep going. The assets never move; only the authentication method changes.
For MPC wallets or custodial services without export, the answer is often "it depends on whether the provider gave you a migration path." This is not a theoretical risk. Services shut down, get acquired, or pivot product lines. If your wallet infrastructure has no onchain continuity guarantee, you have a vendor lock-in problem disguised as a technology choice.
Evaluating a Wallet Service: The Criteria That Matter
Borrowing from and extending industry frameworks—including Dfns's "decemma" model—here are the ten dimensions we think matter most when selecting a wallet service. The weight you give each one depends on your use case.
1. Security
How robust is the key management? What's the attack surface? What certifications does the provider hold? How are vulnerabilities handled and disclosed?
2. Usability
How smooth is the onboarding flow? Can users create a wallet without knowing what a wallet is? What authentication methods are supported (passkeys, social login, email)?
3. Resilience
What happens during downtime? Can users still sign? Is there geographic redundancy? What's the disaster recovery plan? Can the wallet survive provider failure?
4. Programmability
Can you customize wallet behavior? Session keys, spending limits, automated actions, modular extensions? Is the wallet a dumb key or a programmable account?
5. Configurability
Can you choose your custody model? Swap signers? Adjust approval flows? Or is the architecture one-size-fits-all?
6. Manageability
What does the admin experience look like? Can you manage users, wallets, and policies at scale? Do you get dashboards, logs, and operational tooling?
7. Compliance
Does the service support KYC/AML integration? Sanctions screening? Transaction monitoring? Can keys be deployed in specific jurisdictions as regulators require?
8. Performance
What's the latency for key generation and signing? Can the service handle your transaction volume? Does it support the chains you need?
9. Interoperability
How many blockchains are supported? EVM only, or also Solana, Cosmos, Stacks? Can wallets interact with DeFi protocols, DEXs, and bridges? Is there a standard interface?
10. Cost Structure
Is pricing per wallet, per transaction, per API call, or SaaS subscription? Are there minimum commitments? Does the pricing model align with your business model, or does it eat your margins?
No service scores a 10 on all dimensions. The art is knowing which tradeoffs are acceptable for your specific application.
Use Cases: What Good Looks Like in Practice
The abstract dimensions above become concrete when you map them to real applications.
Consumer Payments
You're building a cross-border payment app. Your users don't know what a blockchain is and shouldn't need to. What matters: sub-second signing latency, gas sponsorship (users pay in fiat, not ETH), social login onboarding, and support for high-throughput L2s like Base, Polygon, or Arbitrum. Security is critical but must be invisible. The wallet is infrastructure that never surfaces in the UI.
Key priorities: Usability > Performance > Cost > Security > Interoperability.
Gaming
Players need wallets to hold in-game assets, but they'll abandon your game if "sign this transaction" appears every 30 seconds. What matters: session keys that grant scoped permissions for a play session, batched transactions for multi-step game actions, gas sponsorship, and fast onboarding via social or device-native auth.
Key priorities: Usability > Programmability > Performance > Cost > Security.
Institutional Treasury
A company holds significant digital assets across multiple chains. Multiple team members need approval authority with different permission levels. Compliance requires audit trails, transaction policies, and potentially jurisdiction-specific key storage.
Key priorities: Security > Compliance > Manageability > Resilience > Configurability.
DeFi Frontend
You're building a trading or lending interface. Users likely have existing wallets (MetaMask, Coinbase Wallet) but you also want to onboard new users without friction. What matters: compatibility with external wallets, embedded wallet option for new users, smart routing for gas efficiency.
Key priorities: Interoperability > Usability > Programmability > Performance > Security.
The Smart Wallet Thesis
If there's a single architectural trend worth understanding in 2025, it's the migration from EOAs to smart contract wallets. This isn't ideology—it's pragmatics.
EOAs are static. They can't be upgraded, can't enforce policies, can't sponsor gas, can't batch transactions, and can't recover without the original seed phrase. Every user-facing improvement you want—better onboarding, invisible gas, session-based permissions—has to be bolted on externally, usually through centralized infrastructure that partially defeats the purpose.
Smart contract wallets make the account itself programmable. The signer can be anything: a passkey, an MPC share, a TEE enclave, a hardware key, or a social recovery guardian. The account logic can enforce spending limits, require multi-party approval, or delegate specific actions to session keys—all onchain, all auditable, all upgradeable.
This is why Openfort builds on smart wallets as the foundation. Not because they're newer, but because they're the only architecture that lets you offer a consumer-grade experience without sacrificing the properties that make onchain infrastructure worth using: verifiability, composability, and user sovereignty over their assets.
The signer is a detail. The account is the product.
What Comes Next
The wallet space is evolving fast. A few trends worth watching:
EIP-7702 and the EOA migration path. With Pectra live, existing EOA addresses can temporarily delegate to smart contract logic. This lowers the barrier for existing users and wallets to adopt smart account features without migrating to new addresses.
Chain abstraction. Users shouldn't care which chain their assets are on. Wallet services that can abstract chain selection—routing transactions to the cheapest or fastest chain automatically—will win on UX.
Agentic wallets. As AI agents start performing onchain actions on behalf of users, the wallet becomes the policy boundary. Session keys, spending limits, and scoped permissions become essential—not for human UX, but for constraining automated agents.
Regulatory convergence. Jurisdictions are converging on the idea that custody is defined by legal agreements, not by where a key physically sits. This is good news for flexible architectures. It means you can optimize for security and usability without getting locked into a single custody classification.
Conclusion
The custodial vs. non-custodial debate was a useful starting point, but it's past its expiration date. The real questions are about key management quality, programmability, recovery guarantees, and operational fitness for your specific use case.
A wallet is not a key. It's an infrastructure stack. The best wallet service is the one that lets you compose the right security model, the right onboarding flow, and the right transaction policies for your application—without painting you into an architectural corner.
It turns out that the most powerful custody model isn't the most self-sovereign one or the most delegated one. It's the most flexible one. One where the account is programmable, the signer is pluggable, and the tradeoffs are yours to make.
That's what we're building at Openfort.
Related Reading
- How embedded wallets abstract away private key management for a seamless player experience
- Understanding session keys and how they remove the need for players to sign every transaction
- A practical comparison of account abstraction and MPC approaches to wallet security
- TEE wallets and server-side signing architecture