> ## 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.

# Advanced — RPC and bytecode

> Compile Solidity, deploy bytecode, and call QRC-compatible contracts through Qustody or Quantum Chain RPC.

This page describes **Path B** — deploying and operating custom QRC-compatible contracts without the managed Token Management API. Path B works through the existing transaction endpoints (`POST /v1/transactions` with operation `CONTRACT_CALL` or `RAW`) and reuses Qustody's approval and post-quantum signing pipeline.

<Warning>
  Path B is powerful and unforgiving. There are no typed mint/burn/role validations — every byte of calldata you submit is yours to verify. Test on Quantum Chain testnet, verify the deployed bytecode against your source, and gate the deployment with a strict approval policy.
</Warning>

## End-to-end flow

```mermaid theme={null}
flowchart TD
  A[Write QRC-compatible Solidity contract] --> B[Compile contract]
  B --> C[Generate ABI and bytecode]
  C --> D[Create deployment transaction in Qustody]
  D --> E[Submit through Qustody]
  E --> F[Approval policy gate]
  F --> G[Post-quantum signing]
  G --> H[Broadcast to Quantum Chain]
  H --> I[Contract deployed at on-chain address]
  I --> J[Encode function calls with ABI]
  J --> K[Submit each call as a Qustody transaction]
  K --> L[Track status and confirmations]
```

## Step 1 — Write a QRC-compatible Solidity contract

Use any standard Solidity workflow. The QVM is bytecode- and opcode-compatible with the EVM (Berlin/London), so existing Solidity that does **not** rely on `ecrecover` will compile and run unmodified. If you need in-contract signature verification, call the post-quantum precompile at `0x0b` — see [QVM vs EVM](/quantum-chain/qvm-vs-evm).

## Step 2 — Compile

Any standard toolchain works (`solc`, Foundry's `forge build`, Hardhat, etc.). Produce two artifacts: the **ABI** (JSON) and the **deployment bytecode** (hex string).

## Step 3 — Build the deployment transaction

Construct a Qustody transaction request with the deployment bytecode as the `data` payload and an empty `to` address. Use a vault account that holds enough native currency for gas.

```http theme={null}
POST /v1/transactions
Content-Type: application/json
Idempotency-Key: deploy-mytoken-2026-04-27

{
  "operationType": "CONTRACT_CALL",
  "from": { "type": "vaultAccountId", "vaultAccountId": "vault_123" },
  "to": null,
  "data": "0x60806040…",
  "value": "0",
  "feeStrategy": "MEDIUM"
}
```

## Step 4 — Approval

Qustody evaluates the configured [approval policy](/concepts/policies). For deployments, configure `REQUIRE_APPROVAL` with a multi-approver quorum.

## Step 5 — Post-quantum signing

Once approved, the transaction enters `PENDING_SIGNATURE`. Either:

* The configured signer signs automatically (gRPC or remote modes), or
* You fetch the signing payload, sign externally, and submit the signature back:

```http theme={null}
GET  /v1/transactions/{id}/signing_payload
POST /v1/transactions/{id}/signature
```

See [external signing](/guides/external-signing) for the full flow.

## Step 6 — Broadcast and confirmation

Qustody broadcasts the signed transaction and walks it through `BROADCASTING → CONFIRMING → COMPLETED`. The `receipt.contractAddress` field on the transaction contains the deployed contract address.

## Step 7 — Encode function calls

For every subsequent contract call, ABI-encode the call data client-side and submit a `CONTRACT_CALL` transaction:

```http theme={null}
POST /v1/transactions

{
  "operationType": "CONTRACT_CALL",
  "from": { "type": "vaultAccountId", "vaultAccountId": "vault_123" },
  "to": "0x9a8e5e21f0c27d2c5c14b6e9bd8e4a0f9c9b4d12",
  "data": "0xa9059cbb000000000000000000000000…",
  "value": "0",
  "feeStrategy": "MEDIUM"
}
```

Use any ABI library (`ethers.js`, `web3.py`, `go-ethereum/accounts/abi`) to produce the `data` payload.

## Step 8 — Track transaction status

Poll `GET /v1/transactions/{id}` or subscribe to `transaction.status_changed`, `transaction.completed`, `transaction.failed` webhooks.

## Step 9 — Verify contract state

Query state through Quantum Chain RPC (e.g. `eth_call`) or via your own indexer. Qustody does not currently expose a generic contract-state read endpoint for custom contracts.

## Step 10 — Security warnings

* **Bytecode you submit is bytecode you bear.** Audit your contract before mainnet.
* **`ecrecover` is removed** from the QVM. Any inherited Solidity that uses it will revert on call. See [QVM vs EVM](/quantum-chain/qvm-vs-evm).
* **`tx.origin` is still available** but inadvisable for authorization decisions.
* **Use `Idempotency-Key` on every write request.** Network retries are otherwise unsafe.
* **Treat upgrades as deployments.** A privileged-upgrade transaction is its own privileged operation.

## Related

* [Advanced contracts overview](/qustody/token-management/advanced-contracts)
* [Guide — Deploy a custom token contract](/guides/deploy-a-custom-token-contract)
* [QVM vs EVM](/quantum-chain/qvm-vs-evm)
* [Sending transactions](/quantum-chain/sending-transactions)
* [External signing](/guides/external-signing)