01 · What a wallet is now · The wallet workspace

A wallet is not a place to keep money any more

It is the account layer of a financial product — identity, balance, permissions and history in one object, with other people’s software increasingly acting inside it. Almost every hard decision that follows is a product decision with a regulatory consequence, and only one of them is cryptographic.

4 stagesfrom wallet to programmable app
31 featuresand a handful change your licence
4 audiencesone account model has to serve
1 questiondecides most of the rest — who can sign
What it actually is now
Four expensive surprises
How to use this workspace
Where these numbers come from

Ten years ago a wallet held a key and showed a balance. The products being funded and shipped in 2026 are something else, and the gap between the two definitions is where most planning goes wrong — teams budget for a keychain and are asked to deliver an account.

Account

It is the account, not the vault

For a growing share of products the wallet is the user record: identity, balance, history and permissions in one object. Storage is the least interesting thing it does.

Distribution

It is a distribution channel

Whoever owns the wallet owns the surface where the next product is launched. This is why exchanges, banks, messengers and card issuers all built one, and why several of them bought their way in rather than waiting.

Rails

It is where money changes form

Bank transfer becomes a stable balance, a balance becomes a card authorisation, a card authorisation becomes a settlement. The wallet is the junction, and each conversion has its own provider, its own licence and its own failure mode.

Policy

It is a policy engine wearing a consumer interface

Limits, allow-lists, approvals, delegated permissions, expiry. In a consumer product these hide behind a button; in a business product they are the product.

Programmable

It is programmable, and increasingly not by a human

Scoped, time-boxed, revocable permissions let an application — or an autonomous agent — act within limits its owner set. The specifications for this are still drafts, which is precisely why the design decisions matter now.

The practical consequence

Because a wallet is now an account, the interesting questions stopped being cryptographic. They are product questions with regulatory consequences: what can a user do here, who else can act on their behalf, whose money is it while it sits, and what happens when someone loses their phone. The next section makes those choices explicit — switch on capabilities and watch the product change category underneath you.

Surprise 01

The cryptography is not what fails

In the largest losses on record the signatures were genuine, the threshold was met, and the allow-list was respected. What was compromised was the screen the signers were reading. Multisig has never failed in the way people budget for; interfaces fail constantly, and almost nobody funds that.

Surprise 02

“Non-custodial” is usually a promise, not an impossibility

Of the embedded wallet vendors we examined, only a handful are cryptographically unable to sign without the user. The rest are contractually unwilling. Regulators wrote their test around the first property, and were explicit that a contractual obligation does not change the answer.

Surprise 03

Your curve does not fit in the chip

The curve securing most of this industry cannot be signed inside an Apple Secure Enclave, a TPM, Azure Key Vault or AWS CloudHSM. A multichain wallet needs five signing modes; the major cloud key services cover two, and one of the five is offered by nobody.

Surprise 04

The wallet is not the expensive part

On a realistic first year the wallet licence is well under a fifth of the bill. Identity verification of the same cohort costs more. Sponsored gas — the line everyone worries about — totals a rounding error across the entire industry to date.

The one question worth asking any vendor

Not “is it non-custodial”. Ask: if your company stopped existing tomorrow, what exactly does my user do to move their funds — and can you show me the artefact that makes it possible? Four answers exist in this market. Everything else is a promise about behaviour.

If you are choosing an architecture

Start with Key topology, then run the Custody line classifier. Those two sections decide your licence, your cost base and your recovery story before a single line of code exists.

If you already have a wallet

Go to Anatomy of one signature and break the steps. If your product cannot survive the failures listed there, the gap is in the display layer, not in the key management.

If you are buying

Vendor landscape and Cost and build-vs-buy. The exit test matters more than the feature list: the questions there are the ones vendors answer slowly.

If you are adding chains

Multichain reality. Cost scales with curve groups, not with logos on a slide. Ten rollups are one integration; three unusual chains are three backends.

If you are writing a specification

Standards board. Check the status badge before citing anything. Several of the most-quoted “standards” in this field are abandoned, still draft, or were never standards at all.

If you want to see our work

What we have built, at the end. It is deliberately last: the argument on this page should stand whether or not you ever hire anyone.

Every claim here traces to a primary source: a specification with a status field, a vendor’s own pricing or documentation page, a regulator’s published text, a forensic report, or a filing. Where a number is our arithmetic on published rates, the page says so. Where the industry publishes nothing — onboarding conversion, support ticket volume, transaction-monitoring pricing — the page says that too, because the absence is itself informative.

Three things we will not do here. We will not quote a figure whose source we could not open. We will not present a vendor’s marketing claim as a capability. And we will not recommend a rail that has been wound down — several once-prominent wallet and custody products in this space are no longer maintained, and proposing them in 2026 would say more about the proposer than about the product.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

02 · From wallet to app · Interactive

A wallet stops being a wallet quite quickly

Switch on what your product needs. The panel tracks what it has become, what your users can now do, roughly how much engineering that is, how long it takes in calendar months, and where a licence appears. Core capabilities are locked because nothing works without them.

Wallet MVP
Consumer financial app
Neobank with cards
Business platform
Programmable and agentic
Everything

