Inside Blockops’ Distributed MPC Wallet Infrastructure for Financial Institutions

I have spent close to a decade building blockchain infrastructures for different protocol teams, and most of that time was spent learning one lesson the slow and hard way: wallet infrastructure for institutions is not just some database of blockchain addresses connected to a signing service. It is a control center for money. It decides how wallets come into existence, who is allowed to move funds, how signing authority is split up, how chain state gets reconciled, how you claw your way out of a failure, and this is the part people forget until an auditor asks, how you prove what happened after the fact.

When we started Blockops, we made one rule that the whole system had to obey. No single component can move customer money on its own. Not the API. Not a signing node. Not a cloud account. Not a row in a database. That constraint sounds simple. Implementing it end to end is a serious hardwork.

Our entire model for how we built this is around ensuring: the API can authorize a request but it cannot produce a signature. A signing node holds a share, never a whole key. No individual cloud is the custody boundary. And I want to be precise about operators, because this is where a lot of vendors quietly lie: operators can recover and redeploy infrastructure, but they never touch a plaintext share or a reconstructed key. Recovery runs through encrypted share stores and the secrets that unlock them. Nobody on my team ever holds raw private-key material in their hands. If that weren’t true, everything else in this document would be theater.

That objective is implemented through three distinct layers:

• the Wallet API and policy layer
• the MPC signing plane
• the chain operations and reconciliation layer.

The result is an MPC wallet platform with two deployment & control models:

• Blockops-managed custody infrastructure, where Blockops operates the wallet API, MPC signing cluster, chain operations, observability, backups, and recovery workflows.
• Self-hosted MPC infrastructure deployed through Blockops Mission Control, where enterprises deploy MPC nodes into infrastructure they own and control while still using BlockOps orchestration, monitoring, upgrade, and recovery workflows to abstract infrastructure complexities they don’t care about away

This article is an attempt at breaking down how each components works and explains the architectural design thinking behind how we built our wallet infrasturcture with financial institutions in mind.

TL;DR

Blockops is MPC wallet infrastructure built for institutions that have to answer for custody. The core design constraint: no single component can move customer funds on its own, not the API, not a signing node, not a cloud account, not the database.

• Authority is split across three planes. The wallet API admits and authorizes requests but can’t sign. The MPC signing plane holds key shares, never whole keys. The chain operations plane reconciles what actually happened on-chain. Each can fail independently and leaves enough durable state for the next layer to recover without guessing.
• Signing is 2-of-3 across independent substrates. Keys are generated with DKG(Distributed Key Generation, I wrote about it here), no complete private key exists anywhere. A valid signature needs a threshold of peers, so compromising one cloud, VM, or share store isn’t enough to move funds. Crossing the custody boundary requires multiple independent failures, not one intrusion.
• Automation and governance are separate trust domains. A scoped API credential can run treasury and product workflows but can never weaken the approval model, rotate secrets, or bypass step-up controls. If a static key could quietly route around approvals, the approval model was never real.
• Auditability is native, not reconstructed. Approvals, signing requests, transaction state, and delivery state are durable records the system produces as it runs so you can prove what happened after the fact instead of piecing it together post-incident.
• Three custody postures, one 2-of-3 backbone. Fully managed (we run all three peers), hybrid (you run one peer, we run two — signing now crosses an organizational boundary), or fully self-hosted (you run all three, we still handle orchestration and recovery through Mission Control).

The rest of this article walks through how each layer works and the design thinking behind it. It’s the technical foundation for a series of upcoming pieces aimed at fintech decision-makers.

The Real Problem Institutions Need To Solve

Most wallet products get pitched as if the hard part is generating an address and signing a transaction. If you have ever sat across the table from a fintech or bank’s risk team, you know that is not the hard part. The hard parts are the ones nobody barely talks about:

• preventing a single internal or external compromise from turning into asset loss
• separating automated API access from human governance authority
• proving what happened during a wallet, withdrawal, or approval flow
• recovering from stuck or failed infrastructure without improvising around key material
• reconciling on-chain truth instead of trusting application-side assumptions
• supporting different custody postures without rewriting the operating model

We did not arrive at that list from a whiteboard. It came from years of working with banks, financial institutions and protocol teams managing their validator infrasturcture with more than $50m AUM, mostly in emerging markets, where control over your own infrastructure is not a design preference, it is a policy requirement someone will be held personally accountable for.

It also came from running distributed blockchain infrastructure in production, where the real challenge was never the signature. It was signing in a way a regulator, an operator, and an institution could all trust at the same time. That is the bar. A cryptographic interface does not clear it. A control layer does.

