Threshold custody

Binding a model to one GPU still leaves one party who can unseal it: whoever controls that GPU. Threshold custody removes even that. A model's key is split across several parties, and only a quorum, cooperating, can use it. No single party holds enough to unseal — and any party can revoke and make the model permanently unrecoverable.

This is the difference between "trust the operator" and "trust the math."

The shape

Take three parties — say a bank, a regulator, and the data subject — each on their own GPU. The model is distributed so all three are required to use it, and each holds a veto:

The custody handoff is set up once, naming each party and the quorum required. From then on:

• All three cooperate — each contributes from its own GPU, and the key is recovered.
• The subject destroys their share — and any later attempt refuses with QUORUM_UNAVAILABLE, permanently.

Each party's share is sealed to that party's own GPU. Steal one card and you get one share — useless. The data subject can destroy their share unilaterally, and the model becomes permanently unrecoverable even though the bank and regulator still hold theirs.

Any quorum, not just three

Three parties is an illustration, not a limit. The scheme is k-of-n: split a key across any n parties and require any k of them to cooperate.

• k = n (unanimous) — every party is required and every party holds a veto. Best when each stakeholder must consent to every use (the bank/regulator/subject case above is 3-of-3).
• k < n (fault-tolerant quorum) — e.g. 3-of-5 or 5-of-9. The model still runs if some parties are offline or a few GPUs are lost, and it tolerates a minority of compromised or uncooperative holders. Raising k tightens control; lowering it raises availability.

Tune k and n to the trust model: unanimous consent, majority governance, geographic/jurisdictional spread, or an m-of-n admin quorum that removes any single operator from the loop.

Zero-reconstruct by default

There are two ways to split a key, and the default is the stronger one.

• Threshold DPRF (default). A master secret is shared once. To use the model, each party computes a partial evaluation on its own GPU and contributes only the result — never the share. A combiner interpolates the partials to the key without the master secret ever being reassembled anywhere. Compromising the combiner during one use leaks one key, not the master that derives all keys.
• Shamir (opt-in). The data key is Shamir-split and reassembled on one worker at reconstruction time. This is a genuine weakening — the key exists whole, briefly, on one machine — and it is why it is not the default.

Because the DPRF path never gathers the shares and never reconstructs the master secret, no single party — including the operator running the combine — can unseal alone. That property holds by construction, not by policy.

Why it matters

• Sovereign payments, escrow, evidence custody — counterparties who trust neither each other nor each other's tech stacks can share custody of a model or a key without any of them, or the operator, being able to act alone.
• Individual consent made real. "The individual can revoke their access" stops being a policy promise and becomes a cryptographic fact: the subject's share is required, and destroying it ends access for everyone.
• No hardware-vendor single point of trust. Where attestation still leans on a chip vendor's signing chain, threshold custody spreads trust across independent parties — closer to information-theoretic security than any single TEE.

Combine with sovereign mode and every party runs on its own hardware, with its own key, holding its own share.