Wallet
Hold, send, receive. A user can custody value and move it.
Financial app
Money enters and leaves in the user’s own currency, and the balance does something while it sits there.
Platform
Other people’s money, other people’s rules: multiple users, approvals, roles, reporting.
Programmable app
Third parties and agents act inside the account under permissions the owner granted and can revoke.
Foundations
Everything below assumes these exist.
Key management and signing
120–220h
Wallet creation, signing, the recovery model, and the failure paths around all three.
what this involves →
core
Onboarding without a seed phrase
90–170h
Passkey or social sign-in, device binding, and the second-device path. This is the single biggest lever on conversion.
what this involves →
core
Send and receive
110–200h
Address handling, fee estimation, retries, idempotency, and the confirmation model.
what this involves →
core
Balances and history
130–240h
Indexing, enrichment, caching, and human-readable transaction history. Consistently underestimated.
what this involves →
core
Transaction preview and simulation
90–160h
Simulate before signing and render the payload independently of the interface that produced it. The countermeasure to the losses that actually happen.
what this involves →
recommended
Recovery and guardians
120–230h
Guardian quorum, delay window, notification, and the abuse cases. Do not ship a recovery path without a delay.
→ needs: Key management and signing
what this involves →
recommended
Money in and out
The moment a bank is involved, the product changes category.
Fiat on-ramp
100–190h
Card or bank funding through a licensed provider, plus the reconciliation nobody demos.
what this involves →
recommended
Fiat off-ramp
110–200h
Withdrawal to a bank account, with the payout states and the failure handling.
→ needs: Fiat on-ramp
what this involves →
recommended
Named accounts and IBANs
90–170h
A virtual account per user so incoming transfers reconcile themselves.
→ needs: Fiat on-ramp
what this involves →
optional
Card issuing
180–340h
Virtual cards, authorisation flow, settlement, disputes. The banking-sponsor timeline is the long pole and it is identical on every route.
→ needs: Fiat off-ramp
what this involves →
optional
Assets and networks
What the user can hold, and where.
Additional networks
140–300h
Per curve group, not per logo. A second EVM network is configuration; a second curve is a backend.
→ needs: Key management and signing
what this involves →
recommended
Token support and metadata
70–130h
Lists, prices, decimals, spam filtering, and the tokens whose issuer can freeze them.
what this involves →
recommended
Tokenised and permissioned assets
160–300h
Transfer restrictions enforced on-chain, eligibility checks, corporate actions. A different product from a token list.
→ needs: Token support and metadata
what this involves →
optional
Collectibles and passes
60–120h
Media handling, ownership display, and the access-control use case that is usually the real reason.
→ needs: Token support and metadata
what this involves →
optional
Make the balance work
The difference between a wallet and a financial product.
Swap and routing
110–210h
Quotes, slippage, failure states, and a fee model you can defend.
what this involves →
recommended
Earn and staking
140–260h
Positions, accrual, exit liquidity, and the disclosure. Note that offering this on the user’s behalf is treated as custody in several regimes.
→ needs: Swap and routing
what this involves →
optional
Investment products
170–320h
Tokenised funds, equities or commodities, with the eligibility and reporting they carry.
→ needs: Earn and staking
what this involves →
optional
Spending and payments
Where consumer wallets earn their keep.
Usernames and address book
60–120h
Human-readable recipients over raw addresses. Addresses remain the single largest source of user error.
→ needs: Send and receive
what this involves →
recommended
Pay a merchant
130–250h
QR or link, settlement to the merchant, refunds, and the reconciliation on both sides.
→ needs: Send and receive
what this involves →
optional
Recurring and scheduled payments
110–200h
Standing authority with limits and revocation — which is a permissions problem, not a scheduler problem.
→ needs: Send and receive
what this involves →
optional
Multi-user and business
The step from consumer app to platform.
Organisations, roles and approvals
190–350h
More than one human on one account: roles, quorums, four-eyes, delegation and an audit trail.
what this involves →
optional
Policy engine
160–300h
Limits, allow-lists, time windows, counterparty and calldata scoping. Enforcement on-chain is a different build from enforcement in a service.
→ needs: Organisations, roles and approvals
what this involves →
optional
Back office and operations
170–320h
Support tooling, reconciliation, manual interventions with dual control, and the general ledger.
what this involves →
optional
Statements and reporting
110–210h
Statements, exports, tax artefacts, and accounting integration.
→ needs: Back office and operations
what this involves →
optional
Programmable and agentic
Delegated authority, with limits.
Delegated permissions and session keys
140–260h
Scoped, time-boxed, revocable authority. The relevant specifications standardise expiry and little else, so the limits are yours to design.
→ needs: Key management and signing
what this involves →
optional
Agent-initiated transactions
180–330h
An agent proposes, a human or a policy approves, and the system simulates before anything is signed. The agent must never hold the signing authority.
→ needs: Transaction preview and simulation · Delegated permissions and session keys
what this involves →
optional
Connect to third-party apps
90–170h
Session negotiation, capability discovery and permission prompts a user can actually read.
what this involves →
optional
Compliance and trust
Not optional once real money moves.
Identity verification
110–210h
Tiered verification, re-verification, and the paths for people the first attempt rejects. Priced per person, and usually the largest single line in year one.
what this involves →
recommended
Screening and monitoring
100–190h
Counterparty screening before credit, plus case management for what it flags.
→ needs: Identity verification
what this involves →
optional
Travel-rule messaging
120–230h
Counterparty data exchange between providers, plus proof of control for self-hosted addresses — without which your users cannot withdraw above the threshold from any EU provider.
→ needs: Screening and monitoring
what this involves →
optional
Audit trail and evidence
90–170h
An append-only record that survives a supervisor, an auditor and a court, in that order.
what this involves →
recommended

Why this is in hours and months, and not in money