Our Core guiding Principle

Blockops is designed so that the public API, the database, and an individual signing node are each insufficient on their own.

The API can authenticate, authorize, persist intent, and orchestrate work, but it cannot produce a valid signature by itself.

An MPC node holds only a key share, not a complete private key, so it cannot sign by itself either.

The database stores durable operational state, audit state, workflow state, and transaction state, but not a reconstructed signing key.

That separation matters because financial losses usually happen when too much authority is concentrated in one place. BlockOps is designed to break that concentration apart.

Architectural & System Overview

The important part is not simply that these components exist. The important part is where authority lives.

The wallet API owns request admission, authentication, idempotency, policy boundaries, and durable customer-facing state. The MPC signing plane owns key-share custody and threshold signing. The chain operations plane owns transaction construction, broadcast, receipts, confirmations, deposits, and balance reconciliation.

Each plane can fail independently, and each plane leaves enough durable state behind for the next layer to recover without guessing.

That is one of the most important design choices in the system. A large share of real financial infrastructure failures are not caused by cryptography breaking. They are caused by state becoming ambiguous under partial failure. We designed against that.

Threat Model

The core signing key for a wallet is never stored as a complete private key. Wallet creation uses DKG (distributed key generation, I wrote more about dkg here), producing independent key shares across signing peers. A valid signature requires a threshold of peers to participate in an interactive protocol.

In the standard Blockops-managed custodial deployment, the MPC cluster is three peers with a two-of-three signing threshold.

This design defends against single-substrate compromise. A compromise of one cloud, one VM, one Kubernetes namespace, one peer identity, or one local share store is not enough to sign. It also improves availability. If one peer is offline, the remaining two peers can continue signing while the system runs with reduced redundancy.

This architecture does not claim that threshold cryptography removes every risk. If an attacker controls enough peers to meet the threshold, or obtains enough encrypted share material plus the corresponding keystore secrets, the custody boundary has been crossed. The point of the design is to make that require multiple independent failures, not one successful intrusion. I will discuss the risk associated with this MPC wallets in general later on in this article

That is a much more realistic institutional security model than pretending there is a single perfect box that can hold custody risk by itself.

The Wallet API

This is the public integration surface for fintech platforms and internal Blockops products. It exposes the workflows that customers and product services needs. The wallet api is intentionally not a private-key service. It authenticates requests, validates policy, persists intent, and asks the MPC cluster to perform cryptographic work. It never holds enough material to sign by itself.

Authentication and API Keys

Provider API calls are authenticated with HMAC-signed requests:

ACCESS-API-KEY: <key>
ACCESS-TIMESTAMP: <unix timestamp>
ACCESS-SIGN: <hmac signature>

The canonical signature input includes the HTTP method, request path, timestamp, and body. This keeps request authentication deterministic for backend integrations and avoids relying on dashboard cookies for server-to-server custody operations.

Blockops API keys are scoped. They can be limited by capability, wallet binding, IP allowlist, expiration, revoked state, and last-used tracking. A key that can read wallet assets does not automatically get withdrawal authority. A key bound to one wallet cannot inspect another wallet. Static API credentials must not weaken approval policy, rotate sensitive secrets, bypass step-up controls, or mutate governance rules. That separation is a hard architectural boundary. Provider automation and human governance are different trust domains.

Governance And Approval Boundaries

This distinction is easy to miss if you think of a wallet system as only a signer.

In practice, institutions need two different classes of control:

• automated product and treasury workflows that must run reliably through APIs
• human or higher-trust governance workflows that must not collapse into a single integration credential.

That is why policy evaluation, approval groups, approval requests, typed signing controls, and auditable governance flows are part of the architecture itself. They are not cosmetic dashboard features around the edges of the custody system.

If a static API key can quietly bypass the institution’s approval model, then the approval model was never real.

Durable Operation Ledger

The operation ledger is the part of the system that makes wallet infrastructure debuggable.

Before Blockops publishes a key generation request, it persists a wallet creation operation. Before it publishes a signing request, it persists the withdrawal and signing operation. Before it broadcasts a signed transaction, it persists the signed transaction material and expected transaction hash. This gives the platform durable state for: wallet creation requests, readiness, txn hashes, webhook subscription & delivery states etc

The ledger turns asynchronous infrastructure into a state machine. If a command times out, the state reflects that. If a result arrives after a timeout, the consumer can check whether the operation is still mutable. If a worker restarts, it can resume from stored state. If an operator investigates an incident, they can trace from workspace to wallet to withdrawal to signing correlation ID to transaction hash.

