How Enterprise Wallet Infrastructure Actually Works: MPC, Custody Models, and Why MetaMask Was Never the Answer

A technical deep-dive into what it actually takes to build wallet infrastructure for banks, fintechs, and financial institutions — from key management to compliance to multi-chain architecture.

Every week I talk to developers building on-chain financial products. And almost without fail, the conversation hits the same wall: key management.

Not smart contracts. Not tokenomics. Not gas optimisation. Key management.

Because the moment you try to build a wallet product that works for a bank, a fintech, or any financial institution serving real users — you discover that the entire existing ecosystem was designed for a completely different problem. MetaMask was built for a developer who wants to interact with DeFi protocols. It was never built for a fintech serving 10 million users in Maharashtra who should never see the word "blockchain."

This article is a technical breakdown of what enterprise wallet infrastructure actually requires: the custody models, the MPC architecture, the compliance layer, and the multi-chain problem. By the end, you should be able to make an informed decision about which approach fits what you're building — and understand why most existing WaaS tools fall short.

Prerequisites
Basic familiarity with blockchain concepts (private keys, transaction signing, smart contracts). This article goes deep on architecture — if you want the non-technical business case, the link to the newsletter edition is in the footer.

Why the Old Wallet Model Was Always Wrong for Enterprise

The crypto wallet model from 2017–2023 had one fundamental design assumption: the user is also the operator. The person using the wallet is the same person who understands seed phrases, manages private keys, and accepts full responsibility for key security.

That assumption breaks immediately in any enterprise context.

A bank cannot tell its customers "here is a 24-word seed phrase, please store it safely." A fintech cannot build a product where one customer support call results in someone accidentally approving a transaction with no recourse. A corporate treasury cannot have a single employee hold the private key to $50M in on-chain assets.

The enterprise wallet problem has fundamentally different requirements:

• Wallet creation at scale — millions of wallets, sub-second, no user interaction with keys
• Compliance baked in — KYC, sanctions screening, spending limits, audit trails
• Operational roles — treasury, compliance, support all have different access levels
• Disaster recovery — if a key shard is lost, funds must be recoverable
• Multi-chain — one user, multiple chains, one unified interface
• Regulatory audit — every transaction signed must be attributable and logged

None of these were considerations in MetaMask's design. And that's fine — it wasn't built for this. But it means the enterprise wallet is a completely different engineering problem from the consumer wallet.

The Three Custody Models — Trade-offs You Need to Understand

Before picking an architecture, you need to choose a custody model. This decision flows downstream into every other design choice you make.

Custodial: Simple to build, dangerous at scale
In a custodial model, your company holds the private keys. The user has a database record — an account ID — and you sign transactions on their behalf. This is how early crypto exchanges worked. It's also how traditional fintech apps work (you don't hold your money in a Paytm vault; Paytm does).

Why it's tempting: Easy to build. Fast wallet creation. Full control over compliance enforcement. No key management complexity for users.

Why it breaks at enterprise scale: Your HSM or key vault becomes the single most critical system you own. A breach means every user's funds are at risk simultaneously. Regulators in most jurisdictions are also increasingly hostile to custodial crypto models — you're essentially running a bank without a banking license.

Self-custody: Correct philosophy, wrong UX
Self-custody (MetaMask, hardware wallets, seed phrases) is philosophically correct — the user controls their own keys, nobody can freeze their funds, and there's no counterparty risk. But it fails for mass-market financial products for one simple reason: users lose their keys.

The support ticket "I lost my seed phrase" has no resolution in a pure self-custody model. That's fine for a crypto-native developer. It's a catastrophic product flaw for a fintech serving 10 million retail users.

MPC: The enterprise standard
Multi-Party Computation (MPC) wallets split the private key into cryptographic shards — pieces of the key that are mathematically useless on their own but can produce a valid signature when a threshold number of shards cooperate. A common configuration is 2-of-3: any two of three key shards can produce a valid signature without the third shard ever being exposed.

This is now the dominant model for enterprise wallet infrastructure and for good reason — it eliminates single points of failure while giving the operator enough control to enforce compliance.

How MPC Signing Actually Works

Understanding the mechanics of MPC is important because it determines your architecture decisions downstream. Here's the signing flow:

The key insight: the private key is never reconstructed in full at any point. MPC protocols (like GG20, DKLS, or CGGMP) use cryptographic techniques where each shard holder performs a computation on their shard, and the results are combined to produce a valid signature — without any party ever seeing a complete private key.