Effort is a property of the work; price is a property of a negotiation. Published day rates in this market differ by more than the scope usually does, so a number on a public page would tell you about our rate card rather than about your product. What is portable between vendors is the shape: which capabilities carry real engineering weight, which ones drag a licence behind them, and which ones look small on a roadmap and are not.

Two things the configurator makes visible. First, the crossings: several features move the product into a different regulatory category, and the panel names the moment it happens rather than leaving it in a footnote. Second, the dependencies: a feature you switch on quietly brings others with it, and the ones that look cheapest in isolation — history, reconciliation, recovery — are the ones that carry the most hidden weight.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

03 · How value moves · Interactive

Transaction topology across the integration layer

Two views of the same product. The board shows value crossing counterparties on every ordinary action; the walkthrough shows what the person on the other end actually sees.

Value flow
User walkthrough

Reference scenarios run concurrently, because in production they do. Click a chip to switch one off and watch what stops moving.

Scenarios · click to toggle
S1Top up from a bank
S2Send to a person
S3Swap one asset for another
S4Earn on an idle balance
S5Spend on a card
S6Withdraw to a bank
S7Agent acts within limits
S8Two approvals, one payment

Count the crossings, not the features

Every ordinary action on this board leaves your systems at least twice and comes back. A top-up touches four parties before a balance appears on a screen, and the shortest path here — sending money to a person — still runs through three of your own components plus the network. Each dashed box is a counterparty with its own authentication, schema, rate limits and incident channel; the lines between them are the reconciliation nobody demos.

Use this as a procurement question. Ask any bidder to draw this board for your product and mark which boxes they own, which they rent and which they have never integrated. The teams that have shipped a wallet before will draw it from memory. The rest will describe the happy path of one scenario and stop.

The same product from the outside: four audiences, step by step. It plays on its own — pause it, step through it, or click any step.

Never held a token
Already active on-chain
A company on one account
An agent acting for its owner

The majority of any consumer wallet’s base, and the hardest to keep.

Small in number, loud in feedback, and the reason your support queue exists.

Where the product stops being a wallet and becomes a platform.

The newest pattern, and the one with the least standardisation behind it.

Four audiences, one account model — and that is the hard part

The same account has to serve a person who has never held a token, a person who reads calldata, a company with an approval quorum, and a piece of software acting under delegated authority. Products usually fail at the second audience they add, not the first, because the account model was designed for one of them and the rest are retrofitted into it.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

04 · Reference architecture · Interactive

What is actually in the box

Five layers, and a clear line between what you build and what you rent. Every block opens.

Solid red border — you build it Dashed — rented from a vendor Black — the classification boundary Green — outside anyone’s control

Click any block for what it does, what it is built from, what it assumes and how it fails.

The three boxes you cannot buy

Vendors cover chain access, indexing, money rails and identity — four boxes, and the cheapest four. Application logic, the transaction service and reconciliation are yours in every architecture, and together they are most of the build. The transaction service in particular has no vendor, no standard and no glory: nonce management, fee estimation, retries, idempotency and reorg handling. It is the layer that decides whether your wallet loses money quietly under load.

Read this as a contract map, not a component map. Each dashed box is a counterparty with its own authentication model, schema, rate limits, incident channel and commercial terms. Five vendors is not five integrations — it is five of everything, plus the reconciliation between them, and that glue is the most defensible thing an engineering partner does here.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

05 · Key topology · Interactive

Eight ways to hold a key, and what each one costs you

Pick a topology on the left. The panel answers the four questions that actually matter: who can sign without the user, what happens when the vendor disappears, what happens when the device is lost, and which side of the regulatory line it puts you on.

Seed-based EOABIP-32/39/44, one private key
Smart account (ERC-4337)Contract account, modular validation
EIP-7702 delegated EOAAn EOA that behaves like a contract
MPC / TSS, 2-of-2One share on the device, one with the provider
MPC / TSS, 2-of-3 with independent backupDevice, provider, and a share you hold
Synced passkeyWebAuthn credential in the platform keychain
On-chain multisigM-of-N, enforced by a contract
CustodialThe provider holds the key
Read the verdict column as a starting position, not a conclusion. The same topology lands on different sides of the line depending on one implementation detail — who sits in the recovery quorum. That detail is usually decided by an engineer in week three and discovered by a lawyer in month nine.

Secret sharing is not threshold signing, and the difference is the whole point

Shamir secret sharing reassembles the key in order to sign with it. Threshold signing never reassembles it at all. Several products describe the first as if it were the second. The test is simple and worth putting in writing to a vendor: at the moment of signature, does the complete private key exist anywhere, even briefly, even inside an enclave? If the answer is yes, you have secret sharing with good operational hygiene — which may be perfectly acceptable, but it is not what the marketing says.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

06 · Custody line · Interactive

Are you a custodian? Eight questions decide it

Regulators do not ask what your architecture diagram says. They ask whether you can move the asset. Answer honestly — the point is to find the answer before a supervisor does.

