The Qustody API is a non-custodial orchestration layer. It manages transaction lifecycle, policy enforcement, and event delivery, but never holds private keys.Documentation Index
Fetch the complete documentation index at: https://docs.quantumapi.io/llms.txt
Use this file to discover all available pages before exploring further.
Non-custodial signing model
Unlike traditional custodial solutions, the Custody API delegates all signing to your infrastructure. This means:- You control the keys. Post-quantum private keys live in your HSM, secure enclave, or key management system
- The API orchestrates. It creates transactions, enforces policies, and broadcasts signed transactions to the Quantum Chain network
- Signing is a callback. When a transaction needs signing, you retrieve the payload, sign it externally, and submit the signature back
Transaction lifecycle
Every transaction moves through a deterministic state machine of 14 states. The diagram below shows the most common transitions; see Transaction state machine for the full table.| State | Description |
|---|---|
SUBMITTED | Accepted; awaiting policy and screening evaluation |
QUEUED | Held briefly because of an idempotency conflict or rate limit |
PENDING_AUTHORIZATION | Awaiting manual approval per policy |
PENDING_AML_SCREENING | Compliance screening in flight |
APPROVED | Authorization granted, transitioning to signing |
PENDING_SIGNATURE | Ready for external post-quantum signature |
SIGNED | Signature received and verified |
BROADCASTING | Submitted to Quantum Chain nodes |
CONFIRMING | Included in a block, waiting for confirmation depth |
COMPLETED | Confirmed with sufficient block depth |
FAILED | Transaction reverted, broadcast failure, or invalid signature |
REJECTED | Denied by policy or approver |
CANCELLED | Cancelled before signing or broadcasting |
BLOCKED | Compliance screening flagged or blocked the transaction |
Request flow
A typical transfer follows this sequence:Create transaction
Your application calls
POST /v1/transactions with source, destination, and amount. The API validates the request and runs it through the policy engine.Policy evaluation
Configured policies are evaluated: spending limits, whitelist/blacklist checks, approval requirements, and time windows. If a policy requires approval, the transaction moves to
PENDING_AUTHORIZATION.Retrieve signing payload
Call
GET /v1/transactions/{id}/signing_payload to get the unsigned transaction digest as a hex-encoded byte array.Sign externally
Sign the digest with your post-quantum private key using your key management solution.
Submit signature
Call
POST /v1/transactions/{id}/signature with the base64-encoded signature and the signer’s public key. The API verifies the signature before accepting it.Broadcast and confirm
The API broadcasts the signed transaction to the Quantum Chain network via the node pool and tracks confirmation depth.
System components
| Component | Role |
|---|---|
| API Server | HTTP handlers, authentication, rate limiting |
| Policy Engine | Pre-broadcast rule evaluation and enforcement |
| Node Pool | Manages multiple Quantum Chain RPC connections with failover |
| Deposit Monitor | Watches for inbound transfers to registered wallets |
| Confirmation Tracker | Monitors block depth for pending transactions |
| Webhook Dispatcher | Delivers events with HMAC signing, retry, and dead-letter |
| Recovery Worker | Re-processes stuck transactions after restarts |
| Idempotency Cleanup | Prunes expired idempotency keys |
Multi-tenancy
The API supports multiple tenants with full isolation:- Each tenant has its own API credentials, vaults, wallets, policies, and webhook endpoints
- Cross-tenant access is prevented at the middleware layer
- Tenant context is extracted from the API key and propagated through all service calls
Post-quantum signatures
Quantum Chain uses a post-quantum digital signature scheme offering security equivalent to ~192-bit classical cryptography:| Property | Value |
|---|---|
| Security | ~192-bit classical equivalent |
| Digest size | 32 bytes |