The Two-Vendor Problem: Why Scaling Teams End Up Running Privy and Turnkey Together

Picture a fintech app with 200,000 users. The wallet works, the onboarding is smooth, retail users never see a seed phrase. Then the company needs to hold its own funds onchain — a treasury, operator keys that sign on behalf of the business, automated payouts with spending limits and approvals. The consumer wallet was never built for that. So the team signs a second contract, with a second provider, and now runs two wallet systems in parallel.

We see this often enough in client work that we have a name for it: the two-vendor problem. This piece is about why it happens, what it actually costs, and what the alternative would look like.

A note on honesty up front. The specific claim you may have read elsewhere — that “most teams past 100,000 wallets run two providers” — is a pattern we observe, not a measured statistic, and we have not found a source that establishes it as one. What is well documented is the underlying split it rests on, which is what the rest of this piece defends.

The problem

The thing that makes the two-vendor problem sneaky is that nobody decides to have two wallet vendors. It accumulates.

You start with one job: let users sign in and get a wallet without thinking about crypto. A consumer embedded wallet does that well. Months later a different job appears — the business itself needs to move money onchain, under controls an auditor would recognize: who can sign, for how much, with whose approval, on what schedule. That is a treasury and operator-key problem, and it lives in a different category of product.

By the time both jobs exist, you have two vendor contracts, two integrations, two billing relationships, and two failure modes. The consumer wallet handles user experience. The signing layer handles treasury. Each is good at its half and structurally unsuited to the other.

Why the split happens

It is not an accident or a procurement failure. The two halves are optimized for genuinely different things.

Consumer embedded wallets — Privy, Dynamic — are built for onboarding. Their job is to spin up a self-custodial wallet at signup from an email or social login, abstract away seed phrases, and get a retail user to their first transaction with minimal friction. That is what they are good at. They are not designed to be a treasury policy engine with multi-party approval workflows, and they do not claim to be.

Signing infrastructure — Fireblocks is the clearest example — is built for programmable key control. Fireblocks centers on MPC-based custody, a transaction policy engine, approval workflows, and auditability for institutions. Reviews and its own documentation are consistent that it is built for institutional treasury operations, not retail onboarding UX.

A useful nuance: not every signing-layer vendor sits cleanly on one side. Turnkey, for instance, ships both consumer-facing embedded wallets and company/treasury wallets on top of its enclave-based signing — so it can straddle the gap in a way Fireblocks does not. But the structural point holds: a product tuned for frictionless consumer onboarding and a product tuned for policy-bound treasury signing are pulling in opposite directions, and most stacks end up sourcing the two halves separately.

Fireblocks made this divide explicit when it acquired Dynamic in October 2025, writing that institutional infrastructure and consumer experiences “have long lived in separate worlds.” That is the whole thesis, stated by the institutional-custody side itself: the two worlds have been separate, and the market is now trying to merge them through acquisition.

The real cost

The cost of running two vendors is not mainly the second invoice. It is the operational surface area.

• Two auth surfaces. Two sets of API keys, two permission models, two places a credential can leak.
• Two key-management systems. A consumer wallet’s SSS-or-MPC model and a treasury platform’s policy engine are different architectures with different threat models. Your security review now covers both.
• Two incident-response runbooks. When something breaks at 3 a.m., which provider, which dashboard, which escalation path? The answer depends on which half of the stack failed, and the two halves do not share a runbook.
• Two upgrade paths. Each vendor ships breaking changes on its own schedule. You absorb both.

And then there is the risk that is no longer hypothetical. In 2025, Stripe acquired Privy, Fireblocks acquired Dynamic, and Consensys acquired Web3Auth. If your “two independent vendors” strategy was specifically chosen to avoid concentration, an acquisition can quietly collapse it into one — and the Fireblocks/Dynamic deal is exactly a signing-infrastructure company buying a consumer-wallet company. To be precise: none of those acquired products stopped working, and all were stated to continue. The risk is not that your tools vanish overnight; it is that their roadmaps, pricing, and strategic alignment are now set by an owner you did not choose.

What a single stack would look like

Step back from the specific vendors and the problem is architectural: retail wallets and treasury signing are treated as two products because they grew up as two products. They do not have to be.

A single stack would put one key-management layer underneath both. The consumer wallet and the operator/treasury signer would be two policies over the same non-custodial signing substrate, not two companies. One auth surface. One place to reason about custody. One runbook. Spending limits, allowlists, and approval rules would be configuration on a shared engine, not a feature you buy twice.

This is not a description of any one product — it is the shape of the category that the acquisition wave is groping toward. Fireblocks is buying its way to it from the custody side; the consumer-wallet vendors are extending toward treasury from the other. The question is whether you get there by stitching acquisitions together or by building on a stack that was one thing from the start.

Where FabricBloc is headed

This is the direction we are building. FabricBloc is an onchain stack — wallets, payments, NFTs, identity, and agents behind one SDK and one bill, non-custodial by architecture, with a threshold-based signing layer shared across consumer and operator use. One key model underneath, configured by policy rather than purchased twice.

FabricBloc is in early access and built and operated by BlocLabs. If you are already running two wallet vendors — or you can see the second one coming — we would like to hear how your stack is split.

Request early access to FabricBloc →

For the wider landscape, see our guide to Privy alternatives in 2026. You can also explore our blockchain API services or see the work we have shipped. Learn more about FabricBloc at fabricbloc.com.