Skip to main content
Quantum Chain accepts the same transaction shapes as Ethereum: legacy, EIP-2930 (access list), and EIP-1559 (fee market). The only difference from Ethereum is the signature primitive — see Signing transactions.

​
Transaction fields

FieldRequiredNotes
fromyesSender address
toyes (transfer / call); no (deploy)20-byte address or null for contract creation
valuenoAmount in wei (default 0)
datanoCalldata for contract calls; constructor bytecode for deploys
nonceyesSender’s next nonce; fetch with eth_getTransactionCount
chainIdyes20803 for mainnet
gasyesGas limit
gasPricelegacy onlyIn wei
maxFeePerGas, maxPriorityFeePerGasEIP-1559 onlyIn wei
accessListoptionalEIP-2930 access list

​
Build and broadcast a legacy transaction

// ethers.js v6
import { JsonRpcProvider, Transaction, getBytes, hashMessage } from "ethers";

const provider = new JsonRpcProvider("https://api.quantumapi.io/v1/rpc");

const txData = {
  to: "0x1865476914c85900110Ffc6B092436366E98Db55",
  nonce: await provider.getTransactionCount(myAddress),
  gasLimit: 21_000n,
  gasPrice: await provider.getGasPrice(),
  value: 1_000_000_000_000_000_000n,    // 1 QRC
  chainId: 20803n,
  type: 0
};

// Sign with your post-quantum signer (custom integration; see Signing transactions)
const signed = await myPostQuantumSigner.signTransaction(txData);

// Broadcast
const txHash = await provider.send("eth_sendRawTransaction", [signed]);
console.log(txHash);

​
Send via Qustody

If you use the Qustody platform, you do not build raw transactions yourself: 
curl -X POST "$BASE_URL/v1/transactions" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{
    "wallet_id": "...",
    "to_address": "0x1865...",
    "value": "1000000000000000000",
    "asset": "QRC"
  }'
Qustody handles nonce assignment, fee estimation, signing orchestration, and broadcasting. Your application listens for transaction.broadcast and transaction.confirmed webhooks.

​
Fee estimation

Quantum Chain follows EIP-1559. Use:
RPC methodReturns
eth_gasPriceSuggested legacy gas price
eth_maxPriorityFeePerGasSuggested tip for EIP-1559
eth_feeHistoryRecent base fees and priority tips
eth_estimateGasGas units for a given call
curl -s -X POST $RPC -H 'Content-Type: application/json' --data '{
  "jsonrpc":"2.0","method":"eth_feeHistory","id":1,
  "params":["0x10","latest",[25,50,75]]
}'

​
Nonce management

The nonce is the count of transactions previously sent from the same address. Two rules:
  1. Nonces must be sequential. Skipping a nonce parks all later transactions in the queued pool until the gap is filled.
  2. Nonces from the latest mined block are returned by eth_getTransactionCount(addr, "latest"). To include pending transactions, use "pending".
If you submit transactions from multiple processes, coordinate nonces in a shared store, or route everything through Qustody (which serializes nonces per wallet).

​
Replacing or cancelling a stuck transaction

To replace a transaction that is stuck in the mempool:
  1. Submit a new transaction with the same nonce and a higher gasPrice (or maxFeePerGas and maxPriorityFeePerGas for EIP-1559).
  2. Both transactions race; the higher-fee one is mined.
To cancel, replace it with a self-transfer of zero value at a higher fee. Through Qustody, use POST /v1/transactions/{id}/cancel while the transaction is still in SUBMITTED, PENDING_AUTHORIZATION, APPROVED, or PENDING_SIGNATURE. After it has been broadcast, you must do a fee-bump replacement on chain.

​
Confirmation

# Get the receipt (null until mined)
curl -s -X POST $RPC -H 'Content-Type: application/json' --data '{
  "jsonrpc":"2.0","method":"eth_getTransactionReceipt","id":1,
  "params":["0x..."]
}'
A transaction is confirmed when its block is followed by enough additional blocks that a reorg is unlikely. Mainnet recommendations:
Use caseConfirmations
Light dApp UX1
Default6
High-value institutional12 (Qustody default)
Exchange deposits30+

​
Where to go next