Two products, two responsibilities

Quantum Chain is the network. Qustody is the operational layer.

You can build directly on Quantum Chain without Qustody. You can also use Qustody to organize institutional wallet operations on Quantum Chain. The correct choice depends on who owns signing, policy, submission, and lifecycle handling in your system.

Short answer System layers Responsibility matrix Choose a path Using both

Short answer

Do not use the names interchangeably.

Quantum Chain

A blockchain network with its own chain identity, native currency, transaction format, post-quantum account authorization, QVM execution, blocks, receipts, logs, and JSON-RPC interface.

Use the direct SDKs when your application controls transaction construction and signing.

Start a direct integration

Qustody

A separate custody and wallet operations product. It adds organizational workflows such as users, vault accounts, policies, approvals, audit, and managed transaction lifecycle around blockchain activity.

Use Qustody when those operational controls are part of your integration.

Open Qustody documentation

Independent useNeither product is a renamed version of the other. Direct Quantum Chain RPC and SDK use does not require a Qustody account, Qustody API credential, EnQlave installation, vault account, or approval workflow.

System layers

Place each component at the correct layer.

Your applicationBusiness intent, recipient, value, calldata, and application policy.

Integration pathDirect Quantum SDK and RPC, or Qustody APIs and workflows.

Signing boundaryAn approved local, remote, hardware, or EnQlave-connected signer for the chosen path.

Quantum ChainTransaction execution, state, blocks, receipts, logs, and final network record.

Quantum Chain is always the blockchain layer. Qustody can sit above it, but it does not replace the chain, QVM, node, transaction envelope, or receipt.

The direct SDKs construct the canonical Quantum transaction and return or submit its signed bytes. Qustody owns a different API contract centered on operational resources and controlled workflows. Do not send direct SDK objects to Qustody endpoints or treat Qustody resource identifiers as on-chain addresses.

Responsibility matrix

Know which system owns each job.

Capability	Direct Quantum Chain integration	Qustody integration
Blockchain execution	Quantum Chain	Quantum Chain
Chain ID, genesis, blocks and receipts	Quantum Chain RPC	Quantum Chain beneath the Qustody workflow
Transaction serialization	`@quantum_chain/sdk` or `py-quantum`	Handled through the Qustody transaction lifecycle
Post-quantum cryptography	Quantum native SDK or your compatible signing boundary	Qustody-compatible signing path, commonly with EnQlave or another approved signer
Nonce, gas and broadcast	Your application, or the full JavaScript SDK	Qustody workflow
Receipt polling and confirmations	Your application, or the full JavaScript SDK	Qustody lifecycle tracking
Organization users and roles	Your application	Qustody
Vault accounts and wallet records	Not a chain concept	Qustody
Approval policy and operational audit	Your application	Qustody
Smart-contract bytecode and state	Quantum Chain QVM	Quantum Chain QVM, orchestrated through Qustody where applicable

Choose an integration

Start with the responsibility you want to own.

Choose direct Quantum Chain

Your adapter already owns RPC submission and transaction lifecycle.
You need raw signed transactions, local transaction hashes, signatures, and public keys.
You are building protocol tooling, infrastructure, a wallet, an indexer, or a focused blockchain service.
You will implement your own key authorization and operational policy outside the SDK.

JavaScript SDK · Python SDK

Choose Qustody

You need organizational wallet operations rather than only blockchain primitives.
Users, roles, vault accounts, approvals, and auditable workflows are required.
Your process should coordinate signing and transaction lifecycle through one operational system.
Your team is integrating an EnQlave-compatible signing workflow.

Continue in Qustody documentation

Do not mix credentialsAn npm or Python SDK download credential is not a Qustody API credential. A Qustody credential is not an RPC key, private key, public key, or wallet address.

Using both

They can coexist without collapsing their boundaries.

A company may use the direct SDK for protocol tests, contract deployment pipelines, indexers, or low-level adapter components while using Qustody for governed production wallet operations. Keep the interfaces explicit:

Choose the direct or Qustody path for each transaction workflow.
Authorize the correct signing boundary for that path.
Construct the transaction through the owning integration contract.
Submit once through the path that owns nonce and broadcast state.
Track the final Quantum Chain transaction hash and successful receipt.

Do not have both systems independently allocate a nonce or submit the same intended transaction. One component must own the complete submission lifecycle.

Direct chain quickstartRun a complete Sandbox transfer with JavaScript or Python. Qustody documentationUse the separate custody and wallet operations guide.