> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blockops.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Who holds the keys

> Where wallet key shares live under each deployment model, and what Blockops can and cannot do with them.

A wallet's private key never exists in one place. It is created as shares, one per signing node, and used only when a threshold of nodes cooperates. So the question "who holds the keys" has a precise answer: **whoever operates the signing nodes holds the shares, and no party holding fewer shares than the threshold can sign.**

| Deployment model | Shares held by                                                 | Can Blockops sign alone?                                                            | Can the institution sign alone? |
| :--------------- | :------------------------------------------------------------- | :---------------------------------------------------------------------------------- | :------------------------------ |
| **Managed**      | Blockops, across independently operated nodes                  | Yes, through the platform's policy and approval flow, never by an individual system | No                              |
| **Hybrid**       | Split between Blockops-operated and institution-operated nodes | No                                                                                  | No                              |
| **Self-hosted**  | The institution                                                | No                                                                                  | Yes                             |

## What the platform never does

* **Assemble the private key.** Key generation produces shares directly; signing produces a signature. There is no step at which the full key exists on any machine.
* **Sign outside the flow.** Every signing command must be signed by the trusted initiator identity and must have passed authentication, policy and, where required, approval. The signing cluster rejects anything else.
* **Let an API key change the rules.** Scoped keys can request operations within policy; they cannot alter policy, approve requests, or disable controls.

## What you control in every model

* **Who can initiate and who can approve**, through roles, approval groups and dual control.
* **Where funds may go**, through destination whitelists and the hold period for new addresses.
* **How much can move**, through per-transaction and daily limits.
* **Whether anything moves at all**, through the kill switch.
* **What happened**, through the audit trail and signed webhook events.

## Choosing a model

If your policy requires key material inside your own perimeter, choose **self-hosted**. If you want a cryptographic veto without operating everything, choose **hybrid**: your node is required for every signature. If you want the platform without running signing infrastructure, choose **managed**. Wallets can move between models by resharing, without changing addresses. See [Deployment models](/overview/deployment-models).