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

# Platform architecture

> How the wallet API, the MPC signing cluster and the chain operations layer fit together, and where authority lives in each.

Blockops MPC Wallet Infrastructure is built on one rule: **no single system can move funds on its own.** The API cannot sign. A signing node cannot sign alone. The database holds operational state, not key material. Each layer holds a different kind of authority, and a transaction has to pass through all of them.

## The layers

<Frame caption="The five layers. Only the signing cluster's location changes with the deployment model.">
  <img className="block dark:hidden" src="https://mintcdn.com/blockops-3855c227/OGmnNOc7FURsTCyJ/images/diagrams/platform-layers-light.svg?fit=max&auto=format&n=OGmnNOc7FURsTCyJ&q=85&s=f6823438d342aa76bf079849069e0049" alt="The platform's layers from top to bottom: your systems, citadel-api (control plane), the operation ledger, the command and result plane, the citadel-core MPC signing cluster, and chain operations. The signing cluster is operated by Blockops, by you, or split." width="1100" height="720" data-path="images/diagrams/platform-layers-light.svg" />

  <img className="hidden dark:block" src="https://mintcdn.com/blockops-3855c227/OGmnNOc7FURsTCyJ/images/diagrams/platform-layers-dark.svg?fit=max&auto=format&n=OGmnNOc7FURsTCyJ&q=85&s=0ebf62b201612b980b05d743c3478aa6" alt="The platform's layers from top to bottom: your systems, citadel-api (control plane), the operation ledger, the command and result plane, the citadel-core MPC signing cluster, and chain operations. The signing cluster is operated by Blockops, by you, or split." width="1100" height="720" data-path="images/diagrams/platform-layers-dark.svg" />
</Frame>

| Layer                        | What it owns                                                                                                                                                    | What it cannot do                                                                                |
| :--------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------------------------------------------------------------------------------------------- |
| **citadel-api**              | Admits requests, authenticates them, enforces policy, records intent, and asks the signing cluster for cryptographic work.                                      | Produce a signature. It never holds enough key material to sign.                                 |
| **Operation ledger**         | Durable state for every wallet, withdrawal, signing request, approval and delivery.                                                                             | Reconstruct a key. It stores operational truth, not signing secrets.                             |
| **Command and result plane** | Durable delivery of keygen and signing commands to the cluster, and of results back, with correlation IDs and timeouts.                                         | Alter a request. Commands are signed by a trusted initiator identity and verified by every node. |
| **citadel-core**             | Key shares and threshold signing. Each node holds one share of each wallet key in an encrypted local store.                                                     | Sign alone. A signature needs a threshold of nodes to take part in an interactive protocol.      |
| **Chain operations**         | Turning a signature into a confirmed on-chain event: building the transaction, broadcasting it, reconciling receipts and confirmations, and observing deposits. | Authorise a spend. Signing proves authorisation; this layer proves what happened on chain.       |

## How a transaction moves through the platform

1. **Request**: your system calls the API with a scoped, HMAC-signed request and an idempotency key.
2. **Authorisation**: the API checks the key's scopes and wallet binding, then evaluates workspace policy. A matching rule can require approval before anything else happens.
3. **Approval**: if required, the request waits for the approval group to decide. Approvers act in the console; an initiator cannot approve their own request when dual control is on.
4. **Planning**: the API builds the transaction from trusted server-side state: nonce, gas, chain ID and recipient are never taken from the client.
5. **Signing**: a durable signing command goes to the cluster. Nodes verify the initiator's signature, check readiness, and run the threshold protocol. The result is a signature; the private key is never assembled.
6. **Broadcast**: the API assembles the signed transaction, checks that its hash matches what was persisted, and submits it to the network.
7. **Confirmation**: the chain operations layer polls for the receipt and marks the withdrawal confirmed once it reaches the configured confirmation depth.
8. **Notification**: each state change is written to the ledger and delivered to your webhook endpoints as a signed event.

<Frame caption="Steps 5 and 6: the signing command's path. Authorization happens before it; the cluster checks only that the command is authentic.">
  <img className="block dark:hidden" src="https://mintcdn.com/blockops-3855c227/OGmnNOc7FURsTCyJ/images/diagrams/signing-path-light.svg?fit=max&auto=format&n=OGmnNOc7FURsTCyJ&q=85&s=41620da52745ff3ded893e1e62a55a37" alt="citadel-api signs a command with the event-initiator key, optionally with authorizer co-signatures attached, and sends it over the mTLS message plane to the three citadel-core nodes, which verify the signatures, run the threshold protocol and return a signature, never the private key." width="1100" height="470" data-path="images/diagrams/signing-path-light.svg" />

  <img className="hidden dark:block" src="https://mintcdn.com/blockops-3855c227/OGmnNOc7FURsTCyJ/images/diagrams/signing-path-dark.svg?fit=max&auto=format&n=OGmnNOc7FURsTCyJ&q=85&s=a4d2ba2a5c6f5a3506df32cc19e4dae2" alt="citadel-api signs a command with the event-initiator key, optionally with authorizer co-signatures attached, and sends it over the mTLS message plane to the three citadel-core nodes, which verify the signatures, run the threshold protocol and return a signature, never the private key." width="1100" height="470" data-path="images/diagrams/signing-path-dark.svg" />
</Frame>

Every step leaves durable state behind. If a command times out, the state says so. If a result arrives late, it cannot revive an operation that has already failed. If a worker restarts, it resumes from what was stored.

## Where things run

The API, ledger and chain operations are operated by Blockops. The MPC signing cluster can run in Blockops-operated infrastructure, in yours, or split between the two; see [Deployment models](/overview/deployment-models). Whichever model you choose, the layering above is the same.

## Related

* [Core concepts](/overview/core-concepts): the objects the API works with.
* [How the platform is secured](/security/how-the-platform-is-secured): the trust boundaries in detail.
* [Threshold signing with citadel-core](/security/threshold-signing): the cryptography.