This is fundamentally different from a Shamir's Secret Sharing approach where shards are combined to reconstruct a key before signing. MPC signs without reconstruction, which means there is no moment of vulnerability.

// Simplified MPC wallet creation — what the API looks like
// The complexity of shard generation happens in the MPC library

const wallet = await mpcClient.createWallet({
  userId: 'user_9f2a3b',
  threshold: { signers: 2, of: 3 },
  shards: [
    { holder: 'company-hsm',   endpoint: process.env.HSM_ENDPOINT },
    { holder: 'cloud-kms',      endpoint: process.env.KMS_ENDPOINT },
    { holder: 'user-device',    deviceKey: userPublicKey }
  ],
  chains: ['ethereum', 'polygon', 'solana'],
  compliance: {
    jurisdiction: 'IN',
    kycLevel: 'full',
    spendingLimit: { daily: 100000, currency: 'INR' }
  }
});

// wallet.address is now live on all specified chains
// No seed phrase. No user key management. Sub-second creation.
console.log(wallet.addresses);
// { ethereum: '0x...', polygon: '0x...', solana: 'So...' }

The Compliance Layer — Why It Must Be in the Wallet, Not Above It

This is the architectural mistake I see most often. Teams build a wallet infrastructure layer and then bolt compliance on top — as a middleware that checks rules before passing transactions to the wallet service.

That's backwards. Compliance must be enforced at the wallet level, not above it. Here's why:

The bypass problem
If compliance is enforced in an API layer above the wallet, any internal team member or compromised service with direct wallet access can bypass it. When a regulator asks you to demonstrate your compliance controls, "we check before calling the wallet API" is not an acceptable architecture.

Enterprise wallet infrastructure needs compliance baked into the signing process itself. A transaction that violates a spending limit should fail at the wallet layer — not be rejected by middleware, not return a 403 from an API, but genuinely fail to produce a valid signature.

// Compliance rules enforced at wallet signing time — not in API middleware

class ComplianceAwareWallet {
  async sign(transaction, walletId) {

    // 1. Sanctions screening — check before signing
    const sanctionsResult = await this.sanctions.screen({
      to: transaction.to,
      lists: ['OFAC', 'UN', 'EU']
    });
    if (sanctionsResult.hit) throw new SanctionsViolationError();

    // 2. Spending limit check against daily/monthly rolling window
    const spent = await this.ledger.getDailySpend(walletId);
    if (spent + transaction.value > this.limits.daily) {
      throw new SpendingLimitError(`Daily limit: ${this.limits.daily}`);
    }

    // 3. Role check — does this signer have authority for this txn size?
    const role = await this.rbac.getRole(transaction.initiator);
    if (transaction.value > role.maxSingleTxn) {
      throw new AuthorizationError('Requires dual approval');
    }

    // 4. Only now proceed to MPC signing
    const signature = await this.mpc.sign(transaction);

    // 5. Immutable audit log — written atomically with the signature
    await this.auditLog.record({
      txnHash: transaction.hash,
      walletId, initiator: transaction.initiator,
      timestamp: Date.now(),
      complianceChecks: ['sanctions', 'spending-limit', 'rbac'],
      jurisdiction: this.config.jurisdiction
    });

    return signature;
  }
}

The Enterprise Wallet Stack — Full Architecture

Putting all the pieces together, a production enterprise wallet infrastructure looks like this:

The Multi-Chain Problem Nobody Talks About

One of the most underappreciated engineering challenges in enterprise wallet infrastructure is multi-chain support. It sounds simple — just support multiple blockchains. In practice, it's a deep architectural problem.

Different chains have different:

• Account models (EVM uses accounts, Solana uses programs, UTXO chains use inputs/outputs)
• Transaction formats (different serialisation, gas models, fee structures)
• Nonce management approaches (EVM nonces are sequential and must be managed carefully at high throughput)
• Signature schemes (ECDSA secp256k1 on Ethereum, Ed25519 on Solana — your MPC library must support both)
• Finality assumptions (probabilistic on PoW, deterministic on PoS — matters for enterprise settlement)

The correct architecture is a chain adapter pattern — a common interface that your wallet service calls, with chain-specific adapters implementing the interface for each supported network.