The test
Where the line is drawn
1. Can any process you operate produce a valid signature without the user participating?
Not “would you”. Could you — today, with the code as deployed.
Yes
No
We are not sure
Why it matters — MiCA Art. 3(1)(17) defines custody as safekeeping or controlling crypto-assets or the means of access. The conjunction is disjunctive: controlling the means of access is enough.
2. Do you hold a share, factor or credential that is part of a quorum you could complete on your own?
Two-of-three where you hold two, or two-of-two where the second party is your own subsidiary.
Yes
No
Only with a partner’s cooperation
Why it matters — The US position is explicit: total independent control counts even where the provider is contractually obliged to act only on the owner’s instruction.
3. Can your support team restore a user’s access without the user’s original factor?
A “forgot password” path that actually works is a control path.
Yes
No — loss is final
Only unlock, never re-key
Why it matters — If support can un-brick a user, you control the means of access. The 2025 breach that cost a major exchange a nine-figure sum went through bribed support agents, not through cryptography.
4. Do you route, match or execute the user’s exchange on your own book or through a venue you choose?
A swap widget that quotes from your own inventory is not the same as one that hands off to a public router.
Yes
No, the user picks and signs
Why it matters — Exchange and order routing are separately enumerated services under MiCA. They do not require custody to be regulated.
5. Do you offer “send” as a service you perform, rather than a transaction the user signs?
Including scheduled, sponsored or agent-initiated transfers.
Yes
No
Why it matters — European supervisors treat transfer services as a service in their own right, distinct from custody.
6. Do you stake, lend or otherwise deploy user assets on their behalf?
Including “auto-earn” defaults and idle-balance yield.
Yes
No
Why it matters — Staking-as-a-service is treated as custody, and slashing attributable to the provider is the provider’s liability.
7. Are your users in the EEA, and are you established outside it?
Reverse solicitation is narrower than most product teams assume.
Yes
No
Mixed
Why it matters — The MiCA transitional period ended on 1 July 2026. Supervisors have extended the prohibition on serving EU clients from abroad to business-to-business arrangements, and prohibit delegating custody to entities that are not themselves authorised.
8. Does a push notification, campaign or in-app prompt bring the user back to transact?
This is a marketing question with a licensing answer.
Yes
No
Why it matters — Active solicitation destroys any reverse-solicitation argument. It is the cheapest way to lose an exemption you were relying on.

This is an orientation tool built from published regulatory text, not legal advice, and it does not know your facts. Its job is to tell you which conversation to have and which article to bring to it.

Four regimes, one test. The wording differs; the question does not.

European Union
United States
Switzerland
Asia-Pacific and the Gulf
WhatWhereWhat it says
MiCA custody definitionArt. 3(1)(17)Safekeeping or controlling crypto-assets or the means of access. Disjunctive by design.
Custodian duties and liabilityArt. 75Segregation, and liability toward the client for loss — capped at market value at the time of loss, with the burden of proof on the custodian.
Who may be a CASPArt. 59Authorised legal persons only. A third-country entity cannot serve EU clients from outside the Union.
Credit institutionsArt. 60A bank does not need a separate CASP licence — it notifies, 40 working days ahead, with six documents. Art. 75 still applies.
Transitional periodArt. 143Ended 1 July 2026, EU-wide, whether or not a member state finished implementing.
Travel ruleReg. 2023/1113No lower threshold for crypto transfers. The €1,000 figure applies to verifying control of a self-hosted address, not to the transfer itself.
Proof of controlEBA/GL/2024/11 §83Five accepted methods, including a signed message and the satoshi test. §86 is the commercially useful one: after successful verification, the same address need not be re-verified on every subsequent transfer.
WhatWhereWhat it says
Balance-sheet treatmentSAB 121 → SAB 122The gross-up requirement that made custody punitive for banks was rescinded on 23 January 2025. This, more than any crypto policy, is why bank custody restarted.
National banksOCC IL 1183, IL 1184Supervisory non-objection removed; execution on customer instruction and use of sub-custodians permitted.
Federal ReserveProgramme withdrawalAdvance-notification expectation withdrawn April 2025; the novel activities supervision programme closed August 2025.
Money transmissionFinCEN FIN-2019-G001“Total independent control” is the test, even where the provider is contractually obliged to act only on instruction.
New YorkNYDFS Part 200.9Custody guidance updated 30 September 2025, adding sub-custody with prior approval. Cite the 2025 version, not the 2023 one.
Adviser custodySafeguarding RuleThe proposed rule was withdrawn in June 2025. There is currently no crypto-specific safeguarding rulemaking in force.
Stablecoin issuersGENIUS ActFederal framework for payment stablecoin issuance and reserve custody.
WhatWhereWhat it says
Ledger-based securitiesDLT ActA registered uncertificated security can be transferred on a ledger with legal effect — the reason token issuance is domiciled here.
Bankruptcy remotenessArt. 242a SchKGSegregated crypto-assets can be separated from a bankrupt custodian’s estate. This is the substantive Swiss advantage, and it is a bankruptcy provision, not a marketing one.
Deposit-taking thresholdBankG Art. 1a/1b with BankVWhether holding client crypto is deposit-taking depends on the accounting architecture. FINMA published a three-part matrix mapping architecture to licence tier in January 2026.
AMLAMLA / GwGCustody makes you a financial intermediary: SRO membership or a licence.
Token classificationFINMA ICO guidancePayment, utility or asset token — and an asset token is a security. Pre-financing a future deliverable points to the third box.
WhatWhereWhat it says
SingaporePSA, First ScheduleThe trigger is written as “where the service provider has control” — the same test again, in different words.
Hong KongSFC VATP regimeCustody requirements are specified for licensed platforms, including cold-storage ratios.
United Arab EmiratesVARA; ADGM FSRATwo separate regimes in one country. Licence numbers are published and worth checking rather than accepting.
JapanFSA, post-incident regimeSegregation obligations tightened after two of the largest exchange losses in the industry’s history. Some custodians hold a mirror reserve in the same asset instead of insurance.
United KingdomFCA cryptoasset regimeThe statutory instrument was made in February 2026 and the policy statements finalised in June 2026, but the regime commences in October 2027. The nearest deadline is the application window, not the regime.
The convergence is the finding. European, American and Singaporean texts arrive at the same trigger through different drafting: control over the asset or over the means of access. No jurisdiction asks which cryptographic scheme you used, because all of them were written to be technology-neutral on purpose.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

