Skip to main content
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

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

The five layers. Only the signing cluster's location changes with the deployment model.

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

Steps 5 and 6: the signing command's path. Authorization happens before it; the cluster checks only that the command is authentic.

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. Whichever model you choose, the layering above is the same.