Whoever holds the private key holds the asset — that is the unforgiving rule of self-custodied crypto, and it is why a single stored key is a single point of failure. Multi-party computation (MPC) custody answers it by never letting the whole key exist in one place. The key is split into mathematical shares distributed across separate nodes; to sign a transaction, the nodes run a joint protocol that produces a valid signature without any node ever reconstructing the complete private key. An “MPC custody patent” does not claim that cryptographic idea, which is published and decades deep in the literature. It claims a specific engineered system for creating, using, and protecting those shares — and, as always, the boundary of the right is the language of the independent claims.

A concrete example is US12615147B2, assigned to Nasdaq, Inc. and titled “Systems and methods to replicate private key shares from multi-party computation (MPC) nodes in a primary subsystem to MPC nodes a backup subsystem.” Its abstract is unusually explicit about the machinery, which makes it a good lens on what these claims actually fence:

“A system includes a primary asset custody subsystem in a first cloud computing data center and a backup asset custody subsystem in a second cloud computing data center different from the first cloud computing data center. The primary subsystem includes a plurality of primary multi-party computation (MPC) clusters, where each primary MPC cluster is allocated to an asset owner and includes a primary MPC client and a plurality of primary MPC nodes.”— Systems and methods to replicate private key shares from MPC nodes, US12615147B2

Read what the limitations name. There are two subsystems in two different cloud data centers; each holds MPC clusters; each cluster is allocated to an asset owner and contains a client and multiple nodes. The invention is not “use MPC for custody.” It is a particular topology and a particular backup procedure — the abstract goes on to recite exporting public keys from backup nodes, encrypting each private key share with a corresponding export public key, transmitting the encrypted shares, and decrypting them at the backup nodes so the backup can take over operation. The claim's value, and its limit, is in that specificity: a system that distributes shares differently, or that backs them up by another route, may sit outside it. The CPC profile confirms where it lives — H04L 9/0894 and H04L 9/0825 (key management and distribution) together with H04L 9/50 (the blockchain code).

What the broader cluster shows

The same assignee's related grant US12445274B2 covers a system that “dynamically provisions clusters of multi-party computation (MPC) nodes to securely create different private key shares for signing digital asset transactions and generate blockchain addresses for digital asset owners.” And separate authentication-and-authorization grants such as US12238224B2 describe supporting “a range of cryptographic methods… including split key encryption, multi-party computation, multi-signature authorization, and execution of decentralized smart contract authorization logic.” Read together, the records trace the layers of the custody problem — generating shares, signing from them, replicating them for resilience, and binding signing to an authorization model. Each grant fences one layer; none owns “MPC.”

Reading an MPC custody claim without overstating it

The reason these patents read so structurally is that the custody problem is itself structural. A custodian has to hold keys in a way that is simultaneously available enough to sign legitimate transactions quickly and isolated enough that a breach of any single component cannot move funds — the tension that the industry shorthand of “hot” (connected) versus “cold” (offline) custody only partly captures. MPC reframes that tension: instead of choosing where to store one whole key, the designer chooses how to split, distribute, and recombine shares, and where the signing protocol runs. Every one of those choices — how many shares, how many must cooperate to sign, which cloud or hardware boundary each node sits behind, how shares are rotated or backed up — is an engineering decision, and each is a candidate limitation in a claim. That is why the issued grants read like systems diagrams rather than mathematical statements: the patentable contribution is the specific architecture, and the architecture is what the claims fence. A reader who understands the underlying tension can predict where a custody patent will add detail, because that is where the real design work, and the real claim scope, concentrates.

Three cautions apply. First, distinguish the primitive from the claim: MPC and threshold signatures are public techniques, so a custody patent must add specific structure — node topology, share lifecycle, backup or signing procedure — and that added structure is exactly what to read. Second, watch the verbs and the named components in claim 1: generate shares, distribute to nodes, sign jointly, replicate or back up — the recited sequence and the named subsystems are the actual scope. Third, a grant establishes that the recited combination issued, not that it is broad, foundational, or in production; comparable custody systems built on the same primitive can coexist if they fall outside the claimed structure. With those habits, “MPC custody patent” resolves from a buzzword into something precise: a claim on a particular way of splitting, using, and protecting the key shares that control on-chain assets. The underlying multi-party computation is a shared, published technique that no patent owns; what an issued grant fences is the specific node topology, share lifecycle, and signing or backup procedure its independent claims recite, and that recited architecture — not the buzzword — is the whole of what such a patent covers.