07 · Anatomy of one signature · Interactive

One signature, seven steps — and the one that breaks

This is the whole product, end to end. The failures that cost the most money in this industry all land in the same two steps, and neither of them is the cryptography.

Seven steps. Toggle a real-world failure and watch which steps it lands on.

Blind signing
Compromised interface
Drainer or malicious approval
Supply-chain compromise
Weak key generation

Ask any wallet vendor to walk you through step three

Steps one, two, six and seven are engineering. Steps four and five are hardware. Step three is the entire security model of a consumer wallet, and it is the step every vendor demo skips, because it is the one that cannot be made to look impressive. If a vendor cannot show you how their signer renders a payload independently of the interface that produced it, they have not solved the problem that has caused the largest losses in this industry.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

08 · Vendor landscape · 2026

What you can rent, and what it honestly covers

Two markets sit under one word. Below: who can sign without your user, what happens when the vendor disappears, and the ten questions worth sending in writing before anyone talks about price.

Embedded / wallet-as-a-service
Institutional custody
The exit test
What “insured” means
VendorKey modelVendor outageExit artefactWatch-out
Privy
Stripe
Two shares, both inside the provider perimeterdependsKey export availableBoth shares sit within one operator’s boundary. Contractual SLA is 99% — roughly seven hours a month.
Dynamic
Fireblocks
TSS-MPC, user share on devicesurvivesOpen-source offline recovery toolOne of the few with a documented path that survives the vendor. Billing counts a wallet from the moment it is pre-generated, so pre-generating for your whole base bills your whole base.
Turnkey
Independent
Key reconstructed inside a secure enclavedependsExport availableThis is not MPC, despite being widely described as such: the whole key exists inside the enclave at signing time.
Para
Independent
Two-of-two, share on devicesurvivesBackup Kit issued to youNo native gas sponsorship, so a paymaster is a second vendor and a second line item.
Portal
Monad Foundation
Parallel two-of-two, four shardssurvivesBackup shards on your infrastructureVendor and organisation shards sit in different pairs and cannot collude. Billing counts backups and recoveries as events.
MetaMask Embedded
Consensys
Shamir on self-serve tiers; TSS only on enterprisedependsReconstructed client-sideOn every self-serve tier this is secret sharing, not threshold signing. The key is reassembled on the client.
Magic
Kraken/Payward (WaaS assets)
Delegated key managementdependsNot documentedNo offline recovery path. If the service ends, the wallets do not come back. Liability in the terms is capped at a nominal amount.
Circle
Circle
MPC, optionally self-hosted nodesdependsDepends on deploymentSelf-hosted nodes are the only route to a jurisdictional guarantee. Pricing is not published.
Coinbase CDP
Coinbase
Enclave-backed, policy-gateddependsNot documentedBilling counts policy evaluations, not only signatures. Which Coinbase entity contracts is worth establishing before assuming any licence applies to you.
Openfort
Independent
Configurable; self-hosted signer availablesurvivesSelf-hosted OpenSigner is open sourceSelf-hosting is the only way anyone in this table offers data residency you can point at.
thirdweb
Independent
Delegated, enclave-backeddependsExport availableCheapest at scale on published rates — by a wide margin, which is itself a reason to read the terms carefully.
Tether WDK
Tether
You run it — it is a toolkit, not a servicesurvivesYours by constructionApache-2.0 and genuinely open. But the indexer is a hosted Tether service: not self-hostable, no published SLA, coverage concentrated on its own assets, new chains requested through a form. No RPC, auth, recovery or compliance layer. Build the read layer yourself from day one.
survives the vendor disappearing, with a documented artefact depends on configuration or is undocumented
Data residency is the question nobody in this table answers contractually. None of these vendors publishes a commitment on where key material lives. The only routes to a jurisdictional answer are architectural: a self-hosted signer, self-hosted nodes, an on-premise deployment, or your own stack.
ProviderWhat it actually isTechnologyWatch-out
FireblocksTechnology providerMPC-CMP with enclave isolationPublished entry pricing exists; the meaningful number is basis points on outbound volume, which makes it unit economics rather than an IT line.
BitGoQualified custodian (US trust charters)Classic 2-of-3 multisig, not MPCThe most common misconception in the category. Insurance is a shared crime policy, not a per-client limit.
Anchorage DigitalUS national trust bankHSM at FIPS 140-2 Level 3 with custom logic in hardwareDeliberately rejected MPC. The only federally chartered crypto bank in the US.
TaurusTechnology provider (Swiss)Open-sourced MPC-CMPPublicly argues an HSM is required with or without MPC — a rare case of a vendor arguing against the simpler version of its own product.
Zodia CustodyFCA and CBI registeredHSM-basedBeing absorbed by its bank shareholder, with the platform split into a separate entity. Any statement about ownership needs a date attached.
SygnumSwiss bank (FINMA)Bank-grade key ceremonyHolds a banking licence but reports under ISAE 3402 rather than SOC 2 — a procurement checklist that demands SOC 2 Type II mechanically excludes Swiss banks.
GK8 (Galaxy)Technology providerAir-gapped signing, no inbound connectionThe only vendor found publishing a per-client, per-vault insurance limit rather than an aggregate one.
Ledger EnterpriseTechnology providerSecure-element basedConsumer brand and enterprise product share a name and very little else.
CoboTechnology providerMPC with a policy engineDocuments its own degradation by chain: on some networks policy granularity drops to programme level or to initiators only.
UtilaTechnology providerMPCGas station alerts rather than refuels, and sweeps can sit in an approval queue — automatic sweeping and a manual quorum are not compatible.
DFNSTechnology providerMPC, on-premise optionOne of the few offering an on-premise deployment, which is the practical answer to data residency.
SafeNot a custodian — self-custodial infrastructureOn-chain multisig with modulesThe transaction service moved from MIT to a source-available licence in February 2026 and the hosted API became paid. Any evaluation older than that is stale on this point.
The word “custody” is doing too much work here. This table mixes chartered custodians, licensed technology providers, settlement networks and self-custodial infrastructure. They are not substitutes, they are not priced the same way, and comparing them in one column is the most common procurement error in the category.

