Every application that touches a blockchain needs somewhere for keys to live and something to sign with them. The set of software that handles this is wallet infrastructure, and how you choose it determines your security posture, your regulatory obligations, and roughly how much of the next year your engineers spend on plumbing.
This guide covers what the category includes, how the layers fit together, and the criteria that separate providers once you get past the marketing pages.
What wallet infrastructure is
Wallet infrastructure is the software that creates, secures, and signs with blockchain accounts on behalf of an application's users. It spans four layers: key management, the account model, transaction execution, and the developer surface. Teams buy it rather than build it because the key management layer has no forgiving failure mode. A lost key is not a bug you patch.
The four layers
Most vendor confusion comes from providers competing at different layers while using the same vocabulary. Naming the layers makes shortlists easier.
1. Key management. Where private keys are generated, stored, and used. The main approaches are multi-party computation, which splits a key into shares held by different parties; trusted execution environments, which run signing inside hardware-isolated enclaves; Shamir's Secret Sharing, which splits a key into recoverable shards; and hardware security modules. See our breakdown of key management options for how these compare in practice.
2. Account model. What the on-chain account actually is. An externally owned account is a plain keypair. A smart account is a contract that can enforce rules, batch operations, and pay for gas in tokens. ERC-4337 introduced smart accounts as a separate contract, and EIP-7702 lets an existing EOA temporarily take on contract behaviour. Read the EIP-7702 explainer if this is new.
3. Transaction execution. Getting a signed transaction on-chain: gas estimation, nonce handling, retries, bundlers, and gas sponsorship so users are not blocked by a token they do not hold. Underrated and where most production incidents come from.
4. Developer surface. SDKs, authentication, recovery flows, session management, and the server-side wallets that let your backend act without a human signing each time.
A provider strong at layer one can be weak at layer three. Score them separately.
Custodial or non-custodial
Decide this before comparing features, because it changes which regulations apply to you.
Custodial: the provider can move user funds without the user. Simpler support and recovery, and in many jurisdictions it makes you or your provider a regulated custodian.
Non-custodial: the provider cannot move funds alone, because signing authority is split or held by the user. Lighter regulatory exposure, harder recovery, and the model most consumer applications choose. Our post on self-custody covers the trade-offs.
The line is blurrier than vendors suggest. Ask a specific question instead of accepting the label: if your company received a court order tomorrow, could you move a user's funds? The answer tells you which model you are actually operating.
Build versus buy
Building your own is defensible when key management is your product or a regulator requires a specific deployment. Otherwise the arithmetic rarely works.
What building actually means: hardware-isolated signing, a recovery path that survives a user losing their device, an audited cryptographic implementation, key rotation, 24/7 on-call for a system where downtime means users cannot move money, and an incident plan for a compromise you may not detect immediately. None of it scales down. A hundred users need the same security posture as a million.
Teams that build usually rebuild what a provider already ships, six months later, while carrying the liability themselves. The honest exception is when a provider cannot meet a deployment constraint you cannot negotiate away, which is why self-hostable signers exist. We wrote about avoiding vendor dependency if that is your concern.
Evaluation criteria
Ten questions that separate providers once the demos are over.
| Criterion | What to ask |
|---|---|
| Key management model | MPC, TEE, SSS, or HSM, and can you audit the implementation? |
| Self-hosting | Can you run the signer yourself, and is the code available? |
| Key export | Can you export keys and migrate? Get the process in writing. |
| Account model | Native smart account support, or a third-party integration in the path? |
| Auth flexibility | Can you bring your own OIDC provider, or must you use theirs? |
| Signing latency | Median and p99 under load, not the marketing number. |
| Gas sponsorship | Included, or a separate vendor and contract? |
| Server-side signing | Can your backend sign without a user present, and under what policy controls? |
| Pricing unit | Per user, per signature, or custom? Model your own numbers. |
| Certifications | SOC 2 Type II, ISO 27001, published penetration tests. |
Two of these deserve emphasis. Key export is the only question whose answer tells you what your leverage looks like in three years. Pricing unit is where teams get surprised, because per-user pricing punishes dormant wallets and per-signature pricing punishes automation, and most applications are lopsided in one direction.
How the market is arranged
The category consolidated fast. Stripe acquired Privy in June 2025. Fireblocks acquired Dynamic in October 2025. MetaMask absorbed Web3Auth, and Polygon Labs took Sequence. What was a field of independent vendors is now mostly a set of components inside larger payment and custody platforms.
That has two consequences worth planning around. Bundled providers ship faster because the pieces are already integrated. Independent providers are less likely to have their roadmap set by a parent company's strategy. Neither is automatically right, but "who owns this vendor in three years" is now a real line item in the evaluation.
For where specific providers land, see the wallet-as-a-service comparison and the embedded wallet roundup.
When you do not need this
Some applications do not need wallet infrastructure at all, and vendors will not tell you that.
If users bring their own wallet and you only need to read balances or request signatures, a connection library is enough. If you are minting to addresses users already control, you need a signer for your own account and nothing more. If you are running a single treasury account with a handful of operators, a multisig with hardware wallets is simpler, cheaper, and better understood than anything on this page.
Wallet infrastructure earns its cost when you are creating and operating accounts on behalf of many users who should not have to think about keys.
Where Openfort fits
We build in this category, so read the following as interested. Openfort covers all four layers: OpenSigner as an open-source, self-hostable signer, native ERC-4337 and EIP-7702 smart accounts, built-in paymasters and session keys, backend wallets in TEEs for server-side automation, and support for any OIDC provider you already run. Pricing is per operation, where an operation is creating a wallet or sending a transaction.
The evaluation criteria above are the ones we would want a buyer to apply to us.
Start here
Answer three questions in order and the shortlist writes itself: custodial or non-custodial, do you need smart accounts, and what does your real ratio of wallets to monthly signatures look like. Then price the shortlist on your own numbers rather than the published tier.