Skip to main content
This guide describes a flow that works today. Path B reuses the existing transaction endpoints (POST /v1/transactions with CONTRACT_CALL) and the Qustody approval + post-quantum signing pipeline.
You will compile a QRC-compatible Solidity contract, deploy it through Qustody, and call a function on the deployed contract.

Prerequisites

  • A Solidity toolchain (solc, Foundry, or Hardhat).
  • A Qustody tenant and an API key with transactions:create permission.
  • A vault account with native currency for gas.
  • An approval policy that requires approval for CONTRACT_CALL deployments.

Step 1 — Compile Solidity

You now have build/MyToken.bin (deployment bytecode) and build/MyToken.abi (ABI).

Step 2 — Prepare the deployment payload

If your constructor takes arguments, ABI-encode them and append to the bytecode. For example, with ethers.js:

Step 3 — Submit the deployment transaction

Qustody returns a transaction in PENDING_AUTHORIZATION.

Step 4 — Approve

An approver calls:
The transaction enters PENDING_SIGNATURE.

Step 5 — Post-quantum signing

If your signer is configured to sign automatically (gRPC or remote modes), the transaction continues. Otherwise, fetch the signing payload and submit the signature:
See external signing.

Step 6 — Read the contract address

After confirmation:
The response includes receipt.contractAddress. Save it for later calls.

Step 7 — Call a function

ABI-encode the call data and submit a contract call:

Step 8 — Verify state via RPC

Use Quantum Chain RPC to read state:

Caveats

  • The QVM removes the ecrecover precompile. Solidity that depends on it will revert. Use the post-quantum precompile at 0x0b instead — see QVM vs EVM.
  • BIP-32 / BIP-44 derivation is not applicable to post-quantum keys.
  • Treat upgrades as deployments — the upgrade transaction is its own privileged operation.