The hot wallet is the part of an exchange that has to stay online to move customer funds, and it is therefore the part everyone is most afraid of. The whole design tension is captured in one phrase: a hot wallet must be able to sign, but you do not want it to be able to sign by itself. US12,014,361, granted to Coinbase, Inc. on June 18, 2024, claims one specific resolution of that tension, and claim 1 reads as a tight choreography rather than a broad principle.

The flow begins when the platform receives a transaction request. Rather than reaching for a resident signing key, the platform requests share-encryption keys — the patent calls them SEKs — from operator devices, and receives requests to download the encrypted SEKs in return. The shares the platform holds are useless on their own; they are ciphertext until an operator supplies the SEK that unlocks them.

The computing platform may decrypt encrypted shares using the SEKs, and may use the decrypted shares to reconstruct a cryptographic signing key.

Once operators have supplied the SEKs, the platform decrypts the encrypted shares, reconstructs the signing key from the decrypted shares, validates that reconstructed key, and — only on successful validation — authorizes the requested transfer. The validation step is not decoration; it is a recited limitation. The claim does not merely reconstruct and sign; it reconstructs, checks, and gates on the check.

The limitation that defines the scope is the operator dependency. The signing key does not persist in usable form on the platform; it is reconstituted per transaction only after operator devices participate by returning decrypted SEKs. That is the security claim and the claim-scope claim at once: an attacker who fully owns the platform still cannot sign, because the SEKs live on operator devices outside it. What the independent claim captures is this exact request-supply-decrypt-reconstruct-validate-authorize sequence with operators in the loop.

What it does not capture is broad. A hot wallet that keeps a threshold-signing key live and signs via MPC without ever reconstructing a single key reads differently — there is no reconstruction step to infringe. A wallet that stores its signing key in an HSM and gates on a quorum policy, but never ships share-encryption keys from operator devices to decrypt platform-held shares, is also outside the recited flow. The grant is not “Coinbase owns hot-wallet security”; it is Coinbase owning this particular reconstruct-on-demand-with-operator-SEKs mechanism.

The CPC tags line up with that reading: G06Q 20/3678 (e-money/virtual currency mechanisms), H04L 9/085 (secret sharing), H04L 9/0861 (key generation), H04L 9/3247 (digital signatures), and H04L 9/50 (blockchain). The presence of both the payments class and the blockchain class marks this as application-layer custody IP — squarely about moving on-chain customer funds, not a generic cryptographic primitive.

It is worth sitting with the validation limitation, because it is the part most easily skipped in a casual read. Reconstructing a key from shares is not self-verifying; a corrupted share, a tampered SEK, or a faulty operator response could yield a key that is wrong but still usable enough to produce a signature over the wrong transaction. The claim's insistence on validating the reconstructed signing key before authorizing the transfer is therefore a substantive guard, not ceremony. It also tightens scope: a system that reconstructs and immediately signs, with no validation gate, is performing a different recited method. Limitations like this are where claim teardowns earn their keep — the difference between "reconstruct then sign" and "reconstruct, validate, then authorize" is exactly the kind of distinction an infringement analysis turns on.

There is also a design philosophy embedded in the per-transaction framing that is worth naming. The signing key is not a thing that exists and is guarded; it is a thing that is briefly assembled, used, and dissolved, with operator participation required to assemble it each time. That ephemerality is the security premise. It means the window in which a full signing key exists on the platform is as short as the transaction flow, and it means a static compromise of platform storage yields ciphertext shares and nothing more. Whether competing architectures choose ephemerality-via-reconstruction or never-reconstruct threshold signing is precisely the axis on which this claim's scope turns.

There is a crossover angle worth flagging for readers who also follow the filings. Coinbase (COIN) is a listed company that describes custody and key-management risk to investors in its periodic disclosures; a grant like this is the operational counterpart to that risk language. The patent is what the engineering looks like; the 10-K risk factor is how the company frames the residual exposure to shareholders. The two read well together, and a reader mapping Coinbase's security posture should hold both.

The inventors named — Jeremy Suurkivi, Andrew Pau, and Jayasudha Jayakumaran — are building exchange-side custody plumbing, and this grant is one brick in a larger Coinbase estate. The disciplined takeaway is the usual one for this register: the grant is real and the mechanism is concrete, but its blocking power is exactly the width of the recited sequence. Before anyone cites this as proof that Coinbase has fenced hot-wallet security as a category, read claim 1 — the operator-supplied-SEK reconstruction is the whole ballgame, and most secure-signing architectures route around it. The canonical record is deep-linked above.