The control-plane database is not a private-key database. It stores operational truth, not complete signing secrets.

MPC Command and Result Plane

The MPC layer is event-driven. This is one of the most important parts of the architecture.

Get Adedayo Akinpelu’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The API does not open an RPC connection to a signer and wait for a private-key operation. It publishes durable commands and consumes durable results. That gives Blockops retry semantics, backpressure, correlation IDs, timeout handling, and clean separation between customer-facing HTTP requests and distributed cryptographic sessions.

Conceptually, there are three classes of messages:

• Durable command messages: Key generation request, Signing request, Resharing request
• Ephemeral session messages: TSS broadcast rounds, encrypted direct peer messages
• Durable result messages: key generation result, signing result, resharing result

Durable command and result streams are for operation boundaries. Ephemeral session messages are for the cryptographic protocol itself. Keeping those concerns separate lets the system use durability where the business operation needs it, and low-latency peer messaging where the MPC protocol needs it.

MPC Node Runtime

Each MPC peer runs the same node runtime. There is no master signing peer. A node is responsible for: loading its peer identity, opening its encrypted local share store, connecting to the coordination plane, consuming keygen and signing commands, routing protocol messages and much more

The node is best understood as a session factory plus a secure local share store.

When the node starts, it validates critical configuration before accepting work. If these are missing or inconsistent, the node fails closed. A signing peer that is half-configured is more dangerous than a signing peer that is offline.

Sessions

The node runtime creates three kinds of sessions. Key generation sessions create a new distributed wallet key. All configured peers participate. No peer receives the full key. At the end, each peer stores only its own encrypted share and shared key metadata is recorded for future signing.

Signing sessions load existing key metadata, select enough ready participants, derive the requested child key material where applicable, and run the threshold signing protocol. The output is a blockchain-valid signature, not a reconstructed private key.

Resharing sessions redistribute shares to a changed committee or threshold while preserving the wallet public key. This is the mechanism for peer replacement, topology changes, and long-term key lifecycle management.

Blockops treats resharing as an operations and governance workflow, not a casual API call. Changing signer membership changes the custody boundary and must be auditable.

How a Wallet is Created

Creation starts at the API, but the key is born inside the cluster, not at the edge. The API hands back a pending operation and the client polls:

GET /api/v1/wallets/creation-status/{wallet_id}

That is not a UX shortcut. It is the honest shape of distributed key generation, which depends on every peer, on network coordination, on encrypted storage, on result delivery. Dress it up as synchronous HTTP and you just hide the failure modes that will eventually find you

Signing and Withdrawal Lifecycle (How Money Leaves)

The signing hash is built by Blockops from trusted server-side state. Normal withdrawal flows do not accept arbitrary client-supplied signing hashes. That keeps transaction construction, chain ID validation, nonce handling, recipient validation, and policy inside the custody control plane.

Signing requires only the threshold number of peers. In the two-of-three deployment, two ready peers can complete the signing session while the third is offline.

The final output of the signing session is a signature. The private key is not reconstructed. The Wallet API assembles the signed transaction, verifies that the resulting transaction hash matches persisted withdrawal state, and then broadcasts.

Chain operations and reconciliation

The chain operations plane is responsible for turning signed intent into confirmed wallet activity.

For withdrawals, it handles transaction planning, gas and nonce inputs, signed transaction assembly, broadcast attempts, transaction hash persistence, receipt polling, confirmation depth, missing-receipt handling, rebroadcast policy, terminal success or failure state.

For deposits, it handles watched addresses, observed inbound transfers, deduplication, balance snapshots, transaction history, backfill, scanner lag metrics, reconciliation against chain state.

This plane is deliberately separate from the signing plane. Signing proves authorization to spend. Chain operations prove what happened on-chain.

Balances do not silently zero when a scanner is stale. Transaction history does not depend on a dashboard session. A withdrawal is not marked final because a transaction was broadcast; it becomes final only after chain reconciliation reaches the configured confirmation policy.

Wallet Confidential VM: Blockops-Managed Custody

Managed Wallet Infrastructure architectural overview

We run a three-peer MPC cluster across independent substrates:

• GCP Confidential VM
• AWS Nitro EC2
• Kubernetes peer in Blockops-controlled baremetal server

The substrates are intentionally different. Worth stating plainly: only the GCP & AWS peer runs under confidential-compute memory protection. The other node earn their place through substrate diversity, not equivalent in-memory guarantees. We are using this to reduce correlated failure.

GCP Confidential VM Peer

