Services
Page
web3

Web3 Wallet Infrastructure: Build vs. License a White-Label SDK

Diana Zander
Diana Zander Research Muse
12 min09 Nov 2026
Want to discuss
your project?
image

Who holds the keys, who carries the risk and how long the launch takes. Four paths, four questions and a decision in five lines.

Key takeaways

  • Why it matters: wallet infrastructure decides who controls user funds, how fast you launch and how hard it is to leave.
  • What to do first: decide who must hold the keys before you compare vendors or write code.
  • Licensing an SDK gets you to market in weeks. Building gets you control, at the cost of many months and a security team.
  • The hard part is key management and recovery. The screens around them are the easy part.
  • Plan the exit on day one. Moving users from one wallet provider to another is the costly step.

Wallet infrastructure looks like a feature until you try to build it. The screens are the easy part. Underneath sit key generation, signing, recovery, device changes, chain support, security reviews and, in some markets, licensing. Every one of them has an owner, and every owner is either your team or your vendor.

image
image

Step 1: four questions that decide it

Answer these before you open a vendor site. Each answer removes at least one path.

  1. Who must hold the keys? If users hold them, if you hold them, or if a mix of parties hold shares, the architecture changes. Read custodial vs non-custodial wallet architecture before you pick.
  2. How fast must you launch? A pilot in weeks and a regulated product in a year need different paths.
  3. Which regulation applies to you? Custody and transaction services can fall under licensing rules in some markets, such as the EU's MiCA regime. Whether the duty sits with you or with your provider depends on the setup, so confirm it with the regulator.
  4. Who will run it? A wallet is a security product. It needs people for key ceremonies, audits, incident response and chain upgrades.
image

Option 1: Build from scratch. The control path

Your team designs key management, signing, recovery, chain integrations and the interface. You decide every trade-off, and every audit finding is yours to fix.

This path fits teams for whom the wallet is the product, or whose rules demand full control and a full audit trail of key handling.

  • Pick it when: custody is your core business, your rules demand full control or no vendor may touch keys.
  • Watch for: build times counted in many months, a permanent security and operations team, and audits that repeat with every major change.

Option 2: License a white-label SDK. The speed path

You integrate a ready wallet that carries your brand. Key handling, signing and many chains come from the vendor. Vendors describe launches in weeks, and your team focuses on onboarding, features and growth.

The price is dependence. Your roadmap follows the vendor's, your user experience has limits, and the cost model, often a fee per user or per transaction, scales with your success.

  • Pick it when: you need to launch fast, the wallet supports another product and your rules allow a third party near keys.
  • Watch for: lock-in, a pricing model that grows with volume, and limits on how much of the interface and flows you can change.
image

Option 3: API-first wallet service. The middle path

Here you build the interface and the product logic, and call an API for key management and signing. You get more freedom than an SDK and far less security burden than a full build.

  • Pick it when: you want your own experience, and you want the hardest security work to belong to specialists.
  • Watch for: more integration work than an SDK, a vendor outage that becomes your outage, and uneven support between chains.

Option 4: Hybrid. License now, replace later

Many teams start with a licensed wallet, learn what users do, and then replace modules that matter most, such as recovery or signing policies. The plan works if the architecture keeps the vendor behind an interface you own.

  • Pick it when: you must prove demand before you invest in a build.
  • Watch for: an interface that grows around one vendor's quirks, and a migration you never fund.
image

The real decision: who holds the key

Most of the differences between options come down to one design choice: how the private key is created, stored and used. Public comparisons describe three models.

  • Threshold or MPC signing. The key is split into shares held by different parties, and a signature needs a quorum. No single party holds the whole key.
  • Secure enclaves. Key material lives inside hardware that only releases signatures under set policies.
  • User-held shares. The user keeps part of the key on a device, with a social login or a recovery factor as another share.
image

Vendors describe their own model as the safest one, and their descriptions of competitors often disagree. Treat vendor comparisons as marketing and ask each provider for first-party documentation of the key architecture, the audits and the export policy.

image

A worked cost example

The numbers below are illustrative. Use your own volumes and quotes.

Suppose a licensed wallet charges a revenue share of 0.4% on transaction volume, as in one public vendor example. On $500,000 of monthly volume that is $2,000 a month, or $72,000 over three years.

Set that against a build. A custom wallet needs engineers, a security review, audits that repeat after major changes and an on-call rotation for as long as the product lives. At small volume the licence is usually cheaper. As volume grows and key control becomes strategic, the line can cross.

image
image

Due diligence: what to check before you license