// Chain adapter interface — implemented per chain
interface ChainAdapter {
  buildTransaction(params: TxnParams): Promise<UnsignedTxn>;
  estimateFee(txn: UnsignedTxn): Promise<FeeEstimate>;
  broadcast(signedTxn: SignedTxn): Promise<TxnHash>;
  getBalance(address: string): Promise<Balance>;
  waitForFinality(hash: TxnHash): Promise<Receipt>;
}

// Ethereum adapter — handles EVM nonce management, gas estimation
class EthereumAdapter implements ChainAdapter {
  async buildTransaction(params) {
    const nonce = await this.nonceManager.getAndIncrement(params.from);
    const gasPrice = await this.provider.getGasPrice();
    return { ...params, nonce, gasPrice, chainId: 1 };
  }
}

// Solana adapter — completely different model, Ed25519 signatures
class SolanaAdapter implements ChainAdapter {
  async buildTransaction(params) {
    const blockhash = await this.connection.getLatestBlockhash();
    // No nonces — Solana uses recent blockhash for replay protection
    return new Transaction({ ...params, recentBlockhash: blockhash.blockhash });
  }
}

Custody Model Comparison — Making the Right Choice

What MetaMask Was Actually Designed For

None of this is a criticism of MetaMask. It was designed for a specific and legitimate use case: giving a developer or crypto-native user a browser-based interface to sign transactions and interact with DeFi protocols.

For that use case, it is excellent. The problem is that the industry — particularly in the 2020–2023 period — treated it as a template for all wallet products. "Users need a wallet, MetaMask is a wallet, therefore build like MetaMask."

The wallet is not the product. Finance is the product. The wallet is how finance happens on-chain — and for most financial products, it needs to be completely invisible to the end user.

The fintech user in Maharashtra should tap "send" and the money moves. They should not know what a private key is. They should not manage a seed phrase. They should have the same expectation of reliability, support, and recourse that they have with UPI.

Building that experience requires enterprise wallet infrastructure — not a consumer crypto wallet bolted onto a fintech app.

Tools and Libraries Worth Evaluating

If you're building enterprise wallet infrastructure today, here are the main options in each category:

MPC libraries
GG20 (Zengo's implementation), DKLS (Coinbase's threshold ECDSA), Fireblocks MPC-CMP, and ZenGo-X (open source). For production, evaluate whether you want to run your own MPC nodes or use a managed service.

WaaS providers to evaluate
Privy, Dynamic, Turnkey, Capsule, and Web3Auth all offer different trade-offs between control and convenience. Fireblocks and Copper are more enterprise-grade with higher ACV. Evaluate based on your compliance requirements and whether you need on-premise key shards.

Compliance tooling
Chainalysis and Elliptic for transaction monitoring and sanctions screening. Persona and Sardine for KYC at wallet creation. TRM Labs for blockchain risk scoring. Most WaaS providers have integrations with at least one of these.

The Scaling Challenges to Design For

Before I close, here are the scaling problems that will hit you in production that most architecture articles don't mention:

Nonce management at high throughput. On EVM chains, nonces must be sequential and non-repeating. If you're creating thousands of transactions per second from a hot wallet, nonce management becomes a critical bottleneck. You need a distributed nonce manager with optimistic locking — not a simple database increment.

MPC latency under load. MPC signing involves multiple network round-trips between shard holders. Under high load, this latency compounds. Design your signing service to handle this asynchronously with a transaction queue — don't make users wait synchronously for MPC completion on non-urgent transactions.

Key rotation without downtime. MPC keys need periodic rotation for security. Your architecture must support key rotation without interrupting wallet functionality — this requires careful state management across all shard holders simultaneously.

Chain re-org handling. When a blockchain re-organises (common on PoW chains, possible but rare on PoS), transactions you thought were confirmed can be reversed. Your finality layer must handle this gracefully — especially critical for payment settlement where you've already credited a user's account.

The operational reality
Enterprise wallet infrastructure is not a weekend project. A production-grade system with MPC, compliance, multi-chain support, and the scaling characteristics described above takes a well-resourced team 6–12 months to build properly. Evaluate WaaS providers seriously before deciding to build — the build vs buy decision here is not as obvious as it might seem.

The shift from consumer crypto wallets to enterprise wallet infrastructure is not an incremental improvement — it's a ground-up rethink of what a wallet is and who it serves. The engineering challenges are real, the compliance requirements are non-negotiable, and the UX bar is set by UPI, not by MetaMask.

If you found this useful, the next article in this series goes deep on the compliance architecture — specifically how to design jurisdiction-aware transaction rules that scale across markets without becoming a compliance nightmare to maintain.