Ten questions. Send them in writing, before the commercial conversation, and note which ones come back slowly.

01 · Can the user export a usable private key?

On every tier, not only enterprise. “Export” that requires your service to be online is not an exit.

02 · Show me the offline recovery artefact

Not the documentation page — the artefact. Ask for the tool, run it in a sandbox, and confirm it works with your service disabled.

03 · At signing time, does the full key exist anywhere?

Including inside an enclave, including for microseconds. This single question separates threshold signing from secret sharing.

04 · Who is in the recovery quorum, by name?

If your company or a subsidiary can complete a quorum, you are inside a regulated definition regardless of the label.

05 · Where does key material physically sit today?

Which region, which provider, under which contract. Then ask whether you can pin it, and get the answer in the agreement rather than in an email.

06 · What exactly does your billing count?

Monthly actives, signatures, policy evaluations, balance reads, backups, or wallets created in someone else’s product. These are not comparable, and the spread across this market is a factor of thirty-two on identical usage.

07 · Give me the enterprise rate now, not later

Within a single vendor, list and negotiated pricing differ by up to thirty times. A conversation is cheaper than a migration.

08 · What is the contractual availability figure?

One major vendor commits to 99% — roughly seven hours of downtime a month, by agreement. For a wallet, that number belongs in the incident plan.

09 · Which legal entity contracts, and what is it licensed for?

Group brand and contracting entity are frequently different. Never assume a parent’s authorisation extends to the product you are buying.

10 · What is your migration story to a competitor?

There is no standard for exporting threshold shares. In practice migration means every user takes an action — so ask what fraction of users the vendor has seen complete one.

Ownership changes faster than documentation

Ten vendors in this category changed hands in roughly two years, and several now share a corporate parent with a vendor elsewhere in the same stack. Concentration risk is no longer theoretical: it is possible to pick three “independent” suppliers and end up with one counterparty. Any statement about who owns your vendor needs a date attached to it.

Who is covered

The policy insures the custodian, not you

Limits are aggregate across all clients, not per client. One provider publishes pro-rata sharing between affected customers in the event of a claim. Another commits only to endeavour to make customers whole. Exactly one publishes a per-client, per-vault limit.

What is excluded

Read the exclusions before quoting the number

Insider collusion involving officers is frequently excluded. So is protocol failure. And at least one custodian’s agreement excludes losses arising from the client’s own instructions or authorisations — which means a mistake in your policy configuration is uninsured by construction.

The record

No large payout in this category is publicly documented

The three largest custodial losses on record were all made good from company funds, not from a policy. The largest facility publicly reported in this market is smaller than a single one of those losses.

Proof of reserves

An attestation is not an audit

The US audit regulator has stated plainly that these engagements are not audits and do not provide meaningful assurance, and that the procedures typically do not address liabilities or whether the assets were borrowed. Two major firms exited the practice in the same month in 2022.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

09 · Multichain reality · Interactive

What one more chain actually costs

Chains are not the unit of work. Curve groups are. Pick your target networks and the panel shows how many distinct signing backends you have just committed to, and which of them no managed key service can host.

Select the chains you intend to support.

Ethereum + L2ssecp256k1
Bitcoinsecp256k1
Lightningsecp256k1
Solanaed25519
TONed25519
NEARed25519
Stellared25519
Aptos / Suied25519
Cosmos chainssecp256k1
Polkadot / Substratesr25519
Tronsecp256k1
XRP Ledgersecp256k1 or ed25519
Hederaed25519
Aleo / ZcashCustom

Count curve groups, not logos

Ten EVM rollups are one integration. Bitcoin, Solana and Polkadot are three, and each brings its own signing backend, its own address rules, its own fee model and its own indexer. A roadmap that says “twenty chains” and a roadmap that says “four signing backends” can describe the same product — only one of them is an estimate.

Where the key services stop

This is the table that decides whether your keys can live in managed infrastructure at all.

Key serviceECDSA secp256k1EdDSA ed25519Schnorr BIP-340sr25519ECDSA secp256r1
AWS KMS
Google Cloud KMS
Azure Key Vault / Managed HSM
AWS CloudHSM
Apple Secure Enclave
TPM 2.0
Common IoT secure elements
supported not supported
Two consequences worth stating plainly. First: the curve that secures most of this industry cannot be signed inside a phone’s secure element or a TPM — so “the key is protected by the Secure Enclave” almost always means the enclave encrypts a container while the signature happens in ordinary memory. Second: Schnorr signing for Bitcoin’s taproot is offered by none of the managed services, which pushes it into software threshold signing, where two of the widely used open-source libraries are no longer maintained and one carries a publicly acknowledged “will not fix”.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