Security and exit terms decide the outcome more than features do. Ask for these documents before you sign.

  1. Key architecture. A written description of how keys are created, split, stored and used for signing.
  2. Audit reports. The most recent independent audit and a plan for recurring penetration tests.
  3. Incident history. How the vendor handled past incidents and how it informs customers.
  4. Export and exit. A clear path to move users and keys to another provider or to your own system.
  5. Availability. Uptime targets, support hours and what happens during a vendor outage.
  6. Chains and tokens. Which networks are supported now and how new ones are added.
  7. Regulatory position. Which licences the vendor holds and which duties remain with you.
image

The quiet risk: the migration nobody planned

A wallet is the one product feature users cannot simply re-enter. If keys, accounts and recovery live in a vendor's system, a change of provider means moving every user, with their consent, without losing funds. Teams that skip this question discover it when the vendor raises prices, changes terms or shuts down a chain.

Plan the exit while the product is small: keep an interface between your app and the wallet, record what the vendor stores about each user, and test an export before you need one.

Seven mistakes we see most often

  1. Comparing screens before keys. A beautiful interface on a key model you cannot accept is wasted effort.
  2. Underestimating recovery. Lost devices and forgotten passwords create most support load.
  3. Believing the vendor's comparison table. Check first-party documents.
  4. Ignoring the pricing curve. A fee that is small at launch can dominate margin later.
  5. Skipping the audit report. Ask to read it before you sign.
  6. Building without a security team. A wallet needs continuous security work for as long as it runs.
  7. No exit plan. The cheapest time to design it is before you integrate.

Questions to ask a vendor or your own team

  • Who holds each part of the key, and can any single party sign alone?
  • Can we export keys or move users, and what does that cost?
  • When was the last independent audit, and can we read it?
  • Which chains and tokens do you support, and how fast do you add new ones?
  • What is the pricing model at ten times our current volume?
  • What happens to our users if you change terms or close?
  • Which licences do you hold, and which duties stay with us?

Terms in plain words

  • Private key: the secret that proves ownership of funds and signs transactions.
  • MPC (multi-party computation): a way to sign without any single party holding the whole key.
  • Secure enclave: protected hardware that keeps keys inside and releases signatures only under rules.
  • Embedded wallet: a wallet built into your app so users never install a separate one.
  • White-label: a product from a vendor that carries your brand.
  • WaaS (wallet as a service): wallet functions offered by a vendor through an SDK or API.

In Lazy Ants

We approach wallet decisions as a sequence of checks, in the order above:

  • We decide with you who must hold the keys and which rules apply.
  • We compare paths against your volume and your launch date.
  • We review key architecture, audit reports and export terms with you.
  • We design the interface between your app and the wallet, so the vendor stays replaceable.
  • We build what must be yours and integrate the rest.

If you want an outside read before you commit, our Web3 architecture review covers wallet architecture, custody and launch risk. For budget questions, see what a crypto wallet costs.

Step 2: decide in five lines

  1. If no vendor may touch keys, plan Option 1 and staff it.
  2. If you must launch within weeks, start with Option 2.
  3. If you want your own experience and a lighter security burden, choose Option 3.
  4. If you must prove demand first, plan Option 4 and keep the vendor behind your own interface.
  5. Whatever you choose, read the key architecture and the audit report, and test an export.

FAQ

Is it cheaper to build or to license a wallet?

At small volume, licensing is usually cheaper. A build costs engineers, audits and on-call time for as long as the product lives. As volume grows, a revenue-share fee can exceed the cost of owning the system, so run the numbers at several volumes.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

How long does it take to launch with a white-label SDK?

Vendor guides describe weeks. Your own work, such as onboarding, compliance checks and testing, usually takes longer than the integration.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Can I switch providers later?

Yes, if you plan for it. Keep an interface you own, record what the vendor stores for each user and test an export early.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Who is responsible for security when I license a wallet?

The duties are shared. The vendor handles its key infrastructure, and you handle your app, your access controls and your users' accounts. Read the contract to see where the line sits.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

Do I need a licence to offer a wallet?

It depends on the market and on how custody and transactions are handled. In the EU, rules such as MiCA can apply, and the duty can sit with you or your provider. Confirm with the relevant regulator.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

What is MPC and do I need it?

MPC splits a key into shares so no single party holds the whole key. Many modern wallets use it or similar designs. Whether you need it depends on your custody model and your risk limits.

╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

What is the safest first step?

Write down who must hold the keys and which rules apply, then ask two or three vendors for their key architecture and audit reports.

Sources: public vendor and developer comparisons of embedded wallets, MPC key management and wallet-as-a-service, including provider documentation and independent reviews; secondary summaries of regulatory requirements. Vendor figures are illustrative, prices and rules change, and none of this is legal advice, so check current documents and ask your regulator before you decide.

Conclusions

Who should hold the keys?

image

Need expert advice on your project?

Schedule a call with our team to discuss your needs and get expert guidance.

Building or licensing a wallet? Review it first
Web3 Wallet Infrastructure: Build vs License | Lazy Ants