> ## 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.
# MPC Wallet Infrastructure
> Create wallets, receive and send funds, enforce policy and approvals, and receive signed events through an API built for server-to-server use and a console for the people who govern it.
MPC Wallet Infrastructure gives an institution wallets whose keys never exist in one place, an API to operate them from its own systems, and the controls a treasury or compliance function expects: policies, approvals, limits, an emergency stop, and a complete audit trail.
## The pieces
| Component | Role |
| :--------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **citadel-api** | The control plane your systems integrate with. Authenticates requests, enforces policy, records every operation, and orchestrates signing and chain operations. |
| **citadel-core** | The MPC signing cluster. Generates keys as shares and signs with a threshold of nodes. Runs in Blockops infrastructure, yours, or both; see [Deployment models](/overview/deployment-models). |
| **Console** | Where people manage the workspace: approve requests, set policies and limits, manage members and API keys, register webhooks, and read the audit trail. |
## What you can do
Create MPC wallets, attach assets, get deposit addresses, read balances.
Request withdrawals, follow them from request to confirmation, sign digests.
Spend limits, whitelists, approval groups, dual control, the kill switch.
Signed delivery of every wallet, deposit, withdrawal and approval event.
Transaction history and export, balances, analytics, the audit trail.
Roles for people, scopes for keys, per-wallet access.
## Authentication
Requests to the API are signed with **HMAC-SHA256** using an API key and its secret. Three headers are sent with every request:
| Header | Value |
| :----------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `ACCESS-API-KEY` | The API key. |
| `ACCESS-TIMESTAMP` | Unix time in seconds. Requests more than five minutes from server time are rejected. |
| `ACCESS-SIGN` | `base64(hex(HMAC-SHA256(secret, message)))` where `message` is `method=&path=×tamp=&body=`. `PATH` includes `/api/v1`; `BODY` is empty for `GET`. |
Keys are created in the console under **Developer → API Key** with the scopes, wallet binding, IP allowlist and expiry you choose. The secret is shown once. See [Access control](/security/access-control).
## Conventions
* **Base path**: all routes are under `/api/v1`.
* **Response envelope**: every response is `{"success": bool, "message": string, "code": int, "data": …}`.
* **Request IDs**: every response carries an `X-Request-ID` header; send your own to have it echoed back and recorded.
* **Idempotency**: send `X-Idempotency-Key` on wallet creation and withdrawal requests. Repeating a request with the same key returns the original operation and never creates a second one.
* **Identifiers**: workspaces, wallets, catalog assets, withdrawals and signing requests are UUIDs. Catalog asset IDs are never contract addresses.
* **Asynchronous operations**: wallet creation and withdrawals return immediately with a status; you poll or subscribe to webhooks for completion.
## Environments
Integrate against the **sandbox** at `wallet-sandbox.blockops.network`, which runs on Ethereum Sepolia, before moving to production. Sandbox and production use the same API; only credentials and networks differ. Request sandbox credentials from [hello@blockops.network](mailto:hello@blockops.network), then follow the [quickstart](/get-started/first-wallet-and-transaction).