The GCP peer runs on a Confidential VM backed by AMD SEV-SNP, with attestation verifying the launch state. The purpose is to reduce exposure of in-memory share material to the platform layer. During signing, a share must exist in process memory. Confidential memory encryption helps protect that memory from a compromised or privileged hypervisor layer.

Runtime secrets are fetched at boot into RAM-backed storage. Swap is disabled. The share database may live on persistent disk for recovery, but it is encrypted at the application layer with a passphrase that is fetched separately at runtime.

The deployment is pinned: image, container digest, infrastructure definition, and configuration version are controlled. Patching means rebuilding and redeploying, not hand-mutating a long-lived host.

AWS Nitro Compute Peer

The AWS peer gives the cluster cloud-provider diversity. It uses separate IAM, separate secrets, separate operational access, separate backup storage, and a separate failure domain.

This peer is not treated as a Nitro Enclave. It is a regular EC2 deployment on Nitro hardware. Its role in the architecture is substrate independence: a different provider boundary, identity system, storage path, and incident-response path.

Administrative access is controlled through AWS-native mechanisms rather than open SSH. The peer communicates with the coordination plane through mutually authenticated channels. The wire is not trusted; the identities are.

Kubernetes Peer

The Kubernetes peer runs inside Blockops-controlled infrastructure. It uses Kubernetes-native lifecycle management, scoped service accounts, persistent volume-backed encrypted share storage, and cluster-native deployment workflows.

This is the most conventional runtime of the three. Its value is operational diversity. The Kubernetes peer is managed through different pipelines, identity mechanisms, and runtime controls than the two VM peers.

There is a trade-off: if the Kubernetes cluster also hosts coordination services, a severe cluster outage can affect both a peer and the coordination plane. That is an availability exposure. It is not by itself a full key compromise because the cluster still has only one peer’s share.

Self-Hosted MPC Through Mission Control

Blockops Mission Control already helps enterprises deploy and operate blockchain nodes across infrastructure they own. Blockops extends that model to MPC nodes.

For enterprises with stricter custody, regulatory, or infrastructure-control requirements, the signing peers do not have to be a hidden vendor-operated system. Mission Control can provision and operate MPC nodes in customer-controlled environments while preserving Blockops’ orchestration and operational model.

The important thing is that this is a spectrum, not a switch. The cluster is always three peers signing two-of-three, and the only question is who runs which peer. That gives an institution three concrete postures:

Managed. We run all three signing peers across the substrates described above. The institution integrates against the API and lets us carry custody operations end to end. This is the fastest path to production and the right starting point for most.

Hybrid (one peer on your infrastructure). The institution runs one signing peer inside its own cluster through Mission Control, and we run the other two. Nothing about signing changes — it is still two-of-three — but now producing a signature requires reaching across an organizational boundary as well as a substrate one. Neither side can sign alone, and neither side can sign without the other participating. That is often the sweet spot: real custody leverage without taking on the full operational weight of three peers.

Self-hosted (the full signing quorum on your infrastructure). The institution runs all three peers in environments it owns and controls, and Mission Control still handles orchestration, monitoring, upgrades, and recovery so the operational complexity it does not care about stays abstracted away. Maximum control, and the institution carries correspondingly more of the operational burden.

Why this matters for Financial Institutions

Institutions adopt this model not just for architectural elegance but for reasons that survive a risk review.

One compromise does not become a loss, because no single API, node, database, or cloud can move funds alone. Automation and governance stay in separate trust domains, so treasury and product systems automate freely without any one credential quietly becoming a superuser over the approval model. Auditability is something the system produces as it runs approvals, signing requests, transaction state, delivery state, all durable rather than something we reconstruct after an incident and hope holds up.

The design also assumes operational reality. Retries, partial outages, timeouts, scanner lag, stale receipts, and infrastructure replacement are treated as normal conditions the system recovers from, not edge cases. That same flexibility extends to the custody boundary itself: an institution can run managed, self-hosted, or hybrid control without changing the core operating logic underneath.

Threshold cryptography sits at the center of all of this, but it is necessary rather than sufficient. The signing core only becomes usable financial infrastructure once policy, approvals, chain reconciliation, event delivery, recovery, and observability are built around it.

Conclusion

What financial institutions need from wallet infrastructure is not just cryptography. They need controlled authority, durable evidence, operational resilience, and flexibility over where the custody boundary lives.

That is what Blockops has built.

If your institution needs self-custody infrastructure it can actually answer for, let’s talk. I’ll give you a technical walkthrough and a deployment model (managed, self-hosted, or hybrid) mapped to your requirements.

Here is my calendar link, Feel Free to schedule a call

Thank you