10 · Cost and build-vs-buy

Own the keys, or rent them

One decision, three ways to answer it. Start with what each posture actually leaves on your side, answer eight questions, then look at the two annual figures side by side and find where they cross.

Three postures
Decide
Run-rate and crossover
The lines nobody budgets

Before any number: these are the three things being compared, and what each one actually leaves on your side of the line.

Buy

A wallet vendor holds the key material and ships the SDK. You build the product on top.

You are responsible for
  • The application, the transaction service and reconciliation — in every case
  • The integration, and the glue between five vendors
  • Support, monitoring and the incident when a vendor degrades
The vendor is responsible for
  • Key generation and signing
  • The recovery mechanism
  • Their own uptime, to whatever their contract says
When it is right. Below roughly a million monthly actives, on published rates, and where no data-residency commitment is required.
Build

You own the key material end to end, in your own infrastructure.

You are responsible for
  • Everything in the Buy column
  • Key generation, signing, rotation and ceremonies
  • Recovery, including the abuse cases
  • A security engineering function and 24/7 on-call
  • A recurring audit budget, re-run on every minor version
The vendor is responsible for
  • Nothing. That is the point, and the cost.
When it is right. When the wallet is the product, when residency is contractual, or above the crossover on volume.
Hybrid

Buy the signing, own the exit. The configuration most teams should actually be in.

You are responsible for
  • Everything in the Buy column
  • An independently held share or a tested offline recovery artefact
  • A thin signer abstraction, so replacing the vendor is an adapter change
The vendor is responsible for
  • Signing, under a configuration where they cannot complete a quorum alone
When it is right. Almost always, at the start. It costs a fortnight of design and removes the dependency that is hardest to unwind later.

Notice what does not move between the columns

Application logic, the transaction service, history and reconciliation appear in all three. No vendor removes them, and together they are most of the build. The build-versus-buy argument is therefore about one layer — who holds the key material — and not about the size of the project, which is roughly the same either way.

Eight questions. Same format as the custody classifier, and it takes about a minute.

1. Is the wallet the product, or a feature inside one?
Be honest about which one your roadmap says.
A feature
Both, depending who you ask
The product
Why it matters — If the key primitive is the moat, renting it means renting the moat.
2. How many distinct curve groups will you support within eighteen months?
Curve groups, not networks. Ten rollups are one group.
One
Two
Three or more
Why it matters — Some curves are not signed by any managed key service, which turns the question into a hardware decision rather than a vendor one.
3. Realistic monthly actives at the end of that period?
Actives, not registrations, and not the number in the deck.
Under 100k
100k to 1M
Over 1M
Why it matters — On published list rates the crossover sits near a million. Negotiated rates move it considerably further out.
4. Do you need a contractual commitment on where key material lives?
Not a preference — a clause someone will sign.
No
Preferred, not required
Required
Why it matters — No embedded vendor publishes a residency commitment. The only routes are a self-hosted signer, an on-premise deployment, or your own stack.
5. Will you custody user funds?
If unsure, take the custody classifier in section 06 first.
No, strictly non-custodial
Borderline
Yes
Why it matters — Custody changes the question from a vendor choice into a licensing programme, and the build side of it is mostly not wallet code.
6. Do you already run security engineering and out-of-hours on-call?
Today, not in the hiring plan.
No
Partially
Yes
Why it matters — Owning key material without a 24/7 function is worse than renting it. Settlement does not observe office hours.
7. Can you tolerate a vendor outage or a pricing change?
Consider that ten vendors in this category changed hands in about two years.
Yes, with a documented exit
Uncomfortably
No
Why it matters — The exit artefact matters more than the outage. A vendor you can leave in a fortnight is a different risk from one you cannot.
8. Do limits and permissions have to be enforced on-chain?
Enforced by the chain, not by a service you operate.
No
Later, probably
Yes
Why it matters — On-chain enforcement means your own contracts, which means an audit budget regardless of whose SDK sits above them.

Two annual figures at the same user count: what the vendors charge, against what a standing team costs. Both sides are built from published numbers — vendor list prices and published engineering salary bands — so the comparison is portable and neither side is our rate card.

Monthly active wallets Vendor posture
Buy — annual vendor spend
Wallet licence is of it. The rest is identity, indexing, chain access and sponsored gas.
Wallet-as-a-service
Published list rates vary by a factor of thirty-two across vendors for the same profile, and by a factor of thirty between list and enterprise within a single vendor.
RPC and nodes
Commodity, and swappable. Rarely the problem.
Indexer and history
The layer teams forget until the activity screen is empty.
Sponsored gas and paymaster
Providers charge a flat eight to ten per cent on sponsored gas. That is a tax on success, not a fixed cost.
Identity and screening
Per-verification, charged on the cohort. Usually the largest single line in year one — larger than the wallet.
Build — annual cost of owning the layer

Vendor side: arithmetic on published list rates at a stated usage profile. Build side: published engineering salary bands for the roles this layer requires, plus a recurring audit allowance, and it excludes the application work that both sides pay for anyway. Both are rounded hard and shown as an order of magnitude. This is a shape, not a quote.

The counter-intuitive part. Sponsored gas feels like the frightening number and is not: across the whole industry, all gas ever sponsored through account abstraction adds up to a figure most companies would classify as a marketing experiment. Identity verification of your cohort, charged once per person, will usually exceed your entire wallet infrastructure bill in year one.

Key rotation and ceremonies

A threshold-signing library patch is a migration of every key in the system, not a deployment. Plan it as a programme with user action, because that is what it is.

Store publication

Both major app stores require an organisation account: a wallet cannot be published by an individual. One store additionally lists jurisdictions with licensing prerequisites, and explicitly places non-custodial wallets outside that scope — turning an architecture choice into a distribution choice.

Twenty-four-hour operations

Settlement does not observe business hours. The staffing line for out-of-hours incident response is routinely missing from wallet budgets and is rarely small.

Monitoring the vendor

When a sponsorship service degrades, your users see failed transactions and blame you. Independent monitoring of your dependencies is a product requirement, not an infrastructure nicety.

Audits, recurring

Buying does not remove this if you deploy contracts. The most widely used smart-account entry point has needed several audits and produced multiple high-severity findings; the most widely used multisig has been audited on the order of eighteen times, each minor version again.

Screening and monitoring

Not one major transaction-monitoring provider publishes pricing. Budget it as a negotiated line and open the conversation early, because you cannot estimate around it.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

11 · Standards board · Interactive

What is actually standardised, and what only looks like it

Thirty specifications a wallet touches, with the status they carried when this page was built. Filter by layer. The badges are the point.

All
Connect
Auth
Signing
Accounts
Addressing
Tokens
Compliance
Portability
StandardWhat it isStatusWhy it matters
FINAL ratified REVIEW under review DRAFT draft STAGNANT formally abandoned NOT A STANDARD no specification exists

Three things this table is for

One. Deployment and standardisation do not correlate: two of the most-called wallet methods in Ethereum are formally abandoned, while the permissions specification nobody argues about is ratified. Two. Some widely cited “standards” have no specification at all — one of them appears in security-token proposals constantly and exists only as a closed, stale issue. Three. Portability is structurally unsolved: there is no standard for exporting threshold shares, and the credential-exchange format that finally shipped defines seventeen credential types, none of which is a wallet key.

Practical use. Before citing a standard in a specification or a proposal, check its badge and put the date next to it. Statuses in this field move faster than the documents that quote them, and a reviewer who spots a stagnant reference will discount everything around it.

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com

12 · What we have built

Wallets, custody, and the parts in between

Deliberately last. The argument above should hold whether or not you ever work with us — this is the evidence that we have run into these failures ourselves.

Eight engagements. Client names are withheld where our agreements require it — the badge states the level of disclosure rather than leaving you to guess. Click any card for what was delivered, the technology, and what came out of it.

IN DELIVERY
Non-custodial mobile wallet for a top-tier stablecoin issuer
Global · Ongoing since 2025
One of the largest stablecoin issuers in the world
React NativeExpoTypeScriptERC-4337 smart accounts+5 more
Read the engagement →
PUBLIC
Layer-2 network with its own wallet, exchange and yield protocol
Global · 2024–2026, ongoing
A public zkEVM rollup, live on mainnet
Polygon CDK / zkEVMAggLayerRustSolidity+6 more
Read the engagement →
PUBLIC
Non-custodial execution control plane with an AI copilot
Global · 2025–2026, ongoing
A crypto-finance product team building an agentic interface
ReactCapacitorPython / FastAPILangChain / LangGraph+6 more
Read the engagement →
NDA
Hybrid omnibus custody for a payments platform
United Kingdom · European Union · 2025–2026, phase two in progress
A payments platform with regulatory exposure in the UK and the EU
MPC custody integrationDouble-entry ledgerKYT screeningTravel-rule messaging+3 more
Read the engagement →
NDA
Financial-grade chain with a hardware node and a device wallet
United States · Delivered, in production
A regulated wealth-management fintech
Substrate / PolkadotRustink! smart contractsZero-knowledge proofs+3 more
Read the engagement →
NDA
Institutional custody and tokenised bank deposits
Latin America · Discovery and build, in progress
A commercial bank
GogRPCSolidityMPC custody+3 more
Read the engagement →
NDA
Custodial crypto platform inside a retail bank
South-East Asia · 2025–2026, phase two in progress
An established retail bank
Custodial architectureHot / warm / cold segregationKYT screeningCore-banking integration+3 more
Read the engagement →
NDA
Non-custodial Bitcoin wallet with instant payments
Global · Delivered to production
A product team building a retail Bitcoin wallet
BitcoinUTXO handlingLightning payment channelsMobile
Read the engagement →

How we work on this

We start from the signing model, because everything downstream — licence, recovery, cost, incident response — is decided by it. We write down who can sign without the user before anyone writes code, and we test the vendor’s failure mode instead of reading its marketing. Where a product already exists, the first engagement is usually an honest read of the display step in Anatomy of one signature, because that is where the money is lost.

One question to take away, rather than a conclusion. Ask every bidder to walk you through one signature, from a user’s intent to settlement, and to name which step they own and which they are renting. Teams that have built this before answer in minutes. The rest send a deck.
Talk to an architect →

Every figure on this page is taken from a primary source — a specification, a vendor pricing page, a regulator’s text, a forensic report or a filing — and dated. Where the industry publishes nothing, the page says so instead of estimating. Standards statuses move; check the badge date before quoting one. © 2007–2026 Innowise · innowise.work · case studies · contact@innowise.com