> ## 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.

# Threshold signing with citadel-core

> How citadel-core generates keys as shares, signs with a threshold of nodes, protects the shares, and reshares them to a new set of nodes.

`citadel-core` is the Blockops MPC node runtime. A cluster of nodes generates wallet keys as separate shares and produces signatures through a threshold protocol, so that the private key is never assembled on any machine.

## The threshold scheme

A cluster has **n** nodes, each holding one share of every wallet key, and a threshold **t**: the number of nodes that must take part to produce a signature. The cluster enforces `t ≥ ⌊n/2⌋ + 1`, so a minority of nodes can never sign. The standard managed deployment is three nodes with a two-of-three threshold.

| Operation          | Nodes required                    | Result                                                                                   |
| :----------------- | :-------------------------------- | :--------------------------------------------------------------------------------------- |
| **Key generation** | All *n* nodes                     | Each node stores its own encrypted share; the wallet's public key is recorded.           |
| **Signing**        | Any *t* nodes                     | A valid signature for the requested digest.                                              |
| **Resharing**      | The old committee and the new one | Shares redistributed to a new set of nodes or a new threshold, with the same public key. |

Signing needs only the threshold, so a two-of-three cluster keeps signing while one node is offline. Key generation needs every node, because each one must create its own share.

## Curves and chains

The runtime signs with **ECDSA on secp256k1** (Ethereum and EVM-compatible networks, Bitcoin) and **EdDSA on Ed25519** (Solana, Polkadot and other Ed25519 networks). Which networks are available to wallets is a product matter, not a cryptographic one; see [Supported networks & assets](/overview/supported-networks).

Child keys are derived deterministically from a wallet key using a cluster-wide chain code, so one wallet can hold addresses on several networks. For EVM networks the derivation path is fixed on the server; clients never supply one.

## Inside a node

Each node runs the same runtime; there is no primary. On start, a node loads its identity, opens its encrypted share store, connects to the messaging plane, and registers as ready. It then consumes key-generation and signing commands, takes part in sessions, and publishes results. If any critical configuration is missing or inconsistent, the node refuses to start rather than run half-configured.

**Identity and messages.** Every node has an Ed25519 identity. All protocol messages are signed and verified. Messages sent directly between two nodes are encrypted with keys derived from the two identities, so the messaging layer never sees plaintext protocol state. Transport to the messaging plane is mutually authenticated TLS.

**Command authorisation.** Commands to generate a key, sign, or reshare must be signed by a trusted initiator identity configured on every node. Unsigned or wrongly signed commands are rejected before a session opens. Clusters can additionally require signatures from a set of named authorisers on every command.

**Share storage.** Shares live in an embedded database encrypted with AES-256. The node will not start without the encryption passphrase, which is supplied at runtime and kept separately from the storage volume. Backups are encrypted with the same key before any storage-level encryption applies.

**Readiness.** A node advertises readiness; the cluster checks that enough nodes are ready before it starts a session, so that work which cannot complete is refused rather than left hanging.

## Resharing

Resharing moves a wallet's shares to a new set of nodes, or changes the threshold, while preserving the wallet's public key and therefore every address derived from it. It is how a node is replaced, how an institution-operated node is added to a hybrid deployment, and how a deployment moves between models without migrating funds. Because it changes who can sign, it is treated as a governed operation with an audit record, not a routine API call.

## What the API adds around the runtime

The runtime provides distributed key generation, threshold signing and resharing. Everything that makes those usable for an institution (authentication, policies and approvals, the operation ledger, transaction planning and broadcast, reconciliation, webhooks, audit and recovery) is provided by `citadel-api` and the chain operations layer. See [Platform architecture](/overview/platform-architecture).