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

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

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.

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.

Related

• Core concepts: the objects the API works with.
• How the platform is secured: the trust boundaries in detail.
• Threshold signing with citadel-core